[Feature Request] Remove escape characters in JSON

Something I have to do quite a bit in my day-to-day is taking JSON payloads, removing the escape characters, and formatting them to be more readable. I generally have to visit a couple different web pages to accomplish this. It would be super helpful if it were build into DevToys.

Hi,
DevToysMac is now archived and deprecated. We just released DevToys 2.0 for Windows, Mac and Linux. This issue may or may have not been addressed in the new version. If the issue persist, we encourage to open a new issue on https://github.com/DevToys-app/DevToys or https://github.com/DevToys-app/DevToys.Tools
See more information about DevToys 2.0 here: https://devtoys.app/blog/announcing-devtoys-2.0-preview


Add notice that LFS mirroring is not supported

As discussed in #849:
Mirroring LFS objects is no easy feat, so this PR adds a notice to the migration UI which tells the user that Gitea does not support it currently, hinting at git lfs functionality.

LGTM

Dropped German translation as requested

LGTM


Footsteps in the Dark in Portuguese

Creating this issue to help BGG User GwanGwanish to publish the Localization file for Footsteps in the Dark.
File to be added:
Localization.Portuguese.txt
Simplified steps:

Coopy the file above to %appdata%Valkyrie\MoM\Editor<ScenarioName>
Edit quest.ini file and include "Localization.Portuguese.txt" below [QuestText]
Open Valkyrie > Scenario Editor > Your Scenario. Click Tools and Create Package. The new package will now contain the additional language.
Copy these files to your online repository (copy to local repository and commit changes if you are using GitHub).

Longer explanation available here: https://docs.google.com/document/d/1Gi5gTwKkw84Px0Lvk-bJ3Aml_vF3ZoljjB6a8FjWGt8/edit#heading=h.ka65mn7ohsbw

@GwanGwanish a translation for your scenario here :)

Taking a stab at this today.

I think I did that right. Will test it once it the updated scenario posts to Valkyrie. Thanks @Revokee Revokee!

Hi @GwanGwanish
I've just checked your update and noticed you added the translation to the repo, rather than to your scenario and repackaging.

You will need to drop the translated localisation file in %appdata%\valkyrie\MoM\Editor(your scenario)\
Then edit the quest.ini and add the filename (Localisation.Portuguese.txt) - this will be just under where is says Localisation.English.txt.
Once done open Valkyrie, then your scenario in the editor. From the tools menu 'Create a package' then upload that to your GitHub repository overwriting the old scenario.
Page 235 - Adding a translation file, should help explain the process:
https://docs.google.com/document/d/1Gi5gTwKkw84Px0Lvk-bJ3Aml_vF3ZoljjB6a8FjWGt8/edit?usp=drivesdk

K. Think I got it this time!
On Mon, Jun 1, 2020 at 3:10 PM scrubbless<EMAIL_ADDRESS>wrote:

Hi @GwanGwanish https://github.com/GwanGwanish
I've just checked your update and noticed you added the translation to the
repo, rather than to your scenario and repackaging.
[image: Screenshot_20200601-195936_Chrome]
https://user-images.githubusercontent.com/32058089/83443993-98687200-a442-11ea-9820-189f7b1cf5c1.jpg
You will need to drop the translated localisation file in
%appdata%\valkyrie\MoM\Editor(your scenario)\
Then edit the quest.ini and add the filename (Localisation.Portuguese.txt)

this will be just under where is says Localisation.English.txt.

Once done open Valkyrie, then your scenario in the editor. From the tools
menu 'Create a package' then upload that to your GitHub repository
overwriting the old scenario.
Page 235 - Adding a translation file, should help explain the process:
https://docs.google.com/document/d/1Gi5gTwKkw84Px0Lvk-bJ3Aml_vF3ZoljjB6a8FjWGt8/edit?usp=drivesdk
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/1288#issuecomment-637049182,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBBTNCBDY6YYPWHLRARKLLRUP4JVANCNFSM4NGYVOEA
.

Hmm... I added the translation localisization file to the scenario folder,
edited the quest.ini to include it beneath the english.txt, saved in
Valkyrie, repackaged and uploaded to Github. Github reflects a new version
number, but I don't see the Portuguese flag.
I'll take another stab at it tomorrow.
On Mon, Jun 1, 2020 at 9:14 PM GwanGwanish<EMAIL_ADDRESS>wrote:

K. Think I got it this time!
On Mon, Jun 1, 2020 at 3:10 PM scrubbless<EMAIL_ADDRESS>wrote:

Hi @GwanGwanish https://github.com/GwanGwanish
I've just checked your update and noticed you added the translation to
the repo, rather than to your scenario and repackaging.
[image: Screenshot_20200601-195936_Chrome]
https://user-images.githubusercontent.com/32058089/83443993-98687200-a442-11ea-9820-189f7b1cf5c1.jpg
You will need to drop the translated localisation file in
%appdata%\valkyrie\MoM\Editor(your scenario)\
Then edit the quest.ini and add the filename
(Localisation.Portuguese.txt) - this will be just under where is says
Localisation.English.txt.
Once done open Valkyrie, then your scenario in the editor. From the tools
menu 'Create a package' then upload that to your GitHub repository
overwriting the old scenario.
Page 235 - Adding a translation file, should help explain the process:
https://docs.google.com/document/d/1Gi5gTwKkw84Px0Lvk-bJ3Aml_vF3ZoljjB6a8FjWGt8/edit?usp=drivesdk
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/1288#issuecomment-637049182,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBBTNCBDY6YYPWHLRARKLLRUP4JVANCNFSM4NGYVOEA
.

Hi GwanGwanish,
The localisation file is showing but it doesn't appear to be added to the quest.ini in your package:

I've corrected this and created the package here, if its easier:
EditorFootsteps.zip

Hmmm.. weird. I added it to the Quest ini, but maybe it was the wrong
scenario folder. Sort of had to guess, because I no longer had the original
scenario folder. Had to redownload it from Valkyrie, make a copy, edit,
save, repackage, etc.
I'll try the zip. Thanks.
On Tue, Jun 2, 2020, 5:34 AM scrubbless<EMAIL_ADDRESS>wrote:

Hi GwanGwanish,
The localisation file is showing but it doesn't appear to be added to the
quest.ini in your package:
[image: image]
https://user-images.githubusercontent.com/32058089/83503357-dacd9580-a4ba-11ea-837b-854123c24a8a.png
I've corrected this and created the package here, if its easier:
EditorFootsteps.zip
https://github.com/NPBruce/valkyrie/files/4716177/EditorFootsteps.zip
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/1288#issuecomment-637419034,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBBTNALD4GJD2PJIYS7DFLRUTBRXANCNFSM4NGYVOEA
.

@GwanGwanish I believe it worked - I can see the map in Portuguese now.
Thanks for your support!
@scrubbless I belive that we can close this issue.

Excellent. Thanks everyone! sorry for the delay. Been a little crazy here
in NY.
On Wed, Jun 3, 2020, 8:01 PM Eduardo Almeida<EMAIL_ADDRESS>wrote:

@GwanGwanish https://github.com/GwanGwanish I believe it worked - I can
see the map in Portuguese now.
Thanks for your support!
@scrubbless https://github.com/scrubbless I belive that we can close
this issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/1288#issuecomment-638522027,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKBBTNDI4VHER5377XIBLTDRU3P37ANCNFSM4NGYVOEA
.

Awesome, glad it's sorted!


Add metadata to indicate a warning should be displayed before a change is applied

A common concern with automatic config menus is that users might expect values to be applied directly after saving. This metadata should allow to automatically display warnings if a changed option is saved. In order to help users, some common cases are already defined as an enum.
Note that if no screen-only related metadata is present for a mod, it might be safer to assume that the config requires a restart to apply. I'm not sure if this should be done on quilt-configs side
Applicable to config, section, and option.
Parameters:

value: ChangeWarning enum
custom: String default empty

ChangeWarning options:

RequiresRestart requires the application to restart to apply
Unsafe stuff may/will go wrong, and it's intentional
Experimental not mature enough, may go wrong
CustomTranslatable see custom for translatable string
Custom use custom

love love love this idea

Note that if no screen-only related metadata is present for a mod, it might be safer to assume that the config requires a restart to apply. I'm not sure if this should be done on quilt-configs side

this should be done on the side of the config screen generator, and should be easy with the new API method I added for getting all metadata

love love love this idea

I also love love love this idea.


Auto-Scoped Task Execution In Monorepo Packages

Describe the feature you'd like to request
This is similar to the request in https://github.com/vercel/turborepo/issues/417.
It would be extremely helpful to be able to run turbo-repo commands within individual packages rather than solely at the root of a monorepo. Often times it can be faster and easier to run commands (test, lint, etc) within a specific package while developing, especially if that package is depended on by many other packages or apps within the project.
Describe the solution you'd like
Within a package, I can run turbo run <task>. When this happens, turbo-repo will automatically determine the correct "scope" of the task to the directory the command was executed in, run dependsOn tasks, but not execute the task for any dependencies of the package. Any outputs of this should feed back into turbo-repo's cache.
I believe this maps to:
turbo run <task> --scope="<monorepo-rel-path-to-cwd>" --no-deps --include-dependencies
Describe alternatives you've considered
Updating package.json in 50+ monorepo packages * N different tasks to perform:cd ../<monorepo-root> && yarn turbo run <task> --scope=<package-path> which is extremely time consuming and brittle.

Agree 100000000%. It's annoying. There are two parts of this: turbo run web#build should just work as you described and then also see #144.

Totally agree! Or at least have a way to run turborepo on a specific package including its dependencies, but excluding the package itself. So for example I can run turbo run build on the dependencies of a website package, but excluding the website package itself.
This would even be more versatile I suppose as it could be used with Yarn 2+. We use Yarn v3 and turbo is only installed in the root workspace, so our packages don't have access to the turbo script as it is not installed in them.

This exclusion feature is coming with --filter flag #80 #81

To workaround this problem I have created a nodejs script(turbo-w.js) that execute the given command as turbo command even when it's run from the package itself.
I would still need to go and update the package scripts itself.

You can do this by installing turbo globally now https://turbo.build/repo/docs/installing#install-globally


[boost-exception] Build error (cross-compile for Arm/Arm64 Android on Windows)

Host Environment

OS: [Windows]
Compiler: revision

To Reproduce
Steps to reproduce the behavior:
.\vcpkg.exe install boost-property-tree:arm-android
Failure logs
Building boost-exception[core]:arm-android...
warning: -- Using community triplet arm-android. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: C:\SW\vcpkg\triplets\community\arm-android.cmake
-- Using cached boostorg-exception-boost-1.79.0.tar.gz.
-- Cleaning sources at C:/SW/vcpkg/buildtrees/boost-exception/src/ost-1.79.0-1b4bdfb5ca.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source C:/SW/vcpkg/downloads/boostorg-exception-boost-1.79.0.tar.gz
-- Using source at C:/SW/vcpkg/buildtrees/boost-exception/src/ost-1.79.0-1b4bdfb5ca.clean
-- Building release...
CMake Error: File C:/SW/vcpkg/installed/arm-android/share/boost-build/Jamroot.jam does not exist.
CMake Error at installed/x64-windows/share/boost-build/boost-modular-build.cmake:118 (configure_file):
configure_file Problem configuring file
Call Stack (most recent call first):
installed/x64-windows/share/boost-build/boost-modular-build.cmake:141 (unix_build)
ports/boost-exception/portfile.cmake:12 (boost_modular_build)
scripts/ports.cmake:146 (include)
vcpkg-tool version: 2022-06-17-9268e366206712e38102b28dbd1617697a99ff2e
vcpkg-scripts version: 339a9f5e1 2022-06-29 (2 hours ago)

