Allow language extensions to provide status information

Many language extensions add status bar entries for various information tidbits, like version, language server status, project etc. There is many inconsistencies for how this happens like alignment isn't always in sync with the language name or visibility isn't in sync with the active editor.
We should help extensions do a better job by adding a dedicated "language status" API, some kind of LanguageStatusProvider which we query whenever the editor changes. In its simplest form language status can be text, detail (supporting codicons and md), and severity.

API sketch
enum LanguageStatusSeverity {
    Information,
    Warning,
    Error
}

declare class LanguageStatus {

    text: string;
    detail: string;
    severity: LanguageStatusSeverity;

    constructor(text: string);
}

interface LanguageStatusProvider {
    provideLanguageStatus(): ProviderResult<LanguageStatus>;
}

declare namespace languages {
    export function registerLanguageStatusProvider(selector: DocumentSelector, provider: LanguageStatusProvider): Disposable;
}

Good stuff.
Not sure about text and detail, I would suggest to go with just message: string | MarkdownString.
I imagine this to be shown in a hover over the language mode status bar entry (e.g. 'JSON'). As there can potentially be multiple providers active for a given document, the hover would combine all the messages by concatenating them.

Looks promising. Here's the information we'd potentially like to show for JS/TS:

The current TS version (plus a way to switch versions)
The state of TS server.

Are we spinning up a full server? Right now we show initializing JS/TS language features progress in the status bar for this
Are we in partial only mode. If this is the case, we'd like to tell users that operations such as workspace symbol search may be incomplete

Potentially if logging is enabled and a quick way to jump to the log file

Additionally, it would be nice if we could customize the displayed information per-file instead of showing the same status for all files of given language. For JS/TS, this could be:

The tsconfig/jsconfig that the current file belongs to (and a way to quickly go to that config file)

If multiple extensions can contribute to the language status, it may also make sense to move some ESLint information into the language status

So my high level questions:

Should this API be per-file or per-language?

The current API uses a pull model but if we instead had a push model, we could leave this decision up to extensions like we do for status bar items

Should Language Status be a single item or an array of items?
Can multiple extensions contribute to a language status?

//CC @dbaeumer

Extension will always be free to add additional status bar entries, with command handler, menus etc.
That's why I suggest that for the beginning we keep it simple and introduce a LanguageStatusProvider returning a MarkdownString. That's also straightforward to adopt in LSP.

simple and introduce a LanguageStatusProvider returning a MarkdownString.

I think we need more than just a message because we need to show some kind of anchor in the status bar. I initially tried to hijack the language item for that but it has the "Change Language" message and command.

The current API uses a pull model but if we instead had a push model, we could leave this decision up to extensions like we do for status bar items

Yeah, it might simplify things and prevent repeated LanguageStatusProvider#onDidChange events. Generally we don't know when to ask for language status except when opening an editor. It just needs a nice way to target the files/scope of a certain status. The DocumentSelector could be enough as it support glob patterns and arity.

This is the updated (and implemented) proposal that uses the push model. I still looking for ways to eliminate the severity, e.g TypeScript being single-file only isn't an error nor warning but merely something "unexpected". Ideally, we find a way to express that, maybe a boolean like affectsUsage or limited
https://github.com/microsoft/vscode/blob/e30d70f9f519780ef07840c77d3ffc57459d9dd2/src/vs/vscode.proposed.d.ts#L3162-L3179

Just tested out the changes and like the push model
For the UI, if there are multiple statuses would we want to render them in a list? Perhaps something like:
|===============|
| First Title   |
| details       |
|---------------|
| Second Title  |
| details       |
|===============|
        ˅

A few other ideas:

Should the language status items have a priority, like we have the status bar items? This would help with ordering

Should we add a command to the language status item?

Right now you can run commands using MarkdownString, but it may be nicer if you could click the entire item to perform an action (like you can for status bar items)

Right now detail is used for tooltips. I wonder if we should have separate detail and tooltip fields. For the typescript version information for example, this might be:
title =  "TypeScript Version"
detail = "4.3.0"
tooltip = "/path/to/tsdk"

The ASCII art reminds me of how we do notifications and how they are behind the bell. So, one well-known icon which discloses more information. This would give it a clean & uniform look but might be too much hiding

This is how it currently looks (UI and API)

Language status is text, detail, and command
Language status is part of a rich hover
The is the idea to make a language status pinnable to the status bar. This would make it easier to "migrate" users onto the new behaviour
It's still unclear how to anchor the status hover. Today, its the separate circle icon but a nicer icon and something that's combined with the language name is preferable

	enum LanguageStatusSeverity {
		Information = 0,
		Warning = 1,
		Error = 2
	}

	interface LanguageStatusItem {
		selector: DocumentSelector;
		severity: LanguageStatusSeverity;
		text: string;
		detail: string; // tooltip!
		command: Command | undefined;
		dispose(): void;
	}

	namespace languages {
		export function createLanguageStatusItem(selector: DocumentSelector): LanguageStatusItem;
	}

👋 Here are a couple of additional explorations as I learn more about what's needed here. I've tried a few different versions using the discussion above as input. Any and all feedback welcome! cc @misolori
Option 1
Adds icon before language name

Option 2
Splits status into its own button. Adds counter for potentially multiple messages—not sure if that's needed but thought I'd hint at it here.

Option 3
Similar to option 1. Adds status icon and counter after language name.

I like having a separate status bar entry. I'm used to clicking on the language name to change the language mode of the current file, so I'd be careful about changing that behavior
Will showing a warning/error icon be confusing since we use similar icons for diagnostics? I don't have better suggestion for what to show instead

@mjbvz Thanks for the feedback! Agreed that we shouldn't change the click behavior. The general idea was for the message to only show on hover. But there are of course challenges there too.
Good question re: icons. I'll see what else we have as options.

I like Option 3 because that keeps language and status close together, but I share the sentiment that we cannot change the click action.
I would have to play with it myself to see if the hover alone is sufficient. An alternative would be to allow for child elements within a status bar entry to be sensitive to clicks so that you can trigger the language diagnostics with a dedicated click on the warning icon.

I would keep them separate (in terms of the ability of pushing them and have different commands) but visually connected. I do like if the status is in front and not after the language indicator.

I like them together, with the icon after the language name, if there's a status. I would not put a counter. I think the number of stati is not that interesting as I think for some languages it will be stable number. Instead, a 'dot' could be added if there was a change of status that hasn't been read yet.

I've been looking for prior art and thought of Prettier's status bar contribution. Looks like they also combine status and text into one item. Although they don't provide any information on hover. Interesting to note, in any case.

It feels fairly disconnected to my eyes when split out.

I agree, tho it needs at least two hover areas and likely two click areas. What we could explore is "connected status bar items" which

are always next to each other and have less padding
when hovered also highlight the other item (tho, weaker)

We could apply such a solution to SCM status entries too which currently have 2 entries:

Though arguably now the benefit is that you can hide either the one or both.

One idea for a connected status bar item:
Hover on parent element

Hover on child element

Looking good. It seems like the status bar item doesn't yet support the distinction between the parent and children elements yet?

This oddly reminds me of our split action that has a double hover effect:

@misolori good catch! It looks like that has a more elegant solution. Trying something similar below. I never quite loved how I had the child hover being so dark compared to the resting state of the status bar items.
Here the currently hovered element gets the normal hover state we have today. The other element gets a slightly toned down background color hint. Thoughts?

@rjmholt @andschwa FYI this is an API we're introducing to replace status bar items like the one the PowerShell extension contributes.

@rjmholt @andschwa FYI this is an API we're introducing to replace status bar items like the one the PowerShell extension contributes.

This is going to be very nice!

I have a draft PR that adopts this for TypeScript and JavaScript: #132015.

Some feedback on the API itself:

detail should be optional

Should we have an optional shortTitle? When pinning an item, the title is often too long to include in the status bar. With TypeScript for example, we end up with the following:

I'd prefer just showing the version number when this item is pinned

It is difficult to create a UX that makes sense for both pinned and unpinned cases
Here's what the typescript project status item looks like in the language status UI:

However once a status item is pinned, we now only use the detail field as the tooltip, which doesn't explain what clicking the status bar item will do:

With TypeScript, we currently show the full path to typescript when you hover on the version status bar item. I've moved this into the Command.tooltip but I don't think that's very discoverable

Should we have an optional shortTitle? When pinning an item, the title is often too long to include in the status bar. With TypeScript for example, we end up with the following:

Yeah, unsure about that. I do agree that it is challenging to cater for both UIs and that's the reason why I added only text and detail. The idea is that they map to StatusBarItem#text and StatusBarItem#tooltip. So, in a way its the same information and just different placements

@daviddossett Maybe severity (error, warning, and info) should return and rendered with the items as you outlines here https://github.com/microsoft/vscode/issues/129037#issuecomment-903966955. However, for the composite status bar item it could still be two icons - "info" and "screaming info"

Trying to clean up the single row format and moved from full on primary buttons to link actions instead.

Love it. Might only weakly differentiate from links in the detail text but it looks and feels much better
https://user-images.githubusercontent.com/1794099/131801457-300c9687-a643-49c0-b1a7-1177558d1bb6.mov

Should the icon button be clickable instead of relying on hover to match the common status bar item behavior?

Yeah, that's on the todo-list

I think the icon should go to the left of the text (at least in LTR languages) to mirror the patterns in Source Control, Problems, etc.

Agreed

I still don't love the usage of the info icon as the "normal" state. It doesn't give any great hints as to that being the location to change something like language version

Also agreeing. For now I brought back the severities but we could simply pick a different renderer for info. Something that's language'ish (whatever that would be) and use dedicated icons (or variants of said icon) for warning and error states

Something that's language'ish (whatever that would be) and use dedicated icons (or variants of said icon) for warning and error states

I'll look around to see if we can use something specific to languages here. Ideally we don't have the duplication of the warning/error icons that we use in Problems. May need to create something bespoke for this.

Some alternatives to the info icon. These would bias more towards the status itself and less towards any sort of indication of configuration (version, config, etc.)

