added bcp14ise version

The RFC independent submission stream uses a different BCP14 text.
Use it via "bcp14ise" tag.
There is clearly a bunch of things that should be refactored into common place.
Simplest: just collect the text to be inserted into one place.
More complex, change the if/then structure, and process both boilerplates into a single if statement.

This isn't different wording, but a sentence added at the top?

So I would expect you to write
Although this document is not an IETF Standards Track publication it
adopts the conventions for normative language to provide clarity of
instructions to the implementer.
{::boilerplate bcp14}

(This also fixes the missing "NOT RECOMMENDED".  Didn't think I would meet that ever again :-)

okay.


Changing base font size DOES affect grid breakpoints

I added this issue to the foundation-sites-6 repository but then the official version 6 was released. I tested this bug with the latest release and it is still a problem.
The documentation's indicates that, "if you want your base font size to be different and not have it affect the grid breakpoints, set $rem-base to $global-font-size and make sure $global-font-size is a pixel value" (http://foundation.zurb.com/sites-6-docs/global-styles.html#font-sizing). I've done that but it actually does affect the grid sizing.
As you can see from the attached screenshots, I have set $global-font-size to 22px; and $rem-base to $global-font-size. In the attached browser screenshot, you can see that the "small" breakpoint is being applied before hitting the 550px point (the point I defined in my breakpoint variables, also attached).

If I remenber, In version 5 I solved this kind of problems in this way:
I defined a function that converts px values to %:
@function convert-to-percent($value, $base-value: $rem-base){
  $value: strip-unit($value) / strip-unit($base-value) * 100%;
    @if ($value == 0%) { $value: 0; }
    @return $value;
}
// $rem-base: 16px

then on _global.scss:
html{
  font-size:100%
}
body{
  font-size: convert-to-percent($base-font-size);
}

I will try if the same approach works for FF6

Foundation team: Any update on this?
@erredeco's suggestion made me realize that changing $global-font-size to a bigger or smaller percentage kind of works without messing up the media query breakpoints. However, since both <html> and `' are given the same value, it takes a percentage of the percentage, making it bigger or smaller than intended.
As I mentioned when opening this issue, the Foundation documentation gives different instructions on setting the global font size.
What is the correct Foundation way to change the base font size?

Same problem here, any news? It's a basic function, please fix it

For my understanding it's just a bug in the breakpoint calculation.
If you change the global font-size, the base font-size for the html-tag is set:
html {
  font-size: 12px;
}

Therefore all em/rem values for child elements of  are based on 12px... so far so good. To get the calulation of all the widths of the foundation grid working, the $rem-base must be set to 12px too (default is 16px).
$rem-base: 12px;

The $rem-base is used for the function rem-calc which converts pixel values to the rem unit. This function is widely used in foundation sites... also in the breakpoint calculation.
But media queries em values are not based on the base font-size defined in the :root or html element (http://blog.w3conversions.com/2015/03/all-your-base-are-belong-to-us-—-or-what-base-size-do-em-based-media-queries-use/). So foundation does calculate the media queries on the defined $rem-base, but should calculate them with a base of 16px.
Long answer short: change the -zf-bp-to-em function in the _unit.scss and set the base value for the calculation to 16px.
// Converts a unitless, pixel, or rem value to em, for use in breakpoints.
@function -zf-bp-to-em($value) {
  // Pixel and unitless values are converted to rems
  @if unit($value) == 'px' or unitless($value) {
    // conversion base must be 16, cause for breakpoints it's always 16
    $value: rem-calc($value,16px);
  }

  // Then the value is converted to ems
  @return strip-unit($value) * 1em;
}

My problem seems to be different.
The problem seems to be that the file scss/util/_unit.scss does not import settings and rem base is always set to 16px because of the line 14 containing $rem-base: 16px !default;

ok, I fixed my problem just by moving
$global-font-size: 20px;
$rem-base: $global-font-size;
before
@import 'util/util';
in my settings.scss file
I hope it will help

Alright, to summarize, here are the changes that likely need to happen:

$rem-base should borrow from $global-font-size, so the values are consistent.

Does that mean $rem-base should be a hard-coded value, and not user customizable?
Either way, we'd also need a fallback if $global-font-size equals 100%. Like, if it's 100%, make the value 16px; if not, use the value as-is.

If we fix how rems/ems are calculated in this way, that means the "real pixel value" of the row width, breakpoint widths, etc. should always be the same regardless of the base font size, right?

@gakimball Another option is to abandon "real pixel values" for breakpoints altogether. Since F6 targets good breakpoints for layouts—instead of for specific devices1—why not further advocate for device-agnostic design and set $breakpoints as rems in _settings.scss?
If a project needs a breakpoint that targets a particular pixel width, do the math.
x = [target breakpoint in px] / [base font size]

1 A good motto: "There is no device."

@gakimball IMO - In answer to your last question, yes, the "real pixel value" of the row width and breakpoint widths should always be the same regardless of the base font size. I'm not sure how to accomplish that, you obviously have a better grasp of it than I do.

In my opinion there are two perspectives on the problem: short-term and long-term.
Short-term perspective: Fix the calculation as stated above. You just released F6 and docs talk about pixel-based breakpoints. I think it's not an option for F6 to abandon the pixel/em-based breakpoints right now.
Long-term perspective: I think it's a good idea to make the breakpoints purely em-based (without calculation from pixel value) but not for technical reasons but for educational ones. With pureley em-based values you force frontend developers to understand the whole em/pixel/device matter in order to get a proper site working. ;-)

@jensengelmann :clap: Yas.

Opened a pull request that attempts to fix these issues: #7580

Merged #7580 which addresses this. It'll ship in 6.1 next week.
When you upgrade, you do these things:

Remove $rem-base from your settings file, because it's not needed anymore.
Move $base-font-size above $global-width, which uses rem-calc(). This will prevent the grid width from changing if the base font size changes from 16px.

Thanks for this update. I'm wondering, though, with this in place, what is the recommended way to establish responsive font sizing? Meaning, for small screens it gets the $global-font-size of 100%, but how do I make it so that medium, large, xlarge, etc. screens get larger font sizing?

Would a simple custom rule like this break anything?
body {
  @include breakpoint(medium) { font-size: 120%; }
}

@andycochran - that actually wouldn't work because it's on the body tag and REMs would go to the 100% on the HTML tag. And you can't put that on the HTML tag because then it messes up rem-calc again.

@designerdean Hmm. body { font-size: 120%; } will resize paragraphs, lists, blockquotes, pre/code, etc—all the text sized at inherit or  1em (not rem). Explicitly sized elements like headings and buttons already have methods for sizing at specific breakpoints. I suppose form elements are still a problem tho, since they're rem-sized. It'd be a heavy lift, but you could use @mixin form-element {} at particular breakpoints.

@andycochran I suppose I could do that. I've just found it takes a lot more CSS to update the responsive font sizes as opposed to changing the global font size.

@designerdean I hear ya. Responsive font sizing requires a lot of code. And it's probably not an edge case. Tho I'm wondering if it's a feature worth going against Foundation 6's mission to be simpler/leaner.
The issue might come down to using rem for font-size. If Foundation used em for font-size, a solution like I mention above could be much simpler.
Of course, the downside to using em for font-size is the cascade (e.g. nested lists compounding their size). But that could be avoided by explicitly setting all nest-able text elements to 1em and establishing a best practice that responsive font sizing be done via containing elements, not directly on text elements. A typography helper class like .medium-text-size-large (for large text on medium-up) could be put on anything—the body, a div, instead of <p class="lead">—especially if there's a class like .medium-text-size-normal to reset nested elements.
I'm sure Zurb folks could tell us more on the reasoning behind the decision to use rem for fonts. (And also the decision to use responsive sizes for h1-h6, but not other elements.)

@andycochran I left a comment in another issue about how we can look into auditing our use of font sizes.
As for the responsive sizing, it's mostly a case where it's easiest to set up on headings. There's six of them, and they're all related to each other, so it's easy to set up a simple modular scale to size them all with. From small- to medium-sized screens, we widen the scales.
We could have a scaling system set up for every component that has an alternate font size, but it adds a lot of extra overhead to the codebase, and might be difficult to understand for some developers.

You could say that h1-h6 sizes aren't just related to each other, but all component font sizes are related—consider how closely an <h6> and <p> are typically sized. And a scaling system for every component would be unnecessary with em.

em works if you're uniformly scaling a design up or down, but not if you're changing the scale itself.
For example, this is a 3:4 scale (perfect fourth), in em values:
1 -> 1.5 -> 2.25 -> 3.375 -> 5.063

This is a 1:1.618 scale (golden section):
1 -> 1.618 -> 2.618 -> 4.236 -> 6.854

True. However, with rem, you still have to change every element in order to use a different scale (just as with em). And with rem, you don't have the ability to uniformly resize everything. So I don't see how scale change is a drawback for em.


broken links

Hello Team, these links are broken

Display options
Timeline component name
Records shown on page
Record types shown
Advanced
Record settings
Activities
Notes
Posts
How to create and add custom activities

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 680e01fe-96e2-f539-be10-c8518942d090
Version Independent ID: 44a23653-1f66-f638-ec5c-498f4b877bfb
Content: Configure Timeline
Content Source: ce/customer-service/customer-service-hub-user-guide-timeline-admin.md
Service: dynamics-365-customerservice
GitHub Login: @Lerobbin
Microsoft Alias: lerobbin

@anapereiCRMSE,
Thank you for reporting the broken links. They have been corrected and work fine now. Kindly let know if this issue can be closed if you have no other questions.
Best regards


Remove config update from subscription filter

Fixes #10438
Not exactly sure why this has just recently started appearing - my best initial guess though is that the Tree used to display the Azure accounts was updated in a recent VS Code merge to cause these to be surfaced. This code has always been broken as far as I can tell from its original implementation (we never were setting the config) and the error itself is also nothing new.
We might want to relook at how we're storing this since currently it's tied to the workspace - but this fix at least gets rid of the error and isn't going to change any existing behavior.

Coverage increased (+0.01%) to 33.975% when pulling e9af5cd817878ff9dbf9564214c2139d126999e0 on chgagnon/fixSubFilterError into 452bd6a0cb3336cb5b4e05cd5d6f13a3ba47719c on master.


Run instruction profiling pass at the start of the pipeline for the legacy pass manager

This is already fixed for the new pass manager, add a test case and apply the fix to the legacy pass manager too (cherry-pick of #38197). This prevents LLVM from optimizing out a profiler increment before lowering it, ensuring that we still emit name data for the coverage mapping, even if the increment itself gets optimized out.
This doesn't help in cases where the SIL optimizer optimizes out a profiler increment, but in that case we decline to emit the coverage mapping, so the result is lost coverage instead of a malformed mapping. I'm tracking fixing that in rdar://99813754.
rdar://77217762

@swift-ci please test

@swift-ci please test

@swift-ci please test macOS

@swift-ci please test


Smartcard logon rdp

Added /smartcard-logon:rdp option.
cf. https://github.com/informatimago/FreeRDP/wiki/smartcard-logon (it will be copied to FreeRDP/FreeRDP wiki once the merge is completed).
Basically; sets the autologin flag which along the smartcard redirection allows MS-Windows to use Smartcard Logon.
This patch only works with RDP negotiation.
The /smartcard option can be given several times and allows to select the smartcard readers that are redirected (some card or smartcard readers can interfere with the Smartcard Logon process.

@informatimago sorry for the late reply.
Could you clean up this pull a bit?

Introducing another layer of function abstractions does not seem like a really good idea
What are you trying to achieve with the filter in smartcard?

@akallabeth
layer of function abstractions
I'm not sure what you're refering to with "layer of function
abstractions", but if it's the str.c module, this let us avoid
duplicating code just because of WCHAR vs. char.  There is a lot of code duplication
(and worse, alternative that are implemented only in *A or *W but not both for no
apparent reason).  This all could be avoided by the systematic use of such a string
abstration.
Actually, it should probably be generalized even more, and augmented
to deal with the problem of the various string list formats (arrays of
strings, arrays of pointers to strings, msz, WLinkedList of strings,
etc).  All those different representations for the same thing lead to
a lot of duplicated code, and the associated risk of bugs.
One clear improvement that would have to be made, is to generalize
wrappers for strings, so that functions such as
LinkedList_StringHasSubstring could take as arguments strings in
different formats, and process them generically, instead of hardwiring
a specific format for each argument.  We can see the same problem in
some of the sspi API where some functions are actually mixed, taking
both *W or *A strings.
Note that the alternative of having two copies of the same functions,
one using char (or BYTE), and another WCHAR wouldn't be a problem to
write (we could generate both version from the same emacs lisp macro).
But it would be a maintainance headache, since most people aren't able
to deal with code generating code (otherwise you'd write it in lisp,
not in C ;-)).  I don't think this is a better solution.
The purpose of the smartcard filter is to deal with the following problem we have:

we are using IAS-ECC Smartcard to perform the smartcard logon,

at the same time, we are using a token that is identified as a
smartcard too, but it doesn't contain IAS-ECC files (this token is a
pre-requisite in our use case, since it's used to establish an IPsec
tunnel).

The problem is that when Windows sees this token smartcard, with the wrong files,
it rejects the smartcard logon, and switches to the login dialog.
Also, even without this bug, it is not necessary and it is preferable to avoid
redirect this token to the remote Windows.
So the filter feature allows the user to select what Smartcard will be redirected.
See more details at: https://github.com/informatimago/FreeRDP/wiki/smartcard-logon

@akallabeth
For example, to implement the compare function, we could write:
#define GENERATE_CONTAINS(T, TCHAR)                                     \
    BOOL contains ## T (TCHAR * string, char * substring)               \
    {                                                                   \
        int wlen = strlen ## T(string);                                 \
        int slen = strlen(substring);                                   \
        int end = wlen - slen;                                          \
        int i = 0;                                                      \
        for (i = 0; i < end; i ++ )                                     \
        {                                                               \
            if (ncompare ## T(string + i, substring, slen) == 0)        \
            {                                                           \
                return TRUE;                                            \
            }                                                           \
        }                                                               \
        return FALSE;                                                   \
    }

GENERATE_CONTAINS(A, char)
GENERATE_CONTAINS(W, WCHAR)

BOOL contains (int widechar, BYTE * string, char * substring)
{
    if (widechar)
    {
        return containsW((WCHAR*)string,substring);
    }
    else
    {
        return containsA((char*)string,substring);
    }
}

So granted, containsA and containsW would be more efficient than a contain that uses the funs, but do we really need to exchange the few cycles spared, against the additionnal maintainance work represented by the duplicated code in the C sources or the C macro complexity?   And this doesn't remove the need for a dispatching contains function anyways.

@informatimago yes, but it will needlessly break API stuff (we already struggle to keep it somewhat stable)

@akallabeth Please, tell me how you would prefer me to write it.  I understand that you want to avoid the use of the funs structure with the low level alternative functions for char or WCHAR.  Is the use of macros to generate alternate *A and *W functions the prefered way?

@informatimago Best avoid adding these functions. You have either WCHAR or char you're working with. Conversion functions are already there ConvertFromUnicode as well as comparison functions.

When I pull this repo and attempt to compile the merging branch I get the following errors...
sudo xargs rm < install_manifest.txt > /dev/null; cmake -GNinja -DCHANNEL_URBDRC=ON -DWITH_DSP_FFMPEG=ON -DWITH_CUPS=ON -DWITH_PULSE=ON . | grep smartcard; sudo cmake --build . --target install | grep smartcard;
An error occurred while redirecting file 'install_manifest.txt'
open: No such file or directory
FREERDP_VERSION=2.0.0-dev3
-- Adding device channel client "smartcard": Smart Card Virtual Channel Extension
[1/51] Building C object channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o
FAILED: channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o
/usr/bin/cc -DFREERDP_EXPORTS -DHAVE_CONFIG_H -DNDEBUG -DWINPR_EXPORTS -DWITH_OPENSSL -D_FILE_OFFSET_BITS=64 -I. -Iinclude -Iwinpr/include -Irdtk/include -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -O3 -DNDEBUG -fPIC -MD -MT channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o -MF channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o.d -o channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o   -c channels/smartcard/client/str.c
channels/smartcard/client/str.c: In function ‘towide’:
channels/smartcard/client/str.c:35:31: warning: pointer targets in passing argument 3 of ‘ConvertToUnicode’ differ in signedness [-Wpointer-sign]
In file included from channels/smartcard/client/str.c:24:0:
channels/smartcard/client/str.c:35:2: error: too many arguments to function ‘ConvertToUnicode’
In file included from channels/smartcard/client/str.c:24:0:
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:51:5: error: conflicting types for ‘compare’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:82:5: note: previous declaration of ‘compare’ was here
channels/smartcard/client/str.c: In function ‘compare’:
channels/smartcard/client/str.c:58:27: warning: passing argument 1 of ‘compareW’ from incompatible pointer type [-Wincompatible-pointer-types]
channels/smartcard/client/str.c:46:5: note: expected ‘BYTE * {aka unsigned char *}’ but argument is of type ‘WCHAR * {aka short unsigned int *}’
channels/smartcard/client/str.c:58:44: warning: passing argument 2 of ‘compareW’ from incompatible pointer type [-Wincompatible-pointer-types]
channels/smartcard/client/str.c:46:5: note: expected ‘BYTE * {aka unsigned char *}’ but argument is of type ‘WCHAR * {aka short unsigned int *}’
channels/smartcard/client/str.c: In function ‘ncompareW’:
channels/smartcard/client/str.c:80:42: error: expected ‘)’ before ‘;’ token
channels/smartcard/client/str.c:80:17: warning: passing argument 1 of ‘wcsncmp’ from incompatible pointer type [-Wincompatible-pointer-types]
from channels/smartcard/client/str.c:24:
channels/smartcard/client/str.c:80:25: warning: passing argument 2 of ‘wcsncmp’ from incompatible pointer type [-Wincompatible-pointer-types]
from channels/smartcard/client/str.c:24:
channels/smartcard/client/str.c:81:1: error: expected ‘;’ before ‘}’ token
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:83:5: error: conflicting types for ‘ncompare’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:99:5: note: previous declaration of ‘ncompare’ was here
channels/smartcard/client/str.c: In function ‘containsA’:
channels/smartcard/client/str.c:107:13: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c:107:13: note: each undeclared identifier is reported only once for each function it appears in
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:123:6: error: conflicting types for ‘contains’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:126:6: note: previous declaration of ‘contains’ was here
channels/smartcard/client/str.c: In function ‘contains’:
channels/smartcard/client/str.c:125:13: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:142:6: error: conflicting types for ‘ncopy’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:111:6: note: previous declaration of ‘ncopy’ was here
channels/smartcard/client/str.c: In function ‘ncopy’:
channels/smartcard/client/str.c:148:3: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:152:6: error: conflicting types for ‘LinkedList_StringHasSubstring’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:143:6: note: previous declaration of ‘LinkedList_StringHasSubstring’ was here
channels/smartcard/client/str.c: In function ‘LinkedList_StringHasSubstring’:
channels/smartcard/client/str.c:158:16: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszFilterStrings’:
channels/smartcard/client/str.c:169:7: error: ‘widechar’ redeclared as different kind of symbol
channels/smartcard/client/str.c:167:28: note: previous definition of ‘widechar’ was here
channels/smartcard/client/str.c:169:18: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
channels/smartcard/client/str.c:173:9: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszStringsPrint’:
channels/smartcard/client/str.c:221:7: error: ‘widechar’ redeclared as different kind of symbol
channels/smartcard/client/str.c:219:41: note: previous definition of ‘widechar’ was here
channels/smartcard/client/str.c:221:18: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
channels/smartcard/client/str.c:228:21: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszStringsLog’:
channels/smartcard/client/str.c:236:7: error: ‘widechar’ redeclared as different kind of symbol
channels/smartcard/client/str.c:234:45: note: previous definition of ‘widechar’ was here
channels/smartcard/client/str.c:236:18: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
channels/smartcard/client/str.c:249:21: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszSize’:
channels/smartcard/client/str.c:263:11: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c:267:1: warning: control reaches end of non-void function [-Wreturn-type]

When I attempt to compile this branch the following errors occur...
gofish543@Pavilion-gofish543 ~/FreeRDPSmartCard>
sudo xargs rm < install_manifest.txt; cmake -GNinja -DCHANNEL_URBDRC=ON -DWITH_DSP_FFMPEG=ON -DWITH_CUPS=ON -DWITH_PULSE=ON . | grep smartcard; sudo cmake --build . --target install | grep smartcard;
An error occurred while redirecting file 'install_manifest.txt'
open: No such file or directory
FREERDP_VERSION=2.0.0-dev3
-- Adding device channel client "smartcard": Smart Card Virtual Channel Extension
[5/46] Building C object channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o
FAILED: channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o
/usr/bin/cc -DFREERDP_EXPORTS -DHAVE_CONFIG_H -DNDEBUG -DWINPR_EXPORTS -DWITH_OPENSSL -D_FILE_OFFSET_BITS=64 -I. -Iinclude -Iwinpr/include -Irdtk/include -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -O3 -DNDEBUG -fPIC -MD -MT channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o -MF channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o.d -o channels/smartcard/client/CMakeFiles/smartcard-client.dir/str.c.o   -c channels/smartcard/client/str.c
channels/smartcard/client/str.c: In function ‘towide’:
channels/smartcard/client/str.c:35:31: warning: pointer targets in passing argument 3 of ‘ConvertToUnicode’ differ in signedness [-Wpointer-sign]
In file included from channels/smartcard/client/str.c:24:0:
channels/smartcard/client/str.c:35:2: error: too many arguments to function ‘ConvertToUnicode’
In file included from channels/smartcard/client/str.c:24:0:
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:51:5: error: conflicting types for ‘compare’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:82:5: note: previous declaration of ‘compare’ was here
channels/smartcard/client/str.c: In function ‘compare’:
channels/smartcard/client/str.c:58:27: warning: passing argument 1 of ‘compareW’ from incompatible pointer type [-Wincompatible-pointer-types]
channels/smartcard/client/str.c:46:5: note: expected ‘BYTE * {aka unsigned char *}’ but argument is of type ‘WCHAR * {aka short unsigned int *}’
channels/smartcard/client/str.c:58:44: warning: passing argument 2 of ‘compareW’ from incompatible pointer type [-Wincompatible-pointer-types]
channels/smartcard/client/str.c:46:5: note: expected ‘BYTE * {aka unsigned char *}’ but argument is of type ‘WCHAR * {aka short unsigned int *}’
channels/smartcard/client/str.c: In function ‘ncompareW’:
channels/smartcard/client/str.c:80:42: error: expected ‘)’ before ‘;’ token
channels/smartcard/client/str.c:80:17: warning: passing argument 1 of ‘wcsncmp’ from incompatible pointer type [-Wincompatible-pointer-types]
from channels/smartcard/client/str.c:24:
channels/smartcard/client/str.c:80:25: warning: passing argument 2 of ‘wcsncmp’ from incompatible pointer type [-Wincompatible-pointer-types]
from channels/smartcard/client/str.c:24:
channels/smartcard/client/str.c:81:1: error: expected ‘;’ before ‘}’ token
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:83:5: error: conflicting types for ‘ncompare’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:99:5: note: previous declaration of ‘ncompare’ was here
channels/smartcard/client/str.c: In function ‘containsA’:
channels/smartcard/client/str.c:107:13: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c:107:13: note: each undeclared identifier is reported only once for each function it appears in
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:123:6: error: conflicting types for ‘contains’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:126:6: note: previous declaration of ‘contains’ was here
channels/smartcard/client/str.c: In function ‘contains’:
channels/smartcard/client/str.c:125:13: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:142:6: error: conflicting types for ‘ncopy’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:111:6: note: previous declaration of ‘ncopy’ was here
channels/smartcard/client/str.c: In function ‘ncopy’:
channels/smartcard/client/str.c:148:3: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: At top level:
channels/smartcard/client/str.c:152:6: error: conflicting types for ‘LinkedList_StringHasSubstring’
In file included from channels/smartcard/client/str.c:28:0:
channels/smartcard/client/str.h:143:6: note: previous declaration of ‘LinkedList_StringHasSubstring’ was here
channels/smartcard/client/str.c: In function ‘LinkedList_StringHasSubstring’:
channels/smartcard/client/str.c:158:16: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszFilterStrings’:
channels/smartcard/client/str.c:169:7: error: ‘widechar’ redeclared as different kind of symbol
channels/smartcard/client/str.c:167:28: note: previous definition of ‘widechar’ was here
channels/smartcard/client/str.c:169:18: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
channels/smartcard/client/str.c:173:9: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszStringsPrint’:
channels/smartcard/client/str.c:221:7: error: ‘widechar’ redeclared as different kind of symbol
channels/smartcard/client/str.c:219:41: note: previous definition of ‘widechar’ was here
channels/smartcard/client/str.c:221:18: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
channels/smartcard/client/str.c:228:21: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszStringsLog’:
channels/smartcard/client/str.c:236:7: error: ‘widechar’ redeclared as different kind of symbol
channels/smartcard/client/str.c:234:45: note: previous definition of ‘widechar’ was here
channels/smartcard/client/str.c:236:18: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
channels/smartcard/client/str.c:249:21: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c: In function ‘mszSize’:
channels/smartcard/client/str.c:263:11: error: ‘funs’ undeclared (first use in this function); did you mean ‘puts’?
channels/smartcard/client/str.c:267:1: warning: control reaches end of non-void function [-Wreturn-type]
gofish543@Pavilion-gofish543 ~/FreeRDPSmartCard>