Please remove boost-uninstall:arm-android then try again.

We hope your question was answered to your satisfaction; if it wasn't, you can reopen with more info.


Idea: Ignore return value of producer

Currently the return value (if any) matters a lot, to be able to replace the current state. So there are quite some rules

Return undefined (or no return at all), will assume the draft is the state to be returned
Return any value (except draft or undefined), will replace the state with the returned value

This cause a few tricky cases:

Because of 1, we cannot replace the current state with undefined, by simple returning undefined. For that reason, nothing has to be returned
Because of 2, it is easy to accidentally replace the state, for example in produce({ x: 1}, draft => draft.x = 2) will produce 2 as the next state, not { x: 2 }. (Since assignment is statements return their right hand value, the result of the function is 2, not undefined. To avoid this, we have to write either draft => { draft.x = 2 } or draft => void draft.x = 2.

We could design the API differently, and always by default ignore the return value of a producer, regardless what the return value is. This fixes point 2, where we accidentally replace the state.
To be able to replace the state, we could have a dedicated internal indicating that we intend the replacement: return replace(3). This also solves 1), as undefined has no longer to be treated specially, and we can just return replace(undefined).
Note that we could even detect a replace call without return and warn the user.
Beyond that, we can possible warn about return a value, but not updating the draft (probably replace was intended)
So, in summary:
import { produce, replace } from "immer"

produce({ x: 1 }, draft => draft.x = 2)
// returns { x: 2 }

produce({x : 1}, draft => replace(2))
// returns 2

produce({x : 1}, draft => replace(undefined))
// returns undefined

produce({ x: 1 }, draft => {
   return replace(3)
})
// returns 3

produce({ x: 1 }, draft => {
   draft.x = 2
   return 3
})
// returns { x: 2 }
// The '3' is ignored entirely (and we can't really warn about it)

Alternatively we could warn about non-undefined return values (fixing the last case) and forcing consumers to either use d => { ...  } or d => void ...  or d => replace(...) in producers.
Edit: removed the warnings

IMO: Warn when draft is mutated but not returned. Then whenever a producer returns undefined, replace the draft with undefined.

The replace function doesn't solve the second issue, which is the need for another import. I should be able to create producers in one module without importing immer, then import those producers in another immer-aware module that wraps them and re-exports.

I really like how the "return the draft" requirement discourages footgun one-liners:
// The footgun
produce({}, draft => draft.a = 2) // => 2

// When the draft must be returned, safe one-liners are more intuitive.
produce({}, draft => (draft.a = 2, draft))

@aleclarson do you mean in the current, or new situation? The proposal here is to never care about what is returned, so the above could also be written as () => draft.a = 2, or, with the more stricter proposal needs to be written as () => { draft.a = 2 } / () => void (draft.a = 2)

I've also being bitten a couple of times by:
produce({ x: 1 }, draft => draft.x = 2) // => 2

If you want to replace a state why not call produce with the new state
produce({ x: 1 }, { a: 2 });

As the function is kind of superfluous. If you do so, you can go with always ignoring the value returned by the function:
produce({ x: 1 }, draft => draft.x = 2)
// returns { x: 2 }

@albertogasparin There's no point in using produce in your proposed produce(currState, nextState). Just do currState = nextState when you know the next state already.

Do you mean in the current, or new situation?

@mweststrate My idea is a counter-proposal. WDYT?

The proposal here is to never care about what is returned

My proposal is the opposite: "The return value is always used"
I think explicit returns are the easiest to reason about. And no need for a replace function.

@aleclarson How do you avoid erroneous returns? As you pointed out, even if we say that the returned value is used as new state, arrow function still makes it very error prone:
// The footgun
produce({}, draft => draft.a = 2) // => 2

I like more the main proposal (ignoring the return), which will let immer care only about the changes made to draft.
@mweststrate Besides I don't understand why would someone to use immer to replace the state with undefined (or any other statically known value) inside a produce. As @aleclarson said "Just do currState = nextState". Am I missing something? 🤔

Besides I don't understand why would someone to use immer to replace the state with undefined (or any other statically known value) inside a produce. As @aleclarson said "Just do currState = nextState". Am I missing something? 🤔

Yes, producers may use conditional logic to determine if no changes, some changes, or a replacement is appropriate.

Is optimizing for one-liner producers really worth it? Are people using one-liners more often than they are replacing the base state? I'm really not a fan of adding a replace function. Maybe there's a better way..

As I've said in #246, I'm highly against ignoring the return value by default. The current behavior is much better, and I think the void trick should be discouraged in the docs, since it's just a footgun for no real gain. If anything, the return value should always be used so the mental model is closer to a traditional reducer. In the end, there's really not a strong enough justification for changing the current behavior at all.