I don't see any icons that could easily be used for something the languages in our current library. @misolori do you know of any off the top of your head? One idea would be to have something similar to these icon + status patterns found in other icons e.g.

The only other icon I can think of is the lightbulb, which we do tend to use for "intellisense" and could point to language features. We use that on the website:

I was pointed here by @dbaeumer after I complained about modal status UI used by vscode-eslint. I'm not an extension author, but I can share my end-user experience below about how I currently use status UIs for different JS/TS-related extensions. Hopefully this will be useful as you evolve this proposal.
First, some context: I work primarily in TS. My apps are a combination of front-end (React) and back-end (Node, AWS Lambda, Serverless Framework). I do a lot of viewing of, debugging into, and occasionally editing of (e.g. for use with patch-package) of node_modules code.
Now, here's some use cases and details for how I use language extensions' status UI:
Use Case 1: Why isn't prettier fixing my code when I save a file that I'm editing?
I heavily rely on prettier and format-on-save to fix up my sloppy code formatting.  My typical workflow is to write some code, save the file so prettier will fix the formatting, and then continue. When prettier is not working (meaning I save the file and nothing changes), I usually stop what I'm doing and fix whatever is preventing prettier from doing its job. Here's the steps I take to diagnose:

a) First, I look for the prettier icon in the status bar. If it's , then I know I need to fix my code to remove whatever problem is preventing prettier from building its AST.  Usually this is a missing bracket or parenthesis, or other grievous syntax error.
b) If the problem in my code isn't obvious, then I'll click on the prettier button and look at the prettier output in its output channel. This is a last resort because these messages are usually unhelpful, but I suspect they would be useful in cases where there's a configuration issue.
c) If the prettier icon is , then I'll look at the status bar UI for the vscode-formatting-toggle extension. (Aside: this feature should be built-in!)  If I see , then I'll toggle the auto-formatter back to its normal state .
d) If the prettier icon is , then I know I have a configuration issue and need to check my ignore files.

Use Case 2: Preventing prettier from "fixing" manually formatted files
There are often a few files that shouldn't be auto-formatted by prettier. For these files, I turn off the auto-formatter using the vscode-formatting-toggle extension. I look at the status bar and if I see  then I'll click it which turns the state to .  Then I'll save the file and (hopefully) remember to immediately toggle it back. If I forget, that's (c) in the use-case above.

@jrieken PowerShell will need to "pin something by default" because the version number is critical to be shown to new users and would be "backcompat" with the current experience which is showing the version. I would guess that we'd wanna do this for TS too for backcompat.

+1, because vscode-formatting-toggle could never use this API unless it could be pinned by default, because the whole purpose of that extension is to provide one-click toggling which requires it to always be available on the status bar.
Use Case 3: Dismissing ESLint modal dialogs for problems I can't fix (e.g. when viewing someone else's code)
It's very common to get fatal ESLint failures. Here's a few cases:

a)  When an ESLint configuration depends on a file that wasn't included in the package downloaded from npm. See https://github.com/microsoft/vscode-eslint/issues/1182.
b) When running tests requires cloning another repo into a subfolder in the to-be-tested repo, it's common to get conflicts cloning a repo (e.g. to run tests with it) into a subfolder, it's common to get config conflicts between the ignore files and/or config files of the repos.
c) Less commonly, ESLint has a bug and it will crash if it can't parse your code. See https://github.com/microsoft/vscode-eslint/issues/1238#issuecomment-905159853 for this repro.

In all these cases, the vscode-eslint extension shows a modal dialog that the user must manually dismiss. This is bad because usually the user can't actually fix the problem. Sometimes the cause is someone else's code that I can't fix (cases (a) and (b) above). Sometimes it's a bug in ESLint that I also can't fix, like (c) above.  But the common thread is that most ESLint problems are not fixable by most users so the UI should not be modal. Simply telling me "ESLint isn't working on this file" in the status bar would be fine.
As a general guideline, IMHO language extensions should never show modal UI without a really, really good reason, and only if the end-user has a good change of being able to fix the problem. FWIW, these ESLint popups are by far the most frustrating problem I have with VSCode's UI today because it's such a productivity suck to have to dismiss those dialogs every time I open or save a file in some projects.
Use Case 4: Knowing when I can start editing code / viewing problems after a reload
I frequently reload/restart VS Code, either to reload an extension, after an update, to clear stale problems from the Problems pane, or to fix persistent ESLint issues. After a reload, I like to wait until all initialization is done (CSS, JS/TS Language features, folder-open tasks complete, etc.) before I start editing again. I use the status bar UI to let me know when things have settled down.
Use Case 5: Spell Checking
I use the vscode-spell-checker extension for finding spelling typos. This extension has a really nice status bar UI. When there are no problems with the current file, I see this:

When there are spelling errors, I see this:

And when the file is ignored I see this, with a nice hover UX:

I like how the icon changes as a subtle hint that I should click the button to open the settings UI for that extension.
FWIW, I also prefer the icon being before the name of the extension (like the spelling extension) instead of after it like the auto-formatting toggler extension.

Really appreciate the detailed thoughts @justingrant!

Editor Languages status is available for JS/TS in latest Insiders.
However after "pinning" item it's not clear how to get item back under Language Status group and even if it's related to Language Status.

I think it would be useful to have some marker/title that item in list (Project config in screen above) is related to Language Status and it will be "hidden" under Language Status group.

Pushed a change to allow a status bar item to be positioned relative to another one:
https://github.com/microsoft/vscode/blob/ffbe94df0e65ff10ae6db93255199f2ace5b607c/src/vs/workbench/contrib/languageStatus/browser/languageStatus.contribution.ts#L180-L180
And also introduced a new compact property when doing so which allows to move the 2 entries closer to each other:

They can still individually be shown or hidden and are independent status entries as before.
I cannot really get the hover thing to work though, even with the nice adjacent sibling combinator trick which unfortunately only works for the next sibling not the previous one.
Visually I wonder if both entries should simply show the same hover feedback, because the items are quite close together so I feel a individual hover effect on both might not look so nice.

I cannot really get the hover thing to work though, even with the nice adjacent sibling combinator trick which unfortunately only works for the next sibling not the previous one.

Yeah, I believe it cannot be done in CSS but needs JS. I am also fine with a single hover feedback for "friend items"

@daviddossett do you have thoughts? I think today in the UX call I saw some designs in action how the language status indicator responds to hover. I wonder what kind of spacing you had in mind for this. Currently with "compact" status entries, I put a 3px padding and no margins to make them appear closer together.

Played around with this in Insiders just now. It looks like the combined button hover behavior works when you hover on the language name but not when you hover on the status icon. In any case, great to try this out. I'm ok with us having them separate for now. I may have some other for a sort of nested button that we can explore later.
There was some weirdness with the hover behavior fighting with the click behavior. But IIRC I think @jrieken said he was still working on that.
@bpasero I tinkered with this in dev tools and felt like 3px L/R padding for both the status icon and language item worked well. I think the info icon itself has some extra space on the right however? Visually they still feel somewhat separate compared to something like the Prettier contribution, but we of course need the padding for the button itself.

A related question: how do you feel about the hover treatment when compared to other popovers like notifications and feedback. Both use more of a formal popover w/ shadow and status bar beak. My first impression was that it was a "one of these is not like the other" situation.

Another advantage to using the default item hover styling (i.e. not going darker) is that we're less likely to run into issues like this on other themes. Note that the background color doesn't change on hover here:

Seeing this just now I think we should also consider merging them into a single status bar item. So instead of the info icon it would just say "TypeScript", and you could hover to see "Select Language Mode" above the pinnable language status entries. @eamodio tells me he brought this up before and the push back against that is that then it's a hover only action, I don't see why that's a problem though.
As for the warning one, that could still show the warning-color icon, just it would be closer to the language name, only separated by ~a single space, making it much more obvious that the warning is related to the language.

A bunch of feedback and questions below:
One hover vs. separate
For answering questions like "should there be one hover or multiple?", I'd suggest describing the step-by-step user actions for the various use cases involved, to make sure we don't miss any. For example:

Users who want to know the current TS version can  _________
To change the current TS version, the user can __________ (or however I should choose between built-in vs. project version of TS)
Users who want to frequently switch TS versions can  __________ (use case for pinning?)
To ....

I probably agree with @Tyriar that having a single hover (not separate hovers on icon vs. text) will be clearer UX.  Without seeing the cases and user flow for each, it's hard to know for sure though. A split UX may make some cases much easier.
Simple Extensions
One case to keep on your radar is simple extensions like vscode-formatting-toggle. These extensions put 100% of their important UX (name, status, and click to change status) inside the status bar don't have any follow-up actions in the hover, just text. For complex extensions with multiple actions, the proposed changes discussed above seem like a big win, but need to make sure that it doesn't make UX worse for simple extensions.
It's an interesting question of when icons should be shown for non-warning/non-error situations. I'd suggest leaving it up to the extension. Extensions whose status changes frequently as the user edits code (e.g. ESLint, Prettier) probably will want to keep the icon showing all the time to reduce distracting movement in the status bar as the user types. Extensions like TS,  where status changes rarely and/or only in response to an explicit user action in the status bar, probably will want to hide the icon unless there's a problem.
Pinning
I admit I don't understand how pinning will look and act. Would be good to see some screenshots/videos for pinned vs. un-pinned states, and for the transition between those states. A few pinning questions:

What happens if you pin all the sub-items for an extension?  Does the status bar still show every item including the parent, or is there some real estate savings possible?  For example, I could imagine wanting to show "TypeScript" in the unpinned state but maybe "TS 4.4.3" in the pinned state to save space. I'm not saying we should do this for TS, only that it's likely that some extensions may want to optimize real estate depending on what's pinned.
For TS, by default it will be unpinned and shown under the language name?  Or will the version number be shown by default?  (I think the latter is the current default but not sure)
More generally, will there be a default pin/unpin state for all newly-installed extensions?
Related: will extensions be able to control their default pinned/unpinned state?  An extension like
 may want to be unpinned by default, but ESLint/Prettier probably want to be pinned by default because they apply to multiple languages.