What is the status of this pull request?

@gofish543 waiting for rebase/cleanup

On 21 Aug 2018, at 09:41, akallabeth<EMAIL_ADDRESS>wrote:
@gofish543 https://github.com/gofish543 waiting for rebase/cleanup

Cleanup done; I’m starting the rebase.
--
Pascal J. Bourguignon

@informatimago Would drop the str.c stuff, it is a lot of code that is not actually used and duplicates existing functions.

@akallabeth
mszFilterStrings calls:

ncopy
LinkedList_StringHasSubstring calls:

LinkedList_Enumerator_Reset
LinkedList_Enumerator_MoveNext
LinkedList_Enumerator_Current
contains calls:

ncompare calls:

towide

mszFilterStrings is an ESSENTIAL function to implement the feature in smartcard_operations.c that will allow us to use smartcard logon with MS-Window, preventing the forward of non-smartcard tokens that prevent MS-Windows to perform the login successfull.  Without it, the smartcard-logon-rdp has no point in being merged.
mszSize is used in TestStr.c
mszStringsLog is used in smartcard_operations.c
compare and mszStringsPrint are not currently used.  I will remove them as requested.

@informatimago LinkedList stuff can be replaced with the list functions already supplied by WinPR. No need to reimplement that.

@akallabeth I agree with you that it's a little silly to have half a dozen different formats for lists of strings.  But it's not me who decided to write this program in C instead of Common Lisp. Now, of course, I could convert msz lists into LinkedLists and enumerate the strings in the LinkedList, but for that I would have to enumerate the msz list already!  And it wouldn't be very efficient, since we don't have a garbage collector, we'd have to free all the duplicated strings and the LinkedList after the enumeration.

