Restore previously closed session's state (Buffer contents)

Lets talk about restoring the state of the terminal here.
This could arise in two scenarios I'm thinking of:

Restoring the state of a previously closed terminal session (i.e. the app was closed due to a restart, and you launch it again)
Restoring from a previously closed tab in this session (i.e. you've closed a tab, but not the app.)

1 is certainly harder than 2.
Restoring the buffer contents wouldn't be impossible, but restoring the actual state of the running executable might be impossible. IIRC @malxau has a long email from his work on yori that is relevant to this discussion.
We could certainly restore the buffer contents from file, then display some sort of message saying [Restored from previous session]. That's not that hard.

I think there are possible security considerations with this.  With that in mind, making restoring previous output seems an opt-in rather than opt-out feature seems prudent.  On Windows of course if the user's profile is BitLocker-protected, maybe it's less of an issue, but regardless worth considering.
I did enjoy this feature of Terminal.app for the few years I used a mac some time ago.

Firstly, welcome to github and the terminal project, @BEAClerbois!
Just adding to the record some of the information @zadjii-msft is referring to, I tried to implement save/restore of state as part of Yori, which is a CMD-like shell.  This was opt-in due to the security/privacy issue that @binarycrusader mentioned, and is enabled with an environment variable.  See http://www.malsmith.net/yori/guide/#env_yoriautorestart .
In that context, save/restore meant saving both terminal state as well as shell state.  Terminal state includes things like the size and position of the window, its contents, colors, and fonts.
Shell state includes things like current directory, environment, and in this case, aliases and command history.
But the real challenge is how to reason about multi-process relationships.  One example was given previously: suppose the user launches a CMD window, and within that launches Powershell.  Even if both
CMD and Powershell were capable of saving their state, the restoration process needs to include a) terminal state; b) a CMD process with its state; c) a Powershell process with its state; d) somehow get the CMD process to wait for the Powershell process to terminate.  (d) is very unnatural because on the running system the parent can only reason about the child via a handle or PID, and here neither are known until the child is running.  It's possible that I'm not thinking creatively enough, but this sounds a bit like a cyclic dependency, because on the one hand the parent process should be fully restored before the child can accept user input and terminate itself, but on the other hand, the parent process can't really know what to wait for until the child is present.
A clearer example of the same effect would be opening CMD and within that executing "vim foo".  The terminal will know about the existence of the vim process, but the meaning of "foo" depends on the current directory that vim was launched from, and that information has to come either from vim or from the parent process, and CMD needs to wait for vim.  Recovering things accurately would require coordination from three different programs.
When the multi-process relationship is outside the console, things get messier still.  The specific case that affected Yori users which I couldn't see how to handle is the Virtual Filesystem for Git agent, because launching a shell with a correct current directory does not mean the user can interact with the files there unless the agent is running.  But the agent can be launched via any mechanism which may be completely unrelated to the console, so there's no knowledge indicating it must be restored.  In the context of restoring a recently closed tab this may not be so problematic.
Obviously this is in addition to restoring state which depends on OS configuration which may not be present - having network shares, authentication, a particular IP address, a USB device attached - things that might change between attempting a save and a restore.

