Suppress result show if the last line ends with ;

Example
```!
X = randn(2, 2);
```

Shouldn't show anything but actually shows
2×2 Array{Float64,2}:
 0.392215  0.815316
 1.65514   0.0632031

If the ; is on its own line then the output is indeed suppressed.
```!
X = randn(2, 2)
;
```

ok it's pretty easy; there's a line that checks if the last character is ; but there may be a \n there so it should just be `endswith(..., r";\s*")


Select All jumps to end

Lapce Version
HEAD
System information
Linux (Wayland)
Describe the bug
Ctrl+A (Select All) selects all of the text in the document correctly. The editor is unfortunately then scrolled immediately to the end. It would be better to stay where the view is unless the user does something like arrow keys (to unselect and jump to start/end), typing, etcetera.
This is presumably due to on_ensure_visible immediately scrolling to where the cursor is at.

Happens when formatting too.


ARKit.snapshot() aliasing

When taking a screenshot with ARKit.snapshot() (or other libraries to capture the viewport), there's a lot of aliasing visible on the 3D models, which is not apparent when viewing the models in the scene live.
Here's a screenshot for reference:

How would I go about applying anti-aliasing to the models captured in the screenshot?

Yeah, after closer examination the aliasing is indeed present in the live view as well.
I started looking for a way to change up (or turn on?) the anti-aliasing as described here - but as far as I can see this library does not expose a setting for that.
I haven't been able to look into your source code much so far, but if you can confirm you don't enable anti-aliasing in this library yet, I'm willing to look into it and submit a PR?


Hardlinked files are not counted properly

The same file can appear in multiple places in a directory hierarchy.  This includes things like Rust's own build directories, /rescue partitions with tools like busybox, backups using rsync --link-dest, and so forth.
Traditional du's deal with this by keeping a map of seen inodes and their link counts, and avoid counting additional copies of the same inode - decrementing the link count until all have been seen and the inode can be forgotten.  This may not be perfect for an interactive tool like this, but it would probably be better than nothing.

Thanks a lot for posting your insights on how this is actually implemented in du. This might be helpful when trying to resolve this issue.
Performance-wise it might be OK to implement it, even though the memory consumption might go up visibly. However, being correct AND fast (enough) by default is my preference, too, and as long as hardlink tracking can be disabled I would be happy to see this fixed.

-% target/debug/dua -l /rescue
   1.14 GB /rescue
-% target/debug/dua /rescue
  14.22 MB /rescue

:)

cannot wait :)))!

Hang on while I beat git into submission and repaint part of the bikeshed :)

Closed with release v2.3.0 :)!


Add localStorage-based drawing library

Adding a basic drawing library using localStorage as the storage layer.
Demo video: https://www.youtube.com/watch?v=Vw4j6uzlBTE&feature=youtu.be

[x] View the library with B or with the "Open library" button in the upper left. B also hides the library.
[x] Add saved drawings to the scene by clicking on them, or by clicking the "Add to library" button underneath each entry.
[x] Delete saved drawings by clicking the X underneath them.
[x] Add the current selection to the library with the button in the left island, or with Shift+B
[x] Add the current drawing library from the export dialog using a new button added there. The drawing's name will show up in the button library
[x] View keyboard shortcuts for the library using the keyboard shortcuts menu

Known issues (IMO these are small and shouldn't prevent submission, since the feature is already pretty useful, but LMK how bad these seem):

[ ] No "confirm deletion" when clicking the delete button
[ ] Renaming the project after exporting to library does not rename the entry that was added
[ ] Element coordinates are not normalized (scaled to fit the canvas) when rendered in the drawing library

Future PRs:

[ ] Import / export as ZIP file
[ ] Optional cloud sync (e.g. Google Drive)

This is great! @petehunt, can you figure out how we should move forward between your attempt ( #1787 ) and this one? :)

A couple of thoughts:

I like the drag & drop approach from Pete's PR, if that were added to this library concept then I think it would make the UI feel a little more fluid, making it feel like you're grabbing a drawing from your library and dropping it in

I also like the 3-pane toolbox concept from Pete's PR since it doesn't cover the whole screen; would that scale up to more drawings or is it intended to support a fixed number of shapes?

Maybe the toolbox & library concepts could live together -- the toolbox shows only the 3 most recent shapes from the library with an option to go full screen and see the whole library? Or the library could also allow pinning the most commonly accessed things to the toolbox so it's not just limited to the 3 most recent. Some measure of "frequent + recent" might also be interesting

I also like the 3-pane toolbox concept from Pete's PR since it doesn't cover the whole screen; would that scale up to more drawings or is it intended to support a fixed number of shapes?

It can support any number of items, you can try it.

Maybe the toolbox & library concepts could live together -- the toolbox shows only the 3 most recent shapes from the library with an option to go full screen and see the whole library?

Not sure if we want to complicate it this way, at least for the first implem.

I got a chance to use the demo from Pete's PR -- I like his overall concept better. It feels more minimalistic and the drag & drop experience feels nicer. Do you guys agree? I am happy to close this PR and can instead help contribute with some manual testing / code review on Pete's PR.

@bduffany sounds great. I know that Pete is also short on time, so I'm pretty sure he wouldn't mind if you can take his PR to a shippable state :)

This was superceded by #1787 which got merged.


Have our own syntax highlighting

What we could do is

detect code blocks
call a function on the content of the code block that finds keywords, strings, numbers etc
output id'd HTML elements
have styling in CSS

Since it may be annoying/hard to provide this for every possible language, we could have standard config file for Julia to copy which just keeps track of the keywords that the user want to highlight.
Advantages as mentioned in https://github.com/tlienart/JuDoc.jl/issues/103#issuecomment-469428255_ it could slim down pages further by removing the dependency on highlight.js. Possibly it could still be a "backend" for users who want snippets of code in another language and just want to use an off-the-shelf tool.

We could just use highlight.js offline / at the HTML-generation step. Implementing syntax-highlighting from scratch sounds like a bad idea, since it's a widely "solved" problem. How does Juno/Atom do it? And Documenter.jl?
Or just extract the relevant parts (and CSS) from Pygments, Prism, ...

I definitely agree with the "it's already a solved problem" but I'm not sure I'm with you in terms of how to do it (e.g. how to capture the html that highlight generates or do that pass "offline") but if you have an idea give it a shot and we can compare :)
All of these systems including Juno/Atom at the base have the same kind of idea: they recognise keyword and then apply some style sheet on them, Atom/Juno don't use CSS but some json thing I think (not sure). The part of recognising a set of keywords is easy for JuDoc and takes negligible time, the style sheet could indeed be copied from highlight or prism (btw highlight does a better job at julia than prism).
anyway to make it short:

I'm not sure how you'd do it offline without reimplementing it
I don't think reimplementing it would be hard (but maybe it's not the most useful thing to do right now).

Probably just this: https://juliadocs.github.io/Highlights.jl/stable/man/guide.html#User-Guide-1 :)

Ok so I've now integrated Highlights.jl but it's currently not used. Reasons for that:

modifying the CSS aspect is not directly trivial (but I admit I didn't spend much time to try to tweak it)
if a user shows code that is not supported by Highlights.jl, I feel there should be a fall-back on higlight.js but to make the CSS match would require a bit of fiddling, I may try to get one style to match
a somewhat easier possibility would be to completely ditch highlight.js and just tweak the CSS of Highlight.jl until it looks nice (for all themes!) and just assume that displayed code will be one of the supported language but, for instance, python is not yet in there. That could maybe encourage people to port the python pygment lexer to Highlights.jl

I'm thinking that, for now, we can stick with highlight.js while keeping in mind it's doable to just use Highlights.jl but I'm open to suggestions. Moving this to low-priority though as "it works" and is not too much of a performance drain.


React empty component on first load

Hi :)
I found an issue when i connect an asyncProp to a component which is the first route matched by react router on the first app loading.
Router wait correctly until the async task is complete but the default DOM displayed to the user:

Initializing...

Is replaced by a comment of react:

I think it's because redux-connect return an empty (null) component until the async loading of the component is done.
I'm sure you understand it's a problem because an application can't show "nothing" to the user until she's ready.
There is a workaround to keep the default state in the DOM ? Or a workaround to define a component to display as a loading screen until the first loading of the application is done ?
Thank you very much per advance !
Nicolas

Here's a workaround:
index.html

bundle.js
const initialize = (name) => new Promise((resolve) => {
  window.setTimeout(() => {
    resolve(name);
  }, 2000);
});

@asyncConnect([{
  key: 'name',
  promise: () => initialize('foo')
}])
class Index extends React.Component {
  render() {
    return (

        <Link to="/test">Test</Link>

{this.props.name}

    )
  }
}

@asyncConnect([{
  key: 'name',
  promise: () => initialize('bar')
}])
class Test extends React.Component {
  render() {
    return (

        <Link to="/">Index</Link>

{this.props.name}

    )
  }
}

@connect(
  state => ({
    loaded: state.reduxAsyncConnect.loaded
  })
)
class Initial extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      initialLoadComplete: false
    };
  }

  componentWillReceiveProps(nextProps) {
    this.setState({
      initialLoadComplete: this.state.initialLoadComplete || nextProps.loaded
    });
  }

  render() {
    return

      {!this.state.initialLoadComplete ?
Initializing...
 : null}
      {this.props.children}

  }
}

const store = createStore(combineReducers({reduxAsyncConnect}));

render((
  <Provider store={store} key="provider">
    <Initial>
      <Router render={(props) => <ReduxAsyncConnect {...props}/>}
              history={browserHistory}>
        <Route path="/" component={Index}/>
        <Route path="/test" component={Test}/>
      </Router>
    </Initial>
  </Provider>
), document.getElementById('root'));

Hello @dlakata
It works perfectly ! Thank you very much ;)
I think it should be added to the wiki, i will send a pull request...
Thanks !


added this.props.onStateChange to allow finer control about events

Hi! Thank you for react-youtube, it really saved my life in a project I'm working on.
But: I need a finer control about the changing state of the player. So I added the optional onStateChange prop, that will also take a function. It shouldn't break the plugin for anyone else, but would make it work for me.
Regards,
Daniel

Oh, wait, I made a mistake.


POSIX_IDENTIFIERS compatibility

zsh-autosuggestions plugin doesn't work when zsh has posix_identifiers option enabled.
when set, it keeps complaining about "bad math expression: operator expected at "name..."
but if you surround it with {} it stops and works again

Forgot to mention it work without that option being set


Fix checking run ID in proper location

Two problems fixed with this PR:

id is the wrong variable name
the logger.info raises an error if no run_id: f"runs/{run_data['id']}/" before the RuntimeError

Closes #
Example

Checklist

[x] This pull request references any related issue by including "Closes #<ISSUE_NUMBER>"

If no issue exists and your change is not a small fix, please create an issue first.

[x] This pull request includes tests or only affects documentation.
[ ] Summarized PR's changes in CHANGELOG.md

Failing test unrelated to Prefect


layers.Bidirectional doesn't support multi_gpu_model() method

System information

Have I written custom code (as opposed to using example directory):  Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):  Ubuntu 16.04
TensorFlow backend (yes / no):  Yes
TensorFlow version:  1.12.0
Keras version:  Latest
Python version:  3.6
CUDA/cuDNN version:  CUDA 9.0 / libcudnn7_<IP_ADDRESS>-1+cuda9.0_amd64
GPU model and memory:  2 * RTX 2070 8G

Describe the current behavior
I created a model by using the bidirectional LSTM but it cannot be passed through multi_gpu_model() method when I trying to do the distributed training.
with tf.device('/cpu:0'):
     model = tf.keras.Sequential()
     model.add(layers.Bidirectional(layers.LSTM(_HIDDEN_SIZE, return_sequences=True, input_shape=(_TIME_STEPS, _FEATURE_DIMENTIONS))))
     model.add(layers.Dropout(0.5))
     model.add(layers.Bidirectional(layers.LSTM(_HIDDEN_SIZE, return_sequences=True)))
     model.add(layers.Dropout(0.5))
     model.add(layers.TimeDistributed(layers.Dense(_NUM_CLASSES)))
     model.add(layers.Flatten())
     model.add(layers.Dense(_NUM_CLASSES, activation='softmax'))

If you remove the bidirectional wrapper and use the normal LSTM layer, the error below will not happen:
2019-07-05 12:09:29.034218: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2019-07-05 12:09:29.199596: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:964] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2019-07-05 12:09:29.200231: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1432] Found device 0 with properties:
name: GeForce RTX 2070 major: 7 minor: 5 memoryClockRate(GHz): 1.725
pciBusID: 0000:01:00.0
totalMemory: 7.76GiB freeMemory: 7.42GiB
2019-07-05 12:09:29.329679: I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:964] successful NUMA node read from SysFS had negative value (-1), but there must be at least one NUMA node, so returning NUMA node zero
2019-07-05 12:09:29.330551: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1432] Found device 1 with properties:
name: GeForce RTX 2070 major: 7 minor: 5 memoryClockRate(GHz): 1.725
pciBusID: 0000:03:00.0
totalMemory: 7.77GiB freeMemory: 7.65GiB
2019-07-05 12:09:29.330632: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1511] Adding visible gpu devices: 0, 1
2019-07-05 12:09:29.806507: I tensorflow/core/common_runtime/gpu/gpu_device.cc:982] Device interconnect StreamExecutor with strength 1 edge matrix:
2019-07-05 12:09:29.806532: I tensorflow/core/common_runtime/gpu/gpu_device.cc:988]      0 1
2019-07-05 12:09:29.806537: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1001] 0:   N N
2019-07-05 12:09:29.806540: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1001] 1:   N N
2019-07-05 12:09:29.807007: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 7134 MB memory) -> physical GPU (device: 0, name: GeForce RTX 2070, pci bus id: 0000:01:00.0, compute capability: 7.5)
2019-07-05 12:09:29.807412: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:1 with 7358 MB memory) -> physical GPU (device: 1, name: GeForce RTX 2070, pci bus id: 0000:03:00.0, compute capability: 7.5)
Traceback (most recent call last):
  File "debug.py", line 54, in <module>
    para_model = multi_gpu_model(model, gpus = _GPUs, cpu_merge = True, cpu_relocation = False)
  File "/home/tpc2/anaconda3/envs/machine-learning/lib/python3.6/site-packages/tensorflow/python/keras/utils/multi_gpu_utils.py", line 239, in multi_gpu_model
    outputs = model(inputs)
  File "/home/tpc2/anaconda3/envs/machine-learning/lib/python3.6/site-packages/tensorflow/python/keras/engine/base_layer.py", line 694, in __call__
    in_deferred_mode = isinstance(input_list[0], DeferredTensor)
IndexError: list index out of range

Code to reproduce the issue
The testing code has been attached below:
import numpy as np
import csv
import time
import math
import tensorflow as tf
from tensorflow.keras import layers
from tensorflow.keras.utils import multi_gpu_model

# parameters here
_GPUs = 2
_LR = 0.00003
_BATCH_SIZE = 128
_EPOCH = 150
_NUM_CLASSES = 2
_TIME_STEPS = 10
_FEATURE_DIMENTIONS = 34
_HIDDEN_SIZE = 300

# Model defined below: Bidirectional LSTM + Fully connected layers
with tf.device('/cpu:0'):
    model = tf.keras.Sequential()
    model.add(layers.Bidirectional(layers.LSTM(_HIDDEN_SIZE, return_sequences=True, input_shape=(_TIME_STEPS, _FEATURE_DIMENTIONS))))
    model.add(layers.Dropout(0.5))
    model.add(layers.Bidirectional(layers.LSTM(_HIDDEN_SIZE, return_sequences=True)))
    model.add(layers.Dropout(0.5))
    model.add(layers.TimeDistributed(layers.Dense(_NUM_CLASSES)))
    model.add(layers.Flatten())
    model.add(layers.Dense(_NUM_CLASSES, activation='softmax'))
    opt = tf.keras.optimizers.Adam(lr = _LR)

para_model = multi_gpu_model(model, gpus = _GPUs, cpu_merge = True, cpu_relocation = False)
para_model.compile(optimizer = opt, loss = 'binary_crossentropy', metrics = ['accuracy'])

Anyone know it's a bug or caused by myself? Thank you.

There's a mistake in the first line:
model.add(layers.Bidirectional(layers.LSTM(_HIDDEN_SIZE, return_sequences=True, input_shape=(_TIME_STEPS, _FEATURE_DIMENTIONS))))
Correct:
model.add(tf.keras.layers.Bidirectional(tf.keras.layers.LSTM(_HIDDEN_SIZE, return_sequences=True),input_shape=(_TIME_STEPS, _FEATURE_DIMENTIONS)))

Thank you! The problem has been solved and I will close this issue.


5.7 interface requests

Is there any way to get some features from the old version?
In particular the main screen giving you access to all your accounts instead of having to have a drop down to pick each account.
Also I miss the buttons at the bottom while reading. On bigger phones going to the top to delete is much more cumbersome.
Not having a reply all is also less than optimal. I know you can get to it through the drop down, but that is much more involved than just hitting the button as before.
Thanks!

Most important for me would be a way to select multiple mails fast. Long press and then select is not an option. Swipe right like in the last 6+ years would be gteate.
In general a good UI design is easy and fast to work with, adding at least one press/click for each action is step in the wrong direction.
An other characteristic are short distances between ui elements often used consecutively. The upper left corner is too far for most users to reach easy. Therefore changing mail accounts became a job for both hands.
To add a positive point, the design looks a lot more modern.

I've been using the 5.7 update for the past day, and there are many features from the K-9 Mail that I use.
This includes the main screen showing all the E-Mail accounts in a list, now you have to use the left tab to select E-Mail accounts (takes more time). The icon shortcuts that were on the bottom of the screen are gone, and now have to stretch to the top of the screen to get the functions. Each account no longer has its own dedicated LED Notification Color, they are all now default Blue.
Because of this, I have to remove 5.7 and go back to using 5.6 despite it keeps saying Sync Disabled for my IMAP accounts (even with 15 min Polling selected).

I agree with the other posts. I like the new design better then the old one, but the usibility is not better.
One point I want to add is, that the attachments of a mail is showing only at the end of a mail. So you always have to scroll to the end of the mail to see and save the attachments. I would prefer to have a icon in the header to see that there are attachments in this mail and if you click on it you will see all attachments. Also the icon for the attachments it self is always the green andriod logo and not a document type specific logo like PDF, JPG, Word, Excel etc

In software engineering there is a rule that you must not break: usability over design!
I will also go back to the old version, if this is going to the production version I must quit using k-9.
I thought k-9 ks for professional users only, but now I think it's the opposite. I know it took many time but for what?
Sorry if it sounds rude, but I think this is the wrong way...

I agree with the other posts. I like the new design better then the old one, but the usibility is not better.
One point I want to add is, that the attachments of a mail is showing only at the end of a mail. So you always have to scroll to the end of the mail to see and save the attachments. I would prefer to have a icon in the header to see that there are attachments in this mail and if you click on it you will see all attachments. Also the icon for the attachments it self is always the green andriod logo and not a document type specific logo like PDF, JPG, Word, Excel etc

Sadly the attachments at the bottom has been a request for years, but seems to generate hot debate.  I agree that having it at the bottom is wrong, but this thread https://github.com/k9mail/k-9/issues/2067#issuecomment-559381643 has not been commented on for a long time.  I would do this myself, but don't have the coding knowledge.

When replying, the new message window pane is only 3 lines long.
There is over 5x as much space devoted to the quoted text pane as there is to the composition pane, which does not Auto-expand as you enter text into it (pushing the quoted text down)

I second the "buttons at the bottom went up"-issue. This is not really meaningful, if you have a huge display.

I agree with @Hustensirup in his main point. UX before design. With the new release you removed more than one the half of the user stories you supported in the old version. Only some examples: Missing the unified inbox by default. Overview over all accounts in one place. Swipe gestures in list and many more details.

I can't use the new interface. I liked to select quickly mesages and see all my mailboxes at once.
I can't see if I have new mail with the new ui. And I don't want to use unified mailbox neither.
I reverted to old version.
Do you plan to improve the new ui to have feature of the old ?

As I wrote in another issue report, I like the new UI and am grateful to the devs for their work, but there a few features missing in this new version:

time remaining before next sync and sync errors are no longer shown
the size of the local file for each account is no longer shown
the names of the folders are no longer translated nor exapnded (for example "outbox" -> "messages envoyés" or "sent items"), there was an option for that in setting but it has been removed
please bring back the possibility to store the local files in sdcard (the fake internal one) for backup puroposes
for manual update outside automatic sync, one has to scroll down each folder, there should be a command to run update per account, as it was before
it would be great to be able to select mails by scrolling them horizontally as before (switching to right to left not to interfere with the drawer, for example)
the top right arrow when composing a mail is to close to the send icon, there is a risk that trying to save a mail as a draft, you accidentally send it while it is not finished

Thanks in advance, I think the app is on the right track.

I found two other issues:

in any folder (inbox, outbox...), pressing the three dots at the top right corner opens a menu where there is a "delete" command at the bottom, but this does nothing
the counter of unread messages of the outbox folder (not the one containing the already sent elements but the the one where mails being sent are temporarily stored) is not reset to zero after a mail is manually sent from this folder (to reproduce this bug, disconnect the phone from network, send a mail, it will remain in this outbox folder and an error notification will be shown, then reconnect the phone to the network, go to the outbox folder, press the three dots menu and then the send command: the counter of unread messages in the drawer in front of the outbox folder will remain at one until you close and reopen K9-mail, although there is no more mail in the folder).

I am guessing we will not receive any traction here sadly.

I'm staying with 5.6
Just wish I could get Play Store to stop showing there is an update available.

Indeed it seems :( I saw users on french forums abandoning k9. And the day I will loose the apk, if the ui hadn't adressed these issues, I will drop it too.
Could a developer inform us on their intention for the ui ? Will they address issues or continue with this reduced ui experience ?
It is cumbersome to switch between versions to test if k9 improves.

I'm staying with 5.6
Just wish I could get Play Store to stop showing there is an update available.

You could get it from F-Droid, where you can disable updates per-app.

It looks like this will result in a fork, which is a real shame, but it's what happens if you throw your community off the boat.

I'm staying with 5.6
Just wish I could get Play Store to stop showing there is an update available.

Just unsuscribe to the beta program, I guess, as 5.7 is a pre-release, and as far as I am concerned, I don't see all related updates in Google Play Store.

It looks like this will result in a fork, which is a real shame, but it's what happens if you throw your community off the boat.

Maybe we should not get too impatient, after all, the devs are aware that there are too many issues and regressions to release the app in its current state. Interface aside, the bugs with mails saves as draft and with the scrolling of the answer to a mail during edition are just incompatible with a everyday use of the present version.
Like you, I just hope that K9 mail will never become a project between buddies for the buddies, as K9 mail has some uncommon very useful features, such as deletion sync settings, and also because the situation is not great with alternative apps and the state of mind of their authors (just read posts on XDA about F---E---- !). So, for the time being, I just prefer to tell my gratitude to the devs of K9 mail who work for free on this project and wish everything would be back to a satisfactory condition before the public release.

Thank you all for your feedback. The comments in this issue address a lot of different parts of the app. That makes it very hard to have a constructive discussion on how to improve the app to make it work for you (or telling you that particular use case won't be supported in the future).
We're still quite a bit away from a new stable release. Some of the features that have been removed are coming back in different forms. The open issues for the 5.800 milestone can be found here: https://github.com/k9mail/k-9/milestone/24
Most of the problems mentioned here have already been discussed in more focused issues. Please use the issue search to find them (be sure to include closed issues) and learn how they will be addressed in the future.
I'm closing this issue because it's not focused enough so we could use for planning development work.


[Feature Request] Infinite memory

Proposal
We've got a product that needs to roll into prod and is going to demand (pick a number) terabytes of memory to support the cardinality they're sending.
Are you guys making any progress towards, like, quantum memory or a singularity? How exactly should we answer this request?
No matter how you slice it, you guys are making us store string text for every timeseries, so at minimum, we're talking half a kilobyte of overhead for six kilobytes of data. And sure, we can shard, but why can't I be like, "actually, how about we DON'T keep two hours of samples memory, we aggregate it after five minutes and send it straight to thanos so it becomes bwplotka's problem."
Agent was a good start but it just pushes the problem further down the pipe, because eventually, we've got to load everything back into memory to aggregate it, no?

There is already the stringlabels refactoring that deduplicates the strings in memory quite a bit.
If you know your data well, you can adjust the block duration (--storage.tsdb.min-block-duration) to match your scrape or rule interval and flush faster than every 2 hours. (I'm looking to move our production config to 1h to match our 15s scrape interval and 30s rule interval defaults)

@faangbait I think you are correctly understanding that Prometheus was designed with strict constraints, primarily that everything runs as one process.  A common approach for large estates is to split up the metrics across multiple Prometheus, e.g. by app or by region.
There are several projects which take the core of Prometheus and split pieces of it to run distributed across multiple machines. I haven't kept up with all of them, but Mimir does not need to bring all the data to one place for most queries.  Promcon talk about query-sharding.
On a point of detail about deduplicating strings, none of the currently-merged implementations do that.  I wrote up some details in this document.  There have been some proposals to do it - #5316, #11833 - plus I am working on another, described as option 5 in the doc. However labels are ~30% of the memory in a typical Prometheus (My Promcon talk) so this is not going to solve your whole problem.
I am minded to click the "convert to discussion" button.

A common approach for large estates is to split up the metrics across multiple Prometheus, e.g. by app or by region.

That piece of the puzzle seems well-architected. The piece I'm asking about is specifically aggregating at the scrape level.
Say you've got 10,000 pods that will be horizontally scaled. You don't particularly care about the metrics in any particular pod, but you need to know the average. Now, prom scrapes throw an Instance label on each pod. Which makes a lot of sense, because you need to know what to scrape next time, too. And we could remove the instance label by just, setting it to a static value and honoring it, but that wouldn't remove the address meta label, which means a 10000x explosion.
Victoria structures their memory differently but arrives at the same problem. And it seems like the key reason everyone arrives at the same answer is because the only way to take an average is to load all the values in memory. So... we're back to infinite memory.
Zapier's aggregator version of pushgateway seems like the best solution, but pushing metrics is generally bad. And they don't have much development help.

You don't particularly care about the metrics in any particular pod

Until you do. It's not uncommon, especially in non-trivial networks, to have hot spots or misbehaving infrastructure that disproportionately affects a handful of instances. These few instances are still "healthy", but are serving enough slow requests that it triggers our p99 SLO threshold and we have to cordon the node for investigation.
Without the instance / pod labels, we would not be able to pinpoint the source of the problem quickly.

I like the idea that metrics are aggregated most of the time, at the point of scrape as far as possible, but there is a button on the UI to say "give me full detail here" that stops the aggregation within some scope for a period, e.g. 10 minutes.
I'm not aware of specific work in the Prometheus domain to achieve this, but have been in some blue-sky conversations about it.
One nit:

the only way to take an average is to load all the values in memory

You can distribute computation of sums of values and sums of counts, then bring those together to average. At least one downstream project does this.


Looking forward to your code!

Great work! When will you plan to release your code?

Hi @Ivan-Tang-3D , Sorry for the late response, since the paper is still under review, we are still waiting for the submission results, and we plan to release the code ASAP!

@Ivan-Tang-3D


chore add more log for better tracing for be write

Proposed changes
Issue Number: close #xxx
Recently when tracing when bug happened in version1.1.4 I found out there were some places we can add more log for a better tracing.
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

This PR will print too much logs. If you want to add log to debug temporarily, I suggest to commit in your own repo and test your own branch.

Sorry for so many annoying logs. I do agree it's too many logs and some of them might be redundant. And I do want to seek some help from reviews about which log should be added😂.
I intend to add some useful logs like 1. printing the rows processed by add_batch 2. _pending_batches_bytes when closing the node_channel 3. skipped tablet id when add batch 4. print the afterwards log when it's the last rpc 5. print the logic that has something to do with eos.
The intention to add these logs is that recently we are encountered with one strange bug that one txn's logs show there were no delta writers for a node channel on one client BE. But it's curious cause when you open one node channel there must be at least one tablet and corresponding delta writer. And the afterwards load channel destructor log even show there is no memory usage indicating there is no write. It's so strange.

i don't know which log can help you to debug your issue. but for me, this should be debug log.
my point is，how about adding these logs to a temp branch and run it in your env to debug？


[Help]: During the Refrem Senes operation, the strip was cropped incorrectly

Describe the problem you met
sbas.compute_reframe(AOI)，An error occurred while cropping the image
OS and software version
If applicable, what operating system and software version you are using?
OS: colab
GMTSAR version:
Reproduce the problem
If applicable, how to reproduce the problem from scratch?
Log file
BUFFER = 0.05
Screenshot
If applicable, attach a Screenshot to help us understand your case

[Please note that if no new responses are made over six months from users, the issue will get closed]
[Also if this is a general question that's not particlarly related to GMTSAR, such as "how to correct atmospheric noise" or "how to intepret my interferogram", consider using the discussions page]

Please share your AOI file and the used scenes list.

This is my AOI range
    [ 109.446, 25.6771  ],
    [ 109.624, 24.8848 ],
    [ 110.8204, 24.7592 ],
    [ 111.1063, 25.7768 ],
    [ 110.8573, 26.092  ],
    [ 109.8426, 25.8682 ],
    [ 109.446, 25.6771  ]

This is my scenes list.
S1A_IW_SLC__1SDV_20231223T104313_20231223T104340_051781_064118_9D62
S1A_IW_SLC__1SDV_20231223T104248_20231223T104315_051781_064118_F0B7
S1A_IW_SLC__1SDV_20231211T104314_20231211T104341_051606_063B0E_65D0
S1A_IW_SLC__1SDV_20231211T104249_20231211T104316_051606_063B0E_C57B
S1A_IW_SLC__1SDV_20231129T104314_20231129T104341_051431_0634F7_63FC
S1A_IW_SLC__1SDV_20231129T104249_20231129T104316_051431_0634F7_9581
S1A_IW_SLC__1SDV_20231117T104315_20231117T104342_051256_062EED_5D38
S1A_IW_SLC__1SDV_20231117T104250_20231117T104317_051256_062EED_7730
S1A_IW_SLC__1SDV_20231105T104315_20231105T104342_051081_0628DE_4634
S1A_IW_SLC__1SDV_20231105T104250_20231105T104317_051081_0628DE_7BD5
S1A_IW_SLC__1SDV_20231024T104315_20231024T104342_050906_0622E1_EEC5
S1A_IW_SLC__1SDV_20231024T104251_20231024T104318_050906_0622E1_F00F
S1A_IW_SLC__1SDV_20231012T104315_20231012T104342_050731_061CEA_55EC
S1A_IW_SLC__1SDV_20231012T104250_20231012T104317_050731_061CEA_9B43
S1A_IW_SLC__1SDV_20230930T104316_20230930T104342_050556_0616E8_61C0
S1A_IW_SLC__1SDV_20230930T104251_20230930T104318_050556_0616E8_2D4E
S1A_IW_SLC__1SDV_20230918T104315_20230918T104342_050381_0610ED_BF21
S1A_IW_SLC__1SDV_20230918T104250_20230918T104317_050381_0610ED_12BB
S1A_IW_SLC__1SDV_20230906T104315_20230906T104342_050206_060AF8_B399
S1A_IW_SLC__1SDV_20230906T104250_20230906T104317_050206_060AF8_448C
S1A_IW_SLC__1SDV_20230825T104314_20230825T104341_050031_0604FA_1335
S1A_IW_SLC__1SDV_20230825T104249_20230825T104316_050031_0604FA_D357
S1A_IW_SLC__1SDV_20230813T104313_20230813T104340_049856_05FF08_A517
S1A_IW_SLC__1SDV_20230813T104248_20230813T104315_049856_05FF08_77C4
S1A_IW_SLC__1SDV_20230801T104313_20230801T104344_049681_05F95D_17C2
S1A_IW_SLC__1SDV_20230801T104248_20230801T104315_049681_05F95D_0B5B
S1A_IW_SLC__1SDV_20230720T104312_20230720T104344_049506_05F3F1_9F57
S1A_IW_SLC__1SDV_20230720T104247_20230720T104314_049506_05F3F1_EE80
S1A_IW_SLC__1SDV_20230708T104311_20230708T104343_049331_05EE9E_D0C4
S1A_IW_SLC__1SDV_20230708T104247_20230708T104314_049331_05EE9E_78C5
S1A_IW_SLC__1SDV_20230626T104310_20230626T104342_049156_05E936_F3D6
S1A_IW_SLC__1SDV_20230626T104245_20230626T104312_049156_05E936_1AA3
S1A_IW_SLC__1SDV_20230614T104310_20230614T104337_048981_05E3EA_FC53
S1A_IW_SLC__1SDV_20230614T104245_20230614T104312_048981_05E3EA_A5B7
S1A_IW_SLC__1SDV_20230602T104309_20230602T104336_048806_05DE8E_027D
S1A_IW_SLC__1SDV_20230602T104244_20230602T104311_048806_05DE8E_BD57
S1A_IW_SLC__1SDV_20230521T104309_20230521T104336_048631_05D95A_D4D9
S1A_IW_SLC__1SDV_20230521T104244_20230521T104311_048631_05D95A_9E27
S1A_IW_SLC__1SDV_20230509T104308_20230509T104335_048456_05D42F_23E0
S1A_IW_SLC__1SDV_20230509T104243_20230509T104310_048456_05D42F_0777
S1A_IW_SLC__1SDV_20230427T104307_20230427T104334_048281_05CE54_0414
S1A_IW_SLC__1SDV_20230427T104243_20230427T104310_048281_05CE54_4296
S1A_IW_SLC__1SDV_20230415T104307_20230415T104334_048106_05C87A_9D67
S1A_IW_SLC__1SDV_20230415T104242_20230415T104309_048106_05C87A_32B7
S1A_IW_SLC__1SDV_20230403T104307_20230403T104334_047931_05C28C_31AD
S1A_IW_SLC__1SDV_20230403T104242_20230403T104309_047931_05C28C_98C4
S1A_IW_SLC__1SDV_20230322T104306_20230322T104333_047756_05BCB0_F9B1
S1A_IW_SLC__1SDV_20230322T104241_20230322T104308_047756_05BCB0_BAF0
S1A_IW_SLC__1SDV_20230310T104306_20230310T104333_047581_05B6C0_19ED
S1A_IW_SLC__1SDV_20230310T104241_20230310T104308_047581_05B6C0_7A58
S1A_IW_SLC__1SDV_20230226T104306_20230226T104333_047406_05B0D6_52DC
S1A_IW_SLC__1SDV_20230226T104241_20230226T104308_047406_05B0D6_2672
S1A_IW_SLC__1SDV_20230214T104306_20230214T104333_047231_05AAD7_CCD0
S1A_IW_SLC__1SDV_20230214T104241_20230214T104308_047231_05AAD7_6DAE
S1A_IW_SLC__1SDV_20230121T104307_20230121T104334_046881_059F27_083A
S1A_IW_SLC__1SDV_20230121T104242_20230121T104309_046881_059F27_A838
S1A_IW_SLC__1SDV_20230109T104307_20230109T104334_046706_05993F_C0BC
S1A_IW_SLC__1SDV_20230109T104242_20230109T104309_046706_05993F_F168

Is it because the selected area is too large?

It's about 58 scenes, the same track

I changed the width of the AOI so that when it sits on a strip, the strip can be cropped very well

AOI
   [109.3624, 25.6768],
   [109.6699, 24.3012],
   [110.3915, 24.4266],
   [110.0693, 25.7938],
   [109.3591, 25.6697]

SCENES LIST
The list of scenes is the same as the one above

But my research area occupies two strips, please Mr. Alexey do you have a solution @mobigroup

Fixed in the recent commit, please try.

Fixed in the recent commit, please try.

Thank you very much for your help, dear Mr. Alexey


fix: incorrect path

the path in question is not under an object containers, but rather under an array containers, which means that .spec.containers.volumeMounts is invalid.  The [*] syntax is used throughout the site, so I went with that to denote selecting an item from the containers array.

/lgtm
/approve


Stackstorm update gulp-csscomb

updated gulp-csscomb in order to fix deprecated minimatch

@bgaeddert yes I had planned on attacking each gulp dependency individually.


feat: Refactoring, more options and tests

Sorry, I kind of went over everything and couldn't really untangle it into multiple PRs afterwards. Anyway, this PR adds this:

Advertising of our features in the README.md
Adding a golangci-lint config and CI steps
Rework of the option system in a way that compileOptions does not need to know how to merge everything. Now each option can decide how to merge itself into the existing options.
Rework of the test setup to be more flexible, allow for empty folders and to be platform agnostic (hopefully, not tested).
Expose afero.Fs as fileglob.FileSystem in our API because I thought having other package's types in our API signature is awkward
Option to choose a custom separator (useful if users specify custom filesystems)
Option to choose directory behaviour (should supersede #2)
More tests for each pattern type and the options

I also encountered some problems:

afero does not support symlinks for in-memory filesystems. We probably don't need symlink options for nfpm and goreleaser but eventually someone will probably want this and then we need to test it somehow
afero does not support custom separators so I don't know how to test WithSeparator

Open Questions:

Should we remove custom separators again because they can't be tested (and we don't currently need them ourselves)?
What should we do about the directory matching behaviour (see discussion in #2)?

about the separator, I think it would only be relevant if we use it on something else that isn't file paths... I think we can just default to filepath.Separator and remove the option 🤔

Alright, we'll remove it and make the directories behave like they do in zsh.


Display mongo server connection error in explorer

Rather than popping up the vscode error message, display it right in the explorer.
Also, delay showing error messages for attached nodes until the user expands the node (rather than when the extension is activated)
Fixes #54

@nturinski we can't create an error node when attaching a db errors. We have to connect to the db to get the host and port, which we use as the label for the main node.
Any comments you put on a review are appreciated and not viewed as revenge :) You did make me realize that I should propagate the error in the attach scenario so that it's caught by our telemetry


Add websocket tool

Sends out the events as JSON messages via WebSocket
The current implementation needs some clean up. This is primarily a proof-of-concept.

Rebased on #22


Choose web browser with -UseWebLogin

It looks like -UseWebLogin still uses the IE7 web browser control. If so, are there any plans to upgrade to Microsoft.Toolkit.Forms.UI.Controls.WebView?

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

ID: 7f910a5c-5883-6394-19a3-4cf1670c431f
Version Independent ID: 4451fe4c-df86-34a8-0db0-46a47e70b5a5
Content: Connect-PnPOnline (sharepoint-pnp)
Content Source: sharepoint/sharepoint-ps/sharepoint-pnp/Connect-PnPOnline.md
GitHub Login: @techwriter40
Microsoft Alias: kirks

@officedocsbot assign @yogkumgit

Hello @anthonywhite
Thanks for your feedback. This issue resource is specifically to report about issues in documentation, as you might know, Sharepoint PnP cmdlets are community driven, and they have specific resources to suggest bugs, ideas and feedback, please visit here to more information https://docs.microsoft.com/en-us/sharepoint/dev/community/community
Hope this information helps you

@get-itips  Thank you very much for the contribution and sharing this explanation. @anthonywhite
Hope this comment is helpful for you. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.

@officedocsbot close


Set-based selection logic vs boolean algebra selection logic

The current proof presentation describes the link between input_descriptors and the input_selection via a set-based rule mechanism e.g. "Satisfy all of set A", "Pick # of set B".
This requires all input_descriptors to be assigned to one or more sets.
An alternative approach to the set-based requirement description could a a boolean algebra approach  where input_descriptors are atomic elements describing the input elements that can be identified uniquely ('e.g. "id", "routing_number"') and input_selection describes a boolean algebra like.
[
{
"and": [ "routing_number", "account_number", "idToken"]
},
{
"or": [ "idCard", "passport" ]
}
]

This is just a dummy boolean algebra system. I feel there might be good ones out there already. We should use the same on that we use to represent constraints on individual input_descriptors.
E.g. also see https://stackoverflow.com/questions/20737045/representing-logic-as-data-in-json

https://github.com/epoberezkin/ajv#validation-keywords

I am not seeing anything in JSON Logic, AJV, or Mongo syntaxes to describe the fundamental requirement for multi-option requirement fulfillment: "Pick X from set Y". I would like to timebox this exploration to expire at the next spec meeting, so we can move forward with something. Can we try to see if anything exists to fulfill the multi-option selection use case over the remainder of the week, and if not, just move on?

If by "Pick X from set Y" you are meaning something similar to "present a degree from a UK university" then the way we are addressing this problem is via an ontology that defines the class UK university and each UK university that is a member of this class.

If by "Pick X from set Y" you are meaning something similar to "present a degree from a UK university" then the way we are addressing this problem is via an ontology that defines the class UK university and each UK university that is a member of this class.

No, this is more like a verifying party specifying that they need a certain condition fulfilled, and one of many options may exist to do so - for example: Say I am registering to vote, and it requires proof of citizenship and residence in an area. The citizenship requirement could be fulfilled via a Driver's license, Passport, or State ID, while the residence requirement may be fulfilled via a electric, garbage, or other type of billing statement. In this spec, we are enabling a verifying party to state "Give me X from group Y, and T from group N".

This is simple to specify using a policy tree in CNF. e.g.
(citizen from passport OR citizen from DL OR citizen from StateID) AND (Name and Address from Electric bill OR name and address from Gas bill OR name and address fromf water bill etc)
This is exactly how we specify our policies in JSON

As I said in another post, specifying verifier policies in CNF or DNF allow you to specify any conceivable combination of VCs

This has been relatively solidified now, so I am looking to close it in favor of what we have specified in the spec.

Yes, I agree that we had a clear consensus for a set based logic since it’s a more natural expression syntax then Boolean CNF or DNF.


Remove speak from everything except adaptive card in shared model and UWP projections

@riarenas,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Too many conflicts! closing and reopening once resolved.


Add Userpilot (Actions) Destination Docs

Proposed changes

Userpilot new integration docs
Update description
Add ID to Userpilot Docs

Merge timing

ASAP once approved.

Related issues (optional)
#5000

@rchinn-segment can we get this one merged before site rebuild tomorrow?

@tcgilbert - absolutely, we'll merge and include this in our deploy tomorrow


[BEAM-3705] ApproximateUnique resets its accumulator with each firing.

extractOutput() ended up resetting underlying aggregation. This is due to use of extractOrderedList() which removes all the elements from the heap. extractOrderedList() is costly and is not required either. extractOutput() does not mutate now and is cheaper too.
Merging was not tested as direct-runner does not seem to use combiner. Added test to merge and extract as happens in a window with multiple firings.

+R: @kennknowles, @reuvenlax

Quick comment: can you use CombineFnTester?

can you use CombineFnTester?
That is great. Updated the test.

I reverted my 'improvement' to add(), it was buggy. It is fine as it is.

Can we check to see if Python has a similar bug?
On Wed, Feb 14, 2018 at 2:16 PM, Raghu Angadi<EMAIL_ADDRESS>wrote:

can you use CombineFnTester?
That is great. Updated the test.
I reverted my 'improvement' to add(), it was buggy. It is fine as it is.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/beam/pull/4688#issuecomment-365763150, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AUGE1coJXh4jiLM5NLY2uNHPq75kn8ttks5tU1s8gaJpZM4SF3Ai
.

I don't see a any Approx.* combiners in python. Python Beam can simply use existing reducers like 'sum'.

R: @jkff

Squashed commits.

Review status: 0 of 3 files reviewed at latest revision, 6 unresolved discussions, some commit checks failed.

sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/ApproximateUnique.java, line 342 at r1 (raw file):
Previously, jkff (Eugene Kirpichov) wrote…
That seems quite bad - O(n) for every add(). Is this check actually needed?

Yes. The algorithm requires keeping track of top-k unique hashes. There is no option to insert() in PriorityQueue. That's why reordering the conditions is important (more efficient with as number of elements increases). If we need to increase performance here, I would consider using datastruct using primitive longs from fastutil.. may be a sorted set. For now its ok.. I haven't looked into why we have both ApproximateDistinct (using HLL+) and this.

Comments from Reviewable

Can we just use a TreeSet instead of the PriorityQueue? It seems strictly better, and very easy to switch to.

Updated to use TreeSet. We maintain minHash so that there is no log(n) look up in fast path (i.e. when number elements > sampleSize, which is more likely to happen during merges). We can't be very certain this is better in practice, might need a micro benchmark. PriorityQueue uses an array. Since we always remove min, it could cause more rebalancing than a typical tree set. Either way, it can't be much worse. This is fine. We could use primitive long based tree if we are really concerned about the performance.

Review status: 0 of 3 files reviewed at latest revision, 6 unresolved discussions, some commit checks failed.

Comments from Reviewable

I don't see new changes; forgot to push?

Oops. Just pushed my changes.

LGTM, please ping me when tests are green and I'll merge.

Seems CombineFnTesterTest is failing now.

I was just pushing a fix. I updated the failing test to keep track of number of merges in the accumulator itself rather than expecting extractOutput() to be called exactly once per test.

@jkff Thanks for the review. Looks like the tests have passed.


Make MatSelectionList configurable for Multiselect = ON/OFF

Feature Description
Would be great if we can set on MatSelectionList the multiselect status like :
<mat-selection-list #myList [multiselect]="true">
Use Case
If we wan to to create a list that only allow a single selected item.

Closing as a duplicate of https://github.com/angular/components/issues/16097.


fix: bump decode to package

fix #92
Added the package to decode the paid bolt11 invoices.
Also added a fix to the previous paid invoices bug on android.
Attaching the screenshot for the same.

I think there are still some things which are needed to be taken care of. Like the prefix returns an enum. I will commit the changes in this branch only.

Done!

Sure


Cmake for Linux

Hi,
Thanks for the great example.
I am breaking my head to make this work on Linux. No matter what i do, I get:
Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)
This is the make file:
``
cmake_minimum_required(VERSION 3.6)
find_package(PkgConfig REQUIRED)
set(CMAKE_BUILD_TYPE Release)
#set(CMAKE_BUILD_TYPE "Debug")
set(CXX_RELEASE_FLAGS = -O3 -march=native)
#set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}  -std=c++11 -lGL -lGLU -lglfw3 -lX11 -lXxf86vm -lXrandr -lpthread -lXi")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}  -std=c++11")
#-std=c++0x
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_VERBOSE_MAKEFILE 1)
set(APP_VERSION_MAJOR 1)
set(APP_VERSION_MINOR 0)
#project(imgui-deepsleep)
#SET( PROJ_NAME      imgui-deepsleep )
set(PROJ_NAME DeepSleepGUI) # the name of the executable
message(STATUS "PROJECT_SOURCE_DIR: ${PROJECT_SOURCE_DIR}")
message(STATUS "PROJ_NAME: ${PROJ_NAME}")
message(STATUS "CMAKE_CXX_FLAGS: ${CMAKE_CXX_FLAGS}")
message(STATUS "CXX_RELEASE_FLAGS: ${CXX_RELEASE_FLAGS}")
set(CMAKE_BUILD_TYPE Release)
message(STATUS "CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE}")
message("system: ${CMAKE_SYSTEM_PREFIX_PATH}")
Imgui itself
add_subdirectory(imgui)
include_directories(${PROJECT_SOURCE_DIR})
#target_link_libraries(${PROJ_NAME} imgui)
find Eigen3
find_package (Eigen3 REQUIRED)
include_directories (${EIGEN3_INCLUDE_DIRS})
glfw
find_package(glfw3 REQUIRED)
include_directories(${GLFW_INCLUDE_DIRS})
link_libraries(${GLFW_LIBRARY_DIRS})
find_package(GLEW QUIET CONFIG)
opengl
find_package(OpenGL REQUIRED)
include_directories(${OPENGL_INCLUDE_DIRS})
glew
find_package(GLEW REQUIRED)
include_directories(${GLEW_INCLUDE_DIRS})
add and depend on OpenGL
find_package(OpenGL REQUIRED)
set(EXTERNAL_INCLUDE_DIRS ${EXTERNAL_INCLUDE_DIRS} ${OPENGL_INCLUDE_DIR})
set(EXTERNAL_LIBRARIES ${EXTERNAL_LIBRARIES} ${OPENGL_LIBRARIES})
find_path(GLEW_INCLUDE_DIR GL/glew.h)
find_library(GLEW_LIBRARY NAMES GLEW glew32 glew glew32s PATH_SUFFIXES lib64)
find_package(GLEW REQUIRED)
if (GLEW_FOUND)
include_directories(${GLEW_INCLUDE_DIRS})
link_libraries(${GLEW_LIBRARIES})
endif()
#Boost
message("system: ${CMAKE_SYSTEM_PREFIX_PATH}")
find_package(Boost COMPONENTS system filesystem REQUIRED)
include_directories(${Boost_INCLUDE_DIRS})
message(STATUS "Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")
message(STATUS "Boost_VERSION: ${Boost_VERSION}")
if (APPLE)
# use OpenMP
include(FindOpenMP)
if(OPENMP_FOUND)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${OpenMP_EXE_LINKER_FLAGS}")
else()
message(SEND_ERROR "OpenMP not found.")
endif()
find_library(COCOA_LIBRARY Cocoa)
find_library(OpenGL_LIBRARY OpenGL)
find_library(IOKIT_LIBRARY IOKit)
find_library(COREVIDEO_LIBRARY CoreVideo)
SET(EXTRA_LIBS ${COCOA_LIBRARY} ${OpenGL_LIBRARY} ${IOKIT_LIBRARY} ${COREVIDEO_LIBRARY})
endif (APPLE)
set(PROJ_NAME DeepSleepGUI) # the name of the executable
SET( PROJ_SOURCES_DIR   src)
SET( PROJ_SOURCES   ${PROJ_SOURCES_DIR}/deepsleep/main.cpp)
SET( PROJ_INCLUDES  include)
message(STATUS "PROJ_INCLUDES: ${PROJ_INCLUDES}")
SET( PROJ_HEADERS "")
SET(PROJECT_INCLUDE_DIR ${PROJ_INCLUDES})
SET(PROJECT_SOURCE_DIR ${PROJ_SOURCES})
include_directories("${PROJECT_INCLUDE_DIR}")
add_executable(${PROJ_NAME}  ${PROJ_SOURCES} ${PROJ_HEADERS} ${PROJECT_INCLUDE_DIR})
#find_package(glm REQUIRED)
target_link_libraries(
${PROJ_NAME}
imgui
glfw
${GLFW_LIBRARIES}
${GLEW_LIBRARIES}
${EXTRA_LIBS}
${Boost_LIBRARIES}
${OPENGL_LIBRARIES}
)
``
Any help would be appreciated,

https://github.com/ocornut/imgui/issues/1092

Hello,
I got it building and working on Linux, using OpenGL 3.2 and 3.3 (no 4.x yet, sorry), cmake 3.5.1 + libGLEW + libGL + lbglfw3.
The attached patch (under MIT license) contains everything (including building instructions on Debian like distribution), and should not break the Mac OS X build imho.
full_diff.diff.txt

🙄

Is there something wrong ?

I just "looking" 😊


LMP/LGP to support NL messages

When I ran dev mode with pt_BT, I found OL messages were translated but not the messages from LMP:
[INFO] CWWKM2015I: Número de correspondência: 1 é [15/06/20 12:42:40:685 EDT] 00000021 com.ibm.ws.kernel.feature.internal.FeatureManager            A CWWKF0011I: O servidor defaultServer está pronto para gerenciar um planeta mais inteligente. O servidor defaultServer foi iniciado em 12,094 segundos..
[INFO] Press the Enter key to run tests on demand. To stop the server and quit dev mode, use Ctrl-C or type 'q' and press the Enter key.
[INFO] Source compilation was successful.
[INFO] Tests compilation was successful.
[INFO] [AUDIT   ] CWWKT0017I: Aplicativo da Web removido (default_host): http://host.docker.internal:9080/

Quarkus does not translate messages

Unless directed by an OM or lead architect to do this for all of our plugins, I do not plan on implementing this.

@yeekangc Can we close this? I do not know of any requirement to provide this for our build plugins.

Yes, let us close until we have additional requests/requirements to provide translation.


Multiverse Nether Portals Doesn't Load

BUKKIT VERSION: 1.1-R3
MV VERSIONS: 2.3 AB for both MV-Core and MV-NetherPortals.
SERVER LOG: http://pastebin.ubuntu.com/832604/
Notice that the MV-Nether plugin attempts to load before the MV-Core itself... MV-Core and MV-Portals are working perfectly for me, however only MV-Nether is the only MV plugin acting up.

Update your Multiverse-Core.


Updates?

Any updates from here? you should have a donation button at least or continue with the docker and let's see who will donate and then maintain this project. it has a potential for the open-source community. work with nexttracks rather than owntrack btw.

I don't accept donations because I build my projects purely for my own use, but make them public on a "source available" basis. Donations represent a monetary incentive to steer the project in a direction that I might not need for my own use.
I've archived this repository to move it into a read-only state since this repository will not receive any more updates. (I've since migrated to a new solution which is not open source.)


highlight the MIDI keys on note events

on request of @trebmuh
Transmit the note events to the graphical keyboard and display the key presses

Implemented


[Feature Request] Emby Support

Is your feature request related to a problem? Please describe.
Emby Support
Describe the solution you'd like
I am pretty sold out to Emby, and would love to see an integration! In their in-house forum, the Emby developers have offered API assistance to people building metrics apps.  Is this something you would consider?
Apologies for the “duplicate” issue - the others were archived, I think.

Please see https://github.com/Boerderij/Varken/issues/72

@samwiseg0 - That’s why I spun up another issue - to show there was more interest and a source of information being offered.

As we said in that issue. We would prefer not to poll emby directly. We would like there to be a Tautulli equivalent which currently does not exist. The primary developers on this project do not use emby nor do we have any interest in doing so.
PRs are always welcome.

@samwiseg0 - Looks like there is some work going on for something similar here.  Not sure if this would satisfy your needs or if it would be a drop-in replacement for Varken.  I’ve only just found out about that project, so I’ll dig a bit more.
Curiosity - what is your reasoning for not wanting to poll Emby and Plex directly?

It adds overhead to the server. Secondly, Tautulli keeps much more accurate stats. From my recollection emby is similar as Plex as it does not really keep all the information. Lastly, like any other product. Keeping statistics separate from a product is typically a good idea and typically “best practice”.

@samwiseg0 - That makes sense. Thank you for the information.  I’ll poke around at the other project and see if they are getting anywhere with things.  Maybe I’ll be able to lend a hand to one or both.
I do love a good metric collector. :)

@samwiseg0 - It looks like EmbyStat might be the Tautulli equivalent you've mentioned and is being actively developed.  Is this something you might consider?

We have no plans to support it as we don’t use it and have not plans currently to start using it. We are completely open to PR request and would consider merging if someone developed and integration.
Thanks!


Ripple effect will appear twice when using iPhone browser

For example, using Chrome/Safari, open the demo page of any component like "AppBar" or "Menu", click on any button or any menu item, the ripple effect will appear twice.
Tested on Chrome/Safari, IOS 9.1, iPhone 6.

Duplicate of #1563

Oops, didn't find that one when I search


PR for oAuth

I've got a PR ready to go to fix the  authorisation header for the oAuth update

@digitalgym  - I don't see any PR yet - are you sure you created on this repo?


Workspace Trust for Extension Authors

This issue will be updated as information becomes available. Please subscribe and check back.
This issue will function as the landing page for extension authors while Workspace Trust is in development. If you are an extension author, please subscribe to this issue to receive notifications when the issue is updated.
Note that the feature has been in the works for some time now and we are nearing the phase where we would like extension authors to test it out and provide feedback. Once it is ready, we will post the extension authoring guide in this issue so that you can try adopting the new API.
To learn more about the development of the feature, check out our development issue: https://github.com/microsoft/vscode/issues/106488

Workspace Trust Extension Guide
What is Workspace Trust?
Workspace Trust is a feature driven by the security risks associated with unintended code execution when a user opens a workspace in VS Code. For example, consider that a language extension, in order to provide functionality may execute code from the currently loaded workspace. In this scenario, the user should trust that the contents of the workspace are not malicious. Workspace Trust centralizes this decision within VS Code so that extension authors do not have to handle this themselves. VS Code will offer static declaration and API support to onboard extensions quickly without the need to duplicate code across extensions.
Onboarding
Static Declarations
In your extension's package.json, VS Code will support the following new property:
capabilities:
	untrustedWorkspaces:
		{ supported: true } |
		{ supported: false, description: string } |
		{ supported: 'limited', description: string, restrictedConfigurations?: string[] }

For the supported property, the following values are accepted:

true - The extension is fully supported in an untrusted workspace as it does not need workspace trust to perform any functionality. It will be enabled exactly as before.
false - The extension is not supported in an untrusted worskpace as it cannot function without workspace trust. It will remain disabled until workspace trust is granted.
'limited' - Some features of the extension are supported in an untrusted workspace. Trust-sensitive features should be disabled until workspace trust is granted. The extension can use our API to hide or disable these features. Workspace settings can be gated by trust automatically using the restrictedConfigurations property.

For the description property, a description of why trust is needed must be provided to help the user understand what features will be disabled or what they should review before granting or denying workspace trust. If supported is set to true, this property is ignored.
💡The value for the description property should be added to package.nls.json and then referenced in the package.json file for localisation support.
For the restrictedConfigurations property, an array of configuration settings IDs are provided. When provided, the extension will not be given workspace-defined values for the given settings in an untrusted workspace.
How do I decide how my extension should support untrusted workspaces?
To help extension authors understand what is in scope for Workspace Trust, we have created a list of questions to consider.
Does my extension have a main entry point?
If the extension does not have a main entry point (ex: themes, language grammars), the extensions does not require workspace trust. Extension authors do not need to take any action for such extensions as they will continue to function independent whether the workspace is trusted or not.
Does my extension rely on files in the opened workspace to provide features?
This can mean things like settings that can be set by the workspace or actual code in the workspace. If the extension never uses any of the contents of the workspace, it probably doesn't require trust. Otherwise, take a look at the other questions.
Does my extension treat any contents of the workspace as code?
The most common example of this is using a project's workspace dependencies, such as the node modules stored in the local workspace. A malicious workspace might check in a compromised version of the module. Thus, this is a security risk for the user and extension. Auxiliary to this, an extension may rely on JavaScript or other configuration files that control the extension or other modules' behavior. However, many other examples could occur, such as executing an opened code file to determine its output a error reporting.
Does my extension use settings that can be defined in the workspace in any code execution?
Your extension might use settings values as flags to a CLI that your extension executes. If these settings are overridden by a malicious workspace, they could be used as an attack vector against your extension. On the other hand, if the settings' values are only used to detect certain conditions, (e.g. if the value of a preferred shell setting is bash or pwsh determines what documentation you show), then it may not be a security risk and does not require Workspace Trust. Below is a section dedicated to guidance on settings to help you find the optimal configuration for your extension.
This is not an exhaustive list of cases that might require Workspace Trust. As we review more extensions, we will update this list. Use this list to think of similar behavior your extension might be doing when considering Workspace Trust.
What if I don't make changes to my extension?
As mentioned above, an extension that does not contribute anything to their package.json will be treated as not supporting untrusted workspaces. It will be disabled when the workspace is not trusted and the user will be notified that some extensions are not working due to Workspace Trust. This measure is the most security-conscious approach for the user. Even though this is the default, it is still a best practice to set the appropriate value indicating that as an extension author, you have made the effort to protect the user and your extension from malicious workspace content.
How do I use the API?
As described above, the first step to using the API is adding the static declarations to your package.json. The easiest method of onboarding would be to use a false value for the supported property. Once again, this is the default behavior even if you do nothing, but it's a great signal to the user that you have made a deliberate choice. In this case, your extension does not need to do anything else. It will simply not be activated until trust is given and your extension can know that it is executing with the consent of the user. However, if your extension only requires trust for part of its functionality, this is likely not the best option.
For extensions that wish to gate their features on Workspace Trust, they should use the limited value for the supported property, and we provide the following API:
export namespace workspace {
	/**
		* When true, the user has explicitly trusted the contents of the workspace.
		*/
	export const isTrusted: boolean;

	/**
		* Event that fires when the current workspace has been trusted.
		*/
	export const onDidGrantWorkspaceTrust: Event<void>;
}

We provide a property to determine if the current workspace is trusted and  an event for listening to when trust has been granted to the workspace. You can use these block specific code paths and perform any necessary registrations once the workspace has been trusted.
We also expose a context key isWorkspaceTrusted for use in when clauses as described below.
What about my contributions?
Commands, Views, or other UI
When the user has not trusted the workspace, they will operating in a mode with functionality geared towards browsing code. Any features that you provide that will not be trusted should be hidden from the user. This can be done via when clauses and the context key isWorkspaceTrusted. Since code can still call a command even if it is not presented in the UI, you should still block execution or not register a command based on the API above in your extension code.
Configurations/Settings
First, you should review your settings to determine if they need to take trust into account. As described above, a workspace may define a value for a setting that your extension consumes that is malicious to the use. If you identify settings that are vulnerable, you should use 'limited' for the supported property and list the setting ID in the restrictedConfigurations array.
When you add a setting ID to the restrictedConfigurations array, VS Code will only return the user-defined value of the setting in an untrusted workspace. This means your extension needs no additional code changes to handle the setting. When trust is granted, a configuration change event will fire in addition to the workspace trust event.
What is the guidance for debug extensions?
VS Code will prevent debugging in an untrusted workspace. For this reason, generally, debugging extensions do not need to additionally require trust and should select true for the supported property. However, if your extension provides additional functionality, commands, or settings that are not part of the built-in debugging flow, you should use 'limited' and the above guidance.
What is the guidance for task providers?
Similar to debugging, VS Code will prevent running tasks in an untrusted workspace. If your extension provides additional functionality, commands, or settings that are not part of the built-in tasks flow, you should use 'limited' and the above guidance. Otherwise, you can specify true.
How do I test Workspace Trust?
Please see this issue for current details on development of Workspace Trust. It should be up to date with how the feature is currently enabled.

For those subscribed, we are now ready to share the API and guidance for onboarding to workspace trust for extension authors. This is the first time sharing the guidance to a broader audience so please post questions here and we can update it for clarity. Thanks for your engagement.

Is Workspace Trust going to land in the upcoming release?

The setting to enable the feature will remain disabled by default in the upcoming release

@sbatten thank you for providing guidance on how trusted workspaces would work.
I am concerned about your default behaviour and my expectations would be that extensions that provide web views, side bar views, pseudo terminals and commands you can run in terminal, and work with workspace files, would still function as before when this feature is released.
I would rather see this feature as opt-in for extensions that want to be enabled for trusted workspaces, and work as before for untrusted workspaces. I think the behavior you describe is the opposite.

What if I don't make changes to my extension?
As mentioned above, an extension that does not contribute anything to their package.json will be treated as not supporting untrusted workspaces. It will be disabled when the workspace is not trusted and the user will be notified that some extensions are not working due to Workspace Trust. This measure is the most security-conscious approach for the user. Even though this is the default, it is still a best practice to set the appropriate value indicating that as an extension author, you have made the effort to protect the user and your extension from malicious workspace content.

@sbatten Is there a way to prompt the user, "To enable this feature, you must trust the workspace"? For extensions that provide actions a user can execute, simply hiding (and disabling) that functionality may be bad UX. For example, the ESLint extension - at the moment - will prompt the user to execute ./node_modules/.bin/eslint if it is present, saying something like "Do you trust this?" How should that be updated for Workspace Trust? As I read your explanation, the extension should silently disable that functionality for untrusted workspaces. As a user, I would prefer a prompt - "The extension eslint wants to do <some thing> that requires you to trust this workspace - continue?"
As another example, I have an extension that provides code lenses for profiling benchmarks (CPU/memory use). If I hide these code lenses in untrusted workspaces, I'm sure someone will report that as a bug ("the benchmark code lens doesn't show up for my workspace"). I'd like the API to include something like this:
export namespace workspace {
    export function shouldExecuteActionRequiringTrust(description: string, alertOnFailure: bool, details?: string): Promise<bool>
}

If the workspace is not yet trusted and has not yet been prompted, this would show a prompt asking if the user wants to trust the workspace. If the workspace is untrusted and alertOnFailure is true, this would show a notification that, " cannot execute  because the workspace is not trusted".

@RandomFractals @firelizzard18 Thanks for your engagement.
@RandomFractals you are correct in your understanding of the behavior. It is indeed opt-out, not opt-in. As this is a security feature, we must make the security-conscious decision to disable extensions that execute code and do not tell us about their trust support. We provide a user setting to override whether an extension supports untrusted workspaces locally to unblock users that have extensions that are slow to adopt. This puts the control in the hands of the user and is safe by default.
@firelizzard18 We hear this feedback. It is something we considered when coming up with the current strategy and we will keep our ears to ground on its necessity. With our current UX, we attempt to guide the user into one of two modes of operation, and they must make an explicit choice. In this way, we market the restricted mode for code browsing and navigation, but not active development since active development typically requires execution and thus trust.
We anticipate that a majority of users workflows are with trusted folders and thus should not choose restricted mode to do active development.
For this reason, the guidance is:

If you cannot provide a coherent browsing experience in an untrusted workspace, simply set your support value to false and rely on Code to indicate that features are disabled due to this choice.
If you can provide a solid experience for the restricted mode scenario, do so with limited or true.

@sbatten thanks for your follow up. Sounds like the default behavior has already been decided on. I get why you'd want to configure extension activation and execution this way from security standpoint for trusted workspaces.
What concerns me most about this approach is that it will create a potential stream of updates and some rework for extension developers similar to how we had to scramble and handle webview resources last year. I can also see a lot of users filing issues in extensions related to this new feature if configuration of this functionality is not well exposed in vscode UI for extensions and documented when you release it.

we must make the security-conscious decision to disable extensions that execute code and do not tell us about their trust support. We provide a user setting to override whether an extension supports untrusted workspaces locally to unblock users that have extensions that are slow to adopt. This puts the control in the hands of the user and is safe by default.

The part sounds like it might be ok, if you also provides proper prompts and notifications when switching between trusted and untrested workspaces.
I am not sure if @eamodio still does his monthly extension developers calls, but I think it would be great if we could do one for this functionality and hows us the whole flow of how it functions, and we hear other extension developers provide feedback that way before you realease this feature. There are only a few devs who expressed interest in learning more about this feature. So, should be manageable to get a few devs on a call for ext. devs review.

Hello, thanks for providing this information and way to follow as we prepare for the roll-out.
Can you paste some screenshots showing the user facing part of it? It would help me understand what choices I make as an extension developer.

How do trusted workspaces impact language servers that are not implemented directly as vscode extensions? Will their clients require configuration to receive file change updates over LSP in untrusted workspaces?

@rebornix how do new notebooks, custom kernels, code cells, and custom notebook renderers function in these new utrunsted workspaces??? They do execute cod from cells :)

@m-hilgendorf I think the security mechanism here is if your extension doesn't load then VS Code won't even have an opportunity to launch your language server or run any code of yours to connect to an externally started language server.
@RandomFractals the extensions providing notebook support will very likely simply not load in an untrusted workspace, so there won't be anything available to execute the cells.

@RandomFractals you can check out notebooks and workspace trust updates here https://github.com/microsoft/vscode/issues/118584
@PEZ Since we are still polishing the UX pieces, I recommend you checkout the latest in VS Code Insiders by enabling the feature with security.workspace.trust.enabled in settings. To help you know where to look, you can expect a few components:

A dialog on startup when opening a new untrusted folder
An indicator in the status bar of the restricted mode (we are exploring more obvious UX currently)
A workspace trust settings editor with lots of context, accessible via the Gear icon or clicking the status bar entry

@m-hilgendorf Without any onboarding, these extensions won't activate and thus don't have any vulnerabilities. @TylerLeonhardt has locally onboarded the powershell extension to demo how extensions using LSP could onboard. I think he can provide more details.

super! will try that setting in insiders and run a test Rest Book to see where we at. Thanks for the pointer to the untrusted notebooks and workspaces thread.

@sbatten am I doing this right? seems to have no effect.

@RandomFractals That setting should be set to true in order to enable workspace trust (it turns on the feature but does not mean anything is trusted). It should require a restart to apply.

tried it. do I need to actually check out and build the latest insiders v.? I set it to true, and still seeing that setting greyed out in settings.json, i.e. my insiders v. doesn't recognize it as a valid setting, and not prompts on reload.
my insiders v. info:

@RandomFractals, it needs to be configured in User settings.

@sbatten In testing this out a bit I notice that so far the use case in my extension that I fear would be messed up by Trusted Workspaces actually is not impacted at all.
My extension (Calva) has a command that allows the user to test Clojure out easily. It does this by creating a directory in the system Temp directory, adds a few files there, and then starts a Clojure REPL from the directory.
I am of course happy this still works without the Trust prompt, but also wondering if I rather have found a glitch in the Trusted Workspaces feature or if it is something I can assume will keep working.

@PEZ from my understanding, trusted workspaces isn't blocking what your code can do, it's blocking whether your code runs to begin with. IOW VS Code is not reaching into your Node code and blocking access to files or subprocess execution, it's providing a mechanism for extension authors to tell users, "hey, you can't use this extension with code you don't fully trust as it might do something bad".
So your extension launching without issue is (I believe) expected if you have flagged it as usable in an untrusted workspace.

@brettcannon , that's how I understand it also.
I tested this with Calva flagged as not usable with untrusted workspaces. Opening a folder or workspace things behave as I expect, VS Code asks if I trust the workspace and if I answer yes, Calva is enabled, if I answer no, it is disabled.
From the enabled state there is this command that makes Calva crate directory somewhere on the computer, place some files there and open them. Regardless if there was a folder or workspace opened before or not. I was worried there would be a prompt then if I trusted this temp folder, but there isn't.

@PEZ based on your description, the temp folder is under the control of the extension, it is not a product of the workspace and thus does not require workspace trust.

@sbatten that is awesome. Thanks for helping me understand this distinction.

capabilities.untrustedWorkspaces.supported signals whether your extension performs potentially unsafe operations. The only thing VSCode does1 is load or not load your extension. Depending the value that My Extension gives:

true - indicates that My Extension does not perform unsafe operations - VSCode always runs My Extension
false - indicates that My Extension does perform unsafe operations - VSCode only runs My Extension in trusted workspaces
"limited" - indicates that My Extension may perform unsafe operations - VSCode always runs My Extension

If My Extension's support for untrusted workspaces is "limited", it is the responsibility of the extension author to disable unsafe operations if the workspace is untrusted (vscode.workspace.isTrusted). 1Additionally, in this scenario My Extension can indicate that certain configuration values are restricted - when restrictedConfigurations is provided, "the extension will not be given workspace-defined values for the given settings in an untrusted workspace."

Maybe I'm missing/mixing something, but it seems the debugging process of an extension, while opening trusted/untrusted workspaces as the Extension Development Host, does not respect if the extension supports untrusted workspace or not, at least in some scenarios.
My extension does not have the untrustedWorkspaces capability entry yet, then I do a simple debug:

Start debugging
Open some random folder as Extension Development Host
Choose Untrusted
The extension is active, which is weird because I didn't added support yet

Then, I close the Extension Development Host, add the untrustedWorkspaces capability entry and rebuild the extension. But now...

Start debugging
Open some random folder as Extension Development Host
Choose Untrusted
The extension is active, which is correct
Then I open another random folder, using File / Open command
And now I choose Trusted to this folder
The extension is not active 😕

But, if I close the Extension Development Host window and restart the debugging process, the extension now properly activates. In fact, all installed extensions does activate.
I don't thing the error is just the debugging itself, but the trust engine seems to be failing when you switch/activates new folders while debugging. I have noticed a similar extension activation issue while playing with trusting/untrusting workspaces. It seems the extensions are not properly activated/deactivated when you do this.
Is it an issue with the debugging process? I mean, is it expected that I could play with untrusted workspaces while debugging, or is not a supported scenario yet, and I must package my extension and install the .vsix file, to test the extension?
Thank you

@alefragnani, I have filed https://github.com/microsoft/vscode/issues/124182 to further investigate the issue that you have reported.

Maybe you could see this as a matter or personal taste, but how do you (VS Code team and extension devevelopers) think an extension should describe on its README, when it requires Workspace Trust, or have limitations on Untrusted Workspaces.
I mean, there is no official keyword to be used on Marketplace (which could be used on search), no badge, no shield in Marketplace (like the one you see today in Extension's View). So I wonder the better way to tell the users the extension is not fully supported.
By now, I have a few extensions which will have limitations on Untrusted Workspaces, both settings and commands, and I'm thinking to add a small Requires Trusted Workspace tag/label near each setting/command, but I'm not convinced its a good/efficient approach.
Do you (VS Code team) have plans to change the Extension's View to warn the user about the Settings and Commands which may be disabled/limited? I mean, the settings are listed in restrictedConfiguration and the commands will/can have the isWorkspaceTrusted in its when clause.
Thank you

Hi, I'm the author of the extensions Projects and Diff Folders, that can access workspaces which are not part of the current workspace. I have the issue, that if the extensions are scanning folders and reading/writing files, I do not know if the other workspaces are trusted or not, because they are not part of the current workspace. In this case the extension info isTrusted is not really helpful. With the extension Diff Folders you can copy files and folders across workspaces, even if they are not the current workspace, which can undermined the concept, because you can copy files from an untrusted workspace into a trusted workspace. Is it possible to extend the API for trusted workspaces with the following feature?
export namespace workspace {

    export function isTrustedWorkspace (uri:vscode.Uri, showTrustedWorkspaceDialog?:boolean) :Promise<boolean>;

}

So I can ask/inform the user, that the workspace is not trusted yet and disable/enabled features depending on the result.

@L13 out of curiosity - what type of attack vectors do you want to prevent by using the trust workspace API? Do the extensions copy arbitrary files and folders from external workspace into the trusted current workspace without explicit user action? Or does the extension use configuration or library/executable loaded from those folders?

Hi, @sbatten and @lszomoru , I am from Live Share extension team. We have been testing workspace trust with Live Share. Since we evaluate the flow from both Host (workspace owner) and from the guest perspective, we found out that guest workspaces being always untrusted, which makes  Live Share Guest debugging flow confusing. We are wondering if you can provide us an option to make  guest workspace trust level to always match the host? Because,  Joining a debug session on the guest side actually does not put the guest at risk at all, since the process being debugged is on the host side.

@hyangah The extension Projects scans folders and reads on every startup of VS Code the file .vscode/settings.json in every saved workspace if available. It also writes/changes the file .vscode/settings.json in a workspace even if it is not the current workspace. So you can manage all your workspaces within one place without the need to open it. This works also if the user has never opened a workspace yet. With this API I can ask/inform the user that he has to agree if the extension should do this in a workspace. Another feature would be to provide the info in the list which workspaces are trusted or not.
The extension Diff Folders reads the file .vscode/settings.json in a workspace if available to get the value of the property l13Diff.exclude. This was a feature request by another user. You can define for each workspace with a glob pattern which files should be ignored for a comparison even if it is not the current workspace. This values will be used for the comparison and will be converted into a regular expression.
It is also possible to copy files across workspaces with this extension even if they are not part of the current workspace. So you can copy files from an untrusted workspace to a trusted one. Then you have the untrusted files in the trusted workspace. This undermined the concept in my opinion. With this API the extension can inform the user that he is copying files from an untrusted workspace to a trusted one.

@L13 , I have asked a similar API ( tracked in #123495), but after a few discussions the VS Code team decided to abandon the idea, for now.
Add your comment/upvote, so the team could reevaluate and maybe reopen the issue in upcoming releases.

@setaskin I created https://github.com/microsoft/vscode/issues/124971 to look at the Live Share 'Join as Guest' flow.

@sbatten Using 'limited', I've noticed that VS Code will restart the extension when a folder is removed from the trusted list.  It would be nice to be able to handle un-trusting without having to be restarted.  Also, restarting the extension might be a desirable way to deal with becoming trusted as well.  Would it be possible to support both an event or restart, for both?  i.e.
capabilities:
	untrustedWorkspaces:
		{ supported: true } |
		{ supported: false, description: string } |
		{ supported: 'limited', description: string, restrictedConfigurations?: string[], restartOnTrusted?: boolean, restartOnUntrusted?: boolean }

I figure restartOnTrusted would default to false, and restartOnUntrusted would default to true.
export namespace workspace {
	/**
		* When true, the user has explicitly trusted the contents of the workspace.
		*/
	export const isTrusted: boolean;

	/**
		* Event that fires when the current workspace has been trusted.
		*/
	export const onDidGrantWorkspaceTrust: Event<void>;

	/**
		* Event that fires when the current workspace has been un-trusted.
		*/
	export const onDidRevokeWorkspaceTrust: Event<void>;
}

Or, if letting extensions handle un-trusting is somehow a risk, perhaps just add an option for restart when trusted?  :)

@Colengms, thank you very much for your feedback. Currently all extensions are running in a single extension host independent of their support for untrusted workspaces. When a workspace transitions from trusted -> untrusted, we do not have the capability to individually unload extensions that do not support untrusted workspaces hence we have to restart the extension host in order to safely unload all extensions, and then only load the ones that support untrusted workspaces..

Is my understanding correct that "capabilities" is a completely new field in package.json? So the "capabilities" field goes into package.json alongside "name", "version", "dependencies", etc?

I maintain a VS Code extension which has a setting which is currently marked with "scope": "application", meaning it can't be overwritten at the workspace level. Is there a way to lift this restriction for people who use newer versions of VS Code which mark the workspace as trusted while maintaining backwards-compatibility for older versions of VS Code in the sense of "keep "scope": "application""? I want to avoid bumping the minimum required VS Code version for the extension.

I do not think there is a way other than bumping vscode engine version.

@sbatten What is the motivation behind asking debug extensions to mark themselves as safe for untrusted workspaces?
Debugging untrusted code is among the least safe things one could do.  Wouldn't it make more sense to mark debug extensions as not supported for untrusted workspaces, just to be double-sure?

@sbatten What is the motivation behind asking debug extensions to mark themselves as safe for untrusted workspaces?
Debugging untrusted code is among the least safe things one could do. Wouldn't it make more sense to mark debug extensions as not supported for untrusted workspaces, just to be double-sure?

@vadimcn I think that's covered already. From the description in this comment:

What is the guidance for debug extensions?
VS Code will prevent debugging in an untrusted workspace. For this reason, generally, debugging extensions do not need to additionally require trust and should select true for the supported property. However, if your extension provides additional functionality, commands, or settings that are not part of the built-in debugging flow, you should use 'limited' and the above guidance.

So I don't think debug extensions will be able to debug in an untrusted workspace, no matter what they mark themselves for.

Yes, I've seen that comment.   I still don't understand the motivation for asking debug extensions to set "supported": true.   Is there any behavioral difference between this and "supported": false?

That makes sense. I think it will have to be up to extension authors to determine based on the guidance above. If the only thing an extension provides is debugging, I think that is functionally equivalent to "supported": false, but there could be other features that are safe in an untrusted workspace (or features that aren't, and "supported": "limited" is appropriate).


Added file upload support for Android

Added file upload support, everything's based on this library:
https://github.com/Oblongmana/react-native-webview-file-upload-android
I've also upgraded the SDK version for the build.

I need this, When it will be merged?


Link offsetra profile page to carbonless page

we've got write up on offsetra page finally https://offsetra.com/profile/kodadot

done in #396


Add February RoA rotational ladders

http://www.smogon.com/forums/threads/roa-communitys-choice-ladder-february-2018-dpp-lc.3625534/page-3#post-7669527

Uh, why did you do this? I was specifically tagged and it's been done since I liked the post you linked, I just didn't push it then for obvious reasons.

It may be better to set up a Do Not Merge pullreq so other people know not to repeat work.

I didnt see the tag no need to be aggressive


chore: pydantic>=1.9.0, <2.0

Related issue
# followed by the number of the issue
Summary
Recent release of pydantic v2.0 and related changelog is causing multiple CI failures. Before properly adapting the code to support latest release, we are restricting the usage of pydantic in v2.0
Notes
Please check if the PR fulfills these requirements

[x] If the feature has an impact on the user experience, the changelog has been updated
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)
[x] The commit message follows the conventional commit specification

/e2e --tests substrafl

End to end tests: :hourglass_flowing_sand: STARTING


[BugFix] fix block cache input stream read return value

Fixes #issue
For stream read, it depends on read return value that how many bytes are actually read.
For example in csv scanner, if read does not return correct value, the program will get undefined behaviour.
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[x] Yes, this PR will result in a change in behavior.
[ ] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

[FE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 1 / 1 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/io/cache_input_stream.cpp
1
1
100.00%
[]

[FE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 1 / 1 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/io/cache_input_stream.cpp
1
1
100.00%
[]

@Mergifyio backport branch-3.2

@Mergifyio backport branch-3.1

@Mergifyio backport branch-3.0

@Mergifyio backport branch-2.5


property-manager update not recognized as a command option

When we try to update the property-manager package/module the base CLI package fails to identify property-manager as a command/module. However pipeline is recognized for the update option.

Wrong issue. This was because of a custom code/fork.


Cherry-picks #59 to 1.0

Signed-off-by: Vijayan Balasubramanian<EMAIL_ADDRESS>Description
Cherry-picks #59 to 1.0
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.

[ ] All tests pass

[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[X] Commits are signed as per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #60 (abda52e) into 1.0 (0cba53d) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##                1.0      #60   +/-   ##
=========================================
  Coverage     82.48%   82.48%
+ Complexity      475      474    -1
=========================================
  Files            69       69
  Lines          1821     1821
  Branches        178      178
=========================================
  Hits           1502     1502
  Misses          257      257
  Partials         62       62

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0cba53d...abda52e. Read the comment docs.