Rebased in  Smartcard logon rdp 3 #4823


Breakpoint system needs a serious overhaul

The breakpoint system in Dart needs a serious audit and overhaul. Breakpoints are close to unusable right now.
Among the (many) issues I run into, every time I am trying to debug code:

When you click in the margin of a line in VS Code to set a breakpoint, more often than actually setting a breakpoint on the line, one of the following happens at random (and clicking in the margin of the same line multiple times may do all of these in some random order):

A breakpoint is set on some other line, above or below where you click. Sometimes that line doesn't even have code on it, it is a comment (the first link below shows this).
No breakpoint is set at all.
A breakpoint is listed in the breakpoint dialog at bottom left, but no breakpoint dot is shown on the program. (May be VS Code specific).
Breakpoints are often unconfirmed (gray open circle) rather than confirmed (red dot). The debugger often doesn't even stop on unconfirmed breakpoints.
Adding a breakpoint to one line may randomly remove a breakpoint on another line, even several lines away from the line you clicked in the margin of. Sometimes adding one breakpoint will even remove two nearby breakpoints.

Breakpoints either cannot be set at all in lambda functions, or if they are set, they remain unconfirmed, and the debugger won't stop on them.
Clicking the hot reload button in VS Code often causes breakpoints to jump to different lines, or even disappear.

Here's a video of some of the behavior: https://github.com/Dart-Code/Dart-Code/issues/4811
Related, filed by @DanTup : https://github.com/dart-lang/sdk/issues/54100 -- this was closed because it was supposed to have been fixed by https://github.com/dart-lang/sdk/commit/ec30968b54fa33aefa3f1a33ea038e63ec8cfbb3 by @derekxu16, but this did not fix the issue at all.
Also related: https://github.com/Dart-Code/Dart-Code/issues/4915 .

@lukehutch are you able to capture a video and log using an SDK that includes ec30968b54fa33aefa3f1a33ea038e63ec8cfbb3 with specific code and steps to reproduce?

@DanTup I was only assuming ec30968 is in my latest build, because it was merged in November, and I'm on the pre-release channel of dart-code, and the beta channel of Dart/Flutter. However, how do I check which builds this change made it into?