Thanks @malxau for the great explanation. As we can see, restoring shell state is a neigh-impossible thing to do totally correct (and why I wanted this to have it's own thread separate from #766).
However buffer content is not impossible to restore. Lets make it opt-in, in addition to opting-in to general window state restore being tracked in #766.

After sleeping on it, I started remembering even nastier cases about process relationships.  Consider pipes: "type foo | more" means saving the state of the "type" command and the "more" command and somehow recreating the pipe.  This looks like another cyclic dependency: pipes are normally created by the parent, which carefully hands one end to the child and closes it; but here we need some kind of resumable identifier that describes a pipe between two processes and can recreate that.  The "type" command, in turn, needs to know where it was within its source stream to resume from; in this example with a source file that's at least possible.
When the source stream is dynamic, finding that point becomes somewhat meaningless.  Suppose the command was "tasklist | more" - where should tasklist resume from? Its source stream has completely changed.
Agree with "neigh-impossible", and this feels like something where if we tried to solve it, it would end up being Windows-specific and a large part of the terminal effort is better interoperability with other platforms.  It seems to me like if there was a push to solve this on other platforms we can contribute to the conversation, but going it alone doesn't seem like the right thing to do.  Users would be left with an experience that only works for some programs, some of the time.

@malxau While all the complications make saving state difficult, I don't feel simply saving the tabs, tab names, panes, and their respective directories should be relatively simple.
Having different session setups could also be possible as an argument to wt, for example I could type win+r wt session foo to open the foo session. Saving could be accomplished via wt session -s foo.

@JamieGhassibi How would the terminal obtain the directory that is active within the shell processes?
I can see how this would work if the session is defined in config, but to capture the current state into the config still sounds like it's depending on capturing state from the terminal and from all of the command line processes executing within it.

I would like to see allowing a definition of tabs to be opened on startup (much like other Windows terminal applications).
As far as restoring state, I accept what happens in the terminal to be volatile. If I want the output, I capture it with the commands executed.

It would be great if the Terminal could remember:

List of tabs previously open and their current working directory
List of commands previously ran in each tab (maybe last 10-20)

The actual contents of the buffer are not as important. When I restart my computer or accidentally close the Terminal app, I just want to get back to where I was as quickly as possible.

@nmoinvaz So those two might be generically impossible for the Terminal to solve.

This thread:https://github.com/microsoft/terminal/issues/3158#issuecomment-628628120 (and the threads linked to it) has far, far too many details on why it's hard for the Terminal to get the working directory of the current process.
As far as the list of commands run, that's the shell's responsibility, not the Terminal's. The Terminal doesn't know what is and isn't a command the user entered, it only knows about a stream of input it delivered to the client application. Notably, powershell/pwsh and bash already save the command history on exit. cmd is the one notorious exception, and it's not about to be updated to add that support, since that constantly burns us. See https://github.com/microsoft/terminal/issues/217#issuecomment-404240443.

To me, this is just like how browsers allow for reopening tabs. In fact, a terminal kinda is a browser. And while restoring the session might not be easy, restoring the path (and things like the tab title: https://docs.microsoft.com/en-us/windows/terminal/tutorials/tab-title) definitely is. For my use-cases, that would already be enough

Came here looking for a save last open tabs feature. I have been using Cmder which has a option to open all last closed tabs just like in a browser, it's a really handy feature let's you get to work where you left. I don't think it restores the history of each shell but just restoring tabs and the directory I was on is massive, just like a browser doesn't save the tab state and open the website like it was when last time you loaded (it refreshes it and opens it anew)

Me it's all about the tab colors 🙈

I created #7574 because I really think that the ability to save the current session is extremely important. There are many scenarios when I as a developer could have really benefited from it. Let's say you have several servers that need to be running in order for your app to work, and you're running them all from your command line through different tabs. It's a huge pain to open these tabs and then cd to each location every time you re-boot your computer or run updates.
What would be fantastic is the ability to save the state of the terminal (ie. the tabs and each of their locations) in a config. That way when you open your terminal, you can simply run a command like: terminal-open savedConfigName and your session will be restored.

@nmoinvaz So those two might be generically impossible for the Terminal to solve.

This thread:#3158 (comment) (and the threads linked to it) has far, far too many details on why it's hard for the Terminal to get the working directory of the current process.
As far as the list of commands run, that's the shell's responsibility, not the Terminal's. The Terminal doesn't know what is and isn't a command the user entered, it only knows about a stream of input it delivered to the client application. Notably, powershell/pwsh and bash already save the command history on exit. cmd is the one notorious exception, and it's not about to be updated to add that support, since that constantly burns us. See #217 (comment).

Regarding your first point, I believe simply being able to add the location to a config file manually would suffice. There are already a lot of settings that require manual editing of JSON, so this could very well be similar in that way. Perhaps an array of file system locations, and for each item in the array, a tab would be opened to that location.

Guys, why does it take you years to implement such simple features?
It takes only 15 minutes to figure out the logic + a few hours to implement it:

Add 1 property to settings: settings: { startupAction: ('restore-last-state'|null) }
Add 1 property to globalStore (where you store shared data): globalStore: { state: Object<any> }
Store 2 state properties for each tab in memory: state: { tabs: [{ tab: { cwd: <string>, commands: Array<string> } }] }
When the state of a tab changes, write the state to storage
On app load, restore state from storage

settings.json
settings: {
  startupAction: 'restore-last-state',
}

globalStore
globalStore: {
  state: {}
}

storageData.json
{
 "state": {
    "tabs": []
  }
}

main
async function onAppLoad () {
  await initRestoreLastState()
  ...
}

async function initRestoreLastState () {
  if (settings.startupAction == 'restore-last-state') {
    globalStore.state = await getStorageProperty('state')
  }
}

async function getStorageProperty (key) {
  return JSON.parse(getStorageData())[key]
}

function onExecuteCommand (event) {
  saveTabCommand()
  saveTabCwd()
  writeStateToStorage()
  ...
}

function saveTabCommand () {
  get(stateCurrentTab).commands.push(event.command)
}

function saveTabCwd () {
  get(stateCurrentTab).cwd = getCwdPath()
}

function onNewTab (event) {
  addTab(event)
  writeStateToStorage()
  ...
}

function addTab (event) {
  let tab = {
    cwd: '',
    commands: []
  }
  tab.cwd = getCwdPath()
  globalStore.state.tabs.push(tab)
}

function writeStateToStorage () {
  if (settings.startupAction == 'restore-last-state') {
    // Avoid data corruption by writing data synchronously
    // (file might get corrupted when multiple async processes writing at the same time)
    writeStorageSync('state', globalStore.state)
  }
}
...

Guys, why does it take you years to implement such simple features?
It takes only 15 minutes to figure out the logic + a few hours to implement it:

Add 1 property to settings: settings: { startupAction: ('restore-last-state'|null) }
Add 1 property to globalStore (where you store shared data): globalStore: { state: { tabs: Array<object> } }
Store 2 state properties for each tab in memory: state: { tabs: [{ tab: { cwd: String, commands: Array<string> } }] }
When the state of a tab changes, write the state to storage
On app load, restore state from storage

settings.json
settings: {
  startupAction: 'restore-last-state',
}

globalStore
globalStore: {
  state: {
    tabs: []
  }
}

storageData.json
{
 "state": {
    "tabs": []
  }
}

main
async function onAppLoad () {
  await initRestoreLastState()
  ...
}

async function initRestoreLastState () {
  if (settings.startupAction == 'restore-last-state') {
    globalStore.state = await getStorageProperty('state')
  }
}

async function getStorageProperty (key) {
  return JSON.parse(getStorageData())[key]
}

function onExecuteCommand () {
  saveTabCommand()
  saveTabCwd()
  writeStateToStorage()
  ...
}

function saveTabCommand () {
  get(stateCurrentTab).commands.push(event.command)
}

function saveTabCwd () {
  get(stateCurrentTab).cwd = getCwdPath()
}

function onNewTab () {
  addTab(event)
  writeStateToStorage()
  ...
}

function addTab () {
  let tab = {
    cwd: '',
    commands: []
  }
  tab.cwd = getCwdPath()
  globalStore.state.tabs.push(tab)
}

function writeStateToStorage () {
  if (settings.startupAction == 'restore-last-state') {
    // Avoid data corruption by writing data synchronously
    // (file might get corrupted when multiple async processes writing at the same time)
    writeStorageSync('state', globalStore.state)
  }
}
...

Guys, why does it take you years to implement such simple, highly requested, important features?
Just like @nmoinvaz, @lukaseder, @danyalasif said above, no one asks for a complex system that messes with security, all we need is the ability to restore 2 basic properties for each tab onAppLoad event: tab: { cwd: String, commands: Array<string> }.
It literally takes only 15 minutes to figure out the logic + a few hours to implement it:

Add 1 property to settings: settings: { startupAction: ('restore-last-state'|null) }
Add 1 property to globalStore (where you store shared data): globalStore: { state: { tabs: Array<object> } }
Store 2 state properties for each tab in memory: state: { tabs: [{ tab: { cwd: String, commands: Array<string> } }] }
When the state of a tab changes, write the state to storage
On app load, restore state from storage

settings.json
settings: {
  startupAction: 'restore-last-state',
}

globalStore
globalStore: {
  state: {
    tabs: []
  }
}

storageData.json
{
 "state": {
    "tabs": []
  }
}

main
async function onAppLoad () {
  await initRestoreLastState()
  ...
}

async function initRestoreLastState () {
  if (settings.startupAction == 'restore-last-state') {
    globalStore.state = await getStorageProperty('state')
  }
}

async function getStorageProperty (key) {
  return JSON.parse(getStorageData())[key]
}

function onExecuteCommand () {
  saveTabCommand()
  saveTabCwd()
  writeStateToStorage()
  ...
}

function saveTabCommand () {
  get(stateCurrentTab).commands.push(event.command)
}

function saveTabCwd () {
  get(stateCurrentTab).cwd = getCwdPath()
}

function onNewTab () {
  addTab(event)
  writeStateToStorage()
  ...
}

function addTab () {
  let tab = {
    cwd: '',
    commands: []
  }
  tab.cwd = getCwdPath()
  globalStore.state.tabs.push(tab)
}

function writeStateToStorage () {
  if (settings.startupAction == 'restore-last-state') {
    // Avoid data corruption by writing data synchronously
    // (file might get corrupted when multiple async processes writing at the same time)
    writeStorageSync('state', globalStore.state)
  }
}
...

@aleksey-hoffman we await your pull request! Thanks!

If it'll only take a few hours to implement, then I look forward to the PR 😉

Can't wait for your PR! @aleksey-hoffman

@DHowett @zadjii-msft @portexe seriously, with the sarcasm, guys? I meant it would take you 1 hour because you already know the structure of the project and how everything works. Obviously it would take me longer than that, because I would have to learn the whole codebase in order to not mess anything up. I'm busy working on my own stuff and don't have time to learn how this project works.
I've laid out the whole restoring logic for you above. At first, it doesn't have to be any more complex than this. I use a similar system in my own app and I know that it works perfectly. Just add some error handlers and adapt the logic to your codebase, and it's done.
If you are just going to take questions and advice with sarcasm, I don't really wanna participate

@aleksey-hoffman it’s just... it’s generally considered poor form to find a feature request and gesticulate wildly about how “easy” it would be or how the maintainers are ignoring a common use case or something. We all want this feature! It’s just that we’ve spent the past year and change getting Terminal up and running and shippable before we come back and focus on the lower priority nice-to-haves.
Things like competent terminal emulation, performance and reliability, a UI people can understand, a robust configuration model, and a settings UI (popular request, even if some folks prefer JSON) have been prioritized ahead of other things like this and “well does the bold font actually look bold.”
In general, these decisions come down not to lack of knowledge or understanding of the problem space but of hours in the day for my team—which was up until quite recently only four people—to get work done. 😄

You've provided a gross over-simplification of how this feature would need to work. Let's break it down.

Figuring out the CWD of a process on windows is Hard. See #3158 and linked threads for an in-depth discussion of why.
Restoring just a list of entered commands - that's probably not what the user wants. The user wants the output in the buffer, probably in addition to the list of entered commands. However, the Terminal itself doesn't know what an "entered command" is. When the user has vim open, how would the Terminal differentiate that input from the input at the prompt line? The Terminal really can't which is why restoring command history is usually the responsibility of the shell application, not the Terminal.
The Terminal doesn't currently have a good way of storing runtime state like the globalStore you've mentioned above. We've been trying to avoid writing to the user's settings.json file, since that's been a minefield in the past, but that leaves us without a good way of storing non-user-facing application state. We've got #7972 open though tracking how we might want to do this in the future.
How do we handle restoring multiple windows? When you think about restoring tabs in a browser, it's usually about restoring all the windows with all the tabs, not just the tabs in a single window. We don't really have a "quit"-like feature that closes all the windows simultaneously, so you'd have to close the windows one at a time. When it comes time to restore the state of the window, that would just restore the last window you closed. We'd need some sort of cross-process communication to coordinate the saving/restoring of every window's state, which fortunately we're working on over in #5000
We haven't even gotten to mentioning pane state in addition to tab state. There's actually quite a bit of info we'll need per window/tab/pane - the terminal title, tab color, profile, split size and direction, etc.

All this together makes this feature a lot more work than just "a few hours", even for someone who's deeply familiar with the codebase. We're all very passionate about this project, and very excited to make it the best application we can, including this feature. Collaboration is a key part of that, and we're happy to accept community feedback and contributions. However, suggesting that something is something like this is "easy" is incredibly dismissive of all the hard work that is being done.

@zadjii-msft I don't know mate, I feel like you are overcomplicating this a bit:

Isn't there a workaround for this? Why would it even need to extract CWD from somewhere if all commands are in plain text and stored on the drive? The app could just parse all entered commands and check if any of them change the directory e.g.  doesChangeDir(['cd *', '.. *'], command). If the command changes directory e.g. cd C:\test, write it to storage and, on the next launch, run cd C:\. Would that not work?

I disagree, I think most users just want to re-open the app, press up-arrow a few times and press enter rather than typing the path of the project directory and all the commands manually every single time. And the support for buffers can be added later.

I don't see why creating a shared memory store is a problem, Create 1 file with 1 class for storing shared data. Create a single instance and import it in every file that needs it.
And as for the settings.json, I don't get the point.  So opacity is good enough to be stored in there, but the launchAction is not, for some reason? That's what the file settings.json is for, is it not?

Okay, until you implement the IPC, create a function that sends all opened terminal processes taskkill /pid PROCESS_PID. Isn't that the same thing as closing the window manually by clicking on the X? If somehow Windows Terminal processes get closed forcefully even without the /f flag, then make this feature experimental and add a warning saying "all windows will get forcefully closed" before executing the function.

I don't see why it's a problem to store all the windows data on the drive and then restored it on launch. When a window is closed, do not delete that data so it can be restored on next launch. On the next launch, programmatically create all the windows, open all their tabs, and set all other data (panes, colors, etc):

{
  state: {
    windows: [
      {
        hashId: tXm6Ah5NGskW,
        tabs: [
          {
            cwd: 'C:\\projects\\project name',
            commands: [
              'cd C;\\projects\\project name',
              'npm && npm serve'
            ]
         }
        ],
        panes: [
          {...}
        ],
      }
    ]
  }
}

@DHowett I get it, we have to prioritize, but I'd argue this is feature way more important / desirable than the features like "is bold text really bold"
@zadjii-msft I don't know mate, I feel like you are overcomplicating this a bit.
You're saying the commands cannot be distinguished when you're using vim, but I'm not talking about vim I'm talking about regular commands, not all people use vim. Plus there are other ways to distinguish real commands, e.g. create a keydown listener and record key presses. The functions that paste text (ctrl + v and via mouse) can also record the commands.

Isn't there a workaround for this? Why would it even need to extract CWD from somewhere if all commands are in plain text and stored on the drive? The app could just parse all entered commands and check if any of them change the directory e.g.  doesChangeDir(['cd *', '.. *'], command). If the command changes directory e.g. cd C:\test, write it to storage and, on the next launch, run cd C:\. Would that not work?

I disagree, I think most users just want to re-open the app, press up-arrow a few times and press enter rather than typing the path of the project directory and all the commands manually every single time. And the support for buffers can be added later.

I don't see why creating a shared memory store is a problem, Create 1 file with 1 class for storing shared data. Create a single instance and import it in every file that needs it.
And as for the settings.json, I don't get the point.  So opacity is good enough to be stored in there, but the launchAction is not, for some reason? That's what the file settings.json is for, is it not?

Okay, until you implement the IPC, create a function that sends all opened terminal processes taskkill /pid PROCESS_PID. Isn't that the same thing as closing the window manually by clicking on the X? If somehow Windows Terminal processes get closed forcefully even without the /f flag, then make this feature experimental and add a warning saying "all windows will get forcefully closed" before executing the function.

I don't see why it's a problem to store all the windows data on the drive and then restored it on launch. When a window is closed, do not delete that data so it can be restored on next launch. On the next launch, programmatically create all the windows, open all their tabs, and set all other data (panes, colors, etc):

{
  state: {
    windows: [
      {
        hashId: tXm6Ah5NGskW,
        tabs: [
          {
            cwd: 'C:\\projects\\project name',
            commands: [
              'cd C;\\projects\\project name',
              'npm && npm serve'
            ]
         }
        ],
        panes: [
          {...}
        ],
      }
    ]
  }
}

I look forward to this PR, it'd make it way easier to launch my development environment(s).
Maybe it should be looked at from the direction of the workspace feature in VSCode?
Something along the lines of a window per "workspace", containing the different terminals and their history?

The best way we have to prioritize features is based off of community feedback. Right now, the best way of tracking that is through reactions on issues - not the best metric, no, but definitely something measurable. Just sorting by 👍's, this issue is below 12 other requests, 5 of which we're hoping to get done in 2.0. This one just simply didn't make the cut.

The simple fact of the matter is that we have to design a solution that will work in all cases. If only 20% of people use VIM, and our heuristic for detecting commands doesn't work when the user is using VIM, that means that the solution just won't work in 20% of cases. That's not a solution - that's a hack, and not something we'd be comfortable shipping to our users.

Even if we did track all the key events sent to a terminal, there's no way of knowing if a particular set of keystrokes resulted in a changing of directory. There's just far too many things that could result in the directory changing - there's cd, pushd/popd, Set-Location for cmd & powershell, or the user could be using something like [#keep](https://github.com/zadjii/keep, or something like FAR manager where the user is using arrow keys (or even the mouse!) to navigate the filesystem. That's without considering the use of text editors, or scenarios like WSL, docker, or ssh, where the path inside the distro/container/remote machine aren't the same as on the outside. There's just no way of doing this heuristically from input.
Fortunately, this isn't really an issue! Modern shells (read: not cmd.exe) all persist the command history themselves, so they'll all persist the history across reboots for you! The Terminal doesn't even need to get involved.
Okay, that's a fine opinion to have. See the above - the shell will restore the history for you, so that's why I don't think the command history is a valuable discussion to have.
It's not necessarily a problem, which is why the spec in #7972 is so incredibly straightforward. We don't want to be writing to the settings.json file, because in the past we've messed up the formatting of people's settings files, and people were greatly displeased with this, which is why we're introducing a second file to store this state. It's not terribly challenging, but this is just another piece of the puzzle that will take "a few hours" to implement, debug, write tests for, etc.
I'm pretty sure if we end up taskkill'ing all the Terminal processes, then none of them would have the chance to store the state of the open windows, entirely ruining any chance to restore the state of these open windows, and the whole point of the feature. I'd rather make sure that we implement this right the first time, rather than ship a half-baked hack and have people start taking a dependency on that behavior.
Before there's any sort of IPC way to coordinate between windows, how do we differentiate between the first launch of a Terminal window, and subsequent ones? Only the first launch should restore the state of the persisted windows, not the subsequent ones, right? You don't necessarily want each launch to pop up all the windows/tabs you had in the previous session (though, if you do, you might be interested in #756)

I'm looking forward to working on this, but it's probably not going to land until post 2.0. We're already going to have to work on serializing the state of a terminal tab as a part of #1256. Plus, we're already in the process of developing the IPC functionality as a part of #5000. So a lot of the hard problems that need to be solved before we can address this issue are already in progress!
(Frankly, most of this discussion is better off in #766 - this thread was supposed to specifically be the thread about restoring buffer contents, not window state)

@zadjii-msft well, then I suppose my estimates of "a few hours" were off, I based it on my own experience, but I didn't consider the fact that in my app I already had the IPC, the system for writing to storage, etc. and, for some reason, I assumed that all of those systems were also already in place in the Windows Terminal. Thanks for clarification.

@zadjii-msft
This is a very interesting information about the likes measurement.
Didn't know that one.
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/sorting-issues-and-pull-requests
Just want to make folks aware of this other issue which is quite high in ranking already:
https://github.com/microsoft/terminal/issues/766
using the sort thumbs up emoji
https://github.com/microsoft/terminal/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc
So I have voted now for both as until this is done terminal is a cool project, but until that I need to stick with other projects like Babun, CMDer or Conemu, as at least just reopening my last opened tabs is quite essential for me as well otherwise I always need to remember what was last opened which is quite difficult sometimes for me when it comes to having open more than 20 tabs.

For those looking for a workaround, I use an action like the following:
        { "command": { "action": "wt", "commandline": "new-tab --title OpenConsole cmd.exe /k #work 15 ; split-pane --title OpenConsole cmd.exe /k #work 15 ; split-pane -H cmd.exe /k media-commandline ; new-tab --title \"Symbols Script\" powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu 18.04\" ; new-tab -p \"microsoft/Terminal\" ; sp -V -p \"microsoft/Terminal\" ; sp -H -p \"microsoft/Terminal\" ; focus-tab -t 0" }, "name": "Good Morning" },

and then I invoke that from the command palette each morning after a Windows Update.  Customize as needed for your own profiles/environments. It's definitely not the same as "restore state" or "start with multiple tabs open", but it gets the job done.

@zadjii-msft I don't think the shells can really restore command history in this case meaningfully.  They can save command history, but once multiple tabs/panes are active, the shell has no idea which pane is which.  The naive thing they'll do is terminate all the shells and all append to .bash_history etc in random order, and on restore each pane will have command history from all the other panes in an undefined order.  I don't see how to do this without ascribing each tab/pane some form of identity, having shells persist state related to that identity, and communicating that identity back to the shell on restore.
If that identity did exist though, it would allow shells to save/restore things like the environment, current directory, aliases or other shell state, etc, which seems useful.

Saving a command history per tab isn't even what I would expect, because this is a very shell dependent behaviour.
Enough would be for me to recover the opened tabs plus ideally the saved last directory used in the particular tab.
My assumption is that now that we have the environment variables WT_PROFILE_ID and WT_SESSION.
That would be very enough already, as I am not expecting more from ConEmu.
So saving history per tab would already over scope of a beginning of this feature and in my opinion an enhancement already.
In my opinion writing this state to settings.json is not the right place.
Better would be something like SQLite or some alternative.
Thank you all for kicking this discussion off.

@malxau You're not wrong here. We're not the first terminal emulator that's allowed multiple concurrent instances, however, so I'm thinking that this is more of an issue that shells just simply haven't found the right solution for yet. We've got the WT_SESSION variable that we use for terminal instances, though I wouldn't want anyone taking a dependency on anything like that, especially considering it wouldn't work in something like tmux. If there was a way of identifying unique terminal instances that worked across emulators and shells to help coordinate the restoring of history to the correct terminal instance, I'd be all ears 😄

Speaking for myself, I would be happy if the terminal app just remembered and restored the tabs and separate processes (including elevation state with prompt). The buffer isn't important to me.

Huh, comments above reminds me of myself ~15yrs ago, when I thought I can do everything easily :P
Kidding aside, This issue seems to be describing multiple features together. Maybe it should be broken down into smaller parts and implemented one by one. Saving state, buffer, command list etc... doesn't seem necessary to me and maybe pushed further down the list.
First implementation should be just saving [{guid: cwd}].
First issue is to get CWD from both WSL linux shells and from windows shells. Conemu and Mintty relies on Escape codes from PROMPT to get it. Relevant conemu doc link
This is what I do in my bashrc.
PS1="$PS1\[\e]9;9;\"\$(wslpath -aw .)\"\007\e]9;12\007\]"

I guess Windows Terminal needs to do the same. Although I have no idea how multiple windows should be handled. I never open my terminal in multiple tabs in multiple windows :P
If extension support (#4000) was here, I might've tried to make an extension that listens to that ANSI Escape code and generates a command line with tabs and CWD.

Huh, comments above reminds me of myself ~15yrs ago, when I thought I can do everything easily :P
Kidding aside, This issue seems to be describing multiple features together. Maybe it should be broken down into smaller parts and implemented one by one. Saving state, buffer, command list etc... doesn't seem necessary to me and maybe pushed further down the list.
First implementation should be just saving [{guid: cwd}].
First issue is to get CWD from both WSL linux shells and from windows shells. Conemu and Mintty relies on Escape codes from PROMPT to get it. Relevant conemu doc link
This is what I do in my bashrc.
PS1="$PS1\[\e]9;9;\"\$(wslpath -aw .)\"\007\e]9;12\007\]"

I guess Windows Terminal needs to do the same. Although I have no idea how multiple windows should be handled. I never open my terminal in multiple tabs in multiple windows :P
If extension support (#4000) was here, I might've tried to make an extension that listens to that ANSI Escape code and generates a command line with tabs and CWD.

I would like to mention that these features don't have to be supported for all shells. It would be okay to say, support some of them only for PowerShell, where certain information can be more easily obtained to make the feature work.

I would like to mention that these features don't have to be supported for all shells. It would be okay to say, support some of them only for PowerShell, where certain information can be more easily obtained to make the feature work.

I agree that saving and restoring state is very complicated and I'd not like to attempt to implement it.
However, I think an "undo close tab/window" function with a grace period could be implemented much more simply. You just keep everything running for the grace period and if an "undo close" event happens you just recreate the graphical components.
I know I said "just" a lot, and of course it'd be difficult work, still I think this would be a hugely useful feature for those of us who hit "close window" by mistake and I believe the end result (processes still running, ssh connections active etc) is a better end result (for this use-case).
Cheers.

@zadjii-msft

The best way we have to prioritize features is based off of community feedback. Right now, the best way of tracking that is through reactions on issues - not the best metric, no, but definitely something measurable. Just sorting by 👍's, this issue is below 12 other requests, 5 of which we're hoping to get done in 2.0. This one just simply didn't make the cut.

(Frankly, most of this discussion is better off in #766 - this thread was supposed to specifically be the thread about restoring buffer contents, not window state)

That's where you see the limit of using 👍's as a metric to sort priorities :)
Some features are hard to clearly express (for the end-user) and even harder to specify for the developer. Took me a bit to find this thread, just to realize after having read it all the way... that it's not the one to thumb up.
Like most people, all I need is Terminal to restore all my open tabs and their CWD (don't even need the last commands) when windows decides to reboot my computer for some updates, so I can resume my work as fast as possible with the usual 10 tabs (10 different folders) I've open during my daily sessions. A feature that most Terminal apps (especially on macOS) have.
Maybe start simple with just the last tabs (opt-in like Chrome) and associated CWD, and later add buffers, commands,... as option.

is there any solution on this ? atleast remember 1 tab ?

Nope, there aren't any updates yet. When there are, we'll make sure to post here. In the meantime, might I recommend the Subscribe button?

That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺
We're working on storing "application state" over in #8771, which is one of the prerequisites for doing this.

For reference, I workaround this with a command in the command palette. I like to do like the following each time I boot up the Terminal in the morning:
{ "command": { "action": "wt", "commandline": "new-tab --title OpenConsole cmd.exe /k #work 15 ; split-pane -s .30 --title OpenConsole cmd.exe /k #work 15 ; split-pane  -s .25 -H cmd.exe /k media ; new-tab --title \"Symbols Script\" powershell dev\\symbols.ps1 ; new-tab -p \"Ubuntu 18.04\" ; new-tab -p \"microsoft/Terminal\" ; sp -V -p \"microsoft/Terminal\" ; sp -H -p \"microsoft/Terminal\" ; focus-tab -t 0" }, "name": "Good Morning" },

(you could probably make it shorter by replacing new-tab/split-pane with nt/sp, respectively).
I add that to the keybindings/actions. This creates a new command in the Command Palette named "Good Morning". That opens up a few tabs & panes, running various build environments. I like having it in a command rather than startupActions, because I only really want this in one terminal window, not every single one I launch. It's personal taste.
You could repeat this for multiple different "session"s if you wanted. That way you could have layouts pre-defined for various different dev environments.
We're also tracking adding commands to the new tab dropdown in #1571.

I think session functionality and management is very beyond than session restoration, and I think Windows Terminal must have focus to design and implement great session concept and functionalities about that, like tmux (#10331).

I would settle for remembering which tabs were open, what their custom titles were, and what their custom colours were. A bonus would be the current directories in each shell, but the main thing that annoys me is having to restart my machine for whatever reason, then open Terminal, re-open my tabs, rename my tabs, apply colours to my tabs...

How come emoji support is #2...? I guess I'm missing its use case...
It sounds like this feature would be more important than quite a few from that list. Also, agree with @MarkIngramUK

I'm surprised that nobody has mentioned that yet, but iTerm2 for macOS does pretty much what one would expect from such a feature. It's one of the very few things that I miss from the Mac on Windows. The GitHub project: https://github.com/gnachman/iTerm2

Now I am not really an OS specialist, but I think iTerm2 is not really a good example as it goes back to macOS which basically only has to hold sessions that go back either to zsh or bash. I think Terminal has to fill much more gaps because under a Windows there is an extremely broad spectrum of terminal sessions possible starting from MinGW sessions, Cygwin sessions, bash sessions, Powershell sessions, CMD sessions (which even don't really have a state and you would need to work around lots of things if it's even possible to save the CMD buffer separately). So I think that request is a whole other beast than what iTerm2 has to fulfill.
For Windows you need to compare to a completely other set of shells like e.g. Babun which has been discontinued, cmder or MobaXterm. Lots of these shells base on the initial work that has been done with ConEmu. If you look to all these shell's issue collections you will find out that there have been happening lots of struggles around lots of issues. And the chorus is that some of these shells specialized only on a possible subset of possible shells like e.g. Cygwin sessions or SSH sessions....
Please correct me if I am wrong.

I know that I don't know enough -- by a long shot -- to correct you or to tell you that you're wrong :)
However, sometimes perfect can be the enemy of good (or better). Tools that have to work with a multitude of environments sometimes support features only for a subset of supported environments. If Terraform, for example, only supported features that are supported by all cloud environments it supports, it would not be very useful. Sometimes it makes sense to support features only for a subset of supported environments. In this case, if it can be done, say, for Bash and PowerShell, that would be a huge win for many if not most (or even an overwhelming majority of) users.
(FWIW, iTerm2 supports tcsh, zsh, bash, and fish.)

Agreed!
Only support for bash/powershell is enough for me (for now).
It really is a pain when windows decides to reboot by itself (crash, update, ...) and I loose the 10 shells I have opened because I work on many projects at the same time.
On the other hand, when my mac reboots, I always get back right where I was.
Please consider partial support.

Just expressing my use case: As an IT Pro, I frequently have 8-10 PowerShell 5.1 or 7+ tabs open in terminal. I don't "pre-plan" what's going to happen in these tabs, and I don't waste time customizing each tab with titles or colors. I just open them as I need them to work on different tasks/projects in parallel. So "losing" the content of these tabs when I come back to my PC when either the PC has restarted for Windows updates, or Terminal has mysteriously restarted (I assume for a forced update of some sort?) is very disruptive.
All of this would be solved (for me personally) if only the buffer contents would be restored, as I could easily look and see what I was doing last in each tab. To a lesser degree, restoring the tab's "local" command history would suffice as well, as I could then just use the up arrow to see what the last command was in any given tab.
Currently when these Terminal restarts happen, the number, position, and client of each tab are successfully restored, but that is not enough to get me back on track. Ostensibly I could manually customize the title of every tab just in case this happens, which might help a little, but even then it wouldn't tell me exactly what I was doing in that tab or what state I had left that tab's task in. Plus during a work day I will have opened and closed dozens (maybe hundreds) of tabs, so customizing tabs just in case would be a huge waste of time. The buffer/command history is really what's needed.

Re mmseng's comment:

Restoration of the buffer/command history is really what's needed.

For me, it's more the buffer than the command history. The buffer contains the output and the commands. If the output of a command changed over time, rerunning the commands might not help getting the information back about what happened.
Lateral thought: an on-disk rotating buffer with a maximum lifetime (24h? configurable?) on disk for every tab that contains everything visible on screen would be helpful, too, and would give me most of what the feature of this issue could give me.

it's more the buffer than the command history

Wholeheartedly agreed. The buffer is far more important; I would even go so far as to call it precious.
At the risk of repeating drama from above, from an outside perspective, either item seems relatively simple (compared to something like preservation of state), as both buffer and command history are mostly just plain text and the rendering thereof. The command history implementation already even lends itself to this purpose, since you can technically manually edit it.
I know it's always way more complicated than it seems; I only mentioned the above because, as much as I'd like to see this implemented for the good of all, I would personally be willing to implement a custom solution that, at the very least, dumped buffer history to a file along with some sort of identifier as to the tab it belonged to (e.g. name the file after the tab title), if it allowed me to recover my work in these instances. Of course, I would have no idea how to implement such a hack, and the logic for when to dump that data does not immediately come to mind.

Is this being worked on?
I see that PR #8771 was opened in 2021 but then it got closed without a reason? (last comment was just a discussion on changes)

Yep, I believe @lhecker's been working on this for a bit now.
#8771 was more specifically a PR to implement #766. This issue is more specifically "restore buffer contents", while #766 was more generally "restore various elements of the Terminal's state".
#8771 ended up resurrected as #10513 which then was used by #10972 to store the window position, size (but notably, not the buffer content)

@zadjii-msft Did you know how to use this feature?

This only just merged hours ago, so it's not available yet outside of just building the code from main directly. Tonight's canary build should have this, though, our canary pipeline has been having some publishing issues this week.
It should be enabled if you have "firstWindowPreference": "persistedWindowLayout" enabled in your settings.

Nope. This was added in 1.21.

I've been using it in the 1.21 Windows Terminal Preview. It does work as expected (for a certain definition of expected), however the vast majority of the times when I need it is when Windows updates reboot the machine, or when the machine otherwise reboots while Terminal is open, and from what I've seen I don't believe it's been working in these cases (I haven't been tracking it closely enough to make a more confident statement). As I recall, the issue of reboot due to Windows updates is an open issue.

this thread is so Windows. I don't mean to throw any shade at the devs and designers here, it's just that feeling of "@#(^#@^&" when my OS knocks me down with nagging and unwanted reboots only to hit me again by stealing more of my time, for years and years while my macs have never once hurt me this way.  I mean, at least you can stop worrying about privacy, right? we've all used 11.
...well thanks for the hard work I'll leave now.


fix newline for ja.po

fix for error:
po/ja.po:1372: 'msgid' and 'msgstr' entries do not both end with '\n'
msgfmt: found 1 fatal error

Signed-off-by: Pavol Cupka<EMAIL_ADDRESS>

This pull request didn't trigger Jenkins as its author isn't in the whitelist.
An organization member must perform one of the following:

To have this branch tested by Jenkins, use the "ok to test" command.
To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"


Use a single -with-rtsopts option

Multiple "-with-rtsopts" options are not concatenated so they must be
specified completely.

bors r+


Battery service (180F) not available

Not sure if this is a Linux/Chrome bug or related to #94. I'm running on Ubuntu 18.04 with Chrome. Heartrate test seems to work fine, so I'm confused why there are issues with Battery simulation.
I'm testing through this page:
https://googlechrome.github.io/samples/web-bluetooth/battery-level.html
Seeing the following "Live Output":
Requesting Bluetooth Device...
Connecting to GATT Server...
Getting Battery Service...
Argh! NotFoundError: No Services matching UUID 0000180f-0000-1000-8000-00805f9b34fb found in Device.

I found that exact 0000180f-... battery_service UUID in the android code here:
https://github.com/WebBluetoothCG/ble-test-peripheral-android/blob/277fbf7c586d579a9d270d71f7891144dea5e4d5/app/src/main/java/io/github/webbluetoothcg/bletestperipheral/BatteryServiceFragment.java#L45
The reset energy app works:
https://googlechrome.github.io/samples/web-bluetooth/reset-energy.html
Live output of:
Requesting Bluetooth Device...
Connecting to GATT Server...
Getting Heart Rate Service...
Getting Heart Rate Control Point Characteristic...
Writing Heart Rate Control Point Characteristic...
> Energy expended has been reset.

Which successfully resets the energy expended value to zero in the android app.
Trying to troubleshoot with bluetoothctl (Linux CLI utility). Seeing reasonable GATT listing "Heart Rate Control Point" (2A39) when opening the heartrate tab in the android app:
menu gatt
list-attributes

Primary Service
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0001
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
Characteristic
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0001/char0002
	00002a05-0000-1000-8000-00805f9b34fb
	Service Changed
Primary Service
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0028
	0000180d-0000-1000-8000-00805f9b34fb
	Heart Rate
Characteristic
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0028/char0029
	00002a37-0000-1000-8000-00805f9b34fb
	Heart Rate Measurement
Descriptor
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0028/char0029/desc002b
	00002902-0000-1000-8000-00805f9b34fb
	Client Characteristic Configuration
Descriptor
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0028/char0029/desc002c
	00002901-0000-1000-8000-00805f9b34fb
	Characteristic User Description
Characteristic
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0028/char002d
	00002a38-0000-1000-8000-00805f9b34fb
	Body Sensor Location
Characteristic
	/org/bluez/hci0/dev_65_56_A7_7E_47_2C/service0028/char002f
	00002a39-0000-1000-8000-00805f9b34fb
	Heart Rate Control Point

But when switching over to the Battery tab, I don't see the battery service listed.
menu gatt
list-attributes

Primary Service
	/org/bluez/hci0/dev_5C_91_FB_35_1C_CE/service0001
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
Characteristic
	/org/bluez/hci0/dev_5C_91_FB_35_1C_CE/service0001/char0002
	00002a05-0000-1000-8000-00805f9b34fb
	Service Changed

Upon a fresh connection, I do see the 180F battery status UUID logged with the [CHG] tag, but it does not persist with list-attributes.
[miles g5]# connect 5C:91:FB:35:1C:CE
Attempting to connect to 5C:91:FB:35:1C:CE
[CHG] Device 5C:91:FB:35:1C:CE Connected: yes
Connection successful
[CHG] Device 54:59:49:F9:57:73 ServicesResolved: no
[CHG] Device 54:59:49:F9:57:73 Connected: no
[DEL] Characteristic
	/org/bluez/hci0/dev_54_59_49_F9_57_73/service0001/char0002
	00002a05-0000-1000-8000-00805f9b34fb
	Service Changed
[DEL] Primary Service
	/org/bluez/hci0/dev_54_59_49_F9_57_73/service0001
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
[DEL] Device 54:59:49:F9:57:73 miles g5
[NEW] Primary Service
	/org/bluez/hci0/dev_5C_91_FB_35_1C_CE/service0001
	00001801-0000-1000-8000-00805f9b34fb
	Generic Attribute Profile
[NEW] Characteristic
	/org/bluez/hci0/dev_5C_91_FB_35_1C_CE/service0001/char0002
	00002a05-0000-1000-8000-00805f9b34fb
	Service Changed
[CHG] Device 5C:91:FB:35:1C:CE UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device 5C:91:FB:35:1C:CE UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device 5C:91:FB:35:1C:CE UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[CHG] Device 5C:91:FB:35:1C:CE ServicesResolved: yes

Sounds like BlueZ is not exposing the battery service. That usually happens when a BlueZ plugin claims the service. Maybe try disabling plugins?

Yep. Disabling the battery plugin worked. I couldn't figure out how to do that when you replied, but have since found the details in this SO answer.
The solution is to edit /lib/systemd/system/bluetooth.service and add -P battery to end of bluetoothd:
ExecStart=/usr/lib/bluetooth/bluetoothd -P battery

FWIW, sudo systemctl edit bluetooth.service with the following contents will probably work better for most people.
[Service]
ExecStart=
ExecStart=-/usr/lib/bluetooth/bluetoothd -P battery

If changes are made directly to /lib/systemd/system/bluetooth.service, they will be overwritten whenever the bluez package is updated.

What is the reason for the empty assignment and the leading hyphen in the next line? Would this not work?

[Service]
ExecStart=/usr/lib/bluetooth/bluetoothd -P battery

Services allow more than one ExecStart, ExecStart= is a special case to say "don't run any previous ExecStart, only the new ones after this". So without it, the service will try to start bluetoothd twice.
https://www.freedesktop.org/software/systemd/man/systemd.service.html

Thanks for the link.
I'm still a bit confused about whether an "empty string" is considered "zero commands". I guess not, since that's disallowed with Type=dbus for bluez.
Here are the relevant nuggets from that manual:

Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified. Commands may be specified by providing multiple command lines in the same directive, or alternatively, this directive may be specified more than once with the same effect. If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect.

If the executable path is prefixed with "-", an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success.

It is not an "empty" command, it means delete all previous commands. Since the dbus type can only have one command, we have to delete the old one before we can add a new one. In the end there is still exactly one command.


py_func convert unicode string results to bytes for python2

Fix #16320

@facaiy thanks for the contribution!
@jhseu thanks for fixing the lint error!


wrong altitude setpoint when switching to altitude control

Had a weird behaviour when switching to altitude control.
http://logs.uaventure.com/view/Z9gCEDujtGeJCTEj7dfkd7#Local_Z_PLOT
Must be something with reset_alt_sp and _sp_move_rate(2)

I will look into this, seems to be important for the release.

Ok. That is what I found also. Please refer to
http://logs.uaventure.com/view/sQV6rBwSbQaP3P8vXf2WpV
This happens not all the time, currently it seems to be a random behavior. Although I am new to the PX4 flightstack I am trying to rush through the code.

@tumbili : Did you already had a chance to dig into it? If so, could you share your results here?
Thank you

Maybe another comment: It seems as if the controller takes action, before the set point was reset.

I think you can recreate it by doing: arm -> fly with alt hold -> land and disarm -> arm again -> fly and enable alt hold

Hm. I dont be sure. As far as I remember, it occurs also the first time arming...

More logs: @tumbili This issue is to track the altitude hold reset logic fails we've seen.
http://logs.uaventure.com/view/Z9gCEDujtGeJCTEj7dfkd7#Local_Z_PLOT

@tumbili It would be good if you could have a solid look tomorrow.

As far as I found out, this issue has to do with 'reset_alt_sp' using the FF term at the moment of enabling altitude control. With
_pos_sp(2) = _pos(2) ;//+ (_vel(2) - _params.vel_ff(2) * _vel_sp(2)) / _params.pos_p(2);

disabling the FF term, the set point is not set accurate, but there seems to be no 'jump' anymore.

@ecmnet I will look at it today.

Thank you. Using my modification the result is like this:
http://logs.uaventure.com/view/7t7C7iLc3M6jNKEQWNbwP3#Local_Z_PLOT

@ChristophTobler @ecmnet Which branch do I need to have a look at. It seems that this problem is only occurring when using the lidar.

@tumbili I used the master branch, but added Christoph Toblers 'position_estimator_inav' - version
(https://github.com/ChristophTobler/Firmware/commit/9c30fc5027c1c3867e15ac32e295929eda1d5771).
I don't know, whether Christoph had a branch for this.
On the other hand, position estimation with his modification looks fine also in manual mode. I assume, you're investigation goes in the direction, that _vel(2) is not correct, but I haven't seen this.

@ChristophTobler @tumbili Any further results here? As Christophs enhancement of 'position_estimator_nav' is proposed for release 1.2, this should also be fixed.

@ecmnet Yes, I know now what the problem is, will push a fix shortly.

Fix proposed in #3549

@tumbili Looks good. Did you test it already in flight? I will do that on Friday.

@ecmnet No I did not test it yet.

@ecmnet Ok, I pushed another commit to #3549. Have a look at it and let me know what you think.
By the way, can you try takeoff on master with the exact same paramters as last time (the ones which leas to broken props?). It should be really nice now!

I haven't tried takeoff yet, as I am currently limited to fly indoors and I fear to crash into the ceiling... ;-)

@ecmnet I'll do a video of a takeoff to 1.5 meters, maybe that will convince you ;-)

Well, in return, I'll post a pic of the traces on my living-room ceiling ;-) that my previous java-based flight-stack caused...

We fixed this.


Feature Request: select output location.

For people with really cluttered desktops, having more files invite themselves to the party can be a nightmare. Can't you let the user CHOOSE the output location?
(If you can "Call" the native 'file browser', to select the output location: it has the added feature of letting you generate a new directory in the location of your choosing.)
The proliferation of uninvited files on my desktop reminded me of the Sorcerer's Apprentice ... one broom chopped to splinters suddenly became a flood of brooms marching across my desktop!
(IF you have to have a "Default" location I suggest the "Pictures" folder in the Users Home folder - and have it MAKE a new "Elephicons" folder in "Pictures" to round them all up in. It's a LOT less messy that way!)
All Griping aside ... I posted a really nice review of Elephicon on my web site - with a link to your site. AND I used it for a few projects ... which is why I'm griping about the horrid mess.  (I admit it looked like that before ... but YOUR elephant didn't help ... )
Keep up the Great Work.
￼

@SeaMac
Thanks for your review, I'm glad you did.
Hmmm...
I will consider your suggestions. Maybe on the next minor upgrade. Maybe...

I set the output destination to the current folder.
Isn't that a little better?

I set the output destination to the current folder.
Isn't that a little better?

Well, it is currently in the Applications Folder. It doesn't have PERMISSION to write to that folder, so it will quit working for me. My only choice is to place this application in its OWN Folder in my Pictures Folder ... now ... and NOT with the other applications. I think I'll keep the old version that drops everything on my cluttered desktop - the new version is a definite downgrade.

Hmm...

Well, it is currently in the Applications Folder. It doesn't have PERMISSION to write to that folder, so it will likely quit working for me.

I've moved the output back to the desktop for now.
I'm sorry for the inconvenience.


In some scenario, session get link could be disposed

Description
Fix a bug in https://github.com/Azure/azure-sdk-for-java/issues/25718.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.

/check-enforcer evaluate

/check-enforcer override


react native modal doesn't behave as expected

I'm trying to use <Modal> to make something like this
when pressing on About label in the drawer, it should open this popup screen

but what I get is this
at first it doesn't render the first view and the background isn't transparent

it takes so long before rendering the first view and the transparent background and sometimes it doesn't untill I scroll the <WebView>  the centered view

here is my code
custom drawer
render()  {         return (             <SafeAreaView style={{ flex: 1 }}>                 <Modal                     animationType="slide"                     transparent={true}                     visible={this.state.modalVisible}                     presentationStyle="formSheet"                 >                     <View style={styles.modal}>                         <View style={styles.modalTop}>                             <Image source={require('../../assets/icons/logo.png')} style={styles.smallIcon} />                             <Text style={styles.modalTopText} >About App</Text>                         </View>                         <About />                         <View style={styles.modalBottom}>                             <Text style={{ color: 'red' }} onPress={() => this.setModalVisible(false)}>CLOSE</Text>                         </View>                     </View>                 </Modal>                 <ScrollView>                        ............................                         <ListItem                             leftAvatar={<Image source={require('../../assets/icons/about.png')} style={styles.icon} />}                             title={<Text style={styles.text}>About</Text>}                             onPress={() => {                                 this.setModalVisible(true);                                 this.props.navigation.dispatch(DrawerActions.closeDrawer());                             }} />                 </ScrollView>             </SafeAreaView>         );     }
I tried to center it by using position but nothing change.
I also had to give it specific width and height as it renders as a full screen!!
modal: {         width: '95%',         height: '95%',         backgroundColor: '#fff',         position: 'absolute',          top: 0, left: 0, right: 0, bottom: 0,     },     modalTop: {         height: 50,         flexDirection: 'row',         marginTop: 15,         marginLeft: 20,     },     modalTopText: {         color: '#000',         fontSize: 20,         fontWeight: '300',         marginTop: 8,     },     modalBottom: {         height: 50,         marginTop: 15,         textAlign: 'right',     },
About component
render() {     return (       <WebView         ref={(ref) => { this.webview = ref; }}         source={{ uri: 'https://growthhacktoolkit.com/android/about.html' }}         style={{ flex: 1 }}         scalesPageToFit={true}       />     );   }
Here are my questions

Why Modal takes so long to render properly(without  transparent background)?
Why It doesn't render properly till I scroll the WebView?
Why Modal doesn't slide in from the bottom as it should?! It just appear with no animation.
Why Modal doesn't render at the center? and Why center styling has no effect?
Why textAlign: 'right', has no effect?!

"react-native": "0.57.8"
"react": "16.6.3"
"react-native-webview": "^3.1.2"
android
redmi note 4 - android version 7.0
windows 10

I'm also having the same issue with Modal and WebView :(. Hope to find a fix for this :).


Fix sonar warnings

Signed-off-by: krivchenko_kv<EMAIL_ADDRESS>

@dundich  looks good. Can you please squash all your commits into one?
Then I can accept the PR.
Thanks for your contribution!

fixed: all commits in one...
but he didn't pass the intergation test, I don't know :(

@dundich I believe the branch you want to merge from your fork does not have the recent changes needed to bring Kafka integration tests back on track.
From this view, your branch is 3 commits behind: https://github.com/dundich/SlimMessageBus/compare/sonar-fix...zarusz%3ASlimMessageBus%3Amaster
Please pull the latest changes from this (original) repo into your fork.
Then rebase your branch aginst the latest master.

Thanks for the tips. Done!

Unused local variables should be removed ???
https://github.com/zarusz/SlimMessageBus/blob/bd33379966f710a13b5f4fc15ac084b78ab3eb08/src/SlimMessageBus.Host/DependencyResolver/ServiceCollectionExtensions.cs#L76
   var messageBusSettings = svp.GetRequiredService<MessageBusSettings>();

ps. I didn't remove it because I'm afraid of the side effect.

Constructors should only call non-overridable methods
https://github.com/zarusz/SlimMessageBus/blob/bd33379966f710a13b5f4fc15ac084b78ab3eb08/src/SlimMessageBus.Host/Hybrid/HybridMessageBus.cs#L40C11-L40C12
https://rules.sonarsource.com/csharp/RSPEC-1699/
    protected virtual MessageBusBase BuildBus(MessageBusBuilder builder)

ps. Maybe - sealed class?

That's it. I'm done. :)

Unused local variables should be removed ???
https://github.com/zarusz/SlimMessageBus/blob/bd33379966f710a13b5f4fc15ac084b78ab3eb08/src/SlimMessageBus.Host/DependencyResolver/ServiceCollectionExtensions.cs#L76
ps. I didn't remove it because I'm afraid of the side effect.

It should be safe to remove - I will do it.
Thanks for contribution @dundich !


Error: The category 'Extension Packs' is not available in language 'en-us'

I just started receiving this error message when trying to publish an extension. I am indeed including the "Extension Packs" category, but this didn't cause a problem for me previously. I am using vsce v1.46.0, and here's my full package.json file.

@viradhamMS @pkuma-msft Please check if it is an issue with Market place

Looking into it..

@ericbiewener The issue should be fixed now.. let us know if you still run into trouble. Thank you for reporting this!

All set, thanks!

Thanks @pkuma-msft


Heroku - mLab MongoDB Add-on Discontinued

The mLab MongoDB Add-on will be shutting down on November 10th and may inadvertently affect the Deploy to Heroku functionality.  The following documentation contains specific information.
https://docs.mlab.com/shutdown-of-heroku-add-on/

@Whamo12 Thanks for the information. We should migrate to MongoDB Atlas as suggested here:
https://docs.mlab.com/how-to-migrate-sandbox-heroku-addons-to-atlas/

Something to bear in mind is that the Atlas M0 tier doesn't support server-side javascript (From: Atlas M0 (Free Tier)... Limitations).
There's currently a $where query in allocations-dao.js, which is used to demonstrate NoSQL injection vulnerabilities:
https://github.com/OWASP/NodeGoat/blob/5b6a3078b31dc346e5ce7b86837d6abbe7a18bbd/app/data/allocations-dao.js#L78

I've made a task list for the work to resolve this issue. Feedback is welcome on whether this is the right approach, or if I missed anything important.
The work to fix the "Deploy to Heroku" button can be done by any contributor:

[ ] Remove mongolab:sandbox addon from app.json
[ ] Add a MONGODB_URI env variable to app.json (required, default "")
[ ] Remove reference to the current mLab database from config/env/all.js
[ ] Remove support for MONGOLAB_URI in config/env/all.js (only needed for the mongolab addon)
[ ] Update heroku deploy instructions in README.md to cover database setup
[ ] Update tutorial for A1 - Injection to say NoSQL injection is blocked on deployments using Atlas M0

These tasks can only be done by members of the core project team:

[ ] Create a new Atlas account, database and user for http://nodegoat.herokuapp.com/
[ ] Update http://nodegoat.herokuapp.com/ to use the new Atlas DB and user
[ ] Once the tasks above and #213 are resolved, shut down the mLab database

I'd be happy to make a PR for the first set of tasks (if no-one's already lined up to do it).

Reminder: mongolab heroku addons are due to be deleted on Tuesday, November 10th. When that happens, any mLab databases still attached to a mongolab heroku addon will be deleted.
Hopefully the database for http://nodegoat.herokuapp.com/ has already been detached from its addon, otherwise the app will go down when the database gets deleted on Tuesday.

@rcowsill Thank you for staying on top of this and the PR. @Whamo12, appreciate your reporting this issue.
Merged the PR. I wanted to provide default Altas DB URL for a quick start for those who don't have it or willing to create an account on Atlas. Hence restored the all.js as before except with Atlas DB URL. We can revise this logic, if any suggestions.
Closing this issue.


Log queries if they are greater than equals the threshold

I was using LogToConsole to debug some queries and was confused at first as to why I see some queries logged while others aren't there.
Eventually I realized it's because the query completed in 0ms so it wasn't higher than the threshold... I think it makes sense to have the comparison be >= rather than just >.

Included in<EMAIL_ADDRESS>- wanna test it?


docs: Document that mocha will search for mocha configs by going through parent directories

Mocha currently searches through parent directories to find a mocharc config: https://github.com/mochajs/mocha/blob/37deed262d4bc0788d32c66636495d10038ad398/lib/cli/options.js#L182
But this behavior isn't documented in https://mochajs.org/#configuring-mocha-nodejs, which only says to create the mocharc in your package's root directory.

Hi, I am interested in polishing the documents, can I take this issue?


Discussion: Scroll to top functionality

What:
We can provide users with scroll-to-top functionality. I think this will be a good add-on to the mobile application.

@bhattabhi013 Go ahead assign to you


IMPORTANT - NOT RELATED TO THIS REPO

Can you give me a download of the blocked silent miner pls?

This? https://github.com/UnamSanctam/UnamWebPanel/issues/361#issuecomment-2208790180

This? #361 (comment)

yehhh tyy


Error caching database model. Unknown table 'check_constraints' in information_schema when view ER Diagram of database in mariaDB 10.1

System information:

Operating system (distribution) and version: win10
DBeaver version: 7.1.3 x64
Additional extensions

Connection specification:

Database name and version: mariaDB 10.1.x
Driver name: org.mariadb.jdbc:mariadb-java-client: 2.4.3
Do you use tunnels or proxies (SSH, SOCKS, etc)? : No

Describe the problem you're observing:
Error caching database model.
Unknown table 'check_constraints' in information_schema
Seems something new in #6069, and maybe some db version checks is still missing
Steps to reproduce, if exist:

Open an database conn with mariaDB 10.1.x;
Choose any database, and press F4(View Database);
Switch to ER Diagram tab(, and press F5(Refresh) if it's already opened before);
See the error window;

Include any warning/errors/backtraces from the logs

No related logs can be found.

It should be easy to reproduced.

Download and install DBeaver CE 7.1.3 from https://dbeaver.io/download/;
Download and install mariaDB 10.1.45(win_x64 I used) from https://mariadb.org/download/#entry-header
Create an conn in DBeaver  to the database;
Open database information_schema, and press F4(View Database);
Switch to ER Diagram tab

Also getting this same error by just clicking on the ER diagram tab.

It should be fixed in 7.1.4 release. Could you test in EA version https://dbeaver.io/files/ea/?

@kseniiaguzeeva
Still the same in EA version(Version <IP_ADDRESS>007291911)

@yyjdelete yeah. Find it yet. Fix error in 7.1.4

@yyjdelete Could you test the latest release https://dbeaver.io/download/?

@kseniiaguzeeva
Verified it's fixed in 7.1.4

Thank you for looking at this!

Not it is not fixed : I have <IP_ADDRESS>008021649 (debian paackage) and still have the issue.

@RastaTaz probably fixed in other tiket https://github.com/dbeaver/dbeaver/issues/9450 in version 7.1.5
version 7.1.5 you can find here https://dbeaver.io/files/ea/


fix: add a log for blueprint creation

Add the following log at [INFO] level in from_config.rs:
tracing::info!("🏭  Blueprint generated in {}ms");

Technical Requirements

It should display the log at info level
Should display time in milliseconds

/bounty 25$

/attempt #2532

need to take care of wasm..

/attempt #2532


Demo in codesandbox is broken.

Demo in codesandbox is broken.

Something weird with antd's Menu component. I just removed it for now and it's working again.


bumping cloudserver version to 8.1

Updating cloudserver version
Updating cloudserver version on package.json for development/8.1
This commit is required to fixup Bert-E's workflow and allowing all PR to be automatically forward ported.

Waiting for approval
The following approvals are needed before I can proceed with the merge:

2 peers

Peer approvals must include at least 1 approval from the following list:

@dora-korpar

@RachedBenMustapha

@rahulreddy

In the queue
The changeset has received all authorizations and has been added to the
relevant queue(s). The queue(s) will be merged in the target development
branch(es) as soon as builds have passed.
The changeset will be merged in:

:heavy_check_mark: development/8.1

The following branches will NOT be impacted:

development/6.4
development/7.4
development/8.0

There is no action required on your side. You will be notified here once
the changeset has been merged. In the unlikely event that the changeset
fails permanently on the queue, a member of Release Engineering will
contact you to help resolve the matter.
IMPORTANT
Please do not attempt to modify this pull request.

Any commit you add on the source branch will trigger a new cycle after the
current queue is merged.
Any commit you add on one of the integration branches will be lost.

If you need this pull request to be removed from the queue, please contact a
member of Release Engineering now.

I have successfully merged the changeset of this pull request
into targetted development branches:

:heavy_check_mark: development/8.1

The following branches have NOT changed:

development/6.4
development/7.4
development/8.0

Please check the status of the associated issue None.
Goodbye tcarmet.


Some cases where Extraction produces invalid OCaml

While trying to extract the whole standard library, I stumbled on some corner case of the extraction that should be fixed at some point.

[ ] extracting names to ocaml kewords (for example a variable called sig)
[ ] extracting an empty datatype to an empty datatype (which is not accepted in ocaml, we should make it abstract)

I'm surprised the first bit is not caught by https://github.com/FStarLang/FStar/blob/master/src/extraction/FStar.Extraction.ML.Syntax.fs#L42 ... ?

If I'm not mistaken the first part was fixed by @victor-dumitrescu  and @mtzguido

The first bit was indeed kinda fixed by several bandaid patches, and then definitely fixed by Nik for #310. I'm trying a fix for the the second point now.


Robustness of eth2 clients to the eth1 node

Would like to suggest this reminder to (all) eth2 clients, to be robust on whatever the eth1 node/infrasturcture does.
Here are some recent observations without calling out clients directly:

In one testnet, new beacon nodes couldn't sync to the testnet because the provided goerli node was overloaded with all the clients it is serving.

On a different client, given a running beacon node, validator, and eth1 node, when the eth1 goerli node started having issues (such as losing peers), after some time the beacon node was not able to continue functioning, and so the validator also stopped working.  It's my understanding that the validator should continue unaffected, if an eth1 node goes down.  This was not the case as the goerli node took down the beacon node. [To this client's credit, the validator node never had to be restarted: when the goerli node and beacon nodes are restarted and function again, the validator node resumes nicely.]

(I recall there was a pre-launch checklist of some sort [by @djrtwo] but I haven't been able to find it again.  I suggest this testing be explicitly added.)

Chiming in on the Prysm side of things since I believe you may have experienced the above issues in our testnet.

new beacon nodes couldn't sync to the testnet because the provided goerli node was overloaded with all the clients it is serving.

In order to determine the genesis state, the beacon node must have access to all of the deposits involved in creating this state. Another idea is that we hardcode the genesis state into the application post-launch.

On a different client, given a running beacon node, validator, and eth1 node, when the eth1 goerli node started having issues (such as losing peers), after some time the beacon node was not able to continue functioning, and so the validator also stopped working. It's my understanding that the validator should continue unaffected, if an eth1 node goes down.

I am not sure if this was Prysm or not, but eth1 connection only affects block proposals. The beacon node should be able to continue without an eth1 connection. In Prysm, we have recently implemented a timeout of 2 seconds when requesting eth1 information during block proposals (https://github.com/prysmaticlabs/prysm/pull/5583). This is to help mitigate any issues where an eth1 node is slow to respond and a block proposal must be created in a timely fashion to maximize the validator's reward. If the timeout is exceeded, a random vote is used.
Thanks

I am not sure if this was Prysm or not, but eth1 connection only affects block proposals.

I think this was with Lighthouse but I can't find the issue anymore. There was nothing to suggest that the eth1 node going down was linked to the beacon node losing peers, apart from one happened some time after the other. I've never observed this, nor can I figure how it might happen so I closed the issue.

pre-genesis issue


Update missing pieces list

I updated the doc following this discourse suggestion.

Looks good. My only complaint is that your text is way, way wider than 80 columns, which makes dealing with the markdown later harder. Please try to put in line breaks where appropriate and re-push, and then I'll merge this.

@pmetzger we should add the 80 columns width recommendation to contributing.md.

Although 80 chars is a little harsh. I'm going to merge this and then fix it up.

@bluddy It's very hard to comment on merge requests etc. when the patch lines cover whole paragraphs. Remember this doesn't alter how the web site looks, only the markdown source code we read.

Fair enough. Let's come up with a number that's > 80 though.

Why >80? When I open my Emacs window, that's how wide it is. That's the case for a lot of people...

Sorry. I did it from the github UI instead of vim so I didn't notice the width. FWIW I use 120 instead of 80.

The lowest common denominator is 80, so I think we should stick to that. (It also starts getting hard for many people to read lines of text when they're too wide.)


Syntax highlighting inconsistencies

Constants are not colored as such when declared, only when used:
-- Variable name is colored as a normal variable
local CONSTANT = 0

-- But colored as a constant here
local var = CONSTANT + 1

Redefined builtins are still colored as builtins:
-- This has the correct coloring
local settings = {
	Foo = "Bar",
}

-- This is colored as a builtin
local bar = settings.Foo

Syntax highlight within typeof(...) is not consistent with highlight outside of typeof:
local function returnsComplexType()
	return {} :: { [string]: { number } }
end

-- Key and [1] both have incorrect highlighting
type Inner = typeof(returnsComplexType().Key[1])

-- This has correct highlighting
local inner = returnsComplexType().Key[1]

Tested with semantic highlighting and Roblox types enabled.

Syntax highlighting is either a problem of the syntaxes file, or semantic tokens:

https://github.com/JohnnyMorganz/luau-lsp/blob/main/editors/code/syntaxes/lua.tmLanguage.json
https://github.com/JohnnyMorganz/luau-lsp/blob/main/src/operations/SemanticTokens.cpp

Definitely open to PRs which try to improve either of these!


ArrayMap

What dy'all think? Is this useful?

Don't know, seems very specific. What is the intended use-case for this?

@quintesse it's especially useful when the keys are enum values.

Ok, but wouldn't it be much nicer then to take the possible key values directly from the enum type itself?

Of course, but at present we have no such contract. We would need a specific interface that defines a mapping to a span of integers, consistent with equality, and without holes. And it's not completely trivial to define this at the instance level. It's really a type class.
Sent from my iPhone

On 6 Apr 2015, at 4:08 pm, Tako Schotanus<EMAIL_ADDRESS>wrote:
Ok, but wouldn't it be much nicer then to take the possible key values directly from the enum type itself?
—
Reply to this email directly or view it on GitHub.

Note that the postulated contract is quite closely related to Enumerable, which would probably also be better expressed as a type class.

Probably saying something stupid, but just using caseValues for the possible keys wouldn't be enough?

I don't see how that helps much. What we would want is an efficient way to get the index value of an instance, without needing to search the list of instances.
Sent from my iPhone

On 6 Apr 2015, at 5:32 pm, Tako Schotanus<EMAIL_ADDRESS>wrote:
Probably saying something stupid, but just using caseValues for the possible keys wouldn't be enough?
—
Reply to this email directly or view it on GitHub.

Well very likely I'm just not understanding the issue, but in the current implementation wouldn't the following work (and be efficient)?
value m = ArrayMap<Comparison, String>(`Comparison`.caseValues);
m.put(larger, "Larger");

If so then I'm just suggesting that instead of ArrayMap we'd have an CaseMap and take the possible key values from the Key type parameter instead of explicitly passing them.
If that's not possible then I'm obviously missing things.
Anyway, it's not that I mind having this class, it just seems to have a somewhat weird API with restrictions on usage that mainly come from the docs and are not really enforced statically.

but in the current implementation wouldn't the following work (and be efficient)?

It would work, but it's not as efficient as an EnumMap in Java.
Well, we could make it as efficient as Java, I suppose, by having the compiler assign an integer value to each instance, and optimizing caseValues.firstOccurrence() to return that value.
Perhaps that's worth doing.

I'm not seeing a performance advantage, even for size=2, unless there is something wrong with my test.
void benchMap([Object*] keys) {
    value entries = [ for (i->k in keys.indexed) k->i ];
    value hashMap = HashMap { *entries };
    value arrayMap = ArrayMap { possibleKeys=keys; *entries };

    value lookups = 50M/keys.size;
    value samples = keys.cycled.take(lookups);

    function hashTest() => samples.fold(0)((sum,x)=>sum+(hashMap[x] else nothing));
    function arrayTest() =>  samples.fold(0)((sum,x)=>sum+(arrayMap[x] else nothing));

    assert(hashTest() == arrayTest());

    benchmark {
        scale = lookups;
        ["hash.size=``keys.size``",  hashTest],
        ["array.size=``keys.size``", arrayTest]
    };
}

shared
void doBenchMap() {
    print ("keys = 0:2");
    benchMap(0:2);

    print ("keys = (0:2).collect(Integer.string)");
    benchMap((0:2).collect(Integer.string));

    print ("keys = [true, false]");
    benchMap([true, false]);

    print ("keys = 0:10");
    benchMap(0:10);

    print ("keys = (0:10).collect(Integer.string)");
    benchMap((0:10).collect(Integer.string));

    print ("keys = 0:30");
    benchMap(0:30);

    print ("keys = (0:30).collect(Integer.string)");
    benchMap((0:30).collect(Integer.string));
}

results, raw values in ns/lookup
keys = 0:2
Summary min/max/avg/rstdev/pct
hash.size=2  21/33/24/20% (100%)
array.size=2 24/32/26/12% (115%)

keys = (0:2).collect(Integer.string)
Summary min/max/avg/rstdev/pct
hash.size=2  53/61/56/5% (100%)
array.size=2 96/122/104/8% (181%)

keys = [true, false]
Summary min/max/avg/rstdev/pct
hash.size=2  27/28/27/1% (100%)
array.size=2 29/30/29/2% (107%)

keys = 0:10
Summary min/max/avg/rstdev/pct
hash.size=10  20/25/22/7% (100%)
array.size=10 44/50/47/4% (213%)

keys = (0:10).collect(Integer.string)
Summary min/max/avg/rstdev/pct
hash.size=10  50/64/55/8% (100%)
array.size=10 232/248/241/2% (464%)

keys = 0:30
Summary min/max/avg/rstdev/pct
hash.size=30  20/22/21/2% (100%)
array.size=30 98/109/102/3% (474%)

keys = (0:30).collect(Integer.string)
Summary min/max/avg/rstdev/pct
hash.size=30  52/62/56/6% (100%)
array.size=30 582/764/640/10% (1102%)

I'm surprised by the small-size results - seems like there's some extra overhead. But all in all the results look reasonable when graphed:

@jvasileff The efficiencies are in storage, not time.

It would work, but it's not as efficient as an EnumMap in Java.

I'm dense I know so just bear with me. Because wouldn't the only slow part be (in my example) the call to Comparison.caseValues? Because after that they would get stored in that internal Key[] possibleKeys sequence and be just as fast or slow as passing in [larger, smaller, equal] manually, right?

The difference between Java's EnumMap and this ArrayMap is the keyIndex() method. In Java I can do keyEnumValue.ordinal() to get the index for the key. We can't currently achieve that efficiency in Ceylon, though we could if we optimized caseValues.firstOccurrence() as outlined above.

The efficiencies are in storage, not time

I use enum map & set all the time, but I guess I don't see the common use case for this in its current form, given the tradeoff even for small maps (and I see it being misused). But I do think the suggested optimized version would be great.

The difference between Java's EnumMap and this ArrayMap is the keyIndex() method

I understand, but I wasn't suggesting to change the current implementation, just the public API (well, a minor change in the initializer section). So instead of passing the list of possible keys it would just be obtained from the Key type parameter. It would make the class less useful perhaps, but if the are no good use-cases outside of enumerations the API would be much improved that way IMO.

@quintesse But that wouldn't be any more typesafe, since there is no way to statically restrict the Key type to be an enumerated type with only object cases.
Also, I'm not at all convinced that there are no good usecases besides enumerations.

But that wouldn't be any more typesafe

Ok, true. Couldn't we add a feature that any type that has only object cases implicitly implements a marker interface Enumeration or something like that? :)

Also, I'm not at all convinced that there are no good usecases besides enumerations.

Perhaps, but a short list of fixed elements seems like an ideal candidate for enumerations, maybe we should encourage people to use them.
And is the storage size that much of a problem? Handling only a very limited amount of items it seems that storage won't be much of an issue unless you are planning on using a large number of Maps, right?
Anyway, I don't think I have anything more to add to this discussion. In its current form it seems to me of questionable value, but whatever people decide is fine with me.

Couldn't it be a more general OpenMap instead that takes a HashingStrategy as a parameter, with the key array a special case created by top level function arrayMap?

@ncorai well the whole point of this is that if it's a hash, where there can be multiple elements in a bucket, then we need each bucket to be a linked list. Whereas for this case each bucket is just an array element.

I was thinking of https://en.wikipedia.org/wiki/Hash_table#Open_addressing, no linked list required. I think it can work without having to probe the item array with the restrictions you've added to the ArrayMap.

Hrm, @ncorai, indeed that is interesting. I'll think about it.

It will be better to have map based on two ArrayLists of comparable keys and values.

This PR has been closed as a result of moving Ceylon to the Eclipse Foundation, not as a judgement of its value. We are unfortunately unable to restore it ourselves, but if you feel this PR should be reopened, please rebase your work on the current master and create a new PR. Thanks, and sorry for the inconvenience.


[staging] Updates to perlPackages 2023-11

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Updating this PR to latest changes from CPAN

@ofborg eval

This PR should prob be updated to latest changes from CPAN before being merged


No error lines in Sway Plugin

The following code does not produce any error lines in the Sway Plugin. Running forc build correctly fails to compile.
Plugin: 0.2.9
Forc: 0.35.1
contract;

use std::block::timestamp;

abi MyContract {
    fn test_function() -> bool;f
    dfsdf
}

impl MyContract for Contract {
    fn test_function() -> bool {
        log(timestamp());
        true
    }
}

Probably can close this issue and discuss this over in https://github.com/FuelLabs/sway-vscode-plugin/issues/141


How can we access the hover property on the card created?

Trying to access the hover property of the card to show the URL that it'd would redirect to. Is that possible in the styles dict itself?

Nope

Any sort of workaround that you think might work out ? Or can something be implemented by default: if a url is specified, show it while hovering over the card.

I think that can be implemented.

@OJddJO are you on it?

@OJddJO are you on it?

No, I was thinking a way to do it but I don't have enough time

For anyone else that is interested, hover properties can be accessed via:
card_style = {
    "card": {
        <CARD PROPS>,
        "&:hover": {
            <HOVER PROPS>
        }
    }
}

Any update on this feature would really like to create a tooltip when hovering over one of the cards.
Thanks for all the work on the package super useful.

Hi everyone I don't think implementing the hover of the card for a tooltip is something we should be focusing on, if you want to stylize the card when the hover effect is on, this is the right way:

For anyone else that is interested, hover properties can be accessed via:
card_style = {
    "card": {
        <CARD PROPS>,
        "&:hover": {
            <HOVER PROPS>
        }
    }
}


bottom: Enable Aero bottom Camera

Intel Aero drone has one camera that needs to have specific parameters
set before accessing it with V4L2. Adding a stream to handle those
specific parameters.
To use the VGA Bottom camera, enable aero stream by using --enable-aero
when running configure.

Can you take a look @lbegani @SaliniVenate

CSD is using gstreamer v4l2src plugin to handle v4l2 devices and there is no parameter to set the channel and the preview.

The user doesn't and shouldn't know about this. Taking a look at https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-v4l2src.html ... can't we just get the fd an do whatever additional ioctl() we want to during initialization, stream or teardown?

It is possible to use the prepare-format callback from v4l2src to change the video channel. But I couldn't find a point in the gstreamer available callbacks to set the capturemode and it is necessary to do that in order to capture the video from that camera. Also not sure if this is the only thing necessary.
@lbegani Can you take a look at this patch and find out a way to implement what @lucasdemarchi is proposing?
The video capture with this patch is working and it was based on capturev4l2 sample on https://github.com/intel-aero/sample-apps.git.
More information about that camera was posted on Intel Aero support forum: https://communities.intel.com/thread/110654

@otaviobp @lucasdemarchi From what I understand -

The discussion is on whether to capture the bottom camera  video stream using gstreamer v4l2src plugin or using direct v4l2 interfaces.
Reason why v4l2src plugin is not used is because the v4l2 parameter capturemode needs to be set to preview mode(0x8000) and there is no way to set this using any of the v4l2src plugin properties.
In theory, it is expected that gstreamer pipeline with v4l2src as source element works. However I need to dig in for more details before I understand the issue.

And change the ioctl to set the video input using VIDIOC_S_INPUT. I am not sure if something else is also needed, but I think that's all.

Merged as is, when agreed changes will be applied on top.


[FLINK-3385] [runtime] Fix outer join skipping unprobed partitions

Could add description on how is the fix being done and proposed result. Thanks

Unprobed, spilled partitions are now retained when performing a build-side outer join (and still discarded in all other cases).
When these unprobed, spilled partitions are loaded by MutableHashTable.prepareNextPartition we simply create an iterator over the spilled segments which are read by the appropriate HashJoinIterator in a single loop.

Thanks for the fix! Will merge this.


unable to get image ':latest': Error response from daemon: invalid reference format

make app-docker-start
docker compose
-f docker/docker-compose.yaml
up --build
WARN[0000] The "DOCKER_IMAGE_NAME" variable is not set. Defaulting to a blank string.
WARN[0000] The "ML_API_SERVER_CELERY_RESULT_BACKEND" variable is not set. Defaulting to a blank string.
WARN[0000] The "ML_API_SERVER_CELERY_BROKER_URL" variable is not set. Defaulting to a blank string.
WARN[0000] The "DOCKER_IMAGE_NAME" variable is not set. Defaulting to a blank string.
WARN[0000] The "ML_API_SERVER_CELERY_BROKER_URL" variable is not set. Defaulting to a blank string.
WARN[0000] The "ML_API_SERVER_CELERY_RESULT_BACKEND" variable is not set. Defaulting to a blank string.
WARN[0000] The "ML_API_SERVER_CELERY_BROKER_URL" variable is not set. Defaulting to a blank string.
unable to get image ':latest': Error response from daemon: invalid reference format
make: *** [Makefile:97: app-docker-start] Error 1

исправлено добавлением в .env


How can i convert the trignometic functional angles from radian to degree

Hi team, How can i convert the default set radian in a trignometric function  to degree. With a wide search i haven't got any perfect solution.

MathJax doesn't do any computation; it is only about display of mathematics.  But if you have computational system where sin(x) produces the sine of x radians, then sin((d/180)pi) will be the sine of d degrees.


Network communication deserves its own facility.

Network communication deserves its own facility.
Originally posted by @antkmsft in https://github.com/Azure/azure-sdk-for-c/pull/115/files

https://github.com/Azure/azure-sdk-for-c/pull/124/commits/b2ebf5c759da95b015beaf2102d9b647fa725e93


UI changed

Fixes #
Checklist

[x] My branch is up-to-date with the Upstream master branch.
[x] I have added necessary documentation (if appropriate)

Changes proposed in this pull request

Map theme changed
Marker changed
UI Refreshed

Screenshots (if appropriate)
Link to live demo (if appropriate):
Closes #

Ignore the #8 PR, something went wrong on those commits.
Have a look on this PR

@heyarviind you could have just edited that PR itself
no worries anyway.
I will close that unnecessary PR then

Can you provide screenshots or even better a live demo of the changes you have done. You can easily make a Github Pages link from any branch of your repository which will contain the live demo.

@yashovardhanagrawal here is the live url link https://www.heyarviind.com/addy-project/

nice change in theme @heyarviind
lets keep this 😄


Add Log handler for Cemu

Cemu does not log messages from OSReport, but it does log messages from OSConsoleWrite, so, let's use that.

OSReport actually uses OSConsoleWrite underneath it, so this is a bug in cemu.

OSReport actually uses OSConsoleWrite underneath it, so this is a bug in cemu.


Lokalise: Translations update

This pull request was initiated by Lokalise (user Tian) at 2019-07-30 01:55:06

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Android support

Open source internal Android code along with the tweaks that were applied in the open source version.
ETA: this week

Also, update Android that's already been pushed to match the new interface