[meta] Tracking issue for Node.js/Deno standard library inspired functions to include in @tauri-apps/api

I will be refactoring our js api and aiming to make the it more familiar to users coming from electron/js-land so it is easier to migrate.
Some of current functions will be deprecated and removed when new variants are released.
We want to gather some feedback from users and which functions they want to add from the Nodejs standard library, so comment below and I will add them to this list of new functions:

os module

[x] EOL
[x] platform()
[x] version()
[x] tempdir()
[ ] hostname

path module

[x] join()
[x] normalize()
[x] resolve()
[x] sep
[x] delimiter
[x] dirname()
[x] basename()
[x] extname()
[x] isAbsolute()

fs module

[ ] create()
[ ] open()
[ ] close()
[ ] FsFile class
[ ] writeFile()
[ ] writeTextFile()
[ ] readFile()
[ ] readTextFile()
[ ] copyFile()
[ ] readDir()
[ ] mkdir()
[ ] remove()
[ ] rename()
[ ] exists()

net module

[ ] createConnection()

dns module

Suggestion : get complete directory tree as JSON from a given folder, along with files with their metadata
getFileTree('dir')

Suggestion : get complete directory tree as JSON from a given folder, along with files with their metadata
getFileTree('dir')

Sorry, I am gonna accept only functions from Nodejs standard library for now.
Once I am done with this, I think I will make a plugin for extended api and will accept suggestion for anything

It would be great to have 'net.createConnection' from the Net API so that discord-rpc can work.
I would be happy to make an example project that can be tested with if needed.

It would be great to have 'net.createConnection' from the Net API so that discord-rpc can work.

I added createConnection to the list for now, but I will ask @nothingismagick , our security expert, if it is okay to include it or not since it will deal with sockets.

I would be happy to make an example project that can be tested with if needed.

I will try to do my best but I am not sure if this will be a drop in replacement for the NodeJS one.