If you run flutter --version the output should include your Dart version. The commit above appears to be in 3.3.0-169.0.dev so if the version you have is newer than that, it should include this change. I would expect it to be in Flutter beta by now, although being on the beta channel doesn't necessarily mean you're on the latest beta if you haven't run flutter upgrade in a while.
If your current SDK does not include that fix, then I would try flutter upgrade to see if that gets it for you.
If your current SDK does already include this fix, then a new video/log/repro instructions would help. While it might seem exactly the same, lots of things have changed and a log file from before that fix will be less useful for debugging than one that includes it.
Thanks!

Tentatively triaging to VM. But let me know if this should be moved to VS Code or... vm_service_client or something...

//cc @bkonyi

We have an issue tracking this (Dart-Code/Dart-Code#4734) and an attempt at eagerly compiling functions to force resolve breakpoints in a draft CL somewhere (cc @derekxu16 for the current status).

My draft CL for that regresses breakpoint functionality in certain cases (see the failing test on https://dart-review.googlesource.com/c/sdk/+/338740). I can pick it back up later this week.

@lukehutch for us to take some action on this issue we would need the follwoing

version of Dart being used
source code of the code being debugged with steps that reproduce the problems.

This would help us reproduce the problems and fix the issues.

Hi all, sorry it took me a while to respond, I had to port my code to the main channel of flutter (there were a number of dependency issues).
It turns out I was not in fact using a version of the SDK that included the patch from November, that doesn't appear to have been ported to even the beta branch yet.
I switched to the main channel, so now I am using the following, which should include the November CL:

Flutter 3.21.0-16.0.pre.11 • channel main • https://github.com/flutter/flutter.git
Framework • revision 6807eacb33 (28 minutes ago) • 2024-03-27 18:31:44 -0400
Engine • revision 73c145c9ac
Tools • Dart 3.4.0 (build 3.4.0-279.0.dev) • DevTools 2.34.0-dev.12

Here are the issues that I ran into with this build:
(1) Setting a breakpoint on a const line doesn't seem to work, it seems to jump down to the first non-value statement:
https://github.com/dart-lang/sdk/assets/811305/8b1cdd22-e5eb-4a69-be52-638ad66a58bf
(2) But sometimes even non-const lines are skipped when you try to set a breakpoint, and something below the line gets set as the breakpoint instead (see Style2BottomNavBar here):
https://github.com/dart-lang/sdk/assets/811305/bb5a0756-973d-4634-aba1-5e0afc88bcd7
(3) Sometimes not a single line can have a breakpoint confirmed in an entire function, which is very unsettling. Also, sometimes breakpoints are confirmed and then immediately unconfirmed.
https://github.com/dart-lang/sdk/assets/811305/6316724b-8ddb-4974-89cf-696565b7bfd4
(Also when the debugger stops on an unconfirmed breakpoint, the breakpoint hollow dot disappears, but that is probably a Dart-Code issue)
Issues that do seem to be fixed now include:

The debugger does seem to now stop on unconfirmed breakpoints inside lambdas.
Existing breakpoints don't seem to jump around haphazardly anymore when new breakpoints are added nearby.
Other than the behavior listed in points (1) and (2) above, wherein a breakpoint may jump down a few lines, setting a breakpoint no longer causes a breakpoint to be set randomly above the line that was clicked on (before, clicking on a line could cause a breakpoint to be set or unset anywhere within a few lines' distance above or below the line that was clicked on).

@lukehutch thanks for providing the information.

Thanks for the detailed response @lukehutch! The videos are very helpful in understanding what you're experiencing.
For 1), I think this is working as intended since const expressions are evaluated at compile time, so there's no executable code to set a breakpoint on. The debugger tries to find the next closest valid source location for the breakpoint, which would be the next line with executable code.
For 3), this sounds like https://github.com/Dart-Code/Dart-Code/issues/4734. I'm assuming the breakpoints resolve as soon as the function executes for the first time? If so, this is definitely a Dart-Code UX issue, although it is technically the right behavior since grey breakpoints represent unresolved breakpoints as well as invalid breakpoints. Hopefully we'll be able to force functions to compile when breakpoints are set in them, which will result in valid breakpoints being resolved immediately.
As for 2), it looks like there may be some issues with setting breakpoints in closures (maybe single line closures in particular?). That's definitely worth investigating further.

For 1), I think this is working as intended since const expressions are evaluated at compile time, so there's no executable code to set a breakpoint on. The debugger tries to find the next closest valid source location for the breakpoint, which would be the next line with executable code.

OK, but I suggest not setting a breakpoint at all in this case. It is unnerving to click in the margin of a line, and have a breakpoint appear 8 lines below it. Please pop up a "Breakpoint cannot be set on constant expressions" tooltip error or something.

For 3), this sounds like Dart-Code/Dart-Code#4734. I'm assuming the breakpoints resolve as soon as the function executes for the first time?

No, in my case the breakpoints never resolve, even when the function is executed, or even when the debugger actually stops on an unresolved breakpoint! As I mentioned in my previous comment, what happens in this case is that the hollow circle indicator actually disappears (in VS Code) while the debugger is stopped on the breakpoint, but neither then nor later does it turn into a red dot.

grey breakpoints represent unresolved breakpoints as well as invalid breakpoints.

Related to my first point above, I really believe that if a breakpoint cannot be set, there should be no marker showing an invalid breakpoint. Also this is confusing if invalid breakpoints and valid-but-not-confirmed breakpoints are shown the same way.

Hopefully we'll be able to force functions to compile when breakpoints are set in them, which will result in valid breakpoints being resolved immediately.

I hope that does happen! I have never used a debugging system, in any IDE, for any language, that does not set (confirmed) breakpoints immediately wherever I ask it to set them, or that has such a thing as an unconfirmed breakpoint. It is a major usability problem for Dart, and you feel like you're constantly walking on eggshells when using the debugger, because you don't even know what the debugger is going to do with breakpoints.
There should only be one type of breakpoint: a confirmed breakpoint, set on the actual line that you clicked on, which the debugger is guaranteed to stop at when executing that function.

As for 2), it looks like there may be some issues with setting breakpoints in closures (maybe single line closures in particular?). That's definitely worth investigating further.

This may be related to another issue I have seen, which I alluded to: in the current main channel, sometimes I can't get the debugger to stop at all at breakpoints in closures, even though it lets me set an (unconfirmed) breakpoint.

I really believe that if a breakpoint cannot be set, there should be no marker showing an invalid breakpoint

Unfortunately we can't do this in VS Code - but I'm also not sure we should. The grey indicator specifically means "you've put a breakpoint here but it has not been resolved by the runtime". This could be either because it's an invalid location, or it just hasn't been resolved yet (or that it never will, for example you added it to a file that will never be loaded by the runtime).

I have never used a debugging system, in any IDE, for any language, that does not set (confirmed) breakpoints immediately wherever I ask it to set them, or that has such a thing as an unconfirmed breakpoint.

This concept is baked into VS Code and the debug adapter protocol, it's not something specific to Dart. You can add breakpoints before the program is running and so there's no way for them to be resolved. You may also add breakpoints to files of different types, or files that are just not referenced by your program and are therefore never loaded by the runtime. I've seen grey breakpoints (that ultimately turn red) in several languages in VS Code - although it usually happens pretty quick once the session starts.
I think many of the problems here are because the scripts aren't currently compiled up-front, so you see grey breakpoints a lot when they should generally be an exception (or temporary for the short period when you hit Debug and everything being up and running). I think if the work to pre-compile them was completed then some of this confusion would go away.

OK, but I suggest not setting a breakpoint at all in this case. It is unnerving to click in the margin of a line, and have a breakpoint appear 8 lines below it. Please pop up a "Breakpoint cannot be set on constant expressions" tooltip error or something.

I agree that a breakpoint moving 8 lines is odd. I wonder if breakpoints should only snap a maximum of a line or two. If there are no valid locations within that range, maybe they could just remain unresolved and never be hit (this means they would remain in the editor as grey, but I think that is the correct behaviour.. in the debug adapter protocol we can return a "reason" for an unverified breakpoint which VS Code might show in a tooltip). @bkonyi @derekxu16 what are your thoughts on this? If a breakpoint can't be resolved to a location within some small number of lines, consider that an error (something we can listen for in addition to BreakpointResolved events that we can use to mark the breakpoint as invalid).

How about modifying the code generator to produce additional code where necessary, so that a breakpoint can always be placed at a reasonable point in execution, wherever a breakpoint is set?
This would give rise to the possibility for Heisenbugs, because compiling with breakpoints set  would introduce some new code in some circumstances (e.g. so that the debugger would stop at an appropriate point in execution even on constant expressions), but I think it would be significantly better than the status quo.

This would give rise to the possibility for Heisenbugs, because compiling with breakpoints set would introduce some new code in some circumstances

Breakpoints can be set after code is already compiled so I don't think this would work (at least not consistently). But I'm also not sure pausing execution at a synthetic location like that would be a good experience either (for example if you stop on a const constructor call, it may be confusing for Step In to not work because that code was already evaluated earlier).
I'm also not sure anything this dramatic is required here - I think there are a number of things described above that could significantly improve the experience (the main one IMO being compiling scripts earlier when breakpoints are set so there aren't so many grey breakpoints).

I came across another issue. In the following video, the breakpoints initially start as unconfirmed, then they become confirmed once the third breakpoint is hit (in this case, newItems is empty). Then when I trigger a query that causes newItems to be non-empty, the debuger stops on the first breakpoint, but then never reaches the second or third breakpoint! It is impossible to stop in the catch or even the finally block in this case. There is no async code between the first and the second/third breakpoints. All three breakpoints are confirmed, and the debugger was even able to stop on the third breakpoint, but only if the for loop never executes because newItems is empty.
https://github.com/dart-lang/sdk/assets/811305/1bb7aee7-f6ac-477a-a561-fa9aa32aaf68

@lukehutch are you able to provide any code samples that trigger the issue to help debug? Are you testing this on stable of a version with the other fix discussed above?