Also related: if an extension applies to multiple languages, does its pin/unpin state travel across languages? Or is it language-specific?  I ask because most of the status bar UX that I use (see use cases  in https://github.com/microsoft/vscode/issues/129037#issuecomment-918437232) are cross-language extensions like ESLint or Prettier.
What happens when I hover over a pinned item?
Can pinned items have nested, pinnable items?  "No" is probably fine, just wondering.

Icon Questions

Can each pinned item have an icon, in addition to an icon for the parent item?
Can the parent item and/or a pinned item have multiple icons, or just zero or one icon each?
Can the parent icon change when a sub-item is pinned? For example, a parent item might show an icon like , but if you pin the details then the details could have a full-size icon instead of the small badge on the main icon.

Hover Behavior

it's a hover only action, I don't see why that's a problem though.

Is using VS Code on a touch-only device a supported use case?  If so, then would hover-only actions would need a tap alternative.
Does clicking on the status bar item cause the hover UX to come up and stay up until you set focus away?  If so, that would need to be customizable to avoid breaking the "simple extensions" case noted above.

@daviddossett if you are using insiders you are not on my solution yet, you need to wait for todays insider or try running out of sources.
As for sizing, I used to have 2px padding but can change to 3px padding for each item that is close to each other, so we end up with 6px gap from indicator to language picker:

Btw, I am yielding from any discussion around how the language status indicator should look like because @jrieken owns this component. I am only providing the support for showing status bar entries close to each other.

before and the push back against that is that then it's a hover only action, I don't see why that's a problem though.

@Tyriar Won't that make the hover in-accessible? Today, you can tab your way into the statusbar and manually trigger the language status hover. I believe that we would loose that with a hover only thing.

I think it would be useful to have some marker/title that item in list (Project config in screen above) is related to Language Status and it will be "hidden" under Language Status group

:+1: I will push a change that appends a suffix like "Foo (Language Status)"

One case to keep on your radar is simple extensions like vscode-formatting-toggle. These extensions put 100% of their important UX (name, status, and click to change status) inside the status bar don't have any follow-up actions in the hover, just text.

@justingrant This new API and feature request is for language service things, like a language server or formatter but not a replacement for status bar items. The formatting-toggle extension doesn't seem like a fit for what we are aiming here because it effectively toggles one or more settings but doesn't have a state which depends on the active editor or another "outside" condition.

Won't that make the hover in-accessible?

It should be keyboard accessible yes, I wouldn't call that a blocker to that idea though. Tab could move into the hover if it has actions for example.

I like the idea of only showing warning/error icons if such a condition exists. I share the concerns of hover-only discoverability and accessibility, even if it is keyboard accessible. @Tyriar are there other comparable situations in VS Code where we do this?
Also wondering how that behavior would work on my iPad since the tap would open up the language picker.

@davidanthoff in the editor there is the "Show Definition Preview Hover" which shows it and puts keyboard focus there.

Pushed a change to show unified hover across compact entries:

Keyboard accessibility is also nicely possible, given both entries are actually real status bar entries:

@bpasero Just tried the latest and feels really good! Great job 👏
A couple of small nits I noticed:

If I click on the status item and my mouse leaves the button hit area, the hover disappears but the button remains in a hover/pressed state.
Same behavior after pinning an item—the hover disappears but the button state is stuck

Clicking on the status item dismisses the hover and then renders it again. Is it possible to keep it open in that scenario?

@daviddossett

If I click on the status item and my mouse leaves the button hit area, the hover disappears but the button remains in a hover/pressed state.

I pushed a change to focus the hover on click of the language indicator.

Same behavior after pinning an item—the hover disappears but the button state is stuck

I believe that should be fixed as well given the hover is focused when you click now.

Clicking on the status item dismisses the hover and then renders it again. Is it possible to keep it open in that scenario

Not so easy because we have code to actively remove the hover when you click the element.

I have pushed a change that makes use of the solid dot whenever a warning or error is reported. It is like the roll-up dot for file decorations (as seen in folders), less prominent than full background but still asking for attention

I like the consistency of that UI language because we use it for decorations too. @jrieken is there a way to test this in a build? I.e. can TypeScript already produce such a warning?

You can experience this with lastest insiders and anycode, e.g on gh.dev/insiders

@jrieken 👍 , I somehow feel the large circle is too large, but then the normal circle is too small, so maybe something in between?

Pushed a change that reduces the font size for this specific usage a little. Should be looking better now.

Hmmm...that icon doesn't look great (the cc ration also doesn't pass). Much prefer no color or alternate status icons like from before.

Hmmm...that icon doesn't look great (the cc ration also doesn't pass).

Those are the default warning/error status bar colors... So there might be work to be done somewhere else.
Anyways, this happened because of a lack of icons... Reusing the diagnostics icons (error, warning) doesn't seem like a good fit because it's easy to be confused with the actual diagnostics icons on the left. I do like the double checkmark and it would be great if we can have variants for that - similar to the bell or compass with and w/o dot

Why not use the X icon that the Prettier extension currently uses?

Continuing icon discussion here.

I realize I'm late to this discussion, but I just wanted to explain how the Python extension might migrate to this in case that's helpful at this stage.
Background
For context, here is an example of what the Python extension currently shows in the status bar:

There's four pieces of information, although if we expand out our support for something it could become 5:

Python 2.7.18 is the Python version
64-bit is the bitness
'.venv' is the name of the environment (e.g. the directory the virtual environment is in)
venv (notice not in quotes and not leading dot) is the environment type
And possibly in the future, the interpreter type (pretend Python means CPython in this case; could be PyPy or something in the future)

Information display
The neat thing with this proposal is if I don't care about bitness or the environment name I could choose not to pin it and thus scale down what I show to just what I care about. We will probably need a way to launch things as initially pinned or something, though, as https://github.com/microsoft/vscode/issues/129037#issuecomment-910720375 pointed out for PowerShell. That way we can transition people by saying, "look to the right" instead of, "look to the right, and to get back critical info like Python version, click on the thing and then click the 📌 icon".
Status icon
One use we will have for the status icon is when you open a virtual or untrusted workspace. We can provide IntelliSense via Pylance, but only with Pylance. That means it would be great to be able to communicate to users that if you don't have Pylance installed or explicitly selected Jedi as your language server then that's preventing you from getting IntelliSense.
As for using this for formatting status info like Prettier, we are going to be putting our formatters and linters behind LSP, so I'm not sure how we would want to communicate the status back out. But assuming we come up with a nice way to have the language server  communicate back, I could see us specifying the version of the formatter and whether the last format attempt succeeded or not.

@brettcannon our guidelines about status bar contribution say (should say?) that workspace/folder-things go left, like git status or errors & warnings, and that editor-things to right, like language, selection etc. By that logic python should be on the right and I wonder why it isn't?

We do mention this in our extension guidelines but maybe we need to make it more specific?

Do:

Place primary (global) items on the left
Place secondary (contextual) items on the right

@jrieken Two reasons.
One is simply historical: it's how Don implemented it and thus how the extension came to us.
Two is it was always explained to us as "workspace versus file" (not "workspace versus editor"). Because of that and the fact that we have always viewed the Python environment as a workspace setting and not a file setting, we have left it on the left side. As an example, when you create a Python virtual environment for a project, that's not a per-file thing, but is (typically) expected to be tied to your project (and thus the workspace).
Taking a "workspace versus editor", it's still a little murky since various tools in the Python ecosystem (e.g. pipenv, poetry) very much tie the Python environment they construct to the directory/workspace, so it isn't an editor "choice" as much as an integration with the user's tools. And even when virtual environments are created manually, it is still under the assumption that the environment is tied to a project.
Toss in stuff like HTML files that contain e.g. Django templating and the line of when/how the Python environment is relevant has never been clear cut to us, so we never moved the status bar details to avoid confusing pre-existing users.

Sorry for coming late, I just try the language status API on Java language server and would like to share some feedbacks from Java side.
Overall, it's very helpful to have a "status center" to show language status👍. We can combine our status here, including Java version, server status, etc. For the icon part, the Java language server has two modes, the standard mode and the lightweight mode, we plan to show "warning" icon for lightweight mode, like TS server.
Besides, there are some questions:

I notice that the current proposal includes three icons. For many Java users, "importing project" usually costs several minutes and now they will see a spinning status bar item ($(sync~spin)) during importing projects. IMO the status is not something like "information" nor "warning", the language server doesn't know whether the import process will success until it finishes. In order to let the user know the status of server clearly, is there any way to show a "busy" status of server in the language status level properly? Or we need a new icon (or maybe a new status as well) presents "busy" or "working"? I find the similar thing has been mentioned in https://github.com/microsoft/vscode/issues/129037#issuecomment-883655733, when initialing TS server.
For Java users, we'd like to provide a command clean workspace when the status item runs into an Error state. In this case, it would be great if the pinned item shows a clean icon and the unpinned item shows some texts like Clean workspace with command.
(If I have any misunderstanding, please correct me) Follow https://github.com/microsoft/vscode/issues/129037#issuecomment-909731687, for the pinned item, the title must be the same as the LanguageStatusItem, can we define an alias for an item text so that we can have a way to show different texts for a pinned item and an unpinned item?

Is there anyway to unpin a item?

Is there anyway to unpin a item?

Right click -> Hide "XXX"

For now I have pushed a change to use the commands tooltip as the items tooltip when pinned.

👍, so good for our case, we can provide more information in the tooltip.

You can also use the withProgress-API to report global progress - which is what TS and others are doing

Yeah, I also noticed that, it's indeed a good way to show status/progress when importing project. IMO For those more frequently events (e.g. recompile after changes), some of them are worth telling the users the server is working, and many times of appearing and disappearing about a progress item might disturb users. In another way, it would be better if we could combine and show the all the status in the status item.

Yeah, I also noticed that, it's indeed a good way to show status/progress when importing project.