Returning the value is unnatural, the normal case of using a producer is to modify that thing that you are passing in to it. Needing to write draft => draft.x++, draft (or in other forms) is imho counter-intuitive. In that case I prefer the current 'footgun'  where you shouldn't forget void, but in that case at least a normal {..} function body produces the required result
Producing an entire new value, not based on the value you started with, is the exceptional behavior (don't think I saw it outside Redux reducers). That makes perfect sense; the goal of a producer is to produce a new value based on the current value. If the goal is to replace a value, produce is in principle not needed in the first place! The only reason why we have such a case, is that in reducers it is quite common to have different code paths that either "update" the current state, or entirely replace it with something else.

To summarize, the options are:
Updating a value (the common case)

draft => void draft.counter++   or draft => { draft.counter++ } (as is)
draft => draft.counter++ or draft => { draft.counter++ } (the proposal)
draft => draft.counter++, draft or draft => { draft.counter++; return draft } (proposal @aleclarson )

Replacing a value (the non-common case)

draft => ({ counter: 0})  or draft => { return { counter: 0 } } (as-is)
draft => replace({ counter: 0})  or draft => { return replace({ counter: 0 } }) (the proposal, using replace utility)
draft => ({ counter: 0})  or draft => { return { counter: 0 } } (as-is)  (proposal @aleclarson )

Replacing state with undefined (the really exceptional case)

draft => nothing (as-is, using nothing token)
draft => replace(undefined) (the proposal, no longer an exceptional case)
draft => undefined

My vote is to keep the current behavior.
Note: The replace function in option 2 should only be necessary if the draft has been modified.
import {produce, replace} from 'immer'

produce({ count: 0 }, draft => draft.count++)
// => { count: 1 }

produce({ foo: true }, draft => ({ foo: false }))
// => { foo: false }

produce({ a: 1 }, draft => {
  draft.a = 2
  return replace({})
}) // => {}

Also, there could be a special case for original so you can do:
produce({ a: 1 }, draft => {
  doSomeMutations(draft)
  return original(draft) // Rollback to original state
}) // => { a: 1 }

Made a poll: https://twitter.com/mweststrate/status/1092341986374438912

I agree with @aleclarson on this. I also agree that the void trick should be removed from the docs.
But I disagree that we should always return the draft. because that would confuse someone looking at it for the fist time.
right now, what we have is perfect. just remove void trick. I have the following justifications:

We shouldn't extend the api beyond the scope for no real gain
This library doesn't represent traditional reducers, so it shouldn't be confused with them, we're recording mutations and building a new state from it, not reducing state with mutation to get a new state.
we should encourage readable code. the void (...) pattern is not readable for someone who doesn't know why it's there. because they should know what void does, keep in mind that => expr returns the evaluated value and why it's there in the first place (returned values the callback mean something special)
We need a way to support changing the end value in a composeable way! replace(value) specializes this functionality. so a function from another library, or a shared function must be aware of immer. which is a framework smell. I don't like the nothing solution either, but that's on javascript not immer.

@mweststrate no, it's not. it's a bit different
I'm saying any return value must be ignored EXCEPT when it's the result of replaced. because we want the user to have control outside of functions that might call replace.
produce({ x: 1 }, draft => {
   replace(3)
})

vs
produce({ x: 1 }, draft => {
   return replaced(3)
})

this way, if a nested function returned replaced result, the user can ignore it, or take it into account.
having a function that changes the behavior of a whole subtree is an anti pattern, a framework smell, and we hard to compose.

@alitaheri ok, lol, what you are saying was intended to be the proposal. Will update the original post, the example code is broken :').

Poll results (102 votes):
08% keep as is!
52% awesome idea!
40% results

Seems worth pursuing in a MR

/cc @knpwrs @jineshshah36 @alitaheri @markerikson
Your opinions would be valuable!

I would definitely agree with ignoring the return value. However, I would be curious to know what the return type of replace is as well as a the type of nothing. To make this design the most type safe, I would consider doing the following:
const nothing: unique symbol = Symbol()
const replaced: unique symbol = Symbol()
const replace = (value: any): typeof replaced => {
  // do replacement with value
  return replaced
}

// enforce the return type of produce is the following:
type Return = typeof nothing | typeof replaced | void

Coming from the Redux point of view, I would definitely be against ignoring the return value, for two reasons:

There's still plenty of idiomatic use cases for wanting to generate a new value using existing immutable methods, like removing an item using return state.filter(item => item.id !== someId)
I think most Redux users of Immer will be doing so via something that wraps produce() and calls it behind the scenes, rather than explicitly calling produce() themselves inside their own reducer.  Specifically in the case of Redux Starter Kit, we do this:

export function createReducer<S = any, A extends Action = AnyAction>(
  initialState: S,
  actionsMap: CaseReducersMapObject<S, A>
): Reducer<S> {
return function(state = initialState, action): S {
return createNextState(state, (draft: Draft<S>) => {
      const caseReducer = actionsMap[action.type]
      return caseReducer ? caseReducer(draft, action as A) : undefined
    })
  }
}

From the end user's point of view, there's no visible evidence that Immer is being used:
const todosReducer = createReducer([], {
    "ADD_TODO" : (state, action) => {
        // "mutate" the array by calling push()
        state.push(action.payload);
    },
    "TOGGLE_TODO" : (state, action) => {
        const todo = state[action.payload.index];
        // "mutate" the object by overwriting a field
        todo.completed = !todo.completed;
    },
    "REMOVE_TODO" : (state, action) => {
        // Can still return an immutably-updated value if we want to
        return state.filter( (todo, i) => i !== action.payload.index)
    }
}

Removing the ability to return a new value would cause us issues.

@markerikson You could call replace() in prod but warn when in dev so that you could gradually migrate

/cc @knpwrs [and others]

I changed knpwrs/redux-ts-utils to use createDraft/finishDraft so I don't believe this proposed change would affect me.

@markerikson Raises a good point. I have an idea. We can't just warn by default since cases like this:
return produce(state, draft => draft.a = 2);

will warn for no good reason.
However, we can add an opt-in options: calling enableReturnValueUsageWarning() will enable the error. and we can document it in the migration section. opt-in to avoid confusion in the aforementioned case.
I'm still not 100% bought in the idea, but the community agrees that we should go down this road, so let's at least enable gradual migration paths.
P.S. the warning must use console.error to show the stack trace, makes it a lot easier to track down usages.

@jineshshah36 I think we could overload the produce function. if it matches (draft => () => Replaced<T>) then return T. Otherwise, State. I'm not sure, but when it's done I could play with it a bit.

@alitaheri the point of typing Return as typeof nothing | typeof replaced | void is to ensure that users only return one of those three rather than just anything. I'm not sure an overload could enforce that

@jineshshah36 oh, we shouldn't enforce that. because of this:
return produce(state, draft => draft.a = 2);

the assignment expression evaluates to 2 and the arrow function returns it. so if we type it in a way that disallows return type of not Replaced, we will be disallowing such usages (which is one of the reasons for this idea)

Typewise it is not very hard to make that work produce<D, R>(state: D, (draft: D) => R): R extends Replace<infer X> ? X : D, where replace is defined as replace<T>(value: T>): Replace<T>

@markerikson thanks for the clarification, that is really insightful! I think the abstraction leaks in any case indeed, but I can imagine that you don't want to explicitly use an api of immer for replacement. (Let's throw replacement values wrapped in an exception, lol :P)

Ok, closing this for now. So far everybody seems to be getting along with void or { } quite well, and the abstraction is going to leak somewhere when using produce inside external abstractions like RSK:
Either:

void is needed to avoid accidental replacements
replace needs to be introduced to support replacements

I think in hind-sight, replacing the returned state should not have been supported in the first place (it's not the point Immer, just made currying for reducers more easy), which leaves it to the wrapping abstraction to deal with those cases (need replace? don't call produce in the first place...). But I don't think it is worth the effort atm to enforce such a breaking change on the community :)

In react I am doing:
this.setState(produce(draft => {

});

But then as I am doing changes to the draft, I realize I want to cancel the setState by returning null. Is it possible to do this somehow? As returning null in setState cancels.
I also have this problem with hooks:
            const [ pastes, setPastes ] = useState([]);
            setPastes(produce(draftPastes => {
                const draftPaste = draftPastes.find(paste => paste.id === pasteId);
                if (!draftPaste) return null;
                draftPaste.comments.push(comment);
            }));

Afaik that should work OOTB.
Note that it is not possible to return undefined from a producer, in that
case, one should return NOTHING (can be imported from immer)
On Wed, May 8, 2019 at 4:22 AM Noitidart<EMAIL_ADDRESS>wrote:

In react I am doing:
this.setState(produce(draft => {
});
But then as I am doing changes to the draft, I realize I want to cancel
the setState by returning null. Is it possible to do this somehow? As
returning null in setState cancels.
I also have this problem with hooks:
        const [ pastes, setPastes ] = useState([]);
        setPastes(produce(draftPastes => {
            const draftPaste = draftPastes.find(paste => paste.id === pasteId);
            if (!draftPaste) return null;
            draftPaste.comments.push(comment);
        }));

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/immerjs/immer/issues/246#issuecomment-490321845, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAN4NBE26QAXC6FF6IAR6CDPUI2MXANCNFSM4GCZPBDA
.


ToastNotification is required!

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
https://github.com/raflop/ToastNotifications
Toast Notify  may be  much better  when finish some   command actions !
Describe the solution you'd like
A clear and concise description of what you want to happen.
Additional context
Add any other context or screenshots about the feature request here.
Closed Issues

@wjkhappy14 I don't understand what do you want/need? This library can be used in any WPF app together or without MahApps.


improve chronic disease transition models

Using the T-tests as a benchmark for improvement, we need to improve the transition models for some chronic diseases.
We will focus on Cancer, Diabetes, Heart Disease, and Hypertension first, as these are some of the most important chronic diseases, and some are highly influential in other chronic diseases.
Here are the T-tests as a starting point:

variable
fem_mean_wave3
elsa_mean_wave3
p_value_wave3
fem_mean_wave4
elsa_mean_wave4
p_value_wave4
fem_mean_wave5
elsa_mean_wave5
p_value_wave5
fem_mean_wave6
elsa_mean_wave6
p_value_wave6
fem_mean_wave7
elsa_mean_wave7
p_value_wave7
fem_mean_wave8
elsa_mean_wave8
p_value_wave8

Any ADLs
0.2034
0.21265
0.19503
0.20566
0.22858
0.00341
0.21061
0.23353
0.005
0.2248
0.23014
0.53101
0.24046
0.21925
0.01868
0.25074
0.22498
0.00834

Any IADLs
0.22006
0.22211
0.77756
0.22696
0.24747
0.01084
0.23492
0.2548
0.01807
0.24922
0.26006
0.22174
0.26668
0.25179
0.11507
0.28758
0.26585
0.03525

Cancer ever
0.10529
0.08634
0.00013
0.12412
0.0972
0
0.14332
0.11917
0.00013
0.16537
0.12381
0
0.18708
0.1466
0
0.20995
0.16397
0

Diabetes ever
0.1134
0.0937
0.00012
0.12937
0.11321
0.00658
0.14451
0.12803
0.01107
0.15961
0.13755
0.00165
0.17455
0.15406
0.00933
0.18565
0.15097
4E-05

Heart disease ever
0.22072
0.17494
0
0.24355
0.1983
0
0.26794
0.22183
0
0.29371
0.22953
0
0.32054
0.25602
0
0.34867
0.28985
0

Hypertension ever
0.48354
0.4483
5E-05
0.51649
0.48162
0.00019
0.54569
0.50639
5E-05
0.57324
0.50793
0
0.59931
0.53135
0
0.62452
0.5384
0

Lung disease ever
0.08997
0.07187
7E-05
0.09918
0.07859
5E-05
0.10748
0.08631
0.00011
0.1182
0.08619
0
0.12758
0.09168
0
0.13645
0.08975
0

Stroke ever
0.05877
0.05037
0.02895
0.06486
0.06373
0.8043
0.07241
0.06743
0.30549
0.07907
0.07311
0.25971
0.08516
0.0833
0.75748
0.09339
0.08899
0.50812

Ideas:
So far, I have made some reasonable improvements just by tweaking the transition models. Improving the logbmi model made probably the biggest difference of anything for a couple of variables. I will continue to do this, but also look into some other variables from ELSA we can include. Examples being high cholesterol and hip fracture as 2 variables that have made a noticeable improvement.
This issue continues the work started in #41, #45, #48 & #49.

Models are now pretty reasonable, and logic to calculate them is in the debug document.


Add dewpoint template sensor

Description:
Adds a new sensor, based (via copy/paste/modify) on Template Sensor, that takes two template values--one for temperature, one for humidity--and calculates the dew point.
I first tried to just do it with a template sensor, but the calculation involves natural logarithms, which can't be done using Jinja2's math operators.  And this way is more user-friendly and reusable anyway.
I initially kept the icon and picture customization options copied from SensorTemplate in, but decided they didn't make that much sense on such a conceptually simple sensor, so weren't worth the documentation and maintenance costs of supporting them.
Supersedes #10552.
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
I haven't made a documentation PR yet.  Hoping to get to that tomorrow.
Example entry for configuration.yaml (if applicable):
sensor:
  - platform: dewpoint
    temperature_template: "{{ states.sensor.thermostat_temperature.state }}"
    humidity_template: "{{ states.sensor.thermostat_humidity.state }}"
    unit_of_measurement: TEMP_FAHRENHEIT
    friendly_name: 'Dining Room Dewpoint'

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.github.io

If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

We should not use templates but instead just take 2 sensors as inputs. If people want to use a template, they can use the template sensor to use as an input.

Is this the same sensor functionality maybe? http://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/sensor/mold_indicator.py

Yep it is. Thanks @molobrakos for noticing.

(... although 'dewpoint sensor' is maybe a better name than 'mold indicator sensor')

Agreed.... 👍 for dewpoint

Yeah, I see the mold indicator as a pretty purpose-specific thing.  I was going for "given a humidity sensor, which is not actually useful for evaluating comfort, make a dewpoint sensor, which is."  My purpose is to get a sense of how the dewpoint inside my house compares to that outside so I know if I should open my windows on summer nights or if that will just pull in nasty wet air.


Create broadcast_tx_multiple

The function signature should probably look like this:
async fn broadcast_tx(&self, tx: &impl IntoIterator<Item = Raw>) -> Result<ChainTxResponse, ChainError>

This would be super useful for quickly sending off many txs. @de-husk if you don't have time for this I'd be happy to take a crack at it! My deployment software is regularly sending off 20-30 txs in a row so this would be super useful for me.

:wave:
I will be making the tx module next, and this is a good point.
I'm curious about your use case though. Are those ~30 transactions all being signed with the same key (or the gas being paid by the same key)?
If so you can just batch them under the same Tx. Otherwise, it doesn't look like cosmosSDK actually supports a batch broadcast functionality, so we would end up having to just call /cosmos.tx.v1beta1.Service/BroadcastTx in a loop. Which Im fine with adding a utility method that does that.

I was actually looking at what you have in cost-orc. There you have
pub async fn send_tx(
    client: &HttpClient,
    msg: Any,
    key: &secp256k1::SigningKey,
    account_id: AccountId,
    cfg: &ChainCfg,
)
``` which doesn't support using an Iterator for msg. Ideally when you get the tx module written here having it use `impl IntoIterator<Item = Any>` would be fantastic. Batching them under the same Tx is what I was trying to say. I don't need to batch broadcast many messages, but if you wanted to support that I think you can hack it by manually incrementing the account sequence, although in my testing I've seen that to mostly work, but it was fairly unreliable.

Ideally when you get the tx module written here having it use impl IntoIterator<Item = Any> would be fantastic.
Perfect, really good call, will do.

Initial version done, check out https://github.com/de-husk/cosm-tome/blob/main/src/modules/tx/api.rs


Release

Merge this to make "next" be the new "latest".

:tada: This PR is included in version 1.4.0-rc.1 :tada:
The release is available on:

GitHub release
npm package (@next dist-tag)
v1.4.0-rc.1

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.4.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)
v1.4.0

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.5.0 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)
v1.5.0

Your semantic-release bot :package::rocket:


Fixed LLVM major version from "10.1" to "10".

Using MAJOR.MINOR string in Dockerfile.package-cpu crashes due to a numeric comparison made by scripts/centos_install_llvm.sh.
This simply set LLVM version from 10.1 to 10.
Note: I couldn't find a LLVM released under 10.1.x (in https://releases.llvm.org/), so I assume the current returned value 10.0.1 is correct.

cc @icemelon9

Currently, we are using "10.0". I don't see there's any problem

Currently, we are using "10.0". I don't see there's any problem

I tried rebuilding the Docker image and it seems it crashes because the -gt operator only accepts integer values (match with docs at https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/test.html).
Am I missing something? Please correct me of I’m wrong.

This is a reproduce of the issue I see:
$ cat test.sh
set -e

LLVM_VERSION_MAJOR=10.0

if [ ${LLVM_VERSION_MAJOR} -lt 9 ]; then
  echo "${LLVM_VERSION_MAJOR} is lt 9"
else
  echo "${LLVM_VERSION_MAJOR} is NOT lt 9"
fi

When running it:
$ bash test.sh
test.sh: line 5: [: 10.0: integer expression expected
10.0 is NOT lt 9

$

I agree this is a minor problem - we can live with it for now.


Code Cleanup and Title Bar

Implement a dynamic title bar and clean up the hard-coded column names throughout the application

Note that the title bar doesn't respond properly to click-drag actions in dev mode (with devtools open). This is due to an electron issue which can be worked around manually like this.


Configure acceptance tests for nightly runs

Acceptance tests now upload data to S3 in a publicly-accessible JSON file.

[x] Make upload happen only when specifically requested, i.e. not from Travis-driven runs.

Sample data:
[
  {
    "start":<PHONE_NUMBER>.888421
  },
  {
    "status": "done",
    "browser": "Windows 7 IE 9.0",
    "ok": true,
    "elapsed":<PHONE_NUMBER>7357178
  },
  {
    "status": "errored",
    "browser": "Windows 8.1 Firefox 35.0",
    "exception": "(<class 'selenium.common.exceptions.NoSuchElementException'>, NoSuchElementException(), <traceback object at 0x7fef36cd8488>)",
    "ok": false,
    "elapsed":<PHONE_NUMBER>7631836
  },
  {
    "status": "failed",
    "browser": "Windows 7 IE 8.0",
    "exception": "(<type 'exceptions.AssertionError'>, AssertionError('\\'You deleted\\' not found in u\"Saved changes to the article-916104 article! Remember to submit this change for feedback when you\\'re ready to go live.\"',), <traceback object at 0x7fef36cf3cf8>)",
    "ok": false,
    "elapsed":<PHONE_NUMBER>528717
  },
  {
    "ok": false,
    "end":<PHONE_NUMBER>.508441
  }
]

Updated the sample JSON per @wpietri’s suggestion.

This looks good to me. I think the OUTPUT_FILE code more properly belongs in the superclass in that we want it to happen for all acceptance tests rather than just this one, but since we currently have only one, it's a distinction without a difference. However, I'd rather not merge the Travis bit until the nightly job is up, running, and producing a report that people will actually see on a daily basis.

Latest version looks fine to me too. There are a few things that could be changed to make the file more human-readable and -useful if that's desired – like readable dates and links to browserstack jobs (though from what I hear that's not really posssible).
Also, will we have a hook into Slack so we'll see when these tests have been run?

Oh, and saving archived test results maybe?

None of my suggestions are intended to delay merging this PR though.

I’m putting the finishing touches on the nightly job now!

It looks like if the tests are run n times per os/browser, we will see every test represented in the JSON. Might be cool to have one entry per os/browser combination, a pass/fail ratio, and a list of exceptions.

Ah, I was thinking that the summarization would be taken care of by whatever script was doing the user-visible reporting. E.g., that there would be an HTML page that would load this stuff with JS. Or that some script would grab the data after a run and send us email.

I'm fine with that. I wasn't sure whether this was supposed to be user-visible or consumed by another service (like your dashboard?).

I believe this is read to merge.

Runs nightly with a git pull, with 25 test reps and no retries.
Latest results are always at this URL: http://chimecms-test-results.s3.amazonaws.com/acceptance-test-nights-14b213e30a24.json
Historic results use the commit hash: http://chimecms-test-results.s3.amazonaws.com/acceptance-test-nights-14b213e30a24.json


what and how we can prevent new update of pixi.js ? 5.0

hi guys||girls,  i read you a lot work on PIXI 5.0.
I develop an alpha project based on pixi thecnologie, I would like to be able to anticipate some behavior of the next update.
Do you have a follow-up link on the changes made or a possible release date?
i dont know a lot the labyrinth github are, but I may miss the place to look!?
I would like to avoid breaking my codes, especially if the v5 is better than the 4, and would make a update.
I speak of it because I have read in many places that you work on it.
thank.

... v5 API will be almost 100% the same as current version.

@GoodBoyDigital: Thank you so much for this. It's not something you had to do, esp. with a major version bump, but the fact that you're striving for it overwhelmingly shows how much the pixi.js team cares about the project and its users.
Thank you.

Thanks for the kind words @allanbreyes ! I honestly believe the API is one of pixi's greatest strengths :)
We would only really consider changing it if had some really compelling reasons!


Add integration with CircleCI

It'd be great to have a Zulip integration for notifications from CircleCI.
See http://zulip.readthedocs.org/en/latest/integration-guide.html for how to write a Zulip integration; I'd check out the docs for Travis CI or Jenkins for inspiration on message formatting.
It looks like this should be doable via a webhook, see https://circleci.com/docs/configuration/#notify.

I'm starting to work on it.

Merged via #768 :)


Post-vote release checklist for version 3.0.0

[x] Label this issue with the project that corresponds to this release version
Git tasks

[x] Create a signed rel/<version> tag (and push it)
[x] Merge <version>-rc<N>-next branch into a maintenance branch (if maintenance is expected),
and then into the main branch (and push them)
[x] Remove *-rc* branches

Nexus tasks

[x] Release the staging repository corresponding to the successful release candidate (use "release" button)
[x] Drop any other staging repositories for Accumulo (do not "release" or "promote" them)

SVN / dist-release tasks

[x] Upload the release artifacts (tarballs, signatures, and .sha512 files) for the mirrors
[x] Remove old artifacts from the mirrors (after updating the website)

Board reporting tool

[x] Add the date of release (the date the release artifacts were uploaded to SVN UTC+0000)

Verify published artifacts

[x] In Maven Central
[x] In ASF Downloads
[x] In several mirrors or CDN

Update the website

[x] Release notes
[x] Add LTM: true to the release notes front-matter for LTM releases
[x] Navigation
[x] Downloads page
[x] If LTM release, update previous LTM release entry on downloads page and release notes with an EOL date 1 year from the current release date
[x] DOAP file
[ ] Add manual/examples/javadoc (build javadoc from tag with mvn clean package -DskipTests javadoc:aggregate -Paggregate-javadocs using at least JDK 17)
[ ] Add updated properties documentation (see the website README)
[x] Jekyll config
[x] Grep for, and update any links to previous version to now point to the new version
[x] Update any older release notes front-matter to indicate they are either archived: true or archived_critical: true

Announcement email

[x] Prepare and get review on dev list (see examples from previous announcement messages)
[ ] Send to<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(use plain text mode only; html email will be rejected)

GitHub wrap-up

[ ] Close this issue
[x] Create a new "Automated Kanban" project for the next version (if necessary) and move any open issues not completed in this release to that project
[x] Close the project that corresponds to this release

Twitter

[ ] Tweet it
[ ] Confirm the tweet

I can't really complete the uploading of the javadoc and server properties, until the website is redesigned to accommodate the 3.x documentation, which starts to diverge from the 2.x docs. That redesign is somewhat substantial, and can't be done as a simple website update for the release, because there is a Jekyll plugin written in ruby that writes the links to the documentation, and changing that is non-trivial.

Can't use TweetDeck anymore to post announcements on Twitter, so those actions can't be checked off. I'll probably remove them from this issue template.

I did upload the javadoc and properties config, but I had to manually edit some of them to get them to make sense in the 2.x-centric docs. The site still needs a redesign to accommodate the docs better across major releases, but this is good enough for now.


Feat: Added support for deleting Tags and Tags category.

Describe your changes :

I worked on added support for deleting tags and tags categories. also added a unit test for the delete functionality.
Closes #3013

Type of change :

[x] Improvement
[x] New feature

Frontend Preview (Screenshots) :

Checklist:

[x] I have read the CONTRIBUTING document.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] All new and existing tests passed.

Reviewers

@open-metadata/ui

@ShaileshParmar11 thanks for adding the tests and making it near 90%. Looks like tagsAPI.ts doesn't have as much coverage

can you spend sometime and increase that coverage as well

@ShaileshParmar11 thanks for adding the tests and making it near 90%. Looks like tagsAPI.ts doesn't have as much coverage  can you spend sometime and increase that coverage as well

Yes, @harshach I will look into it.

@ShaileshParmar11 thanks for adding the tests and making it near 90%. Looks like tagsAPI.ts doesn't have as much coverage  can you spend sometime and increase that coverage as well

@harshach I have added a unit test for tagsAPI.ts

@ShaileshParmar11 will this also be applied to the glossary?

@ShaileshParmar11 will this also be applied to the glossary?

This patch contains support only for the tags page.


PDF writing fails with joblib.Parallel using (default) Loky backend

What happened?
Dear developers,
I'm not sure if this is well known, but the following code
import altair as alt
import joblib
import pandas as pd
import os

os.environ["RUST_BACKTRACE"] = "full"

def write_chart(filename):
    df = pd.DataFrame({"x": [2, 3, 4], "y": [5, 5, 3]})
    chart = alt.Chart(df).mark_point().encode(x="x", y="y")
    chart.save(filename)

filenames = [f"chart{i}.pdf" for i in range(2)]
joblib.Parallel(n_jobs=2)(joblib.delayed(write_chart)(filename) for filename in filenames)

results in an error (full message below).
I'm reporting it here since I triggered with altair and would be nice to address with a fix or documentation, but maybe the issue originates in another project and it is beyond the scope of this issue tracker. If you think this would better fit into the loky or deno tracker I'm happy to move it there.
/Users/leo/code/msi/.venv/bin/python /Users/leo/code/msi/code/prototyping/altair_minimal_pdf.py
thread '<unnamed>' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/deno_runtime-0.166.0/worker.rs:701:7:
Bootstrap exception: TypeError: testEnabled is not a function
    at init (ext:deno_node/internal/util/debuglog.ts:51:15)
    at debug (ext:deno_node/internal/util/debuglog.ts:54:5)
    at logger (ext:deno_node/internal/util/debuglog.ts:69:29)
    at readableAddChunk (ext:deno_node/_stream.mjs:2797:7)
    at Readable.push (ext:deno_node/_stream.mjs:2791:14)
    at initStdin (ext:deno_node/_process/streams.mjs:185:13)
    at Object.internals.__bootstrapNodeProcess (node:process:653:22)
    at initialize (ext:deno_node/02_init.js:34:15)
    at bootstrapMainRuntime (ext:runtime_main/js/99_main.js:873:7)
stack backtrace:
   0:        0x31089fa1c - _BrotliDecoderVersion
   1:        0x310098630 - _BrotliDecoderVersion
   2:        0x310875ef8 - _BrotliDecoderVersion
   3:        0x3108a20b8 - _BrotliDecoderVersion
   4:        0x3108a19d0 - _BrotliDecoderVersion
   5:        0x3108a15d8 - _BrotliDecoderVersion
   6:        0x3108a28e8 - _BrotliDecoderVersion
   7:        0x3108a23d0 - _BrotliDecoderVersion
   8:        0x3108a2338 - _BrotliDecoderVersion
   9:        0x3108a232c - _BrotliDecoderVersion
  10:        0x312068e9c - _wgpu_render_bundle_insert_debug_marker
  11:        0x310a71160 - _v8_inspector__V8InspectorClient__BASE__consoleAPIMessage
  12:        0x310a6e184 - _v8_inspector__V8InspectorClient__BASE__consoleAPIMessage
  13:        0x310a806c0 - _v8_inspector__V8InspectorClient__BASE__consoleAPIMessage
  14:        0x3108a4e74 - _BrotliDecoderVersion
  15:        0x1937baf94 - __pthread_joiner_wake
thread '<unnamed>' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/deno_runtime-0.166.0/worker.rs:701:7:
Bootstrap exception: TypeError: testEnabled is not a function
    at init (ext:deno_node/internal/util/debuglog.ts:51:15)
    at debug (ext:deno_node/internal/util/debuglog.ts:54:5)
    at logger (ext:deno_node/internal/util/debuglog.ts:69:29)
    at readableAddChunk (ext:deno_node/_stream.mjs:2797:7)
    at Readable.push (ext:deno_node/_stream.mjs:2791:14)
    at initStdin (ext:deno_node/_process/streams.mjs:185:13)
    at Object.internals.__bootstrapNodeProcess (node:process:653:22)
    at initialize (ext:deno_node/02_init.js:34:15)
    at bootstrapMainRuntime (ext:runtime_main/js/99_main.js:873:7)
stack backtrace:
   0:        0x14889fa1c - _BrotliDecoderVersion
   1:        0x148098630 - _BrotliDecoderVersion
   2:        0x148875ef8 - _BrotliDecoderVersion
   3:        0x1488a20b8 - _BrotliDecoderVersion
   4:        0x1488a19d0 - _BrotliDecoderVersion
   5:        0x1488a15d8 - _BrotliDecoderVersion
   6:        0x1488a28e8 - _BrotliDecoderVersion
   7:        0x1488a23d0 - _BrotliDecoderVersion
   8:        0x1488a2338 - _BrotliDecoderVersion
   9:        0x1488a232c - _BrotliDecoderVersion
  10:        0x14a068e9c - _wgpu_render_bundle_insert_debug_marker
  11:        0x148a71160 - _v8_inspector__V8InspectorClient__BASE__consoleAPIMessage
  12:        0x148a6e184 - _v8_inspector__V8InspectorClient__BASE__consoleAPIMessage
  13:        0x148a806c0 - _v8_inspector__V8InspectorClient__BASE__consoleAPIMessage
  14:        0x1488a4e74 - _BrotliDecoderVersion
  15:        0x1937baf94 - __pthread_joiner_wake
joblib.externals.loky.process_executor._RemoteTraceback:
"""
Traceback (most recent call last):
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/externals/loky/process_executor.py", line 463, in _process_worker
    r = call_item()
        ^^^^^^^^^^^
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/externals/loky/process_executor.py", line 291, in __call__
    return self.fn(*self.args, **self.kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 598, in __call__
    return [func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 598, in <listcomp>
    return [func(*args, **kwargs)
            ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/leo/code/msi/code/prototyping/altair_minimal_pdf.py", line 12, in write_chart
    chart.save(filename)
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/altair/vegalite/v5/api.py", line 2086, in save
    save(**kwds)
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/altair/utils/save.py", line 224, in save
    perform_save()
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/altair/utils/save.py", line 189, in perform_save
    mb_any = spec_to_mimebundle(
             ^^^^^^^^^^^^^^^^^^^
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/altair/utils/mimebundle.py", line 134, in spec_to_mimebundle
    return _spec_to_mimebundle_with_engine(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/altair/utils/mimebundle.py", line 267, in _spec_to_mimebundle_with_engine
    pdf = vlc.vegalite_to_pdf(
          ^^^^^^^^^^^^^^^^^^^^
ValueError: Vega-Lite to PDF conversion failed:
Failed to retrieve conversion result: oneshot canceled
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/leo/code/msi/code/prototyping/altair_minimal_pdf.py", line 16, in <module>
    joblib.Parallel(n_jobs=2)(joblib.delayed(write_chart)(filename) for filename in filenames)
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 2007, in __call__
    return output if self.return_generator else list(output)
                                                ^^^^^^^^^^^^
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 1650, in _get_outputs
    yield from self._retrieve()
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 1754, in _retrieve
    self._raise_error_fast()
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 1789, in _raise_error_fast
    error_job.get_result(self.timeout)
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 745, in get_result
    return self._return_or_raise()
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/leo/code/msi/.venv/lib/python3.11/site-packages/joblib/parallel.py", line 763, in _return_or_raise
    raise self._result
ValueError: Vega-Lite to PDF conversion failed:
Failed to retrieve conversion result: oneshot canceled

Process finished with exit code 1

What would you like to happen instead?
The loop should work without an error, which is the case if you set either of:

n_jobs=1
backend="multiprocessing" and add freeze_support()

Especially the latter is interesting and is what I am using as a workaround now.
Which version of Altair are you using?
5.4.0

Thank you for transferring the issue. With multiprocessing I cannot reproduce this issue, i.e. the following works:
from multiprocessing import freeze_support

import altair as alt
import joblib
import os
import pandas as pd

os.environ["RUST_BACKTRACE"] = "full"

def write_chart(filename):
    df = pd.DataFrame({"x": [2, 3, 4], "y": [5, 5, 3]})
    chart = alt.Chart(df).mark_point().encode(x="x", y="y")
    chart.save(filename)

if __name__ == "__main__":
    freeze_support()
    filenames = [f"chart{i}.pdf" for i in range(2)]
    joblib.Parallel(n_jobs=10, backend="multiprocessing")(
        joblib.delayed(write_chart)(filename) for filename in filenames)

Taken from the loky README:
"All processes are started using fork + exec on POSIX systems. This ensures safer interactions with third party libraries. On the contrary, multiprocessing.Pool uses fork without exec by default, causing third party runtimes to crash (e.g. OpenMP, macOS Accelerate...)."
So my understanding is they use different fork models, but in this case the default multiprocessing seems to work whereas loky does not. I'm not really an expert on the details of multiprocessing to understand how this relates to Deno's runtime.

Thanks for the investigation @leoschwarz. Documentation is probably the best first step, just to let people know that the multiprocessing backend works but loky backend does not.
One thing that we might be able to do is expose an alternative API that doesn't rely on a global instance of the Rust object that wraps Deno.  We might be able to expose a VlConverter() class that wraps a dedicated instance of the Deno, that has methods for each of the global vl_convert.* functions.  The hope would be that if you create and use this from within the forked process, then everything will work fine since the global Deno instance wouldn't be forked.

I'm not sure if that would fully resolve the problem yet, because my workflow is basically joblib distributing tasks which execute the plotting within a new subprocess each starting its own Python interpreter (largely to avoid this type of problem), so I suspect the problem is located in a native extension doing something unusual with memory somewhere. I'm looking into creating a better example for this.

So I've finally gotten around to trace this a bit further since it still is a problem for me.
import pandas as pd
import altair as alt
import sys
import os
import threading
import argparse

def write_chart(filename):
    df = pd.DataFrame({"x": [2, 3, 4], "y": [5, 5, 3]})
    chart = alt.Chart(df).mark_line().encode(x="x", y="y")
    chart.save(filename)

def run_with_thread():
    thread = threading.Thread(target=write_chart, args=("chart_thread.pdf",))
    thread.start()
    thread.join()

def run_with_fork():
    if os.fork() == 0:
        write_chart("chart_fork.pdf")
        sys.exit(0)
    os.wait()

parser = argparse.ArgumentParser()
parser.add_argument("variant", choices=["thread", "fork", "thread-fork", "fork-thread"])
args = parser.parse_args()

if args.variant == "thread":
    run_with_thread()
elif args.variant == "fork":
    run_with_fork()
elif args.variant == "thread-fork":
    run_with_thread()
    run_with_fork()
elif args.variant == "fork-thread":
    run_with_fork()
    run_with_thread()

Every variant except "thread-fork" works as expected.
The error is different this time, but I believe it's the same underlying issue that leads to it as in my experience with joblib Loky, as the latter uses forks too.
thread '<unnamed>' panicked at /Users/leo/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.36.0/src/runtime/io/driver.rs:209:27:
failed to wake I/O driver: Os { code: 9, kind: Uncategorized, message: "Bad file descriptor" }

New Python versions also give us the following warning message:
DeprecationWarning: This process (pid=78279) is multi-threaded, use of fork() may lead to deadlocks in the child.

From what I understand, when a fork is created only the main thread will be present in the fork, so if in deno there is somehow some pointers to some existing threads, then this information will be lost in the forked process which leads to issues. I'm not sure if there is some easy way to avoid this type of problem...
My personal take away is to stop using software that calls os.fork in Python, as we will have proper threading soon. For this we can use subprocessing directly making sure to use the spawn instead of fork context (the default is different on Mac and Linux which can make this a bit more confusing if you are developing on both platforms)...

Initially I created this test case which someone might find handy later
import pytest
import joblib
import pandas as pd
import altair as alt
import sys
import time
from multiprocessing import freeze_support
import os

def write_chart(filename):
    df = pd.DataFrame({"x": [2, 3, 4], "y": [5, 5, 3]})
    chart = alt.Chart(df).mark_point().encode(x="x", y="y")
    chart.save(filename)

@pytest.mark.parametrize("backend", ["multiprocessing", "threading", "loky", None])
@pytest.mark.parametrize("ext", ["png", "pdf"])
def test_joblib(tmpdir, backend, ext):
    filenames = [str(tmpdir/f"chart{i}.{ext}") for i in range(2)]
    if backend:
        freeze_support()
        joblib.Parallel(n_jobs=2, backend=backend)(joblib.delayed(write_chart)(filename) for filename in filenames)
    else:
        for filename in filenames:
            write_chart(filename)

The good news is that it works with joblib's other backends.

Thanks for the detailed writeup. If you have a chance, it would be great to add a short summary to the Limitations section of the README.


Feat/poc detox device action

📝 Description
This PR has a proposal on how to create E2E tests involving Device Actions on LLM.
A few key premises of this proposal:

It only involves the new Device Action paradigm. We can use this as a strategy to create E2E tests (i.e. each time we migrate a device action to the new paradigm, it has to include the associated E2E tests)
It only tests the UI rendering of the device actions and not really their logic, those will be tested separately withing the Device SDK itself.
It doesn't depend on running the app with a specific environment variable such as MOCK=1
The state evolution of the device actions is directly controllable from the test spec itself

How it works
In the new Device Action (DA) paradigm, from the consumer point of view, a DA is only a function that receives instructions of what needs to be executed in the device and returns an Observable that emits events containing the current state of the DA according to the evolution of that execution. For usage withing React and React Native based apps, we also provide within the SDK a hook for each DA that triggers it (via useEffect) and stores the emitted states (via useState).
For usage within the context of E2E tests, we export from the hook file a mockable variable for the DA that is going to be used within the hook. If we initialize that variable, it's possible to directly control the full state that will be stored in the hook. This is why one of the key premises is that we're not actually testing the logic of a DA, but only the UI rendering of a DA within the context of a React / RN app. By initializing this variable from an E2E test context we're able to fully control the state of a given DA.
How to mock a Device Action in a Detox E2E tests
In order to communicate with the app JS execution and correctly initialize the mockable variable, we use the pre-existing Socket communication (it communicates between the Detox server and the app JS execution).
The first step to mock the DA you want to test using the the mockDeviceAction function on the server bridge on Detox side passing the name of the device action. This will send a message to the client side to replace the real DA by a mocked version which we can control and emit events for.

In order to change the state of a DA you call the updateDeviceActionState function on the server bridge on Detox side passing the name of the device action and the new state to be used. This will send a message to the client side to emit an event with a new state from the mocked DA to be used by the corresponding hook.

All the names of the device actions and their corresponding state structures are typed accordingly. If there's a DA that is not listed in the name types, it should be added along with the mocked Subject to be used, all of this can be done inside the deviceActionMocks.ts file.
❓ Context

Impacted projects: ledger-live-mobile, ledger-live-common
Linked resource(s): FAT-806

✅ Checklist

[x] Test coverage
[x] Atomic delivery
[x] No breaking changes

📸 Demo
https://user-images.githubusercontent.com/87659842/218435920-23ea20d1-5c3a-49a7-8a32-2db1cf22e889.mov

Added demo video

Once the new paradigm is fully in place, does that mean we won't need to use the e2eDeviceDescriptorSubject at all and all mocking will be done with the mockDeviceActions and updateDeviceActionState functions? @grsoares21 ?

Once the new paradigm is fully in place, does that mean we won't need to use the e2eDeviceDescriptorSubject at all and all mocking will be done with the mockDeviceActions and updateDeviceActionState functions? @grsoares21 ?

We will still need it whenever we pass through a device selection screen.


[C++][Python] Expose sorting_columns in RowGroupMetaData for Parquet files

Summary
Currently, the pyarrow.parquet.RowGroupMetaData class does not expose the sorting_columns information available in the Parquet format's RowGroup struct. This information is useful for users who need to understand the local sorting order of columns within each RowGroup. It would be beneficial to expose this information in the RowGroupMetaData class.
Details
The Parquet format includes an optional sorting_columns field in the RowGroup struct, which stores information about the sorting order of columns within the RowGroup. This information is defined in the SortingColumn struct in the parquet.thrift file:
struct SortingColumn {
  1: required int32 column_idx;
  2: required bool descending;
  3: optional bool nulls_first;
}

In the RowGroup struct, the sorting_columns field is defined as follows:
struct RowGroup {
  1: required list<ColumnChunk> columns;
  2: required i64 total_byte_size;
  3: required i64 num_rows;
  4: optional list<SortingColumn> sorting_columns;
}

However, the pyarrow.parquet.RowGroupMetaData class does not expose this information. As a result, users cannot access the local sorting information of columns within RowGroups.
Proposal
I propose adding a new method or property in the RowGroupMetaData class to expose the sorting_columns information. This could be implemented as a new method, such as get_sorting_columns(), or as a property, such as sorting_columns. The output should include the column index, sorting order (ascending or descending), and whether null values appear first or last in the sorted order.
Use Case
Users working with sorted Parquet files can benefit from understanding the local sorting order of columns within RowGroups. This information is particularly useful when analyzing large datasets or performing operations that require knowledge of the sort order, such as range queries, filtering, or merging.
By exposing the sorting_columns information in the RowGroupMetaData class, users can more easily work with sorted Parquet files and perform advanced data processing operations.
Component(s)
Python

@ei-grad thanks for opening the issue! I think that would be a welcome enhancement.
Note that this is also not yet exposed in the C++ parquet::RowGroupMetaData (which wraps the raw parquet::format::RowGroup, which is the auto-generated equivalent of the thrift struct you mentioned). So a first step would be to expose it in C++, and then the Python bindings can expose it as well.

I can help with the C++ part. Will finish it tonight

@wjones127 Hi will, I only solve the C++ part. Should we reuse this issue, or I should create another issue for C++/Python, and use that issue?

Ah sorry I didn't notice that. I think we generally want one-to-one correspondence with issues and pull requests, so i should have created a separate sub-issue for the C++ part. I think its fine for now if we re-use the issue, right @jorisvandenbossche ?

Yes, let's just re-use it

I'm not familiar with Python part, would you mind do this, or tell me the code I can take use for reference?

I can work on that soon.

Please not assign to me =_=

@judahrand would you mind reply here?

Sure!


will Windows 10 Creator Update finaly release a 32bit version of WSL and all?

I'm on a 32 bit version of Windows 10 and I'm aware that it isn't possible to install WSL or Bash on Windows on it. My question is: will we be able to install it with the Creator Update?
Thanks in advance.

@noomly - Currently, only 64bit support. Quote from https://msdn.microsoft.com/en-us/commandline/wsl/install_guide

Prerequisites

Your PC must be running (at a minimum) a 64-bit version of Windows 10 Anniversary Update. Creators Update is recommended.

And, #281.

User Voice here.

Out of curiosity: May I ask, why you are stuck with a 32bit version of Windows?

On currently on a Lenovo Ideapad100S. Next time i'll buy a laptop, I should better read more about it.  Plus, it's mostly not compatible with GNU/Linux so I'm quite stuck with this 32bits wondows 10 nonsense.

You can upgrade it to Win10 for free if you feel inclined, but with 2GB of RAM you'll probably hate yourself after the exercise. Also Donald Knuth was right.

@noomly - Wow! Lenovo 100S look like to have 64-bit processor but 32-bit BIOS and windows 10 home 32 bit bundle; https://forums.lenovo.com/t5/Lenovo-IdeaPad-100-305-500-Edge/Installing-Windows-10-x64-on-100S-11IBY/td-p/3536195 :(. But... They seems to release BIOS update for Windows 10 (64-bit); http://pcsupport.lenovo.com/products/laptops-and-netbooks/100-series/100s-14ibr/downloads/ds105646

Thanks for the post. Closing this out as a duplicate request.


cilium connectivity test failing in documented quick start procedure using kind running on Fedora

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
cilium connectivity test timedout due to errors in echo-other-node pod when running through the docummented install process using kind managed k8s cluster running on Fedora (bare metal and pod machine VM on MacOS).
error details:
Error: EMFILE: too many open files, watch '/'
    at FSWatcher.<computed> (node:internal/fs/watchers:244:19)
    at Object.watch (node:fs:2303:34)
    at /usr/local/lib/node_modules/json-server/lib/cli/run.js:179:10 {
  errno: -24,
  syscall: 'watch',
  code: 'EMFILE',
  path: '/',
  filename: '/'
}

Quick fix for kind documented here:
https://kind.sigs.k8s.io/docs/user/known-issues/#pod-errors-due-to-too-many-open-files
Suggested Change:
Enhance install documentation that notes recommended sysctl inotify related settings for kind to avoid too many open files error.
Cilium Version
v1.12.4 and v1.12.2
Kernel Version
Linux carbon 6.0.10-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:55:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Kubernetes Version
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:36:36Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.3", GitCommit:"434bfd82814af038ad94d62ebe59b133fcb50506", GitTreeState:"clean", BuildDate:"2022-10-25T19:35:11Z", GoVersion:"go1.19.2", Compiler:"gc", Platform:"linux/amd64"}
Sysdump
No response
Relevant log output
No response
Anything else?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Do you mind opening a PR to update the docs for kind about this?

Hi, any idea where to eye out? 😉

We're seeing this on a Kubernetes cluster with the following info:

Kubernetes distribution: K3s
Kubernetes: Version 1.24.8+k3s1
OS: Ubuntu 22.04 Jammy LTS
Linux kernel: v5.15.0-56

Cilium:

CLI version: v0.12.11 compiled with go1.19.3 on linux/amd64
Cilium on the Kubernetes cluster: 1.12.4

Following: https://kind.sigs.k8s.io/docs/user/known-issues/#pod-errors-due-to-too-many-open-files too raise the instances and watches values helps and the cilium connectivity test goes through.

I'm a little confused here though. Using e.g. > https://github.com/fatso83/dotfiles/blob/master/utils/scripts/inotify-consumers to view the inotify values for fs.inotify.max_user_watches and fs.inotify.max_user_instances fixes it as I state above. However, this have never been an issue before.
So I looked further and:
Apparently the default fs.inotify.max_user_watches on Ubuntu 20.04 is higher.
# sysctl fs.inotify.max_user_instances fs.inotify.max_user_watches
  fs.inotify.max_user_instances = 128
  fs.inotify.max_user_watches = 131596

# lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:    Ubuntu 20.04.4 LTS
  Release:        20.04
  Codename:       focal

Whereas on Ubuntu 22.04.1 is:
# sysctl fs.inotify.max_user_instances fs.inotify.max_user_watches
  fs.inotify.max_user_instances = 128
  fs.inotify.max_user_watches = 92513

# lsb_release -a
   No LSB modules are available.
   Distributor ID: Ubuntu
   Description:    Ubuntu 22.04.1 LTS
   Release:        22.04
   Codename:       jammy

So I'm writing the above to know if anyone else has experienced this on Ubuntu Kubernetes nodes and what people have done to potentially solve this.
Thank you

@jspaleta Where can the error you pasted be observed? How exactly does this cause the connectivity tests to fail?
We've seen random flakes connecting to echo-other-node in CI, so I'm wondering if this is failing silently behind the curtains somewhere bugtool/sysdump can't see it. Is this in kubelet logs, by any chance?
Maybe we need to investigate ways of grabbing kubelet logs in CI?
cc @brb as resident kind expert

I encountered this problem when I run the connectivity test locally, and I needed to increased the fs.inotify limits.
https://kind.sigs.k8s.io/docs/user/known-issues/#pod-errors-due-to-too-many-open-files
# Run connectivity test locally due to the too  many open files error
$ cilium connectivity test --include-unsafe-tests --collect-sysdump-on-failure \
  --sysdump-hubble-flows-count=1000000 --sysdump-hubble-flows-timeout=5m

# Some pods in cilium-test ns are failing
$ kubectl -n cilium-test get po
NAME                                  READY   STATUS             RESTARTS       AGE
client-6b4b857d98-5ksg2               1/1     Running            0              4m47s
client2-646b88fb9b-pb8hn              1/1     Running            0              4m46s
echo-external-node-545d98c9b4-ntb76   0/1     CrashLoopBackOff   5 (104s ago)   4m46s
echo-other-node-66bdd89578-4r9wl      1/2     CrashLoopBackOff   5 (98s ago)    4m46s
echo-same-node-55db76dd44-smblz       1/2     CrashLoopBackOff   5 (81s ago)    4m47s
host-netns-9gk5m                      1/1     Running            0              4m46s
host-netns-dmpfn                      1/1     Running            0              4m46s
host-netns-non-cilium-zwrpj           1/1     Running            0              4m46s
host-netns-rzz2j                      1/1     Running            0              4m46s

$ kubectl -n cilium-test logs echo-other-node-66bdd89578-4r9wl
Defaulted container "echo-other-node" out of: echo-other-node, dns-test-server

  \{^_^}/ hi!

  Loading /default.json
  Loading /middleware.js
  Done

  Resources
  http://:8080/private
  http://:8080/public
  http://:8080/auth-header-required

  Home
  http://:8080

  Type s + enter at any time to create a snapshot of the database
  Watching...

Error: EMFILE: too many open files, watch '/'
    at FSWatcher.<computed> (node:internal/fs/watchers:247:19)
    at Object.watch (node:fs:2350:36)
    at /usr/local/lib/node_modules/json-server/lib/cli/run.js:181:10 {
  errno: -24,
  syscall: 'watch',
  code: 'EMFILE',
  path: '/',
  filename: '/'
}

Any takes for adding this to docs and making sure we get this right in our CI setup(s)?

Can we replace the json-server with e.g., https://github.com/chanioxaris/json-server?

Documentation about this issue seems to be absent from this page.
I just had the problem, and that's what got me here.


[gsl-lite] update to 0.37.0

What does your PR fix? Update gsl-lite to version 0.37.

Does your PR follow the maintainer guide? Yes (I think)

/azp run

Cools, thanks @mbeutel :)


Confusing sentence

"Service Fabric is a microservices platform that gives every microservice (or container) a unique name that can be either stateless or stateful."
I'm assuming this sentence was meant to explain 1. that microservices have unique names and 2. that they can be either stateless or stateful, but the wording is very unclear.

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

ID: 160326f9-6daa-81be-913b-68f965950964
Version Independent ID: 373b46cd-e1ea-ee72-33cc-7d831af4dc35
Content: Overview of Service Fabric on Azure
Content Source: articles/service-fabric/service-fabric-overview.md
Service: service-fabric
GitHub Login: @athinanthny
Microsoft Alias: atsenthi

@DianeHadley Thanks for your feedback. We are checking on this and will respond to you soon.

@DianeHadley I am assigning the issue to the author.
@athinanthny Can you please look into this issue and update the document as required.

@DianeHadley  Thanks for your feedback. please apply your comments/changes to doc  and create PR.

#please-close


spyder 2.3.0 won't start

From<EMAIL_ADDRESS>on 2014-07-18T13:01:45Z
I am trying to install spyder 2.3.0 on Fedora 20 (Heisenbug).
When I try to run spyder, I get the following output:
#####################################################################################
[nate@fedora-home ~]$ spyder
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/spyderlib/spyder.py", line 2333, in main
mainwindow = run_spyder(app, options, args)
File "/usr/lib/python2.7/site-packages/spyderlib/spyder.py", line 2221, in run_spyder
main.setup()
File "/usr/lib/python2.7/site-packages/spyderlib/spyder.py", line 768, in setup
message=_("DON'T USE THIS CONSOLE TO RUN CODE!\n\n"
File "/usr/lib/python2.7/site-packages/spyderlib/plugins/console.py", line 74, in init
self.find_widget.set_editor(self.shell)
File "/usr/lib/python2.7/site-packages/spyderlib/widgets/findreplace.py", line 261, in set_editor
from spyderlib.qt.QtWebKit import QWebView
File "/usr/lib/python2.7/site-packages/spyderlib/qt/QtWebKit.py", line 10, in <module>
from PyQt4.QtWebKit import *  # analysis:ignore
ImportError: libQtWebKit.so.4: cannot open shared object file: No such file or directory
#####################################################################################
I get the same result whether I install spyder from the yum repository or from pip.
I am running Python 2.7.5 (default, Jun 25 2014, 10:19:55)
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2
My machine has PyQt4 4.10.2 installed.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1897

From contrebasse on 2014-07-19T13:06:59Z
I remember having this problem on centos too. I created a bug report for Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=1121360

From<EMAIL_ADDRESS>on 2014-07-18T12:02:07Z
Problem solved. I just needed to install qtwebkit. I discovered this by running:
yum whatprovides "*/libQtWebKit.so.4"

From ccordoba12 on 2014-08-17T10:19:52Z
Out of our reach. I hope Fedora guys fix it.
Status: Invalid

From contrebasse on 2014-07-31T04:19:06Z
THe bug should be fixed, could you confirm that the dependancy was added in Fedora ?

From contrebasse on 2014-08-20T00:18:57Z
Actually, qtwebkit is already a dependancy of spyder via PyQt4 in fedora20. installing from yum should have installed it.


Update needed: Getting Ahead

The new quest Getting Ahead added a new boss to the NMZ. The plugin doesn't recognize it.

Thanks, I haven't been subscribed for a while but I'll push a fix :)

This has now been merged into the plugin-hub repo, should be fixed.


Unable to drag and drop files from Explorer to VSCode when running as different user

VSCode Version: Code 1.18.1 (929bacba01ef658b873545e26034d1a8067445e9, 2017-11-16T18:32:36.023Z)
OS Version: Windows_NT x64 10.0.15063
Extensions:

Extension
Author (truncated)
Version

npm-intellisense
chr
1.3.0

path-intellisense
chr
1.4.2

vscode-mocha
Com
0.1.1

vscode-eslint
dba
1.4.3

vscode-npm-script
eg2
0.3.3

auto-close-tag
for
0.5.3

code-runner
for
0.8.4

rest-client
hum
0.16.1

search-node-modules
jas
1.2.0

prettify-json
moh
0.0.3

cpptools
ms-
0.14.2

csharp
ms-
1.13.1

sublime-keybindings
ms-
3.0.3

vscode-arduino
vsc
0.2.10

nodejs-extension-pack
wad
0.1.9

JavaScriptSnippets
xab
1.5.0

(1 theme extensions excluded)

Steps to Reproduce:

Open VSCode. Open an Explorer Window.
Try to drag and drop a file into the editor window.
A "no drop" cursor appears.

Reproduces without extensions: Yes/No

@chengkiang are you running VS Code as admin?

@bpasero I tried running both as admin and regular user but it doesn't seem to make a difference. I remember I could drag and drop in older versions...

@chengkiang can you record a screencast and share it of how this works for you?

@bpasero Here is a screencast of the issue.

@chengkiang yeah weird. I have only seen that happening if the user that runs VS Code does not have permissions to open the file that is being dragged. Does this happen with any file?

@bpasero Yeah, it rejects whatever file I drag to it. I did more experiments, and found that opening VS Code by clicking on the pinned taskbar icon lets me drag and drop without issues. This seems to happen only if I run it from the command line.
I tried the same with Sublime Text and it does not appear to have this issue, either.

@chengkiang maybe from the command line you execute it as admin because the command line is running as admin?

+1 same issue

+1 same issue

+1 same issue - with clean Windows 10 installation. As admin and no

Windows 10, when I run VSC as administrator mode, I have the same problem.
As normal mode, no drag and drop file problem, but a lot of other problems occurs, such as:
Python intellisense only work under administrator mode.....

+1 same issue. Clean Windows - logged in as administrator.
Cannot drag and drop when running vscode as admin. Only when running as normal user.

I can't drag and drop neither as administrator or as normal account.

Same here, I am unable to drag and drop, neither as admin nor as regular user, I am on windows 10.

Any progress on this issue??

+1 same issue

same issue .
I switch from install version to portable.
If I don't run as admin , I can't open vscode.  But run as admin come to this issue.

Win10, Run VSC as Admin, Drag & Drop doesn't work. Ready to provide more diagnostic info.

Same issue, isolated to portable version, ran as admin or not

+1 Same issue. Win10, Run VSC as Admin, Drag & Drop doesn't work. I can provide more details if needed too.

+1 Same issue here when running VSC as admin

+1 Same issue, Win 10, run as admin.

Same problem also when admin, work fine when not.

Same problem here.
No Drag&Drop when I run VS Code as admin.
When VS Code is running with my normal privileges, everything works fine.

Same issue. Windows 10, running VSCode as admin

Same issue. Windows 10, run as admin.

Same problem - regardless how how VSCode is started.

Same problem here.
Win10, running VSCode as admin.
Drag & Drop doesn't work but File > Open, yes.

+1 Same issue, Win 10, run as admin.

uncheck 'run as administrator' solved the problem.

Wow. Surprised to see this issue persists. Ran as admin, same here. Weird because it works on my instructor's vid.

+1 Same issue here. Running VS Code as Administrator. Not possible to drag-and-drop files from Explorer into an open VS Code instance. My user account is Administrator (has Administrator privileges).
We have no other option unfortunately, because we need to run our solution in Visual Studio 2015 as Administrator, too, and our website projects are deployed to our local IIS instance.

Everyone please upvote this Electron issue that is the root cause it seems: https://github.com/electron/electron/issues/12460

You can't really achieve this "safely" in Windows. In the NT days, everything in terms of processes on the same machine ran with the same security token and had all the same privileges. UAC (in Vista) changed this by allowing processes with different integrity levels to run on the same machine.
This requires defense against elevation of privilege attacks, see Mandatory Integrity Control: http://msdn.microsoft.com/en-us/library/bb625957.aspx
MIC prevents a user process from accessing protected locations like Program Files or the HKLM registry hive, see http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx
In regards to the drag and drop issue, the technology preventing it is User Interface Privilege Isolation http://msdn.microsoft.com/en-us/library/aa480152.aspx#appcomp_topic21
UIPI blocks Windows messages being sent from process with a lower MIC level to one running at a higher MIC level. Drag-and-drop is implemented via Windows messages.
If you try and drag-and-drop a file from Windows Explorer (it runs in Medium integrity mode) to Electron running elevated (high MIC integrity mode), the Windows messages are blocked and drag-and-drop doesn’t work.
Technically, experiments can be made with ChangeWindowMessageFilterEx, but this will expose the security integrity of Electron. https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-changewindowmessagefilterex

Thanks @SharePointRadi for the very detailed and substantiated analysis!
To verify your statements I tried to open files in an instance of Notepad++ running in Admin mode.
Result:

Drag&Drop does NOT work in Notepad++ either!
Opening a file via context menu DOES work in NP++ running in Admin mode, while it fails in VS Code.

Establishing the latter in VS Code / Electron would be a great help for everyday work.

+1 Same issue, Win 10, run as admin.

+1 Same Issue Here!!!!!!. That is make me crazy bro.
win 10, vscode 1.40.2. and admin used!

I recently switched from linux to windows and I'm currently facing this annoying issue too :/

Same problem. Win 10, Electron.js 6

I have same issue only when Run As Admin
Version: 1.41.0 (user setup)
Commit: 9579eda04fdb3a9bba2750f15193e5fafe16b959
Date: 2019-12-11T18:37:42.077Z
Electron: 6.1.5
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Windows_NT x64 10.0.17134

This does not repro on the latest atom.io editor FWIW. I have tried Run as Admin and non-elevated with the same result.

this is happening with me only I open project from cmd with command  'code .' , open project from VS code shortcut your problem will be solved automatically

I have the same problem running Windows 10 and as Administrator. I can't drag and drop files into the file explorer inside VS Code

Fixed !

Uninstall the bul**hit "user" version
Install the "system" version of VS Code.

Right click to the vs code and click pin to taskbar if you wanna use it (drag and drop)

Same thing here when I launch VS Code from the new PowerToys app "Run". Disabling "always run as administrator" inside PowerToys fixes the issue.
It seems to be something about running VS Code as admin.

I've same issue on the Windows 10 and also after opening VS Code as Administrator

Facing Same Issue, it worked in previous version.

Here's the step on how I fix this issue:

Navigate to where your vs code is installed. Usually is on this path:
C:\Users\[user]\AppData\Local\Programs\Microsoft VS Code.
Make sure to update [user] with your correct user name.
Right-click on Code.exe and select Properties.
Navigate to the Security tab and select the Advanced button on the bottom.
It will open a modal called:
Advanced Security Settings for Code.exe
By default, the value of Owner is the Administrator click on the Change link to change it.
It will open another modal called:
Select User or Group
On the Enter the object name to select field, just type your user name.
Click on OK, Apply, and thenOK* again.
Close and re-open vs code. The Drag-and-Drop files should work now.

Happy to help the community ✌

@genesisneo Not OK...

As was mentioned before, this issue happens due different permissions for VSCode and explorer.
**FIX:

Do not uninstall VSCode from computer(if don't want to destroy your cfg)
Download ZIP version of VSCode(portable version)
Unzip it to your USER folder(C:\Users$userName)**

Now you can create shortcut of Code.exe and move wherever you want.
VSCode will use existing cfg files, so you don't need to configure it again.

1 same issue, ubuntu 20.04 LTS, vscode version 1.50

I also have this issue on Ubuntu 20.04 with Vscode version 1.51.1

Have this issue. I cannot drag-n-drop files, but I can load them through the File > Open menu. This is not very efficient.

The upstream issue has been closed for reasons mentioned in https://github.com/microsoft/vscode/issues/38999#issuecomment-546598939 , vscode cannot fix this. Closing as non-actionable.


comment formatting

There have already been a few issues about comments in coffeescript. I was wondering what you might think about allowing documentary comments in coffeescript.
/**
 * blocks like these are being used by tools like yuidoc
 *
 */

###
# however in coffeescript you would expect something like this
#
###

###
 * not something like this
 *
###

Means it would be cool if leading '#'s inside a block comment would be turned ' *'.
What do you thing about that?

I'm not a fan of fancy/strange comment ornamentation. Personally, I'd prefer a language where the only kind of comment is a single character that leads a line.
# Like
# this
# does.

... CoffeeScript also has block comments -- mostly for consistency with block strings and block regexes, but also to allow you to pass comments through to the compiled JS. Changing the way comments work for a particular documentation tool isn't going to happen.

Related: #1050

what I actually meant whats that, in order to get the first block I wrote you need to write the third one
but it would be nice if coffee-script would turn a leading "#" within a block comment into a "".
This is also because vim for example automatically writes a # at a new line within a block comment, so you always have the second kind of block in there. but after that has been turned into javascript it will look like this
/
# inconsistent comment style
*/


stream: reuse buffers

After our call a couple of days ago where it was pointed out how the 300kb buffer for the line reader gets allocated up front I had a sort of nightmare about the overhead per http request to the APM Server and wanted to look into if it was worth to reuse the buffers between requests. For large requests, the cost of the allocation is not significant, but for many small requests there is a speedup.
While experimenting, I took the rate limiting out of the benchmark and changed it to use the 300kb default line length, as you can see below.  Rate limiting is only in effect in RUM, so the number here would correspond to the data from backend agents.
This change makes the code more complex and I expect the overhead in beats for JSON serializing etc. (which are not measured in this benchmark) might make the gains here less attractive, but it's worth a discussion.
ns/op:
benchmark                                                   old ns/op     new ns/op     delta
BenchmarkStreamProcessor/errors.ndjson-4                    280910        200638        -28.58%
BenchmarkStreamProcessor/events.ndjson-4                    146007        88538         -39.36%
BenchmarkStreamProcessor/heavy.ndjson-4                     24615514      25014177      +1.62%

MB/s:
benchmark                                                   old MB/s     new MB/s     speedup
BenchmarkStreamProcessor/errors.ndjson-4                    15.67        21.94        1.40x
BenchmarkStreamProcessor/events.ndjson-4                    6.90         11.37        1.65x
BenchmarkStreamProcessor/heavy.ndjson-4                     16.19        15.93        0.98x

$ benchcmp old.txt new.txt
benchmark                                                   old ns/op     new ns/op     delta
BenchmarkStreamProcessor/errors.ndjson-4                    280910        200638        -28.58%
BenchmarkStreamProcessor/events.ndjson-4                    146007        88538         -39.36%
BenchmarkStreamProcessor/heavy.ndjson-4                     24615514      25014177      +1.62%
BenchmarkStreamProcessor/invalid-event.ndjson-4             121174        61915         -48.90%
BenchmarkStreamProcessor/invalid-json-event.ndjson-4        98437         43323         -55.99%
BenchmarkStreamProcessor/invalid-json-metadata.ndjson-4     46482         7196          -84.52%
BenchmarkStreamProcessor/invalid-metadata-2.ndjson-4        44754         6398          -85.70%
BenchmarkStreamProcessor/invalid-metadata.ndjson-4          52331         11085         -78.82%
BenchmarkStreamProcessor/metadata-null-values.ndjson-4      101302        41591         -58.94%
BenchmarkStreamProcessor/metricsets.ndjson-4                131967        74594         -43.48%
BenchmarkStreamProcessor/minimal-service.ndjson-4           98320         43179         -56.08%
BenchmarkStreamProcessor/only-metadata.ndjson-4             89040         39160         -56.02%
BenchmarkStreamProcessor/optional-timestamps.ndjson-4       138138        83302         -39.70%
BenchmarkStreamProcessor/ratelimit.ndjson-4                 374608        296282        -20.91%
BenchmarkStreamProcessor/spans.ndjson-4                     221895        160157        -27.82%
BenchmarkStreamProcessor/transactions.ndjson-4              214398        158546        -26.05%
BenchmarkStreamProcessor/unrecognized-event.ndjson-4        75768         29123         -61.56%

benchmark                                                   old MB/s     new MB/s     speedup
BenchmarkStreamProcessor/errors.ndjson-4                    15.67        21.94        1.40x
BenchmarkStreamProcessor/events.ndjson-4                    6.90         11.37        1.65x
BenchmarkStreamProcessor/heavy.ndjson-4                     16.19        15.93        0.98x
BenchmarkStreamProcessor/invalid-event.ndjson-4             6.32         12.37        1.96x
BenchmarkStreamProcessor/invalid-json-event.ndjson-4        5.96         13.55        2.27x
BenchmarkStreamProcessor/invalid-json-metadata.ndjson-4     9.85         63.64        6.46x
BenchmarkStreamProcessor/invalid-metadata-2.ndjson-4        10.01        70.01        6.99x
BenchmarkStreamProcessor/invalid-metadata.ndjson-4          8.73         41.23        4.72x
BenchmarkStreamProcessor/metadata-null-values.ndjson-4      4.91         11.95        2.43x
BenchmarkStreamProcessor/metricsets.ndjson-4                6.71         11.88        1.77x
BenchmarkStreamProcessor/minimal-service.ndjson-4           4.32         9.84         2.28x
BenchmarkStreamProcessor/only-metadata.ndjson-4             6.28         14.27        2.27x
BenchmarkStreamProcessor/optional-timestamps.ndjson-4       7.43         12.33        1.66x
BenchmarkStreamProcessor/ratelimit.ndjson-4                 11.24        14.22        1.27x
BenchmarkStreamProcessor/spans.ndjson-4                     11.97        16.58        1.39x
BenchmarkStreamProcessor/transactions.ndjson-4              13.18        17.82        1.35x
BenchmarkStreamProcessor/unrecognized-event.ndjson-4        5.16         13.43        2.60x

benchmark                                                   old allocs     new allocs     delta
BenchmarkStreamProcessor/errors.ndjson-4                    946            943            -0.32%
BenchmarkStreamProcessor/events.ndjson-4                    377            374            -0.80%
BenchmarkStreamProcessor/heavy.ndjson-4                     134559         134556         -0.00%
BenchmarkStreamProcessor/invalid-event.ndjson-4             270            266            -1.48%
BenchmarkStreamProcessor/invalid-json-event.ndjson-4        199            196            -1.51%
BenchmarkStreamProcessor/invalid-json-metadata.ndjson-4     29             27             -6.90%
BenchmarkStreamProcessor/invalid-metadata-2.ndjson-4        24             22             -8.33%
BenchmarkStreamProcessor/invalid-metadata.ndjson-4          52             49             -5.77%
BenchmarkStreamProcessor/metadata-null-values.ndjson-4      178            175            -1.69%
BenchmarkStreamProcessor/metricsets.ndjson-4                296            293            -1.01%
BenchmarkStreamProcessor/minimal-service.ndjson-4           201            198            -1.49%
BenchmarkStreamProcessor/only-metadata.ndjson-4             212            209            -1.42%
BenchmarkStreamProcessor/optional-timestamps.ndjson-4       388            385            -0.77%
BenchmarkStreamProcessor/ratelimit.ndjson-4                 1448           1444           -0.28%
BenchmarkStreamProcessor/spans.ndjson-4                     767            764            -0.39%
BenchmarkStreamProcessor/transactions.ndjson-4              657            654            -0.46%
BenchmarkStreamProcessor/unrecognized-event.ndjson-4        128            126            -1.56%

benchmark                                                   old bytes     new bytes     delta
BenchmarkStreamProcessor/errors.ndjson-4                    361917        55556         -84.65%
BenchmarkStreamProcessor/events.ndjson-4                    334515        25106         -92.49%
BenchmarkStreamProcessor/heavy.ndjson-4                     7744681       7452358       -3.77%
BenchmarkStreamProcessor/invalid-event.ndjson-4             327101        17011         -94.80%
BenchmarkStreamProcessor/invalid-json-event.ndjson-4        324075        13841         -95.73%
BenchmarkStreamProcessor/invalid-json-metadata.ndjson-4     313344        2157          -99.31%
BenchmarkStreamProcessor/invalid-metadata-2.ndjson-4        313184        1987          -99.37%
BenchmarkStreamProcessor/invalid-metadata.ndjson-4          314585        3320          -98.94%
BenchmarkStreamProcessor/metadata-null-values.ndjson-4      322977        12370         -96.17%
BenchmarkStreamProcessor/metricsets.ndjson-4                330364        20481         -93.80%
BenchmarkStreamProcessor/minimal-service.ndjson-4           325331        15142         -95.35%
BenchmarkStreamProcessor/only-metadata.ndjson-4             325320        15047         -95.37%
BenchmarkStreamProcessor/optional-timestamps.ndjson-4       334785        25205         -92.47%
BenchmarkStreamProcessor/ratelimit.ndjson-4                 393111        86351         -78.03%
BenchmarkStreamProcessor/spans.ndjson-4                     353608        46186         -86.94%
BenchmarkStreamProcessor/transactions.ndjson-4              349446        41338         -88.17%
BenchmarkStreamProcessor/unrecognized-event.ndjson-4        321277        10633         -96.69%

Builds on https://github.com/elastic/apm-server/pull/1473

Proper PR is here: https://github.com/elastic/apm-server/pull/1505