I came across another issue. In the following video, the breakpoints initially start as unconfirmed, then they become confirmed once the third breakpoint is hit (in this case, newItems is empty). Then when I trigger a query that causes newItems to be non-empty, the debuger stops on the first breakpoint, but then never reaches the second or third breakpoint! It is impossible to stop in the catch or even the finally block in this case. There is no async code between the first and the second/third breakpoints. All three breakpoints are confirmed, and the debugger was even able to stop on the third breakpoint, but only if the for loop never executes because newItems is empty.

The behavior shown in the video is definitely unexpected, but I'm unable to reproduce on the main branch with the following example:
void foo() {
  try {
    print('foo'); // Breakpoint
  } catch(e) {
    print('bar'); // Breakpoint
  } finally {
    print('foobar'); // Breakpoint
  }
}

void main(List<String> arguments) {
  foo(); // Breakpoint
}

Either there's an issue on the revision you're using that's been fixed since or there's something with the particular structure of your code that's triggering this behavior. Can you try executing my code sample as part of your project to see if you can reproduce the same breakpoint behavior in your video?

I am having very similarly broken behavior when setting breakpoints
Let me know if I can help in any other way. This problem is very intermittent for me. Reloading VS Code fixes it for a while usually.
Here is a video recorder - I am trying to set a break point on line 35 - every time I click, it does something weird with my breakpoints.
https://github.com/Dart-Code/Dart-Code/assets/11194069/9ecf0e74-f97d-4a60-9a88-1b77bf82f354
Here is the log that I tried to get:
Dart-Code-Log-2024-03-02 13-09-35.txt

@jackmchristie, the log that you included indicates that you're on the stable channel of Flutter. @lukehutch mentioned above that on March 27, there were breakpoint fixes that had not yet made it to the beta channel of Flutter. Can you please try switching to the main channel of Flutter and check whether you still see the same problems?

I have been facing the exact same issue for about a year now.
The only thing I remember is that after upgrading Dart or VS Code version, this problem start to appear.

@jackmchristie The same as you and the author.
Btw, can I ask how you make this running panel here?

This is mine:

I just went and determined the first version of Flutter that includes the debugger fixes – it's 3.19.0. This version is on the stable channel, so if possible, can you flutter upgrade, ensure that you have a version >=3.19.0, and then try your examples again? Thanks!

@derekxu16 I'm on 3.87.20240402, so I should have the latest fix, and video I posted 3 weeks ago was on the same version.

Yes, I'm aware that there are still debugger bugs on versions of Flutter >=3.19.0. @jackmchristie said "Let me know if I can help in any other way", though. So I'm trying to see if he's able to provide a minimal reproducible example on a version >=3.19.0.

The latest version still has this problem, and it's really serious.

https://github.com/dart-lang/sdk/assets/37449310/fac5f866-0014-4b03-bbd9-bd7b628c9f77

That exactly shows the sorts of problems I have been having.
How could the line on which the breakpoint marker is set be chosen nondeterministically when a line is clicked? That would probably be a good place to start looking into the issue.

@Ssiswent @lukehutch are either of you able to provide a code sample that can be copy/pasted that reproduces this? And does it always happen (including on first run), or do things start going wrong after modifying code (and possibly hot reloading/hot restarting)?
I've tried a few times to reproduce these issues from videos without luck. If we can get steps to repro, it will be much easier to track down what's happening.

@DanTup I have at least a partial repro:
Do flutter create flutter_debugger_issue then open VS Code on that directory.
The generated code is, in part (removing comments):
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        backgroundColor: Theme.of(context).colorScheme.inversePrimary,
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            const Text(
              'You have pushed the button this many times:',
            ),
            Text(
              '$_counter',
              style: Theme.of(context).textTheme.headlineMedium,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: const Icon(Icons.add),
      ),
    );
  }

Wrap the body in a LayoutBuilder (to create a lambda boundary), and inline _incrementCounter (so that you now hav a lambda inside a lambda):
  @override
  Widget build(BuildContext context) {
    return LayoutBuilder(
      builder: (context, constraints) => Scaffold(
        appBar: AppBar(
          backgroundColor: Theme.of(context).colorScheme.inversePrimary,
          title: Text(widget.title),
        ),
        body: Center(
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: <Widget>[
              const Text(
                'You have pushed the button this many times:',
              ),
              Text(
                '$_counter',
                style: Theme.of(context).textTheme.headlineMedium,
              ),
            ],
          ),
        ),
        floatingActionButton: FloatingActionButton(
          onPressed: () {
            setState(() {
              _counter++;
            });
          },
          tooltip: 'Increment',
          child: const Icon(Icons.add),
        ),
      ),
    );
  }

This is the behavior I see:
https://github.com/dart-lang/sdk/assets/811305/fda6b6ee-47a6-4621-abed-83122833fd83
The main difference between this behavior and what I see on a much larger project is that with this smaller project, breakpoints are more likely to be confirmed (red), at least if I click in the LayoutBuilder lambda.
The breakpoints in the inner lambda, for onPressed, are not confirmed, and are not set on the right line.
If the above doesn't reproduce the issue for you, try a hot restart, then try again.

I'm on Flutter 3.22.0-0.3.pre, Dart 3.4.0-282.3.beta, code v1.88.1-1712771932.el8.x86_64, dart-code v3.87.20240423.
I didn't modify the code between running it and hot-reloading.