Would be nice to have  a synchronous api to access to files in a way that allows open/read/write/close (as mentions here https://github.com/tauri-apps/tauri/issues/1025) to directly read/write large files without copying them into memory:
Something like https://github.com/emscripten-core/emscripten/blob/main/src/library_nodefs.js

Would be nice to have  a synchronous api to access to files in a way that allows open/read/write/close (as mentions here https://github.com/tauri-apps/tauri/issues/1025) to directly read/write large files without copying them into memory:
Something like https://github.com/emscripten-core/emscripten/blob/main/src/library_nodefs.js

A synchronous api is not possible, but I will add nodejs async function open which returns a FileHandle class

A synchronous api is not possible, but I will add nodejs async function open which returns a FileHandle class

Sorry, a bit off-topic but Is that a design decision or technically impossible?

I will be refactoring our js api and aiming to make the it more familiar to users coming from electron/js-land so it is easier to migrate

Since electron offers sync fs it will be difficult to migrate. Are there ways to customize/extend tauri make a sync fs available in a webworker?

Sorry, a bit off-topic but Is that a design decision or technically impossible?

yeah it is a kinda impossible technically.

Since electron offers sync fs it will be difficult to migrate. Are there ways to customize/extend tauri to make a sync fs available in a webworker?

you can wrap your logic in an async function and await our api calls.
here is an example using an async IIFE.
(async () => {
	doSomething();
	let file = await fs.readFile();
	doSomethingWithFile(file);
})();

Sorry, a bit off-topic but Is that a design decision or technically impossible?

yeah it is a kinda impossible technically.

Since electron offers sync fs it will be difficult to migrate. Are there ways to customize/extend tauri to make a sync fs available in a webworker?

you can wrap your logic in an async function and await our api calls.
here is an example using an async IIFE.
(async () => {
	doSomething();
	let file = await fs.readFile();
	doSomethingWithFile(file);
})();

Regarding sync function calls, I do understand the technical limitations on why promises must be used. But just in case, it is possible to emulate (though inefficiently) a blocking synchronous function in JS from an asynchronous function. This can be done as follows:
const syncFunctionNotDoneSymbol = Symbol(/* named, if you prefer */);
let valueToBeReturned = syncFunctionNotDoneSymbol;

export function syncFunction() {
    asyncFunctionCall().then(result => valueToBeReturned = result);

    while(valueToBeReturned === syncFunctionNotDoneSymbol) {
        // burn CPU cycles...
    }

    // Reset the value, so subsequent function calls still work.
    let val = valueToBeReturned;
    valueToBeReturned = syncFunctionNotDoneSymbol;

    return val;
}

Two important things to note on my primitive implementation above:

The functionality can be made into a simple helper function to convert any async function into a sync one (haven't looked in NPM to see if such a disgrace already exists...
I am not sure if my above implementation works if the function is called from worker threads, as I don't know if the symbol definition is re-evaluated when called from another thread context. Though it is definitely possible to make it work if it doesn't by default by using a simple array as a sort of concurrent queue for the symbols. If you would like me to show you an example, let me know.

It would also be a good idea, if such functionality is desired, to add a disclaimer in the sync function docs where you heavily discourage their use, due to them eating CPU cycles polling for the promise. But it might serve as a simple shim for large code bases until they are ported over.

Regarding sync function calls, I do understand the technical limitations on why promises must be used. But just in case, it is possible to emulate (though inefficiently) a blocking synchronous function in JS from an asynchronous function. This can be done as follows:

The impossible part isn't exposing a sync api, it was the other part of the request.

to directly read/write large files without copying them into memory

This is difficult in the current design because we use message passing to communicate with the WebView, meaning Rust loads the file and passes the bytes over to the webview into JS where it is consumed. To do that without copying into memory, there would need to be a way from JavaScript to directly load a file from the filesystem through the native WebView. Browsers don't have this, and AFAIK the native WebView libraries we use don't expose some way to do this.
As for your sync version of async methods, I'm not sure if we will expose pseudo sync functions. IMO it matters less to have them since all the supported browsers have await. If we don't expose them, it could still be a simple/contained package that wraps the async api. I also think that the JavaScript Generator API would more succinctly allow you to turn it into a sync call.

Thank you for your thoughts and insight, but ...

This is difficult in the current design because we use message passing to communicate with the WebView, meaning Rust loads the file and passes the bytes over to the webview into JS where it is consumed

excuse the heresy - this is pretty much what I can do already in a good old browser: Ask for a file, load it entirely into memory, process it and ask for a save-as dialog. This is fine for small files but let's say I'd like to process a 500MB geotiff then I'll soon hit the limitations of the browser (and tauri's).
The use-case I have in mind is running an emscripten compiled WebAssembly in a web worker to process local files. As of now I can not embed the wasm directly in rust (even if I could it has some advantages being able to run it within the webview). With electron I can run it in a worker and by setting nodeIntegrationInWorker: true the lib gets full read/write access to the filesystem.
I do not dare to ask for design changes but maybe there are ways to allow more customization on the rust level to inject an API (e.g. filesystem) in the worker context bypassing tauris async command (serde) api. Being able to combine WebAssembly, workers and tauri would create really interesting opportunities.

Thank you for your thoughts and insight, but ...

This is difficult in the current design because we use message passing to communicate with the WebView, meaning Rust loads the file and passes the bytes over to the webview into JS where it is consumed

excuse the heresy - this is pretty much what I can do already in a good old browser: Ask for a file, load it entirely into memory, process it and ask for a save-as dialog. This is fine for small files but let's say I'd like to process a 500MB geotiff then I'll soon hit the limitations of the browser (and tauri's).
The use-case I have in mind is running an emscripten compiled WebAssembly in a web worker to process local files. As of now I can not embed the wasm directly in rust (even if I could it has some advantages being able to run it within the webview). With electron I can run it in a worker and by setting nodeIntegrationInWorker: true the lib gets full read/write access to the filesystem.
I do not dare to ask for design changes but maybe there are ways to allow more customization on the rust level to inject an API (e.g. filesystem) in the worker context bypassing tauris async command (serde) api. Being able to combine WebAssembly, workers and tauri would create really interesting opportunities.

I agree with you, that would be a really interesting interface and I would love to see it someday soon. Electron is in a fortunate place regarding this due to controlling both the backend and a custom build of Chromium. We provide Wry by default in Tauri to support the "native" OS browser (iOS/macOS = WkWebView, Linux = webkit2gtk, Windows = webview2) which would require all those libraries to support such functionality, and then apply Tauri APIs over it.
As for regarding "this is pretty much what I can do already in a good old browser", that is relatively true. Browsers will let you open a local file from a prompt, some experimental APIs will even let you do it without a prompt, if the files are in the correct directory.
These types of things can likely be implemented by a Tauri plugin, but only if the underlying platform supports it. I haven't look into it at all, but if you are interested in it then the results may be fruitful.
Additionally, if you did want to support a custom runtime including things like preventing copying memory when reading large files, then you can implement Runtime from tauri-runtime as the backend of your Tauri application. It does take a decent chunk of work to implement your own runtime, so beware if you decide to do so.

I don't see it listed as a task (or maybe I misread), but adding file permissions when writing a file (not after the fact - race condition) would help tremendously for electron apps that needed to store sensitive data (e.g. passwords, secrets) that are not readable by groups or others.
Example:
// mode should be configurable, just showing as an example:
File::with_options().mode(600).open("somefile.txt");

@zoombinis it is listed under fs section, all current functions will have new overloads that is similar to nodejs standard library, with support for file permissions

I really need the net.createConnection method for my app. How quick much work would it be to implement that? Could someone with little Rust experience implement it? Would love to help with that if it means I can use Tauri instead of Electron for my app!

@Lancear we are in a code-freeze phase and there won't be any new features to Tauri v1, so any new features will land in Tauri v2 check #2060 for more info.
With that said, I gotta warn you, we might not be able to exactly replicate NodeJS' net.createConnection() but we will try our best. I also wanna note that fs module has higher priority than net module so it might be a while until we start on it.

Just had a thought that maybe the dns module might be a good fit for this too as this can't be archived using webapis. Of course lower priority than os, path and fs but once we get around to the net stuff having dns would be cool too.
Spinning this further a plugin (core or not) could provide similar apis for mdns in the future

Just had a thought that maybe the dns module might be a good fit for this too as this can't be archived using webapis.

Sure let me add it to the list

Of course lower priority than os, path and fs but once we get around to the net stuff having dns would be cool too.

os and path are already done. fs is a different beast and won't add it in tauri v1 anyway so dns and net would also be planned for tauri v2

The more NodeJS api to include the better, it's much easier and convenient for tauri users to write app logic in js layer than in rust layer.

Just adding my feedback here: We'd love to have access to os.hostname. Specifically, we'd be using it to generate more descriptive device names for things like listing active sessions, trusted devices etc.

Hello,
I would also like to request the ability to read a file line by line, like the following in Node :
import {
    createReadStream
} from 'node:fs';
import {
    createInterface
} from 'node:readline';
for await (const line of createInterface({
    input: createReadStream(
        path,
        {
            flags: 'a+'
        }
    ),
    crlfDelay: Infinity
})){
    // TODO something with `line`
}

Not necessarily by implementing exactly the same modules and methods as long as it does the same thing.
Thanks

@KaKi87 thanks for the suggestion, it has now been implemented in the linked PR and will look like this:
const lines = await readTextFileLines('file.txt', { baseDir: BaseDirectory.App });
for await (let line of lines) {
  console.log(line);
}

Also, sine each line will be lazily read as you advance through the iterator, it makes this function perfect for performance critical apps as you can manually advance the iterator by calling .next() whenever you want.

Nice one @amrbashir

each line will be lazily read as you advance through the iterator, it makes this function perfect for performance critical apps

Exactly, thanks !

Any updates on the net api?

Does the fs module support streaming apis like:

fs.createReadStream
fs.createWriteStream
fs.readableWebStream

I was looking for ways to read files without loading the entire file into memory, but found issues like https://github.com/tauri-apps/tauri/issues/4133 and this one
Any workarounds for the current version of tauri?

Any workarounds for the current version of tauri?

If you need it that bad, then you could call an external tool (maybe cat) using shell.Command.

@KaKi87 that’s great for reading files!  Do you have a workaround for writing files too?

echo.

Ahh, I was looking at the Command interface, not the Child interface.  My bad.  Thank you @KaKi87!

Actually, with echo, it isn’t possible to add the redirect to send the content to a file.  Plus, with cross-platform scripts, it becomes even more challenging.  It may be easiest to include a two sidecar binaries:

one that reads a file, converts the binary to hex, and prints hex
one that reads hex, converts it to binary, and writes it to a file

I hope that a streaming version of file reading/writing can be added to the tauri fs library

Actually, with echo, it isn’t possible to add the redirect to send the content to a file.

You can, using bash -c.

Plus, with cross-platform scripts, it becomes even more challenging.

Indeed, my proposal should work as much on Mac as it does on Linux, but different commands would for sure be required on Windows.

It may be easiest to include a two sidecar binaries

Of course. That, or writing Rust code.

any plans for child_process module support?
I find that whatever apps I write, I always end up using
child_process due to how easy it is to just CLI a solution
quickly and then Worry about writing proper library
bindings later if the app is actively developed and maintained.

@adminy  We already have this, see https://tauri.app/v1/api/js/shell

We decided to most of the JS APIs into its own plugins in https://github.com/tauri-apps/plugins-workspace, most of the APIs proposed here are already implemented there or waiting for merge. The fs changes will have to wait for #6107.

where's the documentation for the fs-extra plugin ?

fs-extra plugin has been removed and its functionality has been integrated into tauri-plugin-fs for v2. The documentation is still WIP.

So, concretely, where will the readTextFileLines method be available ?

That will be implemented in tauri-plugin-fs for v2 possibly with #6107

So it will never be available in v1 ?

Not planned atm but it can be implemented in your app:

The function in typescript

async function readTextFileLines(
  path: string
): Promise<AsyncIterableIterator<string>> {

  return Promise.resolve({
    path,
    rid: null as number | null,
    async next(): Promise<IteratorResult<string>> {
      if (!this.rid) {
        this.rid = await invoke<number>('read_text_file_lines', { path: this.path })
      }

      const [line, done] = await invoke<number>('read_text_file_lines_next', { rid: this.rid })

      // an iteration is over, reset rid for next iteration
      if (done) this.rid = null

      return {
        value: done ? '' : (line as string),
        done
      }
    },
    [Symbol.asyncIterator](): AsyncIterableIterator<string> {
      return this
    }
  })
}

The command in rust

#[tauri::command]
fn read_text_file_lines<R: Runtime>(app: AppHandle<R>, path: PathBuf) -> Result<u32, std::io::Error> {
    use std::io::{BufRead, BufReader};
    let file = File::open(path)?;
    let lines = BufReader::new(file).lines();

    let rid = 0 // generate a uniuqe ID for this request

	// Assuming you have a `ResourceTable` struct where you store your resources
	// and you stored it inside tauri state
	// by calling `app.manage(ResourceTable::new())` in the `setup` function

	// grab the resource table
    let mut resource_table = app.state::<ResourceTable>().inner().lock().unwrap();
    // store the lines iterator inside the resource table
    resource_table.insert(lines);

    // return the rid
    Ok(rid)
}

#[tauri::command]
fn read_text_file_lines_next<R: Runtime>(app: AppHandle<R>, rid: u32) -> Result<(Option<String>, bool), std::io::Error> {
    use std::io::Lines;

	// grab the resource table
    let mut resource_table = app.state::<ResourceTable>().inner().lock().unwrap();
    // get the stored lines iterator for this rid
    let lines = resource_table.get(&rid).unwrap();

    let ret = lines
      .next()
      .map(|l| (l.ok(), false))
      .unwrap_or_else(|| {
        let _ = resource_table.remove(&rid).unwrap();
        (None, true)
      });

    Ok(ret)
  }

Most of the APIs in this issue have been implemented in path module in @tauri-apps/api and in tauri-apps-plugin-fs starting 2.0.0-alpha.5
If there is any missing APIs, feel free to open an issue in plugins-workspace repo.

updates on net?

No work has been done on net module unfortunately, and it is not a priority atm.

I get path.isAbsolute not allowed. Command not found. Tauri version is 2.0.4, I have core:path:allow-is-absolute capability. Trying to check whether some system-wide path is absolute.


[Removal]:

Hotspot Name
Tart Orange Crab
Hotspot b58 Address
1129xFYm4VzesHcgdvTbkfMz9zv6PJW7gmPJgKVKpp9VrtESD3Di
Discord Handle
no idea (some kind of a tool?)
Hotspot Manufacturer
RAK
Removal Reason
i think i put it right.
Modifications
No
Extra forwarders
No
Extra antennas
Yes
Additional Information
i have two hotspots. one of them puts 5dB Antenna. another is default.
Hotspot Name: Cheerful Pineapple Whale
Hotspot b58 Address: 11LSigu5yMutGEUBCRFpoLg9sXQQuEXfhuSks6XnA5T8LXMyzAi
That's my setting of Cheerful Pineapple Whale

setting of Tart Orange Crab

closed? so, what should i do more?


Description:  Multiple elements were matched - waitfor Error

Describe the bug
    await waitFor(element(by.id("someID"))).toBeVisible();     await waitFor(element(by.id(someOtherID)).atIndex(0))         .toBeVisible()         .whileElement(by.id("someID"))         .scroll(200, "down");
results in
 "Description":  Multiple elements were matched:
when there are multiple "someOtherID" elements. It looks like it's ignoring atIndex
To Reproduce

[X ] I have tested this issue on the latest Detox release and it still reproduces

Provide the steps necessary to reproduce the issue. If you are seeing a regression, try to provide the last known version where the issue did not reproduce.
Perform a waitFor and a scroll for an element that displays multiple times on the screen
If possible, please provide a small demo project that reproduces the issue, or attach a video with the reproduction - this would be very appreciated.
Expected behavior
It should not throw Multiple Elements were matched error
Screenshots
Environment (please complete the following information):

Detox: 12.7.0
React Native: 57.3
Node: 10.14.2
Device: iPhone 7
Xcode: 10.2
iOS: 12.2
macOS: Mojave

We have a test in the demo suite that tests atIndex().
Please provide a clean project where this reproduces. Thanks


react-redux connect revamp

This is still very WIP and the API is not yet complete (API is now decent), so consider this more as a preview. For basic use cases with class based components these types works like a charm already (see tests).
Motivation for the rewrite is that currently connect libdefs are in really bad shape and doesn't catch if some of the required props are missing.
The main problem with this approach is that functional stateless components does not work like expected with this, see: https://github.com/facebook/flow/issues/5652 E: sorted out, now they works!
Second problem is that exact object types are hard to get work with this.
@GAntoine am I missing something or is there a bug in Flow with either in $Diff or react stateless functional component type definitions? E: Needed to use React.ElementConfig
E: This starts to be ready from my side.

I'm thinking about taking a stab at this as well. For me react-redux not working consistently is one of the main detractors to recommending flow more widely.
@villesau Are you still working on this? Do you have any updates?
Thank you!

@cprodescu yes I'm still working on this :) I've been busy with other things so haven't had time to push this forward. Next i'm going to implement mergeProps. Then i think it starts to be in decent shape. Note that the libdefs won't work with stateless functional components due to some Flow bug. I'd hope to get that fixed.

@villesau What does "won't work" mean? Will it leave things as they are or break them further?

@ancestorak It means that stateless components will not type check, you don't get any errors. So you can use stateless components but you don't get any help from Flow. See the issue and examples there: https://github.com/facebook/flow/issues/5652

@villesau Thank you for taking this on!
Out of the following requirements, which ones do you plan to tackle? Sorry for the verbosity, want to get an idea of which cases your solution plans to address.

Type-checking works when the class definition and usage are across different files.
Current react-redux interface fails here, not trigger most ExpectError tests if you just separate current test_connect.js code into 3 files:

component and prop definitions
connector definitions
usage of connected components

Type-checking works for class components with non-exact props
Type-checking works for class components with non-exact props and default props
Type-checking works for class components with exact props
Type-checking works for class components with exact props and default props
Type-checking works for stateless functions with non-exact props
Type-checking works for stateless functions with non-exact props and default props
Type-checking works for stateless functions with exact props
Type-checking works for stateless functions with exact props and default props

@cprodescu I'm sorry but type definitions with exact props won't work. That's a Flow limitation: spreading exact props doesn't work right now, see https://github.com/facebook/flow/issues/2405 . And also intersection between exact is impossible, e.g: {|a: number|} & {|b: number|} is impossible type: It can't match two exact types simultaneously. Thus, exact typing will not be supported any time soon at least. My approach is using intersection at least for now.
Stateless functional components will not give any errors until the bug in Flow is fixed. That's very unfortunate and my major concern with the approach. I still hope that when the types are in good enough shape otherwise, the bug will gain some traction on Flow side.
So:

Type-checking works when the class definition and usage are across different files.
Current react-redux interface fails here, not trigger most ExpectError tests if you just separate current test_connect.js code into 3 files:

component and prop definitions
connector definitions
usage of connected components

This is my number 1 goal. To get type checking working across different files by typing your functions and components props you pass to connect. And for class based components it's already the case, feel free to copy & paste the types and try out. Only mergeProps argument is missing. You can also check out the tests I've written so far, I hope they are more readable and understandable than the previous tests.

Type-checking works for class components with non-exact props

This will work

Type-checking works for class components with non-exact props and default props

Not sure, can you give an example of this?

Type-checking works for class components with exact props

This will not work, see above explanation

Type-checking works for class components with exact props and default props

can you give an example?

Type-checking works for stateless functions with non-exact props

I hope to get the bug fixed once the types are in good shape. These should work exactly like with class based components.

Type-checking works for stateless functions with non-exact props and default props

example needed

Type-checking works for stateless functions with exact props

This will not work

Type-checking works for stateless functions with exact props and default props

example needed

Would be really good if you could try out the definitions so that I get more feedback what works and what doesn't. So far my next goal is to take a look into mergeProps.

Flow complains Cannot create MySFC element because props [1] is incompatible with empty [2].
when using stateless functional components referencing
79│   declare function connect
(
So basically Flow infers stateless functional components as empty (?) with these libdefs.
Workaround for this is to write SFC like: const MySFC: React.ComponentType<Props> = (props: Props) =>
 which is suboptimal.
Any ideas?

Some known issues:

If your component is connected in different file where you pass mapStateToProps etc, libdefs doesn't work. You get Error:(40, 4) Cannot create MyComponent element because props [1] is incompatible with empty [2]. error. Flow bug? ( https://github.com/flowtype/flow-typed/issues/1331 )
In some rare cases where property is missing, error is shown in wrong place. Instead of component usage the error is shown where mapStateToProps etc is defined.
StatelessFunctionalComponents need to be separately typed like const MySFC: React.ComponentType<Props> = (props: Props) =>
 ( https://github.com/facebook/flow/issues/5652 ?)
exact types does not work ( https://github.com/facebook/flow/issues/2405 )
There is a case where inference chain gets broken: ( https://github.com/flowtype/flow-typed/pull/1731#discussion_r167033777 )

But regardless of the issues, I've been able to take the current version of libdefs into use for rather large React & redux code base. It's unfortunate that SFCs needs to be typed, but on the other hand with these libdefs i've been able to catch some real issues. If you write your react & redux like explained in the first list item, you might or might not be able to already get some benefit of this.

Just here to say that this refactor was well overdue and I'm very grateful that someone has decided to take this on - I've found the existing connect types almost entirely useless and the type-integrity of all of my apps breaks down at the boundary between components and containers.

@villesau I just smoke-tested this type-def in my current project and it works 1000x better than the existing type defs. It's uncovered dozens of potential defects I wouldn't have caught otherwise. I can't wait until these are merged! 🍾 🎉

@ryami333 Thanks for the encouraging feedback! To me these are now good enough at least for now, and we at Smartly are already using exactly this version of the libdefs :) For other usages i've been waiting for feedback and e.g options is pretty good catch already!
The test errors comes from previous libdefs, as some PRs with issues were merged when there was a period that flow-typed test suite didn't check for unused suppression.
From my side, I think I'll do some cleanup and then these should be good to go.

@AndrewSouthpaw could you go trough this? The interface is now decent for at least my and apparently as well for @ryami333 s use case.
The test failures comes from previous libdefs. There was a period when $ExpectError cases were not checked and some pull requests slipped trough broken.

what is missing here?

@sibelius For my use case the libdefs are working decently, although there are some caveats e.g with SFC:s. Can you give them a try for the feedback?

I'm happy to announce that now the libdefs supports Stateless Functional Components and component default props without any hacks :)

This is a huge improvement over the previous version!
Are the known issues still up-to-date?
Will test this in my code-base as well.

@cprodescu The list is up to date. Please give it a try and tell if you find any issues!

@cprodescu I can't reproduce your issue with stateless functional components. Do you have some simplistic example? I tried to reproduce by spreading all connect, mapStateToProps function and the component all into separate files but couldn't break the type safety: If my component required some prop what mapper function or the user of the component didn't offer, Flow were well aware of that.
The other problem is something I was able to reproduce, but unfortunately i don't have a solution for it. It might also be Flow issue. As a workaround, if your inference cases are naive enough, you could go around them by coercing them like { maybe: (window. foo ? '' : null: ?string) }

Looks like the build is still failing due to unused error suppressions?

@AndrewSouthpaw It's the old libdefs which I haven't changed. There was a period when unused suppressions didn't fail the build https://github.com/flowtype/flow-typed/pull/1407 . Imo not in the scope of this PR to fix them.

Yeah that's kinda the whole point of this PR isn't it? The old defs were broken, so here are some new ones which aren't.

@villesau I'm running into an issue with optional props returned from mapStateToProps. Here's an example:
type OwnPropsT = {
  isA: boolean,
}

type PropsT = OwnPropsT & {
  a?: number,
  b?: string,
}

export class _Foo extends React.Component<PropsT> {
  render() {
    return (
Hello
)
  }
}

const mapStateToProps = (state, ownProps) => {
  if (ownProps.isA) {
    return { a: 1 }
  } else {
    return { b: 'foo' }
  }
}

export const Foo = connect(mapStateToProps)(_Foo)

const testUse = <Foo isA />

I get the following errors:
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ frontend/src/modules/lesson_editor/components/context_panel/foo.jsx:22:12

Cannot return object literal because undefined [1] is incompatible with number [2].

 [1] 10│   a?: number,
       :
     19│
     20│ const mapStateToProps = (state, ownProps) => {
     21│   if (ownProps.isA) {
 [2] 22│     return { a: 1 }
     23│   } else {
     24│     return { b: 'foo' }
     25│   }

Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ frontend/src/modules/lesson_editor/components/context_panel/foo.jsx:24:12

Cannot return object literal because undefined [1] is incompatible with string [2].

 [1] 11│   b?: string,
       :
     21│   if (ownProps.isA) {
     22│     return { a: 1 }
     23│   } else {
 [2] 24│     return { b: 'foo' }
     25│   }
     26│ }
     27│

It seems to be cranky about the props being optional. Thoughts?

@AndrewSouthpaw Yeah that's unfortunate. I think it's most likely some sort of Flow inference issue which I don't have good answer to, but potential workaround instead:
Does this happen if you cast your returned objects like:
type MapStateToPropsReturn = {
  a?: number,
  b?: string,
};

const mapStateToProps = (state, ownProps) => {
  if (ownProps.isA) {
    return ({ a: 1 }: MapStateToPropsReturn)
  } else {
    return ({ b: 'foo' }: MapStateToPropsReturn)
  }
}

Yep, that fixed the issue. Looks good to me, I was able to adopt it in our codebase. I like that we don't need to have a Connector type with OwnProps and Props types, it everything a lot easier, and allows for passthrough props which is brilliant.
I'm also noticing that it's best to return an object literal in mapStateToProps. I had one case where it was something like:
const mapStateToProps = (state, ownProps) => {
  return pick(['foo'], state.myFooState)
}

which led to a cryptic error with a useless stack trace:
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ flow-typed/npm/react-redux_v5.x.x.js:56:46

undefined property schools [1] is incompatible with object type [2].

     flow-typed/npm/react-redux_v5.x.x.js
     53│   declare export function connect<Com: ComponentType<*>, DP: Object, RSP: Object>(
     54│     mapStateToProps: MapStateToProps<DP, RSP>,
     55│     mapDispatchToProps?: null
 [1] 56│   ): (component: Com) => ComponentType<$Diff<OmitDispatch<ElementConfig<Com>>, RSP> & DP>;
     57│
     58│   declare export function connect<Com: ComponentType<*>>(
     59│     mapStateToProps?: null,

     frontend/src/modules/sa_dashboard/types.js
 [2] 57│   schools: { [number]: SchoolT },

Note that it wormed into the type definition, rather than to the offending culprit.
I haven't actually looked at the code... and given it seems to be working even better than before, I give this my 👍.

I think it should be possible to make this support exact types also, by changing it to use type spreads ({ ...SP, ...DP } instead of intersection types (SP & DP). In this comment @villesau refers to facebook/flow#2405, but that bug is about ES6 (javascript) spread, not Flow's type spread. Type spread works fine, also with exact types.

I think that's true, and also I'd be fine with keeping that out of scope. Unless there are significant objections, I'm going to merge this.
@GAntoine What's the policy around libdefs that introduce breaking changes to the API? I.e. this gets rid of the Connector type which was the standard before the revamp, so people will need to refactor all their files (it's not terribly hard, took ~30 minutes for me using regexes for a large codebase)

@ahem Actually current solution is semantically more correct than spreading. If you define exact types, you should define identical (same) types for all the parts which receives the props except with mergeProps where component receives result of mergeProps only. mapStateToProps, mapDispatchToProps and component all receives the same props, with an exception that component also receives pros from mapXtoProps functions. This is already supported, you can use exact types as long as they are identical. I think exact props should represent real, exact props, when inexact props might only represent what you are interested in.
@AndrewSouthpaw I wouldn't want to add anything else into scope at this point. Any possible problems can be handled by opening a new PR. This is already much more validated PR than most of others.

@villesau I think you misunderstood me, I'm with you in not wanting to add scope. :) I just wanted to check that pushing breaking API changes won't make people mad, at it's par for the course with the flow-typed repo.

Love the work in this PR so far, but the following code types, which i think i shouldn't
import React from 'react';

type OwnProps = {
    a: ?string,
}

type Props = {
    b: string,
}

class C extends React.Component<Props> {}

connect((state, ownProps : OwnProps) => ({
        b: ownProps.a,
}))(C);

@AndreasDahl I made that mistake too, the key is to use the component, that causes the type error to occur. So, the full code would be this, which does raise an error:
// @flow
import React from 'react'
import { connect } from 'react-redux'

type OwnProps = {
  a: ?string,
}

type Props = {
  b: string,
}

class C extends React.Component<Props> {}

const mapStateToProps = (state, ownProps: OwnProps): Props => ({
  b: ownProps.a,
})

const ConnectedC = connect(mapStateToProps)(C)

const a = <ConnectedC a="foo" />

@AndrewSouthpaw it looks to me like the only reason you get an error from your example is because you explicitly type return of mapStateToProps. If you instead write mapStateToProps as
const mapStateToProps = (state, ownProps: OwnProps) => ({
  b: ownProps.a,
})

Do you still get an error?

@AndreasDahl I think that's a bug in Flow it self. That specific case worked prior to 0.57.1: https://github.com/facebook/flow/issues/5792
to my knowledge, there is not much what can be done on libdef side to tackle that problem :/

Merged. I think we've explored this PR long enough. @villesau, great work, really. You've tackled a huge project that many people could not wrap their heads around (including myself). I hope to grok Flow as deeply as you some day. 😅

As @AndrewSouthpaw suggested I opened an issue regarding the removal of the type parameterization in the return of MapStateToProps: #1934
@villesau, would really appreciate if you could just elaborate on your explanation in that issue. Totally buy that it's a Flow issue, just curious what the issue is specifically, and having an issue to track it won't hurt.

This is so awesome, thanks!!
I'm having issues getting this to work using class decorators. Is it known whether using decorators is supported or not? Currently working around this by:
class _Foo extends PureComponent<Props> {}
export default connect(mapStateToProps)(_Foo)

That's what we do as well. I don't think class decorator syntax is supported, though I never tried. That'd be a question for the flow team.

We were using Connector in our project. If the component is not directly in a function call will it type, how should we adjust the types?
const withSearchFormConnect: Connector<*, SearchFormProps> = connect(
 // mapStateToProps
  (state, ownProps) => ({
      ...ownProps,
     search: state.search,
  }),
  // mapDispatchToProps
  {
      setLocation: location => duck.actionCreator.setLocation({location}),
  }
);

const SearchForm = compose(withSearchFormConnect, withSomethigElse)(
  SearchFormPresenter,
);

I am having a similar issue as @marcelmokos. We currently use Connector as well. I would like to update, but not sure what adjustments to make after removing Connector.
@villesau @AndrewSouthpaw Is there a recommended migration path to using the new libdef?

You don't need to add anything once you've removed Connector, you can look at the tests for an example. If it's not making sense, LMK, and I can post an example.
For migration, I did a few regex find/replaces with my IDE, it wasn't too painful, took maybe 15-30 minutes. Find/replace hit 95% of cases, then a few with custom syntax I cleaned up manually.

Try just using the inferred type (*) instead of Connector

@AndrewSouthpaw Thanks, I looked through the tests and adjusted my code accordingly. It seems that I lose typechecking in the passing of props into the component being wrapped by connect. Previously, I could type my connect function as Connector<OwnProps, WrappedComponentProps>, with WrappedComponentProps having been imported from the wrapped component's file. With this configuration, if I tried to return an incorrect type from my mergeProps function, flow would catch it and give me an error. Now, without the Connector type, and without WrappedComponentProps explicitly imported, flow no longer catches these errors.
The tests make it seem like flow should be catching these errors. Got any ideas? I would say that I could still import WrappedComponentProps and use that as the return type from mergeProps, but that leaves me in a strange spot in components that don't use a mergeProps function. Is this possibly an issue that flow has with HOCs in general?

@bgergen are you using a recent release of Flow? I know that perhaps 3-4 months ago there was a bit of an overhaul to error handling and it fixed a bunch of errors being located in the wrong place (or not at all).

@ryami333 I'm on the newest version I believe: 0.67.1
I ran into a different issue. Props were being checked, but defaultProps in my wrapped components were causing all sorts of conflicts with the ElementConfig type in the libdef. Changing ElementConfig to ElementProps in the libdef seems to have fixed the issue.
@AndrewSouthpaw @villesau Does any of that make sense?

@bgergen Can you provide an example code where libdefs fails? Without an example it's not possible to try to figure out what is wrong.

Seems that this introduces regressions, like lack of getWrappedInstance() for connect-ed component.
Also, mapStateTo* is missing factory annotation:
function mapStateToProps(initialState, initialOwnProps) => {
  // some per component instance optimization
  return (state, ownProps) => ({
    /* ... */
  });
}

None of those were included in the tests :(

@stryju please add support for factory mapStateToProps

It infers empty even for class components. What am I missing?

I'm not sure if this is the appropriate place for it, but I'm not sure where else to mention this, it might save someone else the 5 hours I just lost.
While I haven't had any issues in getting type checking to work, the connect function provided here broke intellisense on every editor I've tried (webstorm, atom+nuclide, vscode). The solution I've found is to simply cast the connect call to the appropriate ComponentType, like so:
import type {ComponentType} from 'react'
import type {Props} from "./MyComponent"
import {MyComponent} from "./MyComponent"

// ...

export default (connect(mapStateToProps, mapDispatchToProps)(MyComponent): ComponentType<Props>)

Note it has to be ComponentType imported as above, React.Component imported from import * as React from 'react' will not work.

@abeforgit I think you'll want to have a $Diff of your comopnent's config and store props, like:
type ConnectedComponent = ComponentType<$Diff<ElementConfig<ComponentType<Props>>, StoreProps>>;
export default (connect(mapStateToProps, mapDispatchToProps)(MyComponent): ConnectedComponent);

@stryju Strangely enough, while your suggestion does provide intellisense, it stops the flow typechecking (as in it does not error when props are missing). However the below does work:
type connectedComponent = React.ComponentType<$Diff<React.ElementConfig<typeof MyComponent>, StoreProps>>

Which is weird since the type of the component should be ComponentType<Props>... which is the same as your suggestion...
Ill use this for now as it is better than my original solution, but it still feels like there should be a better way


adding Delta University in Egypt to domains deltauniv.edu.eg

Name : Delta University for Science & Technology
Location : Egypt
Official Domain : deltauniv.edu.eg

@Eng-MuhammadAbdulrazek First stage of verification passed, official domain is deltauniv.edu.eg as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.

@philipto
Hi, it has been a week since your last comment & this pull request is still open and not merged yet!
If you have any information still needed feel free to contact me

@Eng-MuhammadAbdulrazek Thank you for your patience while waiting for a review and processing your request. Pull request merged.


reorganize docs folder

Following the discussion about Dev Guide https://github.com/engula/engula/discussions/84#discussioncomment-1610368, this PR reorganizes the docs folder into:
docs
├── README.md
├── dev
│   ├── README.md
│   ├── api-guidelines.md
│   ├── cli-guidelines.md
│   ├── get-started.md
│   ├── maintainer-guide.md
│   └── release-manual.md
├── rfcs
│   ├── 0000-template.md
│   ├── 0041-engula.md
│   ├── 0054-microunit.md
│   └── README.md
└── user

We will continuously collect effective guidelines to Engula development.
Signed-off-by: tison<EMAIL_ADDRESS>

cc @huachaohuang
If this PR gets merged first, #77 & #80 should be updated correspondingly.

I like how cockroachdb organizes docs. It can be simplified as follows:
docs/
  README.md
  some top-level design documents...
  dev/
  rfcs/
  images/

The top-level design documents define common concepts, terms, and modules, so they are the prerequisites for dev/ and rfcs/. dev/ describes the internals, workflows, project organization, etc.

As for user documents, we may want to put them to another repo (for example, the website repo) because contributors of user documents are very different people, they don't have to understand how Engula works.

@huachaohuang thanks for your input. I agree to follow the ideas. Updating...

@huachaohuang updated.
For the user docs, shall we put them into engula.github.io repo when we actually collect/generate some?


Summary list links are hard to localise

Related component
Summary panel
Context
Trying to localise the 'Change' links into another language.
Additional information (if applicable)
https://github.com/alphagov/govuk-design-system-backlog/issues/36#issuecomment-694167301

I'm going to close this as from reading the linked backlog comment, I think it's the same thing as #2649 which covers this in more detail.


Lack of examples / tests.

We're evaluating this library and we're having a very hard time understanding how to use it.
A small paragraph on how its internal types translate to libsodium would be great.
We found several behaviours but they don't seem to be called from anywhere - so understanding what inputs should be used is quite puzzling.

We found several behaviours but they don't seem to be called from anywhere

Could you name which behaviour(s) in particular?
If there are any specific modules/use cases/primitives you require examples/docs/tests for, I will start there. This library could indeed use some more documentation.
While it may not be the best documentation, looking at the original C NIF code (https://github.com/ArteMisc/libsalty/blob/master/src/salty_nif.c) might give some insight into the mapping between elixir's in-/output parameters and the ones in libsodium.

@ArteMisc @tuupola Thanks for the update, and BTW impressive work on the NIF side of things.
I think there should be documentation (maybe in the form of doctest so it's always up to date) for secret box and sealed boxes first. This is most likely why people would turn on using this sort of lib - to be able to perform encryption / signing in a more advanced fashion.


Added links section to network container tab

List linked containers and open container page.
Allow to manage container links adding new or remove an existing existing one.
Add style to select input.

@daaru00 you're moving fast on the PRs 💟  👍
Unfortunately links are somewhat of a legacy concept; could we perhaps show the list of containers on the same network instead?

With latest commit when container start all linked container will be automatic start (if the new option in preference is set)


when I npm install show the warning:

when i npm install show the warning :
<EMAIL_ADDRESS>requires a peer of<EMAIL_ADDRESS>but none was installed.  how to fixed it?  thanks!

fix  {react: "~15.3.2"} in package.json

fix {react: "~15.3.2"} in package.json @13240913592

when i npm install show some error:
for example:
npm ERR! Unexpected end of JSON input while parsing near '...y-name-6.1.17.tgz"},"'
npm ERR!      C:\Users\Administrator\AppData\Roaming\npm-cache_logs\2018-03-16T02_10_20_139Z-debug.log


internal/eval: embedded scalar inconsistency

Uncovered by @mpvl whilst investigating comprehension changes in the https://review.gerrithub.io/c/cue-lang/cue/+/529524/10 stack.

What version of CUE are you using (cue version)?

$ cue version
cue version +1374dc99 linux/arm64

Does this issue reproduce with the latest release?
Yes
What did you do?
exec cue eval x.cue

-- x.cue --
a: {
	2
	{
		#x: 1
	}
}

a: {
	#x: 1
	if true {
		2
	}
}

What did you expect to see?
The above to pass.
What did you see instead?
The above fails. It currently needs to be "fixed" by:
exec cue eval x.cue

-- x.cue --
a: {
	2
	{
		_
		#x: 1
	}
}

a: {
	#x: 1
	if true {
		2
	}
}

From a symmetry argument, however, this should work.

Duplicate of #1472. :)

Ha!


SOLR-16866: Deleting a non-existent directory should not fail

https://issues.apache.org/jira/browse/SOLR-16866

I think I saw some problems with the RunExampleTool when I was trying to make it so you could run it twice, and it would reset the state on the second run..  weird things happened, so eventually I gave up and just logged a "Your example already exists so you may get werid stuff"..   I may go back and take a looksee at it as it may have been related to this...

I'm curious, was there a reason for replacing FileUtils.deleteDirectory() with PathUtils.deleteDirectory()?
Related: I've been in the CachingDirectoryFactory code recently and I recall there's some logic that's supposed to defer the deletion of parent directories until descendant directories are no longer referenced (have been deleted). This change seems reasonable to me (i.e., if you're asking to delete something, at the end of the day you want it gone; so if it's already gone, that shouldn't throw an exception). Still I'm going to take a look and see whether there might be a problem with the "deletion-deferral" code that's being uncovered by this issue.

I'm curious, was there a reason for replacing FileUtils.deleteDirectory() with PathUtils.deleteDirectory()?

@magibney https://issues.apache.org/jira/browse/SOLR-16074

Not sure if this is the end-all-be-all approach. Maybe the error occurs while it's deleting a child tree, and the rest of the files arent' deleted?
Here's the stack trace:
2024-03-07 18:59:44.928 ERROR (parallelCoreAdminAPIBaseExecutor-20-thread-6-processing-solr-e2e-1-foo-solrcloud-0.test.solr.org:80_solr e2e-2_shard2_replica_n5 solr-e2e-1-foo-solrcloud-0.test.solr.org-78 move-replicas-foo-solrcloud-0698005595075831 unload) [ x:e2e-2_shard2_replica_n5 t:solr-e2e-1-foo-solrcloud-0.test.solr.org-78] o.a.s.c.CachingDirectoryFactory Error removing directory => java.nio.file.NoSuchFileException: /var/solr/data/e2e-2_shard2_replica_n5/data/index
	at java.base/sun.nio.fs.UnixException.translateToIOException(Unknown Source)
java.nio.file.NoSuchFileException: /var/solr/data/e2e-2_shard2_replica_n5/data/index
	at sun.nio.fs.UnixException.translateToIOException(Unknown Source) ~[?:?]
	at sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source) ~[?:?]
	at sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source) ~[?:?]
	at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(Unknown Source) ~[?:?]
	at sun.nio.fs.UnixFileSystemProvider.readAttributes(Unknown Source) ~[?:?]
	at sun.nio.fs.LinuxFileSystemProvider.readAttributes(Unknown Source) ~[?:?]
	at java.nio.file.Files.readAttributes(Unknown Source) ~[?:?]
	at java.nio.file.FileTreeWalker.getAttributes(Unknown Source) ~[?:?]
	at java.nio.file.FileTreeWalker.visit(Unknown Source) ~[?:?]
	at java.nio.file.FileTreeWalker.walk(Unknown Source) ~[?:?]
	at java.nio.file.Files.walkFileTree(Unknown Source) ~[?:?]
	at java.nio.file.Files.walkFileTree(Unknown Source) ~[?:?]
	at org.apache.commons.io.file.PathUtils.visitFileTree(PathUtils.java:1654) ~[?:?]
	at org.apache.commons.io.file.PathUtils.lambda$deleteDirectory$0(PathUtils.java:503) ~[?:?]
	at org.apache.commons.io.file.PathUtils.withPosixFileAttributes(PathUtils.java:1774) ~[?:?]
	at org.apache.commons.io.file.PathUtils.deleteDirectory(PathUtils.java:502) ~[?:?]
	at org.apache.commons.io.file.PathUtils.deleteDirectory(PathUtils.java:487) ~[?:?]
	at org.apache.solr.core.StandardDirectoryFactory.removeDirectory(StandardDirectoryFactory.java:92) ~[?:?]
	at org.apache.solr.core.CachingDirectoryFactory.close(CachingDirectoryFactory.java:216) ~[?:?]
	at org.apache.solr.core.SolrCore.doClose(SolrCore.java:1891) ~[?:?]
	at org.apache.solr.core.SolrCore.close(SolrCore.java:1755) ~[?:?]
	at org.apache.solr.core.SolrCore.closeAndWait(SolrCore.java:1561) ~[?:?]
	at org.apache.solr.core.CoreContainer.unload(CoreContainer.java:2170) ~[?:?]
	at org.apache.solr.handler.admin.CoreAdminOperation.lambda$static$1(CoreAdminOperation.java:128) ~[?:?]
	at org.apache.solr.handler.admin.CoreAdminOperation.execute(CoreAdminOperation.java:414) ~[?:?]
	at org.apache.solr.handler.admin.CoreAdminHandler$CallInfo.call(CoreAdminHandler.java:374) ~[?:?]
	at org.apache.solr.handler.admin.CoreAdminHandler.lambda$handleRequestBody$0(CoreAdminHandler.java:235) ~[?:?]
	at org.apache.solr.handler.admin.CoreAdminHandler$CoreAdminAsyncTracker.lambda$submitAsyncTask$0(CoreAdminHandler.java:473) ~[?:?]
	at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:212) ~[metrics-core-4.2.20.jar:4.2.20]
	at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:294) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[?:?]
	at java.lang.Thread.run(Unknown Source) [?:?]

The stack trace to me looks like it could be there are 2 things doing the delete and its a race condition who gets there first? Otherwise I don't see how we would end up getting this exception. This isn't the top level path right? The stack trace says this is happening while walking the file tree...

Maybe the error occurs while it's deleting a child tree, and the rest of the files arent' deleted?

Yeah I expect that'd be the case.
If we can instead fix the removal-reordering logic, that would probably be best; esp. since some strictness around this would probably be a good thing (if data we think should be there is being deleted by some other means, that's not ideal in general). In this case we're pretty sure we know why it's being deleted, and that it's ok. But I suspect that simply fixing/extending the removal-reordering logic to cover the cases it's currently missing would fix this issue.

Any thoughts on #2349 ? This issue creates a lot of log noise 😓

Maybe the error occurs while it's deleting a child tree, and the rest of the files arent' deleted?

Yeah I expect that'd be the case.

Btw I no longer think there's a race condition leaving the file tree partially undeleted.

The stack trace to me looks like it could be there are 2 things doing the delete and its a race condition who gets there first? Otherwise I don't see how we would end up getting this exception. This isn't the top level path right? The stack trace says this is happening while walking the file tree...

I think this is very likely a top-level path -- it's "walking the file tree", but it just hasn't gotten beyond the top level yet.
In the vast majority of cases the approach taken by this PR should be fine (i.e. would not lead to partial deletion or other failure). Still, if we can get away with handling this in a stricter way I still think that's preferable. In the unlikely event that some other non-solr process really is deleting stuff, we'd want to know about it; and if we swallow this error, we would have no way of knowing there's a problem.
I think it's well within our ability to properly order the deletes for all the tracked directories -- the logic was already basically there, it just wasn't working in all cases, and #2349 should fix that.

Although I haven't looked at this in as much detail as others, I find Michael's arguments persuasive and would prefer we do #2349 instead.

Closing in favor of https://github.com/apache/solr/pull/2349


Fix input box

Called the input box change handler onChange from caller end and setValue from the component side. I went with the name onChange to make input box more generalized and implemented test for input box.

Branched from a prior merged branch, still had an old commit that was changed due to Squash and Merge. Gonna open new PR with that commit removed.


Android Read Characteristic data spamming typemap: unable to find mapping to a Java type from managed type 'System.Byte, mscorlib'

Recently updated to the latest Xamarin on Mac, and while reading data from a Characteristic the output log spams the following error...
[monodroid-assembly] typemap: unable to find mapping to a Java type from managed type 'System.Byte, mscorlib'
Steps to reproduce

Updated to latest Xamarin (version listed below)

Connect to a Bluetooth device (you may see it spam the error at various points)

Open connection to a Characteristic and read data (or register for notifications)

Notice the error printing out whenever data is read/received.

Configuration
Version of the Plugin:  MvvmCross.Plugin.BLE (2.1.1)
Platform:
=== Visual Studio Community 2019 for Mac ===
Version 8.6 (build 4520)
Installation UUID: e2b3cdef-17c0-4d86-bad7-d9abc047fef0
GTK+ 2.24.23 (Raleigh theme)
Xamarin.Mac <IP_ADDRESS> (d16-6 / 088c73638)
Package version: 610000104

=== Mono Framework MDK ===
Runtime:
Mono <IP_ADDRESS> (2019-12/5d03a6fe116) (64-bit)
Package version: 610000104
=== Roslyn (Language Service) ===
3.6.0-3.20210.9+4eafdcb1bcbd8d3573f2ba6065e56d9b9ce4f8a3
=== NuGet ===
Version: <IP_ADDRESS>91
=== .NET Core SDK ===
SDK: /usr/local/share/dotnet/sdk/3.1.300/Sdks
SDK Versions:
3.1.300
3.1.202
3.1.200
3.1.102
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Sdks
=== .NET Core Runtime ===
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
3.1.4
3.1.2
2.1.18
2.1.17
2.1.16
=== Xamarin.Profiler ===
Version: <IP_ADDRESS>
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Updater ===
Version: 11
=== Apple Developer Tools ===
Xcode 11.4 (16134)
Build 11E146
=== Xamarin.Mac ===
Version: <IP_ADDRESS> (Visual Studio Community)
Hash: b3eedfed9
Branch: d16-6
Build date: 2020-04-09 10:22:36-0400
=== Xamarin.iOS ===
Version: <IP_ADDRESS> (Visual Studio Community)
Hash: b3eedfed9
Branch: d16-6
Build date: 2020-04-09 10:22:36-0400
=== Xamarin Designer ===
Version: <IP_ADDRESS>9
Hash: d4f8bcd13
Branch: remotes/origin/d16-6
Build date: 2020-04-24 02:16:02 UTC
=== Xamarin.Android ===
Version: <IP_ADDRESS> (Visual Studio Community)
Commit: xamarin-android/d16-6/3fe860a
Android SDK: /Users/iainstanford/Library/Developer/Xamarin/android-sdk-macosx
Supported Android versions:
5.1 (API level 22)
6.0 (API level 23)
7.1 (API level 25)
8.1 (API level 27)
SDK Tools Version: 26.1.1
SDK Platform Tools Version: 29.0.4
SDK Build Tools Version: 28.0.3
Build Information:
Mono: 165f4b0
Java.Interop: xamarin/java.interop/d16-6@2cab35c
ProGuard: xamarin/proguard/master@905836d
SQLite: xamarin/sqlite/3.31.1@49232bc
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-6@bfb66f3
=== Microsoft Mobile OpenJDK ===
Java SDK: /Users/iainstanford/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_<IP_ADDRESS>
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL
=== Android SDK Manager ===
Version: <IP_ADDRESS>
Hash: 5901879
Branch: remotes/origin/d16-6
Build date: 2020-04-30 04:01:22 UTC
=== Android Device Manager ===
Version: <IP_ADDRESS>
Hash: 45d17b5
Branch: remotes/origin/d16-6
Build date: 2020-04-30 04:01:42 UTC
=== Build Information ===
Release ID: 806004520
Git revision: 9c92c7baceef7771f8dcf5c86e1e1a66fdc26182
Build date: 2020-05-18 10:05:00-04
Build branch: release-8.6
Xamarin extensions: 9c92c7baceef7771f8dcf5c86e1e1a66fdc26182
=== Operating System ===
Mac OS X 10.15.4
Darwin 19.4.0 Darwin Kernel Version 19.4.0
Wed Mar  4 22:28:40 PST 2020
root:xnu-6153.101.6~15/RELEASE_X86_64 x86_64
Device: Moto G6+

Hi @IainS1986,
I'm the friendly issue checker.
It seems like (37.50 %) you haven't used our issue template :cry: I think it is very frustrating for the repository owners, if you ignore them.
If you think it's fine to make an exception, just ignore this message.
But if you think it was a mistake to delete the template, please close the issue and create a new one.
Thanks!

This was a Xamarin issue that has since been fixed!


install script error

the injest server compiles fine but the webrtc one errors.. when using the script or just 'go build'

cd Lightspeed-webrtc
git checkout main
Already on 'main'
Your branch is up to date with 'origin/main'.
GO111MODULE=on
go build
main.go:15:2: cannot find package "github.com/GRVYDEV/lightspeed-webrtc/ws" in any of:
/usr/lib/go-1.10/src/github.com/GRVYDEV/lightspeed-webrtc/ws (from $GOROOT)
/root/go/src/github.com/GRVYDEV/lightspeed-webrtc/ws (from $GOPATH)
main.go:16:2: cannot find package "github.com/gorilla/websocket" in any of:
/usr/lib/go-1.10/src/github.com/gorilla/websocket (from $GOROOT)
/root/go/src/github.com/gorilla/websocket (from $GOPATH)
main.go:18:2: cannot find package "github.com/pion/interceptor" in any of:
/usr/lib/go-1.10/src/github.com/pion/interceptor (from $GOROOT)
/root/go/src/github.com/pion/interceptor (from $GOPATH)
main.go:19:2: cannot find package "github.com/pion/rtp" in any of:
/usr/lib/go-1.10/src/github.com/pion/rtp (from $GOROOT)
/root/go/src/github.com/pion/rtp (from $GOPATH)
main.go:20:2: cannot find package "github.com/pion/webrtc/v3" in any of:
/usr/lib/go-1.10/src/github.com/pion/webrtc/v3 (from $GOROOT)
/root/go/src/github.com/pion/webrtc/v3 (from $GOPATH)

It seems go v1.10 is used, which afaik does not support go modules, which are required for building. Try to use at least go v1.11 or newer (current is v1.16.1) for building.

I tried it with the original Debian Package. Also with the Go Version 1.15.11, 1.16, 1.16.1, and 1.16.3. I always run into the same error while building the webrtc package. I tried it in a clean debian 10.9 lxc on proxmox as root.
build github.com/GRVYDEV/lightspeed-webrtc: cannot find module for path crypto/ed25519
At<EMAIL_ADDRESS>I find files which are the same as on the golang.org site.
Any Idea where to start with this?


SvgSpriteLoader is trying to guess you are using webpack 4 or 5

Do you want to request a feature, report a bug or ask a question?
Bug
What is the current behavior?
In my environment I am using monorepo with some package using webpack 4 and some webpack 5.
See https://github.com/JetBrains/svg-sprite-loader/blob/master/lib/utils/get-matched-rule-4.js#L4
It seems svg-sprite-loader is trying to access 'webpack/lib/RuleSet' to see the user is having webpack 4(w/ RuleSet) or webpack 5(w/o RuleSet), but this is not 100% true in monorepo environment.
In this case when using SvgSpriteLoader/plugin to build, an error will show as
Error: Rule can only have one resource source
What is the expected behavior?
Maybe we should be able to let the user to choose different version of the plugin for webpack 4 or webpack 5 instead of doing a strange internal "guess".
If the current behavior is a bug, please provide the steps to reproduce, at least part of webpack config with loader configuration and piece of your code.
The best way is to create repo with minimal setup to demonstrate a problem (package.json, webpack config and your code).
It you don't want to create a repository - create a gist with multiple files
If this is a feature request, what is motivation or use case for changing the behavior?
Please tell us about your environment:

Node.js version: ?
14
webpack version: ?
5.73.0 in a monorepo where has webpack 4.46.0 as well
svg-sprite-loader version: ?
6.0.11
OS type & version: ?
mac

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

14.17.0


MissingPluginException for path_provider -Android(iOS working fine)

[ERROR:flutter/lib/ui/ui_dart_state.cc(199)] Unhandled Exception: MissingPluginException(No implementation found for method getApplicationDocumentsDirectory on channel plugins.flutter.io/path_provider)

Manually giving the directory for Android worked from me @expertdev-designer . See this example:-
Directory dir = Directory('/storage/emulated/0/SaveIt/Youtube');
dir.listSync()

Hi @expertdev-designer
Just tried the latest  path_provider: ^2.0.2 on Android running API 30, no such issue
Code sample
https://pub.dev/packages/path_provider/example

flutter doctor -v
[✓] Flutter (Channel stable, 2.2.3, on Microsoft Windows [Version 10.0.22000.51], locale en-US)
    • Flutter version 2.2.3 at C:\Users\Taha\Code\flutter_stable
    • Framework revision f4abaa0735 (7 days ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\Taha\Code\SDK
    • Platform android-30, build-tools 30.0.3
    • ANDROID_HOME = C:\Users\Taha\Code\SDK
    • Java binary at: C:\Users\Taha\Code\android-studio\jre\bin\java.exe
    • Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[✓] Visual Studio - develop for Windows (Visual Studio Community 2019 16.10.3)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.10.31424.327
    • Windows 10 SDK version 10.0.19041.0

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

[✓] VS Code (version 1.57.1)
    • VS Code at C:\Users\Taha\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.24.0

[✓] Connected device (5 available)
    • Redmi K20 Pro (mobile)  • def0ad20      • android-arm64  • Android 10 (API 29)
    • sdk gphone x86 (mobile) • emulator-5554 • android-x86    • Android 11 (API 30) (emulator)
    • Windows (desktop)       • windows       • windows-x64    • Microsoft Windows [Version 10.0.22000.51]
    • Chrome (web)            • chrome        • web-javascript • Google Chrome 91.0.4472.124
    • Edge (web)              • edge          • web-javascript • Microsoft Edge 91.0.864.64

! Doctor found issues in 1 category.

Can you please provide your flutter doctor -v your flutter run --verbose and a complete reproducible minimal code sample
Thank you

Hii @TahaTesser Thanks for quick response
I am already using latest version path_provider: ^2.0.2
[✓] Flutter (Channel stable, 2.2.0, on Mac OS X 10.15.7 19H2 darwin-x64, locale en-IN)
• Flutter version 2.2.0 at /Users/mac-2/Documents/sdks/flutter
• Framework revision b22742018b (8 weeks ago), 2021-05-14 19:12:57 -0700
• Engine revision a9d88a4d18
• Dart version 2.13.0
[!] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
• Android SDK at /Users/mac-2/Library/Android/sdk
• Platform android-30, build-tools 30.0.3
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
✗ Android license status unknown.
Run flutter doctor --android-licenses to accept the SDK licenses.
See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.
[✓] Xcode - develop for iOS and macOS
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 12.3, Build version 12C33
• CocoaPods version 1.10.1
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 4.2)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6916264)
[✓] Connected device (3 available)
• Redmi Note 7S (mobile)  • 265ac434                                 • android-arm64  • Android 9 (API 28)
• Elint’s iPhone (mobile) • caeedac25a54fc67101807449f92effc8f753851 • ios            • iOS 14.5.1
• Chrome (web)            • chrome                                   • web-javascript • Google Chrome 91.0.4472.114
! Error: iPhone is not connected. Xcode will continue when iPhone is connected. (code -13)

Hi @expertdev-designer
Can you please upgrade to the latest Flutter stable and provide flutter run --verbose logs running the minimal code sample, tap to call getApplicationDocumentsDirectory while running the app
Thank you

I had this same error when using Hive and flutter_facebook_auth together. My issue was that I hadn't performed the Android setup for the facebook plugin.
@expertdev-designer The error you mention was being thrown when I called Hive.initFlutter() since Hive uses path_provider under the hood.

I had this same error when using Hive and flutter_facebook_auth together. My issue was that I hadn't performed the Android setup for the facebook plugin.
@expertdev-designer The error you mention was being thrown when I called Hive.initFlutter() since Hive uses path_provider under the hood.

I have the same problem. How to solve the problem?

The packages mentioned are  third-party packages
@expertdev-designer
Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


Added a way to examine submodule changes

Nice. Looking forward to trying this tomorrow.
On Jul 17, 2017 2:39 PM, "Mandeep Bhutani"<EMAIL_ADDRESS>wrote:

You can view, comment on, or merge this pull request online at:
https://github.com/conda/conda-concourse-ci/pull/39
Commit Summary

Added a way to track submodule changes

File Changes

M conda_concourse_ci/compute_build_graph.py
https://github.com/conda/conda-concourse-ci/pull/39/files#diff-0
(24)
A conda_concourse_ci/diff-script.sh
https://github.com/conda/conda-concourse-ci/pull/39/files#diff-1 (8)

Patch Links:

https://github.com/conda/conda-concourse-ci/pull/39.patch
https://github.com/conda/conda-concourse-ci/pull/39.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/conda/conda-concourse-ci/pull/39, or mute the thread
https://github.com/notifications/unsubscribe-auth/AACV-SukPzjALVP8nCJ8AdNflm60ePvHks5sO7hVgaJpZM4Oab87
.

Nice work here, Mandeep.  I'll look forward to using it on real packages when I get back.


langgraph cannot reference other functions within a single tool.

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangChain rather than my code.

Example Code
@tool
def mytool(param1,param2):
  """description"""
  print("this is mytool)
  _second_tool(param1)
  print("end")

def _second_tool(param1):
  print("this is second")

Error Message and Stack Trace (if applicable)
No error happend.
print like :
this is mytool
end

Description
There were no errors in this process, just other functions in between that weren't executed and were skipped.
System Info
langgraph verion 0.0.34-0.0.30.I've been through trying these versions

Please provide actual langgraph code - the above doesn't involve langgraph at all


The blob name is not surrounded by quotes in 'Promote Snapshot' activity log

Storage Explorer Version: 1.15.0-dev
Build: 20200722.6
Branch: master
Platform/OS: Windows 10/ Linux Ubuntu 18.04/ macOS Catalina
Architecture: ia32/x64
Regression From: Not a regression
Steps to reproduce:

Expand one storage account -> Blob Containers.
Select one blob container -> Upload one blob to it -> Create snapshots for the blob -> Manage Snapshots.
Select one blob snapshot -> Click 'Promote Snapshot'.
Check the activity log.

Expect Experience:
The blob name is surrounded by quotes.
Actual Experience:
The blob name isn't surrounded by quotes.

Would like to fix this by moving our promote snapshot code to use AzCopy code path, but Azurite does not currently support put block from URL.
https://github.com/Azure/Azurite/issues/699

Verified this issue on the build 20240526.2. Fixed. So, we are going to close it.


WebAudio.initialize is not a function

🤷♂ i think you're doing something wrong, try running without mods (OneLoader) and/or reinstalling your game


[TRA1][W14-B4] ChenZhiLiang

Add a new command - favorite, with corresponding updates in help commands etc.

This PR is not necessary as the PR for this activity should be sent from your organization as a group. I have seen your commits in the group PR. So i will close this.


Scoreboardstats - Craftconomy

I have switched from Iconomy to Craftconomy, but now scoreboardstats doesnt show the money per-world, It shows the money somewhere else, I have craftconomy setup into 2 "pools", And scoreboardstats shows nether of them, It claims i own 100k, while i only own 1024 in one of the pools and 50 in the other

Which Vault version do you use?

Sorry for the delay.

i never got it to work, but i got the functionality needed with vault+ecomony+gringotts.

Found out that this is actually a vault bug.


Large amount of print calls in short time causes issues

Describe the bug
As title said.
To Reproduce
Running this code causes this to happen:
for i=1,100 do
print(123)
end
1280x ...ddOns\Glass\Glass\Components\SlidingMessageFrame.lua:401: Action[SetPoint] failed because[SetPoint would result in anchor family connection]: attempted from: :SetPoint.
[string "=[C]"]: in function SetPoint' [string "@Glass\Glass\Components\SlidingMessageFrame.lua"]:401: in function CreateMessageFrame'
[string "@Glass\Glass\Components\SlidingMessageFrame.lua"]:436: in function Update' [string "@Glass\Glass\Components\SlidingMessageFrame.lua"]:425: in function OnUpdate'
[string "@Glass\Glass\Components\SlidingMessageFrame.lua"]:230: in function <...ddOns\Glass\Glass\Components\SlidingMessageFrame.lua:229>

Hey @Grimonja. Thanks for this. Unfortunately I don't think this is a supported use case as it doesn't happen in real-world use.

Hey @mixxorz,
I don't agree. There are quite a few snippets out there that casual person might run to display some data. I recall there was a snippet that displayed quest completion. Combine that with spamming trade chat. And it might happen.
Not to mention its extremely annoying in development purposes when you just want to quickly print arguments of a frequently frying event. Or by just using /dump on a sufficiently large table.
I honestly don't think chat addon should interfere with this.

Hey. Thanks for the context.
I think I mentioned this before, but for addon development, you ought to really be using ViragDevTool for debugging. It lets you "print" tables and lets you inspect them. I suspect this will also save you from having to print out 100 lines in quick succession.
Also, I think that code snippet might be a bit extreme. Glass can handle even the spammiest of Trade Chats, but I don't think it's reasonable to expect Glass to handle creating 100 frames in an instant. In fact, I expect that this might be a limitation of WoW's UI.
Nevertheless, this feels like an extreme edge case that not a lot of people are running in to, and will probably not be prioritized any time soon.
That being said, I am working updates to how messages are added to the frame. This might be inadvertently fixed by that. I'll circle back here once that gets merged.
Also, Glass is open-source so if you feel that this is really important, I'd be happy to merge in a pull request.


set http2 to default false

https://github.com/PrefectHQ/prefect/issues/7442
https://github.com/encode/httpx/discussions/2112
considering that the above two issues mean that using http2: true leads consistently to irrecoverable worker failures, I think the default should be false

Hi @jawnsy , thanks for the quick response!
I was about 2 weeks behind latest, which looks like right around when that PR was merged. I'll update that and let you know if the worker failures persist or not

just wanted to update that I attempted to update the chart, but it causes the worker to fail in kube with
prefect.exceptions.PrefectHTTPStatusError: Client error '404 Not Found' for url 'https://prefect.manifoldtrading.net/api/deployments/89ee0166-b731-4967-8d0b-19d7d3a6bb2e'
Indeed this deployment does not exist. I'm not sure where it's getting that from or why it's trying to query that. moreover, the prefect UI shows the worker as healthy despite crashing repeatedly in kube
anyway, I've reverted back to the chart from mar 10 and the above error as gone away. just setting http2: false locally for the time being

This was an issue with an upstream dependency, which should have been resolved in encode/httpcore 0.17.1. I'm closing this out as the default behavior (to use HTTP/2) should now work reliably. Please let us know if you see otherwise after upgrading to the latest version.


extra frames

Describe your bug here.
when i want to make a json for my character psych engine adds 5 extra frames to my character
before frames end:

after frames end:

does anyone know why it happens?
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
no

also its only on idle animation, on singLEFT or rest its normal


Package dependency not found

From @TheColorRed on April 11, 2016 1:22

VSCode Version: 0.10.11
OS Version: Linux

I have the following project.json file:
{
    "version": "1.0.0-*",
    "description": "Test Console Application",
    "authors": [
        ""
    ],
    "tags": [
        ""
    ],
    "projectUrl": "",
    "licenseUrl": "",
    "tooling": {
        "defaultNamespace": "CSharp-gtk"
    },
    "commands": {
        "ConsoleApplication": "MainApp"
    },
    "frameworks": {
        "dnx451":{
            "dependencies": {
                "GtkSharp": "3.1.3"
            }
        }
    }
}

I then have the following using statements in my MainApp.cs file:
using System;
using Glade;
using Gtk;

Even though VSCode can't find the Glade item, I can still run it with the following command:
mcs -pkg:glade-sharp-2.0 -out:build/MyPackage Source/MainApp.cs
So, is there a way for me to reference the glade-sharp-2.0 item so I can get intellisense to work with it?
Copied from original issue: Microsoft/vscode#5137

Moving to vscode-omnisharp for investigation.

@TheColorRed -- this is more of a DNX question, isn't it? It seems like you want to reference glade-sharp-2.0 in your project.json?

This issue has gotten pretty stale (no response in four months). Also, with the .NET Core release this summer the project.json here is invalid. I'm not sure this is relevant any longer.


Release v1.2.3

Signed-off-by: Keith Mattix II<EMAIL_ADDRESS>

[X] I have cherry-picked any changes labeled needs-cherry-pick-vX.Y.Z

[X] I have made all of the following version and patch updates:

Updated the container image tag in charts/osm/values.yaml
Updated the chart and app version in charts/osm/Chart.yaml
Updated the image tags used in the automated demo
Regenerated the Helm chart README.md

[X] I have checked that the base branch for this PR is correct as defined by the release guide

Is this a release candidate? no
Image digests: https://github.com/openservicemesh/osm/actions/runs/3690857830/jobs/6248301694

Codecov Report

Merging #5267 (368fda9) into release-v1.2 (6ecc61c) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           release-v1.2    #5267      +/-   ##
================================================
- Coverage         68.82%   68.81%   -0.02%
================================================
  Files               210      210
  Lines             15679    15679
================================================
- Hits              10791    10789       -2
- Misses             4837     4839       +2
  Partials             51       51

Flag
Coverage Δ

unittests
68.81% <ø> (-0.02%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/certificate/manager.go
77.07% <0.00%> (-0.80%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


RDP Wrapper not working after lates win10 updates.

After lates win10 updates (version 1903, 18362.418) i cant use two users at the same time. RdpConf screen attached. Help please.

https://github.com/stascorp/rdpwrap/issues/906
can try that, you'll need to uninstall first.

could U up your rfxvmt.dll? My version is as your previous one.

could U up your rfxvmt.dll?

rfxvmt.zip

thks，and I have solved it by the method #906 . It may help you also.

can try that, you'll need to uninstall first.

It working!!! Thank you very much!!!!!

Make sure you disable windows updates if you require RDPWrap to work. This project is no longer maintained and the community releases are slow.

https://github.com/SobieskiCodes/RDPWrap


link definition title on line following link url is parsed as a separate paragraph

http://daringfireball.net/projects/markdown/syntax#link says:
'
You can put the title attribute on the next line and use extra spaces or tabs for padding, which tends to look better with longer URLs:
[id]: http://example.com/longish/path/to/resource/here
    "Optional Title Here"

'
However when marked sees this it parses the title line as a separate paragraph from the definition on the line above.

#984


ci: Build dependency for Github Actions

This creates dependency for things to run Github Actions to better prevent wasted CI on things

CI Vulkan-Tools build queued with queue ID 295367.

CI Vulkan-Tools build queued with queue ID 295367.

CI Vulkan-Tools build # 1561 running.

CI Vulkan-Tools build # 1561 passed.


build error with public URL

@jamesknelson great work！
I have a question：if  I set PUBLIC_URL=/xxx/yyy/ in .env config，npm run build will throw an error：
.......
The project was built assuming it is hosted at /qingtong/papaya-blog/.
You can control this with the homepage field in your package.json.

The build folder is ready to be deployed.

Find out more about deployment here:

  http://bit.ly/CRA-deploy

navi-scripts: Using config at /work/FE/gatsby/react-blog/navi.config.js
Error: Could not load script: "/qingtong/papaya-blog/static/js/30.7a7c1dba.chunk.js"
    at onErrorWrapped (/work/FE/gatsby/react-blog/node_modules/jsdom/lib/jsdom/browser/resources/per-document-resource-loader.js:38:19)
    at Object.check (/work/FE/gatsby/react-blog/node_modules/jsdom/lib/jsdom/browser/resources/resource-queue.js:72:23)

actually，react-scripts build is ok，it seems navi-scripts have some problem with PUBLIC_URL。
I can not find any document related to this in the project。

This looks to be an issue in navi-scripts instead of this project, closing this for now.

Found this issue through github search. Couldn't find anything related to PUBLIC_URL in the navi repo (where navi-scripts is kept). @jamesknelson any updates on this? Can't find any documentation either


updating po roadmap

Pull Request Test Coverage Report for Build 756

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.273%

Totals

Change from base Build 689:
0.0%

Covered Lines:
1290

Relevant Lines:
1354

💛  - Coveralls


How to execute JavaScript?

I've tried to find a way to execute JavaScript, in the official document, Issues, StackOverflow and google, but I can't still find.
As Selenium supports WebDriver.ExecuteScript, I thought atata also naturally would do.
Is there any way to execute JavaScript by any chance?

Sure, you can get whole instance of RemoteWebDriver and invoke any native WebDriver method.
AtataContext.Current.Driver.ExecuteScript("...");

Oh! I didn't expect it to be in AtataContext.
Thank you! :)

Always welcome.


Value class support for makros

I'd like to add support for value classes and made a start here. I have temporarily commented other tests so that it's easier to debug and play around.
https://github.com/mpollmeier/gremlin-scala/compare/macro-value-classes
Essentially it's this part that I want to get working (MarshallableSpec):
      val cc = CCWithValueClass("some text", MyValueClass(42))
      val v = graph.addVertex(cc)

      val vl = graph.V(v.id).head
      vl.label shouldBe cc.getClass.getSimpleName
      vl.valueMap should contain("s" → cc.s)
      vl.valueMap should contain("i" → cc.i.value)
      vl.toCC[CCWithValueClass] shouldBe cc

I fiddled around in Marshallable.scala (needs lot's of cleanup) and got to fromCC part working fine. The toCC seems to be a bit more tricky though - probably due to my lack of macro knowledge. Basically I want to lookup the primary constructor of the case class (i'm using the companion object to get there) and use it in the quasiquote.
I put together four versions (Marshallable.scala line 109-119) which have different outcomes / problems. @joan38 can you have a look please? Ignore the non-generic way to pull out the apply method, I'm mostly interested in how to use it in quasiquotes.

figured it out. with
val valueClassCompanion = returnType.typeSymbol.companion
I can just do
q"$valueClassCompanion(valueMap($decoded).asInstanceOf[$wrappedType]).asInstanceOf[$returnType]")
no need to search for the apply method. need to do some cleanup, hopefully this works for all generic cases.