Our thinking is to add a new progress location that can be used for withProgress, like withProgress({languageStatus: yourStatusId }, ...

Yeah, I also noticed that, it's indeed a good way to show status/progress when importing project.

Our thinking is to add a new progress location that can be used for withProgress, like withProgress({languageStatus: yourStatusId }, ...

Where the new progress location would be in the UX? It's will appear on the language status item or not?

It's will appear on the language status item or not?

Yes - it will appear on the language status, e.g the item itself as well as the composite status bar item

It's will appear on the language status item or not?

Yes - it will appear on the language status, e.g the item itself as well as the composite status bar item

Sounds great - looking forward to trying it in a prototype😀

re https://github.com/microsoft/vscode/issues/129037#issuecomment-957360329 and having some special kind of withProgress({...}). I wonder what the expectation is when having a long running operations but no corresponding status bar item. E.g language status visibility is driven by its selector and when showing progress there it would mean we only show progress when having the corresponding files open. E.g without a file open or while looking at README users won't see that the language service is started. I doubt that's useful because these are often "heavy" operations...

I wonder what the expectation is when having a long running operations but no corresponding status bar item.

Agree with a long running operation should have a corresponding status bar - that's also what our Java extension is doing now, it shows a status bar item when having "heavy" operations, such as importing or compiling. it's not a ""

And in the discussion, we suggest a way to represent the "busy" or "synchronizing" status after language status item can be used. IMO the language status item is more like a "status center" (please correct me if I understand wrongly) so we want to put and merge all our language status here, including the current status bar. So it would be great if the appearance of language status item could be something like "busy" or "running" in some specific status.

This is what I have prototyped. Extensions can report progress per language status item, using window.withProgress({ viewId: "myId" }, ...). Progress shows in the composite item, in the hover for the corresponding item, and when detached as dedicated item. The remaining question is what should show when having no editors open?
https://user-images.githubusercontent.com/1794099/143552619-749e739d-a943-4627-8ff5-483732af435a.mov

@jrieken I'm sorry about misunderstanding your point just now. IMO we can sort out two kinds of "heavy" operations.
Operations of the first kind are something in "workspace scope" or "workspace event triggered". They include some importing processes, it may happen when the user opens a workspace and there are no editors open. Since the visibility of language status item is controlled by the document selector, which depends on the opened file, for those ones, we'd better show some extra notifications.
The other ones are something in "file scope" or "file event triggered", usually triggered by some code changes, they might be something like synchronizing. Imagine a user is editing a source file, he will care about mostly the corresponding language status and our item will show him correctly. It's OK to hide the status when he opens a file in another selector's scope since he is changing his focus. The language status progress location is useful for these scenarios.

Understood. Tho, in that case I might go with a simpler API, e.g one which simply allows to mark a language status item as busy, so instead of withProgress(...) have something like LanguageStatusItem#busy: true | false

Pushed a first cut and simplified API. The recording shown above should be reproducible with the following snippet. Thanks for the quick feedback, so far I quite like the outcome
    const status3 = vscode.languages.createLanguageStatusItem('ddd', ['rust', 'java']);
    status3.name = "Greeter"
    status3.text = '$(globe~spin) Grüezi'
    status3.command = { title: 'Hi 👋', command: 'fff', tooltip: 'This is my command tooltip!' }
    status3.severity = vscode.LanguageStatusSeverity.Error

    vscode.commands.registerCommand('extension.helloWorld', async (args) => {
        status3.busy = true;
        setTimeout(() => {
            status3.busy = false;
        }, 5000);
    });

hi @jrieken, I'm trying to adopt this API in Java language support and it works well 👍. And I just find if we pin an item and we mark it busy, the spinning icon will appear in both language status item (the left one) and pinned item (the right one).

IMO it's a little duplicated and it's better to show the busy icon only in the language status item (the left one) to help users focus on the item. Does it make sense?

I agree. Can you please file a separate bug for that. Thanks

@jrieken thanks for the swift reply! issue created here: https://github.com/microsoft/vscode/issues/145115

@andschwa The default in my case seems to be pinned. So in my screenshot, the default is only to show the left one, but no the right one.
But if you choose to unpin this item, the right one appears. It works when we just change the severity, text, etc. , but if we mark it busy, duplicate busy icons appear.

Here is a suggestion about the visibility, sorry for disturbing. 🙂
We find abnormal severity (error or warning) for unpinned status (which is the default behavior) is not easy to find, compared to the pinned item.
pinned error:

unpinned error:

Users will find the status easier for the pinned item than the unpinned item, since the background is different. Can we consider changing the background color of the pinned item as well? (or another way to help users find this status)


Determine Quality of Text with Natural Language Processing

Determine the quality of text outputted by pytesseract using natural language processing. This will allow for a measure of how good the output text is, and whether the program should continue on to TTS or inform the user that the scanned image was too poor of quality.
A possible package to use for this could be NLTK. An introductory tutorial can be found here

The text now gets autocorrected using the autocorrect package.

Linear searches using NLTK take far too long, although its ability to find a Jaccard index could come in handy.


Mnesia crash

Our login server based on cb, we use mnesia, we meet one problem, below is error log
2015-09-29 11:12:18.577 [error] <0.117.0> CRASH REPORT Process <0.117.0> with 0 neighbours exited with reason: {failed,{error,{file_error,"/home/longtu/ErlServer/gateway/mnesia/PREVIOUS.LOG",enoent}}} in disk_log:reopen/2 in disk_log:do_exit/4 line 1188
2015-09-29 11:12:18.578 [error] <0.105.0> Supervisor disk_log_sup had child disk_log started with {disk_log,istart_link,undefined} at <0.117.0> exit with reason {failed,{error,{file_error,"/home/longtu/ErlServer/gateway/mnesia/PREVIOUS.LOG",enoent}}} in disk_log:reopen/2 in context child_terminated
2015-09-29 11:12:18.637 [error] <0.93.0> Mnesia('master@<IP_ADDRESS>'): ** ERROR ** (core dumped to file<EMAIL_ADDRESS> ** FATAL ** {error,{"Cannot rename disk_log file",latest_log,"/home/longtu/ErlServer/gateway/mnesia/PREVIOUS.LOG",{log_header,trans_log,"4.3","4.12.4",'master@<IP_ADDRESS>',{1443,496338,568410}},{file_error,"/home/longtu/ErlServer/gateway/mnesia/PREVIOUS.LOG",enoent}}}

2015-09-29 11:12:28.617 [error] <0.93.0> Mnesia('master@<IP_ADDRESS>'): ** ERROR ** mnesia_event got unexpected event: {'EXIT',<0.96.0>,killed}

2015-09-29 11:12:28.617 [error] <0.93.0> CRASH REPORT Process mnesia_event with 0 neighbours exited with reason: killed in gen_event:terminate_server/4 line 302
2015-09-29 11:12:28.618 [error] <0.90.0> CRASH REPORT Process <0.90.0> with 0 neighbours exited with reason: killed in application_master:terminate/2 line 227
2015-09-29 11:13:30.141 [error] <0.205.0> gen_server lib_game terminated with reason: {aborted,{no_exists,[server,1]}} in mnesia:abort/1 line 310
2015-09-29 11:13:30.142 [error] <0.205.0> CRASH REPORT Process lib_game with 0 neighbours exited with reason: {aborted,{no_exists,[server,1]}} in gen_server:terminate/7 line 804
2015-09-29 11:13:30.142 [error] <0.55.0> Supervisor boss_sup had child lib_game started with lib_game:start_link() at <0.205.0> exit with reason {aborted,{no_exists,[server,1]}} in context child_terminated
2015-09-29 11:33:00.768 [error] <0.147.0> gen_server <0.147.0> terminated with reason: {aborted,{no_exists,account,attributes}} in mnesia:abort/1 line 310
2015-09-29 11:33:00.768 [error] <0.147.0> CRASH REPORT Process <0.147.0> with 0 neighbours exited with reason: {aborted,{no_exists,account,attributes}} in gen_server:terminate/7 line 804
2015-09-29 11:33:00.768 [error] <0.142.0> Supervisor {<0.142.0>,poolboy_sup} had child boss_db_controller started with {boss_db_controller,start_link,undefined} at <0.147.0> exit with reason {aborted,{no_exists,account,attributes}} in context child_terminated

Anybody meet this problem?
Similar prolem in RabbitMQ:
http://comments.gmane.org/gmane.comp.networking.rabbitmq.general/28794
http://comments.gmane.org/gmane.comp.networking.rabbitmq.general/21366

I think the key of this problem is when rename LATEST.LOG to PREVIOUS.LOG, PREVIOUS.LOG not exist, then get a error enoent.
Read mnesia doc, some instructions about log file:
Log File

When starting Mnesia, a .LOG file called LATEST.LOG is created and placed in the database directory. This file is used by Mnesia to log disc-based transactions. This includes all transactions that write at least one record in a table that is of storage type disc_copies or disc_only_copies. The file also includes all operations that manipulate the schema itself, such as creating new tables. The log format can vary with different implementations of Mnesia. The Mnesia log is currently implemented in the standard library module disk_log in Kernel.

The log file grows continuously and must be dumped at regular intervals. "Dumping the log file" means that Mnesia performs all the operations listed in the log and place the records in the corresponding .DAT, .DCD, and .DCL data files. For example, if the operation "write record {foo, 4, elvis, 6}" is listed in the log, Mnesia inserts the operation into the file foo.DCL. Later, when Mnesia thinks that the .DCL file is too large, the data is moved to the .DCD file. The dumping operation can be time consuming if the log is large. Notice that the Mnesia system continues to operate during log dumps.

By default Mnesia either dumps the log whenever 100 records have been written in the log or when three minutes have passed. This is controlled by the two application parameters -mnesia dump_log_write_threshold WriteOperations and -mnesia dump_log_time_threshold MilliSecs.

Before the log is dumped, the file LATEST.LOG is renamed to PREVIOUS.LOG, and a new LATEST.LOG file is created. Once the log has been successfully dumped, the file PREVIOUS.LOG is deleted.

The log is also dumped at startup and whenever a schema operation is performed.

So, I think PREVIOUS.LOG is a tmp log, why need it exist?

i think you better ask on erlang mailling list, you will have better answer.

it's not a CB issue, so it's better to follow @mihawk's advice


Title: add option to center relative to figure instead of data area

suggested by @jaguarxii in #364

I'm adding this feature to the next release. If you can think of a better name for it, let me know!
formsPlot1.Plot.Axes.Title.FullFigureCenter = true;

default
FullFigureCenter


BareFoot with H2GIS

Hi,
H2GIS is a 100% java standalone spatial database able to [import openstreetmap data][1] . Can you give us some guidelines in order to link through jdbc barefoot to a localhost h2gis database then doing map matching ?
Thanks
[1]:http://www.h2gis.org/docs/dev/OSMRead/

Have a look to the PostGISReader (https://github.com/bmwcarit/barefoot/blob/master/src/main/java/com/bmwcarit/barefoot/road/PostGISReader.java) and implement your own Reader variant, that should implement the RoadReader interface. If you're using the stand-alone server you also need to replace the map loading in ServerControl (https://github.com/bmwcarit/barefoot/blob/master/src/main/java/com/bmwcarit/barefoot/matcher/ServerControl.java). That should do it.
Please feel free to branch it and make a pull-request, or submit your code in any other way!

Nice, thanks for your help !
Maybe I will write a gpl standalone project with barefoot and embedded h2gis for a single jar deployment solution.


About assigning value to a tensor

Thank you for the awesome package! I'm programming using MXNet and have a question about the way we assign value to tensor, e.g. https://github.com/dmlc/mxnet/blob/master/python/mxnet/optimizer.py#L166 Can we directly access the original value without [:] added? I've tried that and find no problem. But https://github.com/dmlc/mxnet/blob/master/doc/tutorial/new_op_howto.md points out that adding [:] is a necessity. I must have missed some critical part of the design.

with out [:] you are allocating a new ndarray (or numpy.ndarray) to store the results. This will hurt performance and sometimes correctness.
I would keep the [:] unless I really want to allocate a new array

Without [:], actually what was happened was the old ndarray is discard, and the variable now stores an float value in python. So the correctness of code depend on how you use it

Thank you very much @piiswrong @tqchen ! I've figured out the difference now.


fix(pwa): avoid caching large files

Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Improvement (refactoring and improving code)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

Description
I'm going to try to solve an issue related to caching files that are chunked for transfer (usually they have a 206 status) that we have discussed here GH-1651. To avoid this error, we should only cache files that have a response code of 200.

@cotes2020 What do you think if I fix the 206 code to filter the request and finalize this PR, but create a new discussion to find a better solution?

@cotes2020 What do you think if I fix the 206 code to filter the request and finalize this PR, but create a new discussion to find a better solution?

I didn't elaborate on this much, but I have seen the problem in action as it causes errors for newly developed features and so should be fixed before release, I think.
Is there anything else we should fix except 206? I mean maybe it's a good idea to fix what we have discovered so far only?

The comments I left above were mainly to get your opinions on whether there is a better solution.
Unless you have a better way, detecting whether the response status code is 206 is an acceptable solution.

If innerResponse’s status is 206, return a promise rejected with a TypeError.
Ref: https://w3c.github.io/ServiceWorker/#cache-put

@cotes2020 added the changes to your comment

Sorry guys, I made a mistake while reviewing, returning directly after event.request.headers.has('range') is met would have the undesirable result that fontwesome styles could not be cached.
So, I'm going to rewrite this commit to fix this issue.


The new console warnings have a huge amount of false positives

How often can you reproduce it?

[ X ] Always
[ ] Sometimes
[ ] Rarely
[ ] Unable
[ ] I didn’t try

Description:
The console warnings are drowning us in useless errors like:
 title="" is deprecated. Use title:from="''" instead
Thousands of lines of warnings for every prop that is not a stache binding.
Note, that the above is a custom tag and not a standard HTML tag.

Environment:

Software
Version

donejs -V
1.1.0

node -v
8.4.0

npm -v
5.5.1

Browser

Operating system
Ubuntu 14.04.5 LTS

@justinbmeyer @chasenlehara @phillipskevin Anyway we can check to see if the ViewModel contains the property before we give this warning? Multiple people have complained about it being too verbose.

Perhaps we should just remove this warning for now until we find a better solution.


regression: removed test run is not removed from the page automatically

After removing test run it still present on the view until page is refreshed.
All removed test runs should be deleted from page asap

@vdelendik Could you re-check and confirm if issue is already solved. Thx.

Not repro


[WIP]: support “standard” footnotes

(I'll update this PR description over time as I add to it. For now, it's just the description of the first commit: tests!)

[ ] Resolves #20
[ ] Resolves #142
[ ] Resolves #530

Introduce tests for standard footnotes
Starting with the existing footnotes test suite, write tests for an implementation which matches the behavior of footnotes from other major implementors, including e.g. markdown-it and GitHub-Flavored Markdown. These "standard" footnotes:

are block items which behave like lists, and may have arbitrary blocks nested within them
include back-reference links, using the now-standard ↩ character, which include aria-label="back to content" and role="doc-backlink" to support better screen-reader feedback
appear in an ordered list at the end of the document, rather than inline in the flow of the text, which list is preceded by an hr

Additionally, these footnote links and back-link are disambiguated from other possible in-document links (e.g. heading links) by incorporating fn- at the start of the link name.
Finally, I fixed the descriptive text of the existing footnotes' spec for the multiple-paragraphs case, because it does not in fact support multiple paragraphs!

An observation here – @marcusklaas @raphlinus I’d be curious to get your thoughts on this:
The current implementation of HtmlWriter::run effectively hard-codes the implementation of footnote output, and indeed all output—it more or less assumes that that output is non-conditional, and certainly not configurable. I also know that configuration of the output has been generally viewed as non-desirable in the past, and I would broadly agree with that design: people can implement their own custom writers in general, and that's fine. However, in the case of the alternative (more standard) footnote design, FootnoteDefinitions must have a different HTML representation than they do in the current output, and that can only be specified via a configuration choice as the design of pulldown-cmark stands today.
The body of the footnote is not a problem: as long as the updated parsing I'm working on correctly generates events within the block, the writer will emit them and then emit the footnote definition closing tag appropriately. It's only an issue for the open and close of the definition tag.
(As an aside, and related to #517, it's actually very helpful to have the name of the footnote in the closing tag for the more-standard footnotes design, as it makes it easy to generate the back-reference link.)
For now, to keep making forward progress, I'm going to simply update the main invocation to take some kind of configuration here, but it's definitely a thing we'd need to resolve before merging (once I get it working of course).

Hmm. It occurs to me as I'm a good chunk of the way through implementing the output that in fact the key is to just avoid emitting those events! That is, instead of emitting FootnoteDefinition, the parser should simply emit the sequence of bog-standard HTML events. For my own easy reference, esp. since it may be this time next month before I finish this 😬:

Event::Rule
Event::Html("
)
Event::Start(Tag::List(1))
Event::Start(Tag::Item)
(body of the item, usually but not always a paragraph...)

if it ends with a paragraph:

the return
Event::End(Tag::Paragraph)

otherwise, just the return  `Event::Html("<a href=""

Event::End(Tag::Item)
Event::End(Tag::List)
Event::Html("
")

Where the return  is roughly:
Event::Html(r##" <a href="#fn-<name>-ref" class="footnote-backref" aria-label="back to content" role="doc-backlink">↩"##)

Here's a question: what should we emit for this?

I actually really like the decision GitHub has made here: "naming" (by number) the return link:

Rendered markup, stripped of GH-specific bits:

What up my young youngs.1 ATP theme.1

Footnotes

A silly song. ↩ ↩2

markdown-it names the reference itself but not the return link, which is quite unhelpful IMO. Potentially we could do both: if there are multiple references to the same link, match the name of the reference and the return value so that people can keep track of it.

Hey Chris, big thanks for creating this pull request and starting the work on giving the footnotes a facelift. I have gone through most of your posts here and I think many of your considerations are sound. I am very happy to see that you've familiarized yourself with previous discussions we have had, so you're not missing anything that has already been tried or ruled out.
I don't have time right now to go through the changes you've made so far, but I wanted to let you know that we are very excited to have someone work on this, so that we can bring the footnotes implementation in line with other parsers. I hope to get to it in the next few days!

No worries on the delay; as you can tell I have significant delaying factors myself. One of the things that I noticed when working through and evaluating next steps is that we would basically have to rewrite the tree every time we encounter a footnote definition, carrying around the extra state to support it. I think that's doable, but it's going to be a non-trivial amount of work to do it and get it right (and not mess up everything else 😂), so it'll likely be my next investment day (Dec. 10th) before I keep moving on this.

When you mention rewriting the tree, is it for the purpose of doing backreferences? That does sound computationally expensive..
The way I had in mind to do backreferences is to basically cache all events, put them in a vec and capture all references to footnotes. Then, go back to the footnotes in the event vec (maybe with an index?) and add the backrefs there. It's also not the best from a performance standpoint, but it may be quicker. But it does force us to consume all events in one go...
Now that I think of it, indeed, updating the tree in place may be preferable. Especially if we can be a bit smart about looking up the footnote definitions. I am curious what you'll come up with!

Yeah, there are two specific things which make it particularly tricky:

Backreferences, for the reasons you covered.
The existing approach wants to just emit the stream of events as it builds them from the tree, which is lovely for consumers, but that means that somehow you have to build up a stream of extra events to handle at the end, consisting of footnote definitions which will be emitted as list items which also track reference order.

It may be possible to simply push definitions into another data structure, and to also keep track of the order in which references are emitted, and that would be preferable in terms of costs I think—but it wasn't totally obvious to me how I would pull that off. I’ll be pushing at this again on my investment time this Friday, so I’ll see how far I get with one or the other approaches.
In sum, though, “standard” Markdown footnotes are the kind of thing which more or less require you to make a full pass for them, as far as I can tell, and there's not quite enough information from the first pass to do it as things stand.

All right, after a looooong hiatus I have picked this back up, and I wanted to note a couple significant things that I did in the course of this evening's work. (These are pulled directly from the commit messages, but surfaced here for easier discussion.)

I introduced callbacks to handle broken footnotes. I think we need this minimally to be able to provide useful feedback when there are unused definitions or undefined references.
Given the additional complexity this requires, instead of adding yet more new_with_* variations, introduce a ParserBuilder which allows a user to set up a Parser instance like so:
let parser = ParserBuilder(text)
    .with_options(some_options).
    .with_broken_link_callback(a_broken_link_callback)
    .with_broken_footnote_callback(a_broken_footnote_callback)
    .build();

(This can also work for the existing cases, but they are left as is for this change.)
To enable making the builder robust, I extracted a new type alias, BrokenLinkCallbackFn, representing the type which is wrapped in an Option by the existing BrokenLinkCallback type, and did the same for the two new callbacks allowed.
Obviously this marks a relatively significant change to the public API, but I think it's reasonably well-warranted, and it is totally backwards compatible.

Emitting "standard" footnotes requires rewriting the tree by moving the body of each definition to an appropriately-ordered list at the end of the tree, rather than inline in the body of the document. Accordingly, I introduced two new data structures in the parser module:

ParsedFootnotes: a struct the parser can push definitions into as it traverses the tree and emits items initially. When encountering a footnote definition or a footnote reference, it pushes them into the appropriate field on the ParsedFootnotes type:

a HashMap for the definitions, where the key is the definition name and the value its body

a Vec of references, so that the order which footnote references appear in the body of the text is maintained so that they can be numbered appropriately and

EmittableFootnotes: a struct with three fields:

a Vec of footnote definitions used in the text, consisting of:

the Vec<Item> making up the body of the definition

the corresponding Vec of back-reference names, which can be used to generate back-reference links

a Vec of undefined references, which can be normalized, warned on, or any other option using the callback introduced in the previous commit

a HashMap of definition names and bodies for unused footnote definitions, which can likewise be

This provides all the information needed to correctly emit footnotes definitions in the correct order and with the correct structure at the end of the parse tree. (It does not include enough information to emit the correct numbers for footnote reference text, but I believe the existing parser infrastructure already handles that?)
Now, the big thing to note here is the data structures. I tried to make this as lean as possible, using only moves and using a HashMap<CowStr<'a>, usize> to index into the list of used footnotes while building up the list to emit, but I would very much welcome feedback on that point.

I don't know whether this burst of energy will continue in the week ahead, but I'm hoping so: I would really like to get this across the line sometime soon so that I can actually use this library both for my own projects and in the context of Zola!

Oooh, happy to see more progress on this. I will try to take some time this week to have a first look at the code!

Okay, I took some time before work this morning and saw how far I could get with the data structures I have, and the answer is: they have all the data we need (:tada:) but none of the existing infrastructure around the Iterator for Parser is ready for this short of actually rewriting the end of the tree. Unfortunately, I do not yet see a clear path to doing that, because that also involves rewriting the allocations. (I’m sure it’s possible, I just don’t yet have enough of the context loaded to see where and how I need to do that.)

What's the status on this? I would love to see this get addressed. Right now I'm seriously missing the use case described by the last 2 points listed in the OP (having the "back to text" link and collecting them all at the bottom of the text).

s/radically/realistically/

It would be nice to have specified here the differences with #654, thanks.


Using gui feature

how to use gui feature?
I tried to use tkinter but it keep prints no display module

Read this section: https://github.com/bajrangCoder/acode-plugin-acodex?tab=readme-ov-file#how-to-run-gui-apps-in-acodex

I followed the instructions but only I can see is black screen
can you make a tutorial video?


WARNING: polling: none_stop parameter is deprecated. Use non_stop instead

related: https://github.com/eternnoir/pyTelegramBotAPI/pull/1551

released in https://github.com/eternnoir/pyTelegramBotAPI/releases/tag/4.6.0


Cosmetic Changes for GQL

Remove data type from function names
generate_schema_dict -> parse_schema
generate_schema_str -> generate_schema

There are multiple names to consider for replacing _Types:
allowed_keys = ["_Interfaces", "_Types", "_Scalars", "_Enums", "_Inputs"]
schema_dict = select_keys(schema_dict, *allowed_keys)
dispatch = {
    "_Interfaces":  parse_interfaces_or_types["interface"],
    "_Types":       parse_interfaces_or_types["type"],
    "_Scalars":     parse_scalars,
    "_Enums":       parse_enums,
    "_Inputs":      parse_inputs,
}

There are multiple names to consider for replacing _Types:
allowed_keys = ["_Interfaces", "_Types", "_Scalars", "_Enums", "_Inputs"]
schema_dict = select_keys(schema_dict, *allowed_keys)
dispatch = {
    "_Interfaces":  parse_interfaces_or_types["interface"],
    "_Types":       parse_interfaces_or_types["type"],
    "_Scalars":     parse_scalars,
    "_Enums":       parse_enums,
    "_Inputs":      parse_inputs,
}

Yeah we can just change the _ prefix with GraphQL for all of them, I think.

The one comment I have both of these functions have the suffix schema but one works on a string and the other on a dict. So not sure if this is clear enough for usage by users. @UlfBissbort what do you think?

My thinking is that, the "schema string" is commonly known as THE schema by most people. so parse_schema is parsing THE schema while generate_schema is generating THE schema


Resolve warnings in the Concurrency runtime

Squashes a few warnings in files under stdlib/public/Concurrency/.

@swift-ci please smoke test


different mode for share memory and socket

I select different mode for share memory and socket by edit $ROS_ETC_DIR/transort_mode.yaml inside of docker. I select the socket but the config is no effect.

Please confirm whether communication type for the topic is intraprocess, you can get the information by executing the command "rostopic info topic_name". According to our design, intraprocess topic will not communicate based shm mode.

$ rostopic info chatter
Type: pb_msgs/perf
Publishers:

/talker (http://in_dev_docker:44125/)
Subscribers:
/listener (http://in_dev_docker:33207/)

I do the test transport time about share memory and socket.but I get different result inside of docker and outside of docker.
inside of docker

data
share memory
socket

5m
23ms
26ms

10m
47ms
90ms

15m
71ms
1461ms

20m
95ms
4570ms

outside of docker

data
share memory
socket

5m
21ms
23ms

10m
45ms
46ms

15m
69ms
69ms

20m
92ms
92ms

Would you pack the complete test program and provide for us? my email address is<EMAIL_ADDRESS>If convenient, please tell us the detailed test process, thank you!

@bjtulynn  thanks you! I has been sent an mail

Closed due to no response for a while, please reopen it if you still have questions. Thanks!


Fix pipeline.editorial.get_media_range_with_retimes with image sequence and FreezeFrame/LinearTimeWrap to 0

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior:
There seems to be an issue currently when publishing a plate product from an image sequence with a freeze_frame effect to it.
Publish Logs
publish-report-240918-17-03.json
Serialized OTIO clip to reproduce the clip:
img_sequence_freeze_frame.json
Error I get:
ayon_core.pipeline.publish.publish_plugins.KnownPublishError: Files of representation does not contain proper sequence files.
Collected collections:
Collected remainders: output.1000.tif

Expected Behavior:
The image sequence goes from output.1000.tif to output.1100.tif and I froze the first frame.
So I guess only output.1000.tif should be exported as plate ?
Version
1.0.0
What platform you are running on?
Windows
Steps To Reproduce:

Create a clip from an image sequence in Resolve
Ensure clip speed is edited to 0%
Try to publish the resulting clip as a plate

Are there any labels you wish to add?

[X] I have added the relevant labels to the bug report.

Relevant log output:
No response
Additional context:
No response

This is in core but has label Resolve. Do we need to move it @robin-ynput ?

No this can be triggered from Resolve but the function to debug is in ayon-core. I'm quite sure this means the same issue goes with Hiero and Flame.


Insert issue

When i try to insert js code inside my blog it's Show 403 error why how can i post js code inside insert function?
Forbidden
You don't have permission to access this resource.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.

Hi @tonmooy ,
Are you sure that issue is about PDOx library ?

Hi @tonmooy ,
Are you sure that issue is about PDOx library ?

yes please give me a solution 😟 try to insert some js tag inside using $_POST method

Hi @tonmooy ,
Are you sure that issue is about PDOx library ?

is it host problem or anything else?

it's work on local host but in namecheap  host it's show this error

I think this problem might be related with web server security. Pdox has no restriction like that. Maybe you can check your web server configuration or security level.


Switch  ->  for javadoc

We don't have a particular need to use the /-linkOffline
capability and it doesn't work as currently written so let's just use
regular  for now and we can revisit this later if we need to.
Testing Done:

ran the javadoc:javadoc build, verified the link errors went away

LGTM


Add ability to modify permalink

It would be nice to be able to specify a desired permalink (ex: /feed/) instead of the default /feed.xml. I'm not sure how this would work out with a permalink structure defined in config.yml, but it would probably have to play nicely with that as well.

You can! See https://github.com/jekyll/jekyll-feed#already-have-a-feed-path.

Well I did see that but you aren't able to specify something like /feed/ and receive the desired result. Doing so built a feed directory, but inside was an index file (note: no .html file extension).
Here's what's in my config:
gems:
    - jekyll-feed

feed:
    path: /feed/

Have you tried?
feed:
  path: /feed/index.xml

Hmm interesting. /feed/index.xml does indeed output correctly. For some reason I wasn't thinking and was trying /feed/index.html, but that incorrectly outputs feed > index > index.html.
I'm not sure if that qualifies as a bug or not, but at the very least the documentation could be clarified a bit.


Fix/smoke test

Correct erroneous reference to company-mode in https://github.com/raxod502/straight.el/commit/acd268e851d46beb1accb29d410d83c4eb8ef48c

Rolled this in #535 and #549, but I'm still getting CI errors:
Makefile:96: recipe for target 'docker' failed
make: *** [docker] Error 2

Oops. Thanks, and I'll take a look at the remaining problem

Are you sure? It works for me locally, and your pull request's build seems to be passing on all versions.

Re: company VS comapny-mode: https://github.com/search?q=use-package+company-mode&type=Code
I don't believe straight provides a recipe for "company-mode".
Don't know about the docker issue.

No, your pull request definitely fixed a bug; the package name is definitely company rather than company-mode, as you said. What I'm saying is CI is no longer reporting the error you mentioned in https://github.com/raxod502/straight.el/pull/554#issuecomment-671081631.

straight.el throws following package-lint errors. Perhaps they are relevant?:
5763:24: error: You should depend on (emacs "25.1") if you need `package--ensure-init-file'.
5765:24: error: You should depend on (emacs "25.1") if you need `package--save-selected-packages'.
5769:23: error: You should depend on (emacs "25.1") if you need `package--ensure-init-file'.
5771:23: error: You should depend on (emacs "25.1") if you need `package--save-selected-packages'.

Oddly enough, the smoke test seems to pass on my local machine as well.
make docker VERSION=24.5 puts me at a docker shell. make smoke from there passes.

I think I see what's happening now:
In toplevel form:
straight.el:4088:1:Warning: Unused lexical variable `local-repo'
straight.el:4088:1:Warning: Unused lexical variable `package'
In straight--run-build-commands:
straight.el:4117:34:Warning: reference to free variable `repo'
Makefile:30: recipe for target 'compile' failed

Probably a byte-compilation bug in 24.5 when using cl-destructuring-bind

Found it. Addressed in #557


fix boolean type offset [maxmind GeoIP2-Anonymous-database not working #12]

Maxmind db boolean type description
"boolean 14 - A true or false value. The length information for a boolean type will always be 0 or 1, indicating the value. There is no payload for this field."
There is no payload for boolean type, so offset shouldn't be incremented by length.
Guess this breaks for all database having boolean values. Tested with Maxmind Anonymous IP and City database seem to be working fine.
Please let me know if i could help with any other testing.
@daurnimator

Could you add a comment to the code quoting the spec?

sure. done

Minor things:

Could you wrap the comment line
Please squash your change into a single commit
Follow repository convention and use a commit message that is prefixed with the file you've changed

done


feat: add documentation

Updated the README.md with some pertinent development and benchmark information
Added a missing license identifier
Fixed clippy lint errors

The looks good to me. I run the docs through Grammarly, those changes are all Grammarly.
I would have preferred to have 2 PR's here one for Docs, one for Clippy fixes, or at least have them split into two separate commits. But luckily all changes where still small.

Yes, agreed and nice touch verifying with Grammarly, thanks.


Multipart fields with brackets in names

Trying to simulate browser file upload request, it is sending multipart fields like that:
------WebKitFormBoundaryVUPdjEIH1BKgPvL1
Content-Disposition: form-data; name="category[]"

1
------WebKitFormBoundaryVUPdjEIH1BKgPvL1
Content-Disposition: form-data; name="category[]"

4

In needle file options I'm declaring category field:
let file = {
  ...
  category: ['1'],
  ...
}

And when I'm inspecting in debugger, it shows that request was sent like that:
----------------------NODENEEDLEHTTPCLIENT
Content-Disposition: form-data; name="category[0]"

1

Is this intentional (I mean index number in brackets)?
Because I have response from server to select a category after this request.

Yes this is intentional, but the behavior on the server side shouldn't differ. Are you not getting an array at params.category? What type of server are you running?

Unfortunately server is not mine, I'm just automating some browser task, for this part I did not tested much and switched to request module.

Sure, no problem. I just don't see where/what the problem is, since the end result from the server side should be the same.


Fix config/manager/kustomization.yaml

By mistage introduced with:
https://github.com/openstack-k8s-operators/openstack-operator/commit/26d2e0ea06195343748fd8c3715a0e5d0d6847c1#diff-14effe9ea1a3ddb6e419e627a3501a6c42aa2dcbc76803923e9aff2438e6ee34L15

/retest


Possibly a small mistake in Method 2

Hello,
Some adjustments were made to this document following issue #81236. Thank you for this!
I think a small error remains in the new version if you wish to take a look.

Assign the group as eligible for a role through PIM. Everyone in the group gets access to the role assignment at once when the group's assignment is activated. This path requires a role-assignable group for the Azure AD role, and a security group for Azure resources.

When you assign a group as eligible, every group member receives the eligible assignment. It is visible in "My roles" for each member. However, each member still has to activate their role individually.

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

ID: 3f2bcbe3-6edd-c413-390b-ae70b8dc3bbb
Version Independent ID: 0b0b0feb-26a1-68cb-18dc-4f3fc7c96f3a
Content: What's the difference between Privileged Access groups and role-assignable groups - Azure AD
Content Source: articles/active-directory/privileged-identity-management/concept-privileged-access-versus-role-assignable.md
Service: active-directory
Sub-service: pim
GitHub Login: @curtand
Microsoft Alias: curtand

@matflol
Thanks for your feedback! We will investigate and update as appropriate.

Thanks! I made a pull request to update this. https://github.com/MicrosoftDocs/azure-docs-pr/pull/183234
@curtand please review.


Refactor rg-header to work with ui-router and state. Removes complexi…

Refactor rg-header to work with ui-router and state. Removes complexity of transcluding attributes in favour of simple angular models. Update demo and tests.

@gregbenner no merge on this, you need to be able to set is-active="true" not just using sref this is a feature for Create and can't be removed can you please ensure that this is still possible

yeah go for it cheers :+1:

Ready from my point of view for merge but please also check this if you want to merge https://github.com/rockabox/rbx_campaign_management/pull/268 should be done in parallel.

@nwhite89 I ended up resolving with ng-if to avoid conflicts between href and lack of ui-sref, should be good to go.


Fix for None datatype in _parse_job_results()

Description
Adding an exception handler to catch datatype errors with jobs where details is None.
Motivation and Context
Resolve bug described in #470
How Has This Been Tested?
The command that encountered the issue were rerun and the response was successful.
download_cmd = "<request><plugins><download><file>vm_series-2.1.2</file></download></plugins></request>"
download_response = parent.op(download_cmd, cmd_xml=False)
download_result = parent.syncjob(download_response)

Successful download response
{
   "success":true,
   "result":"OK",
   "jobid":"18",
   "user":"None",
   "warnings":"None",
   "starttime":"2022/07/26 08:58:18",
   "endtime":"08:58:19",
   "messages":[

   ],
   "devices":{

   },
   "xml":"<Element""response"at 0x7f68569ca180>
}

Tested against panos 9.1 using the pan-os-python poetry venv.
This is very small and self contained change and won't affect other parts of the code base.
Screenshots (if appropriate)

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist

- [ ] I have updated the documentation accordingly.

[x] I have read the CONTRIBUTING document.
- [ ] I have added tests to cover my changes if appropriate.
- [ ] All new and existing tests passed.

I had a similar issue.
Can @shinmog or @btorresgil review?


Appliance ON / OFF

Hello,
I am inquiring about : Fridge / Television / Office PC.
I merged these together and did k-means clustering (80% Train and 20% Test) for 8 clusters.
The clusters (8) being: Fridge / Television / OfficePC / Fridge + Television / Fridge + OfficePC / OfficePC + Television/ Fridge + Television + OfficePC / Nothing.
The issue is that all three appliances are always turned on (there is always "active_power"). Is there some sort of threshold for each appliance? How could I find these thresholds?
Thanks,
Marcia

I am not really sure what you mean. The devices draw variable power depending on their current state (e.g. the television depending on the content of the TV and brightness setting etc., the office PC depending on what is computed...) K-means will not be able to detect these appliances based on active power alone. Furthermore, whenever you use aggregated data you would need to use the delta power but I guess you are aware of that.


Feature: Ability to Rename a StarSearch Conversation

As a user of StarSearch, I want the ability to rename a conversation so that I can more easily identify it in the list of my past conversations with StarSearch.

Looking at the different platforms, ChatGPT offers delete, rename, and archive

whereas Gemini offers pin and rename

and Claude AI offers rename and delete.

Building off the work in #3527 we should consider allowing the renaming of a StarSearch conversation via a PATCH endpoint, e.g.
PATCH /v2/star-search/<uuid>/stream


Pub get error

I get this error while installing this package and its dependencies.
Cannot open file, path = 'C:\flutter\.pub-cache\_temp\dir5ba449a4\test\fixtures\invalid\n_structure_<.>.json' (OS Error: The filename, directory name, or volume label syntax is incorrect.
, errno = 123)
pub finished with exit code 66

I have tried everything based on previous answers related such as
flutter clean
flutter pub cache repair

Also deleting pub cache folder. Nothing worked. The issue comes only when I install this image_editor_pro plugin. It is not the case with any other plugin. I thought there is some bug with this plugin. Surprisingly, no one else reported this issue. So please help me if someone tried to resolve this

Same with my case too.. unable to solve with cache clear.

I have resolved it. You can download it from here - https://drive.google.com/file/d/1DV1OsriI0su3Is13j65NpOpabRlOhDTZ/view?usp=sharing
Now it will work with flutter 2.5
Enjoy :)

I have resolved it. You can download it from here - https://drive.google.com/file/d/1DV1OsriI0su3Is13j65NpOpabRlOhDTZ/view?usp=sharing
Now it will work with flutter 2.5
Enjoy :)

Thanks for your time on this. By any chance, you have it GitHub so that it can be used directly in pubspec.yml and contribute too?

Is it working properly for you @Purus ?
@jackeychina  I am getting this error while uploading pubspec via path.
Running "flutter pub get" in editing_pro...
Because every version of image_editor_pro from path depends on firexcode from path which is forbidden, image_editor_pro from path is forbidden.
So, because editing_pro depends on image_editor_pro from path, version solving failed.
pub get failed (66; So, because editing_pro depends on image_editor_pro from path, version solving failed.)
exit code 66

This is the pubspec file
version: 1.0.0+1

environment:
  sdk: ">=2.15.0-285.0.dev <3.0.0"

# Dependencies specify other packages that your package needs in order to work.
# To automatically upgrade your package dependencies to the latest versions
# consider running `flutter pub upgrade --major-versions`. Alternatively,
# dependencies can be manually updated by changing the version numbers below to
# the latest version available on pub.dev. To see which dependencies have newer
# versions available, run `flutter pub outdated`.
dependencies:
  flutter:
    sdk: flutter

  # The following adds the Cupertino Icons font to your application.
  # Use with the CupertinoIcons class for iOS style icons.
  cupertino_icons: ^1.0.2
  image_editor_pro:
   path: "C:/Users/Avilain/Downloads/ImageEditorPro-master_solved/ImageEditorPro-master_solved"

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^1.0.0

# For information on the generic Dart part of this file, see the
# following page: https://dart.dev/tools/pub/pubspec

# The following section is specific to Flutter.
flutter:
  uses-material-design: true

I have resolved it. You can download it from here - https://drive.google.com/file/d/1DV1OsriI0su3Is13j65NpOpabRlOhDTZ/view?usp=sharing
Now it will work with flutter 2.5
Enjoy :)

Thanks for your time on this. By any chance, you have it GitHub so that it can be used directly in pubspec.yml and contribute too?

No i haven't created separate git to maintain or contribute. If you want then you can do it.

Is it working properly for you @Purus ? @jackeychina I am getting this error while uploading pubspec via path.
Running "flutter pub get" in editing_pro...
Because every version of image_editor_pro from path depends on firexcode from path which is forbidden, image_editor_pro from path is forbidden.
So, because editing_pro depends on image_editor_pro from path, version solving failed.
pub get failed (66; So, because editing_pro depends on image_editor_pro from path, version solving failed.)
exit code 66

This is the pubspec file
version: 1.0.0+1

environment:
  sdk: ">=2.15.0-285.0.dev <3.0.0"

# Dependencies specify other packages that your package needs in order to work.
# To automatically upgrade your package dependencies to the latest versions
# consider running `flutter pub upgrade --major-versions`. Alternatively,
# dependencies can be manually updated by changing the version numbers below to
# the latest version available on pub.dev. To see which dependencies have newer
# versions available, run `flutter pub outdated`.
dependencies:
  flutter:
    sdk: flutter

  # The following adds the Cupertino Icons font to your application.
  # Use with the CupertinoIcons class for iOS style icons.
  cupertino_icons: ^1.0.2
  image_editor_pro:
   path: "C:/Users/Avilain/Downloads/ImageEditorPro-master_solved/ImageEditorPro-master_solved"

dev_dependencies:
  flutter_test:
    sdk: flutter
  flutter_lints: ^1.0.0

# For information on the generic Dart part of this file, see the
# following page: https://dart.dev/tools/pub/pubspec

# The following section is specific to Flutter.
flutter:
  uses-material-design: true

My flutter version is 2.6.0-12.0.pre.701

You do not have to define whole C drive path. Kindly check my code .

I am still having the same issue as before. I am trying in Windows 10.
I updated the path of firexcode in ImageEditorPro-master_solved/pubspec.yaml to refer the correct path. But after that, i get the initial error.
Cannot open file, path = 'C:\flutter\.pub-cache\_temp\dir5ba449a4\test\fixtures\invalid\n_structure_<.>.json' (OS Error: The filename, directory name, or volume label syntax is incorrect.
, errno = 123)

Cannot open file, path = 'C:\flutter.pub-cache_temp\dir5ba449a4\test\fixtures\invalid\n_structure_<.>.json' (OS Error: The filename, directory name, or volume label syntax is incorrect.
, errno = 123)
pub finished with exit code 66


some gnmi.Get() call is replaced by gnmi.Watch() call

The test "feature/gribi/otg_tests/get_rpc_test/get_rpc_test.go" was failing against CISCO vxr dut (kne environment). The test was not getting the expected results by placing gnmi.Get() queries into the DUT. So, I replaced the "gnmi.Get()" query with "gnmi.Watch()/gnmi.Get()". Check the value is present by polling the DUT and if the value is found then fetch and compare.


Color key missing from legend box above the map

Describe the bug
Somewhere along the way we lost the words "Color key" above the blue dot in the legend box above the map on the Explore the tool page.
To Reproduce
Steps to reproduce the behavior:

Go to 'Explore the tool'
Scroll down to 'above the map'
See error in legend

Expected behavior
Add the words "Color key" back above the blue dot (see screenshot)
Screenshots
If applicable, add screenshots to help explain your problem.
Error -

Design -

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

also we can add the stroke back in around the circle.
same color as inside (1A4480), just 100% alpha.

ok cool!
Wondering that the side panel also has this circle.. we'll want to change it there as well right?

we had a reason to remove it and now I don't remember why... let's leave that as is for now? I don't know. I am decided out for today.


add main

add main as interface{},because sometime it is string,sometime it is []string

Thanks for the patch!


refact: adjust hugegraph project structure to prepare for merge PD and Store

Purpose of the PR
Subtask of #2265.
Adjust the project structure of this repository to include three sub-modules: hugegraph-server, hugegraph-pd, hugegraph-store at the root level.

Main Changes
Roll back to the moment when https://github.com/apache/incubator-hugegraph/pull/2266 was merged on pd-store and incorporate the latest changes in master.
For more detailed information, please refer to https://github.com/apache/incubator-hugegraph/pull/2266#issue-1834369489.
TODO:

[ ] check pom.xml
[x] pass required CI
[x] core (common) version

Verifying these changes

[ ] Trivial rework / code cleanup without any test coverage. (No Need)
[ ] Already covered by existing tests, such as (please modify tests here).
[x] Need tests and can be verified as follows:

CI

Does this PR potentially affect the following parts?

[ ]  Nope
[ ]  Dependencies (add/update license info)
[ ]  Modify configurations
[ ]  The public API
[x]  Other affects (breaking changes)

Documentation Status

[x]  Doc - TODO
[ ]  Doc - Done
[ ]  Doc - No Need

seems we shouldn't import guava separatly, it should be imported & define version by hugegrpah-common (could check the import, or just remove it if we already import common?)

seems we shouldn't import guava separatly, it should be imported & define version by hugegrpah-common (could check the import, or just remove it if we already import common?)

already imported in hugegraph-common (with version 30.0-jre), so removed

Also. the grpc dependencies should be imported from hugegraph-commons-rpc? (could also check & replace it) to solve the 3rd-party check

Similarly, the grpc dependencies should be imported from hugegraph-commons-rpc? (could also check & replace it) to solve the 3rd-party check

found in org.apache.hugegraph:hugegraph-rpc:jar:1.0.1 - com.alipay.sofa:sofa-rpc-all:jar:5.7.6 - io.grpc:grpc-protobuf:jar:1.28.0 (with lower version compared to hugegraph-server)

LGTM, merge it after #2337


tiles.setTilemap(x) decompilation fails

Type following code in monaco editor and go to blocks. It decompiles but the setTilemap block doesn't refer 'x'
let x = tilemap`level1`
tiles.setTilemap(x)

The block does not take an argument, it just has a field editor. This is working as intended

The block does not take an argument, it just has a field editor. This is working as intended

GIF

GIF


Update angular compiler cli

Codecov Report

Merging #1032 (080e44a) into master (93e25a2) will increase coverage by 0.71%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1032      +/-   ##
==========================================
+ Coverage   41.17%   41.89%   +0.71%
==========================================
  Files          55       55
  Lines         697      697
  Branches       43       43
==========================================
+ Hits          287      292       +5
+ Misses        406      401       -5
  Partials        4        4

Impacted Files
Coverage Δ

...s/team-member-modal/team-member-modal.component.ts
41.66% <0.00%> (+5.55%)
:arrow_up:

src/app/components/snippets/snippets.component.ts
72.22% <0.00%> (+16.66%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Az ML v2: workspace name yml property is ignored

Extension name (the extension in question)
Machine Learning v2
Description of issue (in as much detail as possible)
workspace.yml:
name: myworkspace 123

az ml workspace create --file workspace.yml

When running the above command, although a workspace name is provided in my yaml file, still a workspace-name property is looked for as shell argument which is not expected.

route to service team

@denniseik thx for reporting the issue, can you share 1) version of your ml extension and 2) exact error message you got?

Version is 2.0.1a3. Error thrown is "Workspace with name productexperimentsc already exists.", which means that my default values are used and not used what is provided in the yaml file @luigiw .

@denniseik , thx for reporting this, I was able to reproduce the behavior. It will be fixed in the next ml extension release.


ANR will occured when stopPreview with bag file

Required Info

Camera Model
{ D415 }

Firmware Version
<IP_ADDRESS>

Operating System & Version
Ubuntu 18 x86-64 LTS

Platform
Android 5.0

SDK Version
2.16.2

Language
c++/Java }

Issue Description
ANR will occured when stopPreview  with bag file
the apk source code could be found here:
https://github.com/zhouwg/irsa/blob/master/examples/irsa_example/app/src/main/java/com/android/irsa_example/MainActivity.java
the screensnap is here:
https://github.com/zhouwg/irsa/blob/master/img-folder/irsa_example.jpg

the steps to reproduce the issue:

fetch apk source code
$ git clone https://github.com/zhouwg/irsa

build apk
$ cd irsa
$ source build/envsetup.sh
$ cd examples/irsa_example
$ gradle build

3.install apk
$ ./install_apk.sh

setup envs to running apk on Android device
$ cd -
$ adb root
$ adb push doc/demo.bag /sdcard/

running apk
there are two running mode within apk:
1)default mode is fake preview mode: playback with /sdcard/demo.bag
click button "On"  --> click button "PLAY" , fake preview mode will working;

click button "STOP" , ANR would be occured.
this mode could be works fine on any common Android device without real camera hardware.
2) realsense mode with real D415 camera:
click "Realsense Preview" --> click button "On" --> click button "PLAY", the realsense mode will working.
this mode need a real D415 hardware

how to toggle two preview mode:

click "On"  -->  click "PLAY" --> fake mode working  --> click "STOP" --> click "OFF"  ---> click "Realsense Preview"  --> click "On" --> click "PLAY" --> the realsene mode will working

FA mode is disabled because of IPR policy.