@lukehutch are you able to capture a full log (run Dart: Capture Debugging Logs before you start the app) and attach here (using the newly created test project, so it matches what I'm using)? Maybe from that I can better understand what's happening.

PS: your video doesn't play for me, for some reason...

Odd, works on my Windows PC and my MacBook. Basically I added breakpoints to the same lines as you, and they all remained on those lines, and then I triggered the ones in the callback by clicking the button in the app.

PPS: How are you getting a treeview superimposed in the left margin of the code?

That's the "Flutter UI Guidelines" - https://dartcode.org/releases/v3-1/#preview-flutter-ui-guides
It's still "preview" and not enabled by default because it's quite janky because of limited VS Code APIs (it's drawn as text with ascii characters) - see https://github.com/microsoft/vscode/issues/73780.

@DanTup OK, for some reason this is very hard to reproduce now (and I didn't change the code at all...)
I got a repro only one time out of about 20 or 30 attempts, and the issue showed up for only one one breakpoint:
At 1:14 in this video, I clicked on line 61, but the breakpoint was set on line 47:
https://github.com/dart-lang/sdk/assets/811305/07a00705-f851-4674-964c-74d7fb4200c6
Logs:
Dart-Code-Log-2024-03-02 01-19-19.txt

@lukehutch thank you for the video and log, this is very helpful. I believe I've tracked down at least one cause of these issues. Here's what I see:
00:48: Add a breakpoint to line 47
The VM adds this breakpoint and resolves it. The ID is "breakpoints/1":
[1:20:14] [General] <== [VM] {"jsonrpc":"2.0","result":{"type":"Breakpoint","fixedId":true,"id":"breakpoints/1","enabled":true,"breakpointNumber":1,"resolved":true,"location":{"type":"SourceLocation","script":{"type":"@Script","fixedId":true,"id":"libraries/@18279082/scripts/package%3Aflutter_debugger_issue%2Fmain.dart/18f2de00c3a","uri":"package:flutter_debugger_issue/main.dart","_kind":"kernel"},"tokenPos":1180,"line":47,"column":31}},"id":"13"}

01:04 Remove breakpoint from line 47
This cause DAP to remove the breakpoint "breakpoints/1" from the VM:
[1:20:22] [General] ==> [VM] {"jsonrpc":"2.0","id":"30","method":"removeBreakpoint","params":{"isolateId":"isolates/2872512907539435","breakpointId":"breakpoints/1"}}
[1:20:22] [General] <== [VM] {"jsonrpc":"2.0","method":"streamNotify","params":{"streamId":"Debug","event":{"type":"Event","kind":"BreakpointRemoved","isolateGroup":{"type":"@IsolateGroup","id":"isolateGroups/3867994198877240","name":"main.dart","number":"3867994198877240","isSystemIsolateGroup":false},"isolate":{"type":"@Isolate","id":"isolates/2872512907539435","name":"main","number":"2872512907539435","isSystemIsolate":false,"isolateGroupId":"isolateGroups/3867994198877240"},"timestamp":1714461621702,"breakpoint":{"type":"Breakpoint","fixedId":true,"id":"breakpoints/1","enabled":true,"breakpointNumber":1,"resolved":true,"location":{"type":"SourceLocation","script":{"type":"@Script","fixedId":true,"id":"libraries/@17279082/scripts/package%3Aflutter_debugger_issue%2Fmain.dart/18f2de03318","uri":"package:flutter_debugger_issue/main.dart"},"tokenPos":1180,"line":47,"column":31}}}}}
[1:20:22] [General] <== [VM] {"jsonrpc":"2.0","result":{"type":"Success"},"id":"30"}

01:15 Add a breakpoint to line 61
We send the breakpoint to the VM, and it assigns the ID "breakpoints/1":
[1:20:31] [DAP] ==> {"command":"setBreakpoints","arguments":{"source":{"adapterData":{"type":"@Script","id":"libraries/@17279082/scripts/package%3Aflutter_debugger_issue%2Fmain.dart/18f2de03318","fixedId":true,"uri":"package:flutter_debugger_issue/main.dart"},"name":"package:flutter_debugger_issue/main.dart","path":"/tmp/flutter_debugger_issue/lib/main.dart"},"lines":[61],"breakpoints":[{"line":61}],"sourceModified":false},"type":"request","seq":23}
[1:20:31] [General] ==> [VM] {"jsonrpc":"2.0","id":"36","method":"addBreakpointWithScriptUri","params":{"isolateId":"isolates/3553538615064143","scriptUri":"file:///tmp/flutter_debugger_issue/lib/main.dart","line":61}}
[1:20:31] [General] <== [VM] {"jsonrpc":"2.0","result":{"type":"Breakpoint","fixedId":true,"id":"breakpoints/1","enabled":true,"breakpointNumber":1,"resolved":false,"location":{"type":"UnresolvedSourceLocation","script":{"type":"@Script","fixedId":true,"id":"libraries/@17279082/scripts/package%3Aflutter_debugger_issue%2Fmain.dart/18f2de045ba","uri":"package:flutter_debugger_issue/main.dart","_kind":"kernel"},"line":61}},"id":"36"}
[1:20:31] [General] <== [VM] {"jsonrpc":"2.0","method":"streamNotify","params":{"streamId":"Debug","event":{"type":"Event","kind":"BreakpointAdded","isolateGroup":{"type":"@IsolateGroup","id":"isolateGroups/739322616014296","name":"main.dart","number":"739322616014296","isSystemIsolateGroup":false},"isolate":{"type":"@Isolate","id":"isolates/3553538615064143","name":"main","number":"3553538615064143","isSystemIsolate":false,"isolateGroupId":"isolateGroups/739322616014296"},"timestamp":1714461631053,"breakpoint":{"type":"Breakpoint","fixedId":true,"id":"breakpoints/1","enabled":true,"breakpointNumber":1,"resolved":false,"location":{"type":"UnresolvedSourceLocation","script":{"type":"@Script","fixedId":true,"id":"libraries/@17279082/scripts/package%3Aflutter_debugger_issue%2Fmain.dart/18f2de045ba","uri":"package:flutter_debugger_issue/main.dart"},"line":61}}}}}

In the debug adapter, we handle the VM reusing breakpoint IDs (because that can be normal if you add multiple breakpoints that resolve to the same location), but because we never cleared the state we kept when we removed the first breakpoint, it appears that we send back the stale information about the first breakpoint with that ID (on line 47):
[1:20:31] [DAP] <== {"seq":3979,"type":"response","body":{"breakpoints":[{"id":100004,"verified":false}]},"command":"setBreakpoints","request_seq":23,"success":true}
[1:20:31] [DAP] <== {"seq":3980,"type":"event","body":{"breakpoint":{"column":31,"id":100004,"line":47,"verified":true},"reason":"changed"},"event":"breakpoint"}

This is hopefully an easy fix - I'll try to get a repro in a test.
FYI @bkonyi @a-siva - this seems like a DAP bug that would cause breakpoints to show up in the wrong locations, so the VM resolving to different locations might not be the issue we thought it was. I'm curious if it's intended that breakpoint IDs are reused like this though? (I will fix on the assumption it is, but I think not reusing them would avoid some class of issues like this where an editor is caching data to try and handle things like BPs that have already been resolved by earlier requests without waiting for an event).

Here's a small repro. I think the breakpoint ID reuse only happens when it's a new isolate, so the hot restart is important - it causes the new breakpoint to reuse information about the first one.
Reproducing in Dart in the IDE might be tricky (because of the isolates), but probably can be done in a test by sending a breakpoint to just one isolate and removing it, then sending a different breakpoint to another.
import 'package:flutter/material.dart';

/// 1. Add a breakpoint on line 17
/// 2. Remove the breakpoint on line 17
/// 3. Hot Restart
/// 4. Add a breakpoint on line 20.

void main() {
  runApp(const MainApp());
}

class MainApp extends StatelessWidget {
  const MainApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const MaterialApp(
      home: Scaffold(
        body: Center(
          child: Text('Hello World!'),
        ),
      ),
    );
  }
}

https://github.com/dart-lang/sdk/assets/1078012/8c231ae6-a9e1-440e-97da-dfee153fc4c1

@bkonyi @a-siva

I'm curious if it's intended that breakpoint IDs are reused like this though?

Nevermind - with more testing, I have realised that breakpoint IDs are entirely isolate-specific. The reason they seemed to be the same across isolates was just because in my tests isolates were all created and given the same breakpoints at the same time. If I set breakpoints, spawn an isolate, then spawn more - I can see the new isolate is starting from 1 and the assumptions in DAP are all wrong.

@bkonyi @a-siva

I'm curious if it's intended that breakpoint IDs are reused like this though?

Nevermind - with more testing, I have realised that breakpoint IDs are entirely isolate-specific. The reason they seemed to be the same across isolates was just because in my tests isolates were all created and given the same breakpoints at the same time. If I set breakpoints, spawn an isolate, then spawn more - I can see the new isolate is starting from 1 and the assumptions in DAP are all wrong.

I can confirm that we don't reuse breakpoint IDs, but IDs are isolate specific and start from 1.

@bkonyi thanks - got a fix on the way. It also seems that maybe the VM isn't jumping breakpoints as much as we (I) thought - for example all of those on the const constructor lines here do not move, they just don't resolve:
https://github.com/dart-lang/sdk/assets/1078012/86ddd82d-f8b5-497e-be5b-2b40cb94006b
So it's possible that there's nothing to do there (cc @derekxu16 @aam). It would definitely be nice to improve the tooltip for those breakpoints (because I don't think it's obvious why you can't break there, especially if the const is a long way away in code), but I can review the VM responses and file a separate issue about that.

@DanTup thanks for the updates and follow up on this. If it turns out the issue is in DAP I would also suggest we don't implement the eager resolution of breakpoints and leave it the way it is.

@a-siva

If it turns out the issue is in DAP I would also suggest we don't implement the eager resolution of breakpoints and leave it the way it is.

I do still think there's a value in that, because right now you can't tell the difference between breakpoints in invalid locations (such as line 18, 19, 20 in my video above around 00:12) and those that just aren't resolved yet. However, I do think the bug I'm fixing is the bigger issue and things will feel much less broken with is fixed and it may be worth re-evaluating how things feel with that fixed.
Once the fix lands and gets to Flutter master (via a DDS release), it would be good to try and get some feedback from people above that have been hitting these issues.

@DanTup I hope that this does improve things, but I think you are exhibiting a different issue: the breakpoint jumps from line 20 to line 17 because the entire expression is const, and the only non-const part of it is the return.
The issues I have seen most reliably occur in lambdas.

We discussed the possibility of using tooltips to differentiate between these two categories of breakpoints, though. Do you think the UX of that solution is worse than that when breakpoints are eagerly resolved?

Yes, I think we should do that - but I don't think it solves the same issue. The problem eagerly compiling fixes is giving the feedback sooner. When the user first runs their app, ideally they would see all breakpoints turn red, or remain grey with a tooltip like "A breakpoint is not allowed at this location" (or maybe even "in a const expression"!). If we don't eagerly compile then all breakpoints are grey for a longer period and the user can't tell if that's because they're in invalid locations, or just that they haven't caused compilation of that function yet.
If I'm trying to debug something and I've added a breakpoint, I really want to know if that breakpoint was valid or not before I spend time interacting with my app to try and trigger the issue I'm debugging, because if the breakpoint turns out to be invalid, that time may be wasted.
@lukehutch

but I think you are exhibiting a different issue: the breakpoint jumps from line 20 to line 17 because the entire expression is const, and the only non-const part of it is the return.

I don't believe that's the case - I thought it was until I got your log above and repro'd. I had assumed the jump was the VM snapping, but it was the bug described above - we were using the wrong resolution info (from a breakpoint with the same ID in another isolate). For breakpoints on const expressions, they fail to resolve so they remain in the same place and will remain grey (this is always what's happened, the jumping breakpoints is just a "visual" issue in VS Code, because we told it the wrong thing).
That's not to say there aren't other issues - but the issue above is certainly confusing things and making it hard to tell what's happening (and it's the issue your repro was triggering).
Once we get this into Flutter master, it would be great to have you try to reproduce any other issue and capture a log without that bug getting in the way.

OK, I have had a truly weird situation come up, which may shed some light on this issue...
I set two breakpoints, one on setChannelViewNewMessageListener and one on unsetChannelViewNewMessageListener, and caused the code to hit one of the breakpoints:

The code view shows that the breakpoint that was stopped on was setChannelViewNewMessageListener in line 87, but the call stack view shows that the code is actually stopped on the breakpoint in unsetChannelViewNewMessageListener -- which is also showing as line 87 in the bubble at the end of the stack frame, even though that line number is not even in that function!
Furthermore, the parent stack frame, dispose, calls unsetChannelViewNewMessageListener, not setChannelViewNewMessageListener, so it is impossible to stop on line 87 given the call stack:

@DanTup following on from my previous comment, I believe that the compiled code getting out of sync with the source is playing a role here (maybe separately from the issue you are currently fixing), because flutter clean ; flutter compile apk on the commandline causes the breakpoints to subsequently behave much better in VS Code.

More evidence that the compiled code is getting out of sync with the source (there are some old stale files being left around that are not being correctly re-generated during an incremental build):

I plugged in a Pixel 7 Pro, hit F5 to launch the app, which incrementally rebuilt and then launched on the phone, and I got the above error. I then plugged in a Pixel 4, hit F5 again, and the above error was not triggered (so it's not a problem in the code -- also, there are no analyzer errors shown in VS Code for this app).
(This sort of thing keeps happening...)

I dug further into the stale code issue. My client, after a hot restart, was trying to call and endpoint that didn't even exist anymore -- in fact the endpoint name didn't even exist in my source anymore. Here are the files that contained the stale symbol:
$ grep addEmojiReaction . -r
grep: ./build/app/intermediates/stripped_native_libs/release/stripReleaseDebugSymbols/out/lib/armeabi-v7a/libapp.so: binary file matches
grep: ./build/app/intermediates/stripped_native_libs/release/stripReleaseDebugSymbols/out/lib/arm64-v8a/libapp.so: binary file matches
grep: ./build/app/intermediates/stripped_native_libs/release/stripReleaseDebugSymbols/out/lib/x86_64/libapp.so: binary file matches
grep: ./build/app/intermediates/flutter/debug/flutter_assets/kernel_blob.bin: binary file matches
grep: ./build/app/intermediates/flutter/release/armeabi-v7a/app.so: binary file matches
grep: ./build/app/intermediates/flutter/release/arm64-v8a/app.so: binary file matches
grep: ./build/app/intermediates/flutter/release/x86_64/app.so: binary file matches
grep: ./build/app/intermediates/assets/debug/mergeDebugAssets/flutter_assets/kernel_blob.bin: binary file matches
grep: ./build/app/intermediates/merged_native_libs/release/mergeReleaseNativeLibs/out/lib/armeabi-v7a/libapp.so: binary file matches
grep: ./build/app/intermediates/merged_native_libs/release/mergeReleaseNativeLibs/out/lib/arm64-v8a/libapp.so: binary file matches
grep: ./build/app/intermediates/merged_native_libs/release/mergeReleaseNativeLibs/out/lib/x86_64/libapp.so: binary file matches
grep: ./.dart_tool/flutter_build/954dc83fd2834ac9b92c685a1effff2e/armeabi-v7a/app.so: binary file matches
grep: ./.dart_tool/flutter_build/954dc83fd2834ac9b92c685a1effff2e/arm64-v8a/app.so: binary file matches
grep: ./.dart_tool/flutter_build/954dc83fd2834ac9b92c685a1effff2e/app.dill: binary file matches
grep: ./.dart_tool/flutter_build/954dc83fd2834ac9b92c685a1effff2e/program.dill: binary file matches
grep: ./.dart_tool/flutter_build/954dc83fd2834ac9b92c685a1effff2e/x86_64/app.so: binary file matches
grep: ./.dart_tool/flutter_build/015933dbf8d31ced73a7771dac98a983/app.dill: binary file matches

When the running code doesn't match what's in the editor, you'll definitely see odd behaviour. Unfortunately right now VS Code / DAP don't have a good way to handle this (besides unconditionally downloading sources from the VM, but that results in multiple copies of source files opening which can be very confusing, particularly in the case where the sources are unmodified). I have some ideas to try out, but I don't know if they'll work without changes to VS Code / DAP.
It's easy to get into this state if you (for example) disable hot-reload-on-save or even just modify a file and don't save - however I get the impression that you're unexpectedly getting into that state so it would be good to get a repro (possibly that's more of a Flutter issue than Dart/debugger, but I'm not too familiar with the compilation side of things - maybe @a-siva can advise on best steps to debug that).

@DanTup that's understandable if I edit code and don't hit Save. It's not understandable for code and the generated program to be out of sync if I save the source then hit F5 to run, then do a hot reload without changing anything, and then I end up with a binary running that somehow has symbols in it that haven't existed in my source for a couple of hours (since many saves ago). Something is very busted here, but I don't know if it's in Dart or Dart-Code.
This may be a new issue -- I upgraded VS Code and Dart/Flutter recently -- however, it could also be an old issue that happens to be manifesting itself much more prominently given the recent upgrades, and that could be causing some of the issues where the breakpoints are not stable or do not resolve to the correct line. (Which is why I reported it here...)
I don't have a clue how to make a good repro case for this, but I'll keep watching the situation, and I will report more if I can find any more info.

@lukehutch

@DanTup that's understandable if I edit code and don't hit Save. It's not understandable for code and the generated program to be out of sync if I save the source then hit F5 to run, then do a hot reload without changing anything, and then I end up with a binary running that somehow has symbols in it that haven't existed in my source for a couple of hours (since many saves ago).

I agree, this sounds like a serious bug. My suggestion above was to file a new issue - this isn't a debugger/breakpoint issue (as you could presumably illustrate the issue without breakpoints at all, by printing some text, modifying it, and seeing the old text printed). This issue is already covering a number of different issues that make it difficult to track so I think it's better if we open more specific issues as we isolate them.
Btw, the very latest Flutter master (as of a change I landed a short while ago) includes a fix for breakpoints reusing stale resolution info from old isolates. I would be interested in hearing whether you can reproduce any breakpoint issues (that aren't caused by the stale update issue just mentioned) on that version (and if so, steps and a log). I'm hopeful that this fix covers the majority of the "breakpoints jumping to different locations" and "breaking in a different place to where the breakpoint was shown in the editor" type of issues that were described above.

@DanTup awesome, I'll check out your fix. Thanks for fixing that!
Although the stale state issue seems to be much worse on Flutter master than on beta -- so I'll have to pick my poison :-)
I'll file a separate bug for the state state issue. I just thought it might be related to the breakpoint issue here (since it could certainly explain breakpoints not being put where you intended) -- but you're right, it's probably something totally different.

@DanTup I'm still seeing the same broken breakpoint behavior with:
[✓] Flutter (Channel beta, 3.22.0-0.3.pre, on macOS 14.5 23F79 darwin-x64, locale en-US)
    • Flutter version 3.22.0-0.3.pre on channel beta at /Users/luke/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 87b652410d (5 weeks ago), 2024-04-23 21:41:18 -0500
    • Engine revision b4bfd45986
    • Dart version 3.4.0 (build 3.4.0-282.3.beta)
    • DevTools version 2.34.3

[✓] VS Code (version 1.89.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.91.20240529

@lukehutch are you able to capture a video and log of the issue(s) you still see? There are a number of different issues described above so it's not clear which are still occurring. Thanks!

@DanTup here you go. Basically about 90+% of the time, when I click on a line number, a breakpoint is set on a line several lines away from where I clicked. Sometimes the line that the breakpoint appears on doesn't even have any code on it (e.g. once in this example, the breakpoint appeared on an empty line 35, between functions). Sometimes setting a breakpoint on one line and then setting a second breakpoint on a second line causes both breakpoints to disappear, and be replaced by a display of a single breakpoint far from both selected lines.
There's an enormous amount of weirdness here, and it makes the debugger very hard to use!
https://github.com/dart-lang/sdk/assets/811305/3001bd58-ba20-456e-9f54-bd7dab8f5c86

@lukehutch the issue discussed above that caused this problem has only been fixed on master so far, but the version you're using here is much older:

Framework revision 87b652410d (5 weeks ago), 2024-04-23 21:41:18 -0500

I'm pretty sure from the video you're just seeing the same issue here. Are you able to test on the latest master (and if you still see issues, capture a video and log at the same time)? Thanks!

@lukehutch the issue discussed above that caused this problem has only been fixed on master so far, but the version you're using here is much older:

Sorry, I assumed that change would already be in the preview release, since a couple of updates to that preview release have been published since you mentioned the change.
Can I just use the code-insiders build (Dart Code extension: 3.79.20231214, Flutter extension: 3.89.2024050), or do I have to check the master version out of git?

Thanks, but let me rephrase my question: has this reached the latest code-insiders build yet?

The version of VS Code (or Dart-Code) is not important here, only the version of the Dart or Flutter SDK.

Sorry, I totally missed that you were saying it was the Flutter master channel that I needed to use, since I filed this bug in dart-code. I switched to the master channel, and so far haven't seen a whole lot of weirdness with breakpoints (other than some breakpoints not getting set on lines I didn't expect, but it's nowhere as bad as before, and I can explain what I have seen so far by certain lines being compiled out by inlining etc.). I'll report back if I see anything out of place.

The version of VS Code (or Dart-Code) is not important here, only the version of the Dart or Flutter SDK.VS Code（或 Dart-Code）的版本在这里并不重要，重要的是 Dart 或 Flutter SDK 的版本。

Can I ask when will this fix be done on Flutter stable channel? Because our office only allows us to use stable version of Flutter.
Currently this:
Flutter 3.22.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision a14f74ff3a (13 days ago) • 2024-05-22 11:08:21 -0500
Engine • revision 55eae6864b
Tools • Dart 3.4.1 • DevTools 2.34.3

(I'm getting some breakage on Flutter master now too, had to switch back to beta...)

@Ssiswent the fix will be included in the next main Dart/Flutter releases (these releases are approximately quarterly).
@lukehutch since the main thing shown above was fixed, are you happy to close this issue and open new (more specific) issues for any issues you still see on versions with this fix? It's harder to ensure everything is fixed when a single GitHub issue contains multiple problems.
And if you can provide matching videos+logs with any new issues, that would really help track them down.

I was only able to test in a very limited way before something broke in my app due to using the master channel, and I had to switch back to the beta channel. I can't yet completely confirm that the original issue is fixed, since the bug was sporadic. However, I agree that this issue report got pretty messy...

Oh sorry, I thought you meant with breakpoints but realise now you probably meant with something else.

I agree that this issue report got pretty messy...

Ok, let's close this issue and file new ones for any remaining/new issues. For now, issues that appear to be breakpoints jumping to other locations after a hot reload/restart are only worth filing if using master (until the fix above reaches the other channels).  Thanks!

I know it should been fixed by now. And where waiting on a flutter update to get the changes, but here is some extra:
https://github.com/user-attachments/assets/0117a0b4-8829-48c5-870b-89a010cbfe98

@stan-at-work it's hard to tell exactly what's happening here because I don't see any breakpoints in the gutter and it's not clear what action you're performing.
If you're able to test on Flutter master I'd be interested in a log while reproducing this. Otherwise, hopefully the fix will be in the beta branch soon and could be tested there.

That correlates with my experience. I haven't seen much weirdness lately with breakpoints, other than late confirmation.

There's an updated Flutter beta that includes Dart 3.5.0-323.1.beta, which includes the change to pre-compile functions. If you're able to try it out, please let me know how it works for you :-)

@DanTup I see two significant problems with breakpoints in the latest beta. I'll report them here first rather than opening new bugs for them.

The first time during a run of the app that the debugger stops on a breakpoint, The arrow selector appears around the red dot, indicating the debugger stopped at the breakpoint. This lasts about half a second, then the arrow indicator disappears, and the debugger disconnects from the device. The stacktrace disappears, and the debugger still shows the device as running the app, but it's impossible to use the debugger again until a hot reload. However, if you perform a hot reload after starting the app, before the first breakpoint is hit, then the debugger successfully stops on the breakpoint.
If the debugger stops on a breakpoint and you change the code around the breakpoint and hit Save, then again the debugger detaches and goes into the same zombie state.

Sorry, I'm in a crunch and don't have time to capture videos etc. about this right now -- hopefully that's at least a start!

@lukehutch I don't seem to be able to reproduce either of these. The one think I did see was that if you modify code such that the current execution pointer (and breakpoint) are no longer valid, they'll go grey (unverified) because when you save, VS Code is now sending breakpoints on lines that don't match (and may be invalid) - but a grey/unverified icon under the current execution pointer isn't visible. This looks a little odd, but I believe is working as intended.
Could you capture logs/videos of the two issues you're seeing and file new issues for them? Please CC me. Please also try to repro in a new project first to see whether there might be something specific in the code/project that triggers them.
Thanks!

@DanTup here is a video of issue 1 from my previous comment:
https://github.com/user-attachments/assets/29a71d60-f474-4ada-97f1-06ee343ec869
Can you please remind me how to capture debugger logs?

@lukehutch could you file a new issue with a video and matching log (and cc me)? Log info is below. From the video, it seems you have a second isolate "Paused on Entry" but it's not clear why (we do set isolates to start paused so we can send breakpoints to them, but they should be resumed afterwards).
If you're able to extract a repro you can share, that would help a lot too. Thanks!

Run the Dart: Capture Debugging Logs command
Reproduce the issue
Click Cancel on the logging notification to stop logging and open the log
Remove anything sensitive from the log

@DanTup here you go
https://github.com/user-attachments/assets/bf7cb6fc-55d9-4259-9a61-191b5f692a3e
Dart-Code-Log.txt.gz

@lukehutch thanks - can you file a new issue for this and CC me? And also confirm whether you can repro in a clean project or only in this one? Thanks!

dropping label area-vm as the VM issue with eagerly compiling functions has already landed.

@lukehutch this issue has been marked as closed, if you have further issues with the breakpoint system please open new issues


feat(documentation): Add information about the configuration options of install script

Added information about the install script configuration:

Raised the behaviour with respect to existing configuration file
Split options in 2 categories: for agent configuration and for install script itself. The latter ones should not be used by customer.
Documented each option
I mentioned OPW and vector install script but didn't gave much details.

You can review the README here for more comfort.
This README will eventually be referenced from Agent Install Instruction page.

/merge


Template compose-multiplatform-ios-android-template

Similar to https://github.com/JetBrains/compose-multiplatform/issues/2823
We need a template that supports only iOS and Android, because removing the other targets isn't easy right now, but they may not be needed.

We don't want to use mobile in naming. It may associate just with Android. Let's use compose-multiplatform-ios-android-template to avoid confusion as discussed with @SebastianAigner in Slack.

Here it is: https://github.com/JetBrains/compose-multiplatform-ios-android-template
Couple of things to be done:

Remove issues
Add About

Couple of things to be done:

Done

@katia-energizer, should we change the title to Compose Multiplatform iOS+Android Application?

How to use this template?
I have Koplin Multiplatform Mobile and Compose Multiplatform IDE Support plugins installed for Android Studio. When I pick Kotlin Multiplatform App template I get project structure that is on the first look similar to compose-multiplatform-ios-android-template but is actually implemented in not multiplatform friendly way. Shared module has no UI components (no App). Instead each platform has it's own Greeting and theme implementation. I can't find any information how to add a template to AS (so I assumed it's shipped with a plugin) and there is no info about it in readme files nor on wiki...

How to use this template?

Yes?

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Scorpio: some improvement required

In the past few days I tested scorpio for integrating zed with mega and here are my suggestions for it.

[ ] Gracefully start and quit: When scorpio receives a signal to quit, it won't umount the mountpoint. Causing it cannot correctly start in the next time.

[ ] IO Error on reading non-exist files: Using cat command for a non-exsiting file in the fuse would get a IO Error message.

[ ] Confusing meanings for mount: mountpoint and mount doesn't share the same meaning
https://github.com/web3infra-foundation/mega/blob/c64b9e938f80d8ceffb249dd5ca05cc792b1f60d/scorpio/src/main.rs#L30
https://github.com/web3infra-foundation/mega/blob/c64b9e938f80d8ceffb249dd5ca05cc792b1f60d/scorpio/src/deamon/mod.rs#L84

[x] mountpoint should not be hard-coded: request it from /api/config would be nice.

[ ] Let's use absolute path: Just a suggestion.

[ ] Duplicated mount paths: Simply call /api/mount on the same path twice and you'll got:

@Ivanbeethoven

Got it !

PRs #688 and #687  has solved the problems

[x] Gracefully start and quit
[x] Confusing meanings for mount
[x] mountpoint should not be hard-coded
[x] Duplicated mount paths： Now you can't mount twice

TODO:

[ ] IO Error on reading non-exist files : need some error check with libc function .
[ ] Let's use absolute path


🌱 Add CAPI v1.8 contract

This PR add CAPI v1.8 contracts

Should we also update the e2e-conf file in this PR or open a separate one for that?

I was thinking the same, didnt touch it thinking if that would affect the tests before the release, would it ?

It should not affect anything if we add a new version but those changes are mostly related to clusterctl tests, I will open a separate PR that updates the tests and also update the e2e-config file.

Ok, I checked again test/e2e/data/infrastructure-metal3/v1.8/metadata.yaml and test/e2e/data/shared/v1.8/metadata.yaml are only needed in the main branch so let's add them once we have release-1.8 branch. Other changes we can already merge.

/test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

/test metal3-centos-e2e-integration-test-main metal3-ubuntu-e2e-integration-test-main

/retest

/retest
Artfifactory issues.

/retest

/retest

/lgtm

/retest


Expose TaskInterface's spawn API to clients

TaskInterface offers an API to spawn sub-processes for ExternalCommands' executeExternalCommand method. This API was not exposed to Swift clients before. With this change, Swift (and C) clients can spawn sub-processes from within the ExternalCommand context enabling custom commands with custom dependency and lifecycle logic while still using llbuild for the execution of processes.
rdar://58130781

@swift-ci please smoke test


Support other clustering algorithms

Is your feature request related to a problem? Please describe.
This is not a problem per se, but AgglomerativeClustering and SpectralClustering in sklearn.cluster is not always favorable especially for large datasets due to its numerical scaling (benchmark at HDBSCAN docs. For example, personally I usually use genieclust, and would like to use it instead of sklearn clusterers, which is impossible in the current implementation.
Describe the solution you'd like
A Clusterer base class for interfacing both sklearn and other types of clusterers by inheritance can be implemented and its instance (or class itself) can be given as an argument while splitting. Or it can be some if-else statements in datasail.cluster.clustering.additional_clustering(), but it might be less elegant.
Describe alternatives you've considered
Alternatively, sklearn clusterers can be replaced with ones from fastclust package.

Dear @isty2e,
Thank you for your feedback and suggestions. We will definitely consider these for future versions and improvements of DataSAIL. Customized clustering is indeed something we haven't thought about and implemented yet.
Best, Roman


Singleton design pattern implementation for UI server client:

Partial code review + proper implementation as a learning exercice:

singleton class shall never use static methods: it's redundant, the
singleton already guarantee that all invocations will occur on the very
same instance
the singleton is also a proxy class for WebSocket API, the naming
shall reflect it

Signed-off-by: Jérôme Benoit<EMAIL_ADDRESS>

If everyone is okay with it i shall merge tomorrow by 10am (GMT+2)


You Removed My Code??

You accidentally removed this code after you merged it.

I found that your code led to some bug.


Make cli run with python3

Had to upgrade my CircleCI python version since docker-compose mysteriously broke.
Now docker-compose works fine on python 3.5.1 but docker-cloud doesn't!
I don't see any mention in the docs about python version requirements - I assume this package only runs on python2.x?
Traceback (most recent call last):
  File "/home/ubuntu/virtualenvs/venv-3.5.1/bin/docker-cloud", line 9, in <module>
    load_entry_point('docker-cloud==1.0.3', 'console_scripts', 'docker-cloud')()
  File "/home/ubuntu/virtualenvs/venv-3.5.1/lib/python3.5/site-packages/pkg_resources/__init__.py", line 558, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/home/ubuntu/virtualenvs/venv-3.5.1/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2682, in load_entry_point
    return ep.load()
  File "/home/ubuntu/virtualenvs/venv-3.5.1/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2355, in load
    return self.resolve()
  File "/home/ubuntu/virtualenvs/venv-3.5.1/lib/python3.5/site-packages/pkg_resources/__init__.py", line 2361, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/home/ubuntu/virtualenvs/venv-3.5.1/lib/python3.5/site-packages/dockercloudcli/cli.py", line 10, in <module>
    from dockercloudcli import commands
  File "/home/ubuntu/virtualenvs/venv-3.5.1/lib/python3.5/site-packages/dockercloudcli/commands.py", line 14, in <module>
    from dockercloudcli import utils
  File "/home/ubuntu/virtualenvs/venv-3.5.1/lib/python3.5/site-packages/dockercloudcli/utils.py", line 16, in <module>
    from exceptions import BadParameter, StreamOutputError
ImportError: No module named 'exceptions'

:+1:
Really needed feature..

Wow, March 2017 and this is still an issue?

As of 2017.04.12, in this page of the official documentation, it is implicitly stated that Python 2 and 3 are supported.
https://docs.docker.com/docker-cloud/getting-started/deploy-app/2_set_up/#install-the-docker-cloud-cli

We are currently focusing on making swarm mode GA on Docker Cloud. There will be no new features added to the existing "classic" mode of Docker Cloud, but only bugs fixing.


Change header color

I want to change the color of h1.
Code in my css snippet:
body {         --h1-color: #8fbcbb; }
Expected result: h1 header turning green instead of yellow.
Actual result: h1 header stays yellow.
Why?
(Sorry if I missed something obvious; Thanks a ton for putting in the work to port this awesome theme to Obsidian!)

Use this instead. This should work with any theme.
.theme-dark { --h1-color: #8fbcbb; }