composing css modules throws error

I'm working with @erikras redux boilerplate which recently integrated webpack-isomorphic-tools and I've noticed that I cannot use the composes feature of css-loader as documented here: https://github.com/webpack/css-loader#composing-css-classes. In order to use flexboxgrid, a responsive styling library, I would like add the following to my App.scss:
:local(.appContainer) {
  composes: row from 'flexboxgrid/dist/flexboxgrid.css';
  margin: 20px;
}

But I get the following error:
[0] /[REDACTED]/node_modules/webpack-isomorphic-tools/babel-transpiled-modules/plugin/write assets.js:202
[0]         throw _iteratorError;
[0]               ^
[0] SyntaxError: Unexpected token +
[0]     at Object.parse (native)

Full error gist is here: https://gist.github.com/bdefore/60b3206cc2a57b87116b

So, what's on the line 47 then?
/[REDACTED]/webpack/webpack-isomorphic-tools.js:47:42
Anyway, the error is in your parser function.
So you should provide it's source code.
It even says that in the second line of the error stack.

That file is unchanged from the version you provided in your PR. It's where a JSON.parse call is made: https://github.com/erikras/react-redux-universal-hot-example/blob/master/webpack/webpack-isomorphic-tools.js

The same error appears to occur when loading in a file from a relative path such as:
:local(.appContainer) {
  composes: foo from './Home.scss';
  margin: 20px;
}

Maybe put a console.log(match) before that line 47 to see what it's trying to parse?

Well, this issue is surely unrelated to webpack-isomorphic-tools as far as I can tell.
As far as I understood this is the issue with the parser function.
And I have no idea what it does actually

Yeah, try to output the match object.
Something like
options.log.info('match', match[1])

Using the simpler version above, using Home.scss, a console.log('match', match[1]) yields:
[0] match {
[0] 	"appContainer": "appContainer___18ST9 " + require("-!./../../node_modules/css-loader/index.js?modules&importLoaders=2&sourceMap&localIdentName=[local]___[hash:base64:5]!./../../node_modules/autoprefixer-loader/index.js?browsers=last 2 version!./../../node_modules/sass-loader/index.js?outputStyle=expanded&sourceMap!./Home.scss").locals["foo"] + ""
[0] }

It looks like it's trying to append something incorrectly.

Yeah, no way concatenation is allowed in JSON format spec.

Actually it's not JSON anymore - it's javascript.
So maybe use eval() or something like that?

I'll close the issue because you've found the root of the problem.
You are free to continue your discussion here though.

If I change the parser in the configuration file to use parser: WebpackIsomorphicToolsPlugin.url_loader_parser even for styles_module, rather than the JSON.parse approach, it appears to function correctly. This function currently does some string manipulation, splicing things together around double quotes:
	// retain everything inside of double quotes.
	// usually it's "data:image..." for embedded with the double quotes
	// or __webpack_public_path__ + "..." for filesystem path
	var double_qoute_index = module.source.indexOf('"');
	var asset_path = module.source.slice(double_qoute_index + 1, -1);

I tried to bring that logic into the other method but was unsuccessful.
Replacing the parser entirely makes me wonder if it's not correctly going to pick up the correct Webpack configuration depending on environment. @erikras do you think that will be the case?

I don't actually understand what you are talking about here, but I as far as I can tell the issue is arising only if you use a particular feature of style modules. To be more specific, the compose feature (I don't know what it does though).
Therefore, I guess, using the compose feature makes css-loader change its output and it becomes non JSON-parseable.
This parser function for css-modules is a fragile thing and of course it can break on any new use case.
I think that's the case here.

FYI
I'm posting this in every issue and PR to notify whoever may be interested:
today I've released an alternative helper library called universal-webpack.
It takes a different approach than webpack-ismorphic-tools and instead of hacking Node.js require() calls it just compiles all code with target: 'node' webpack configuration option.
As a result, all Webpack plugins and features are supported.
If you think you might need that here's an example project:
https://github.com/halt-hammerzeit/webpack-react-redux-isomorphic-render-example


[Feature request] Use an external file to store redirections mapping

Hello!
Sometimes, in large base documentation evolving for a few years, it's quite hard to maintain a healthy redirections mapping and it's not really convenient as it's stored within the mkdocs.yml.
Why not allowing to load redirections map from an external file, for example a CSV with an option (mutually exclusive with redirect_maps) like this:
plugins:
    - redirects:
        redirect_file: "config/redirections.csv"

I don't think this should be solved within this plugin because I'm sure many other plugins have the exact same inflexibility so it might be way more worth it to support it in MkDocs itself.
Unfortunately this issue didn't come to a satisfactory solution:

https://github.com/mkdocs/mkdocs/issues/2218

-- I am open to revisiting it instead.
I haven't looked at that issue in detail before, but to me a feature similar to this one seems very good to have:
https://stackoverflow.com/a/9577670

Thanks for your answer. The configuration inheritance is clearly still a thing. I had already suggested to support multiple inheritance: https://github.com/mkdocs/mkdocs/issues/2624


Heroku Deployment - Archive not found

I'm having issues with deploying the app on heroku. The data I used was the same I had before (I deleted the old app since the old version was on there pretty long and had an error).

Any ideas?

The problem seems to be fixed, I was able to run the script again. Thanks for the update!

Sorry for the late reply, glad it's working now


rats-tls:  Failed to set logging callback for the quote provider library in sgx 2.14

Steps:
git clone https://github.com/alibaba/inclavare-containers/
cd inclavare-containers/rats-tls
cmake -DRATS_TLS_BUILD_MODE="sgx" -DBUILD_SAMPLES=on -H. -Bbuild
make -C build install

cd /usr/share/rats-tls/samples &&  ./rats-tls-server -t openssl -c openssl -a sgx_ecdsa -v sgx_ecdsa

cd /usr/share/rats-tls/samples &&  ./rats-tls-client -t openssl -c openssl -a sgx_ecdsa -v sgx_ecdsa

The sgx sdk version is <IP_ADDRESS> and the dcap version is <IP_ADDRESS>
The error is shown :
[INFO] ecall_rtls_server_startup()@L90: Waiting for a connection ...
[get_qpl_handle ../qe_logic.cpp:295] Failed to set logging callback for the quote provider library.[get_qpl_handle ../qe_logic.cpp:295]
[INFO] ecall_rtls_server_startup()@L119: Client: Hello and welcome to Rats TLS!

@zhiminghufighting  please help check this issue, thanks

The reason is that  the version of libsgx-dcap-default-qpl is 1.10 not <IP_ADDRESS>.
Update libsgx-dcap-default-qpl to <IP_ADDRESS> can solve this problem.


got an error

Class SMXTabBarManager was not exported, Did you forget to use RCT_EXPORT_MODULE()?
and can not display icons.
any help, thanks

Just released a new version 0.0.2 that supports React Native 0.3.11 which introduced this requirement and will fix this.


File System API

Low level random access read/write APIs similar to fs.read
Gecko has multiple FileSystem APIs available most recommended one (last time I checked) was OS.File which likely could be (wrapped &) exposed as WebExtensions API. For random access read / writes there are still nsIFileInputStream & nsIFileOutputStream APIs and legacy add-on API wrappers to expose them in node compatibleAPI. For reading / writing at specific byte offset OS.File.prototype.setPosition could be used.
🐞 1246236

From @pfrazee

If we're looking for a 1:1 with what Beaker can do, having a Filesystem API that can watch folders for changes, do read/writes within files, and handle "sparse" files, should all be fairly important.

In the short-term: we can get Dat working on IndexedDB, but performance would suffer a bit. In Beaker we also watch local folders to autopublish to dats, and that wouldn't be possible here.

From @mafintosh

Noting we'd need random access read/write fs support here to make it as performant as the node/beaker impl.

Also, we rely on native code to run our utp stack. We can run without it, but we might need some udp support here else.

From @rpl

an API for direct filesystem access has been debated a number of time over the last two years but we haven't yet reached an agreement about it, it is not that we will never provide one, but it has not been an "easy topic", and we don't have it on roadmap for the next two releases (62 and 63).

One of the tricky things about an API for direct filesystem access (besides the security/privacy concerns) is that the extension code runs in a sandboxed child process which cannot directly access files on disk (and so any disk access should be mediated by the main process, possibly not on its main thread).

In the meantime, the extension that needs some kind of random access files have only two options:

nativeMessaging, and so basically leave the external native app to access the files on behalf of the extension

IDBMutableFile, which is a non-standard extension to the IndexedDB API which allows IndexedDB to associate to a key a mutable file (instead of just an immutable Blob/File like it is supported on most of the modern browsers), and the mutable file profiles a (non-standard) API to read and write the file with random access (the file is stored on disk as a real file, read/write should happen in a separate IndexedDB thread, and it can be used in the sandboxed child extension process):
https://developer.mozilla.org/en-US/docs/Web/API/IDBMutableFile and https://developer.mozilla.org/en-US/docs/Web/API/LockedFile

As a side note, issues with micro-tasks and Promise scheduling has been recently fixed in Firefox 60, and so the IDBRequest API that IndexedDB APIs provides can now be easily wrapped into a promise based API without issues with the IDB transaction being closed before the promise has a chance to run (https://bugzilla.mozilla.org/show_bug.cgi?id=1193394#c164).

From @pfrazee

Helpful insight, Luca. The downside of FS access through the main thread is messaging overhead, right?
IDBMutableFile might end up being a performance benefit compared to the rest of IndexedDB.
There are basically 2 concerns:

Internal storage performance. This is what needs random read/write control.

UX for dev workflows. This doesn't need total FS access, but it does need the extension to be able to access folders that the user specifies. That access then needs to include watching and read/write.

From @rpl

We try to avoid to run heavy tasks on the main thread because it creates "user perceivable" performance issues, especially the main thread on the main process (which if it is too busy, it would make the browser UI to lag)
And so, given that the child process are sandboxes by default and cannot access the filesystem, IndexedDB ensure that we run the most expensive code in a separate thread of the main process.
IDBMutableFile could help with "1. internal storage performance" (even if in a non-standard way),
but unfortunately there isn't currently any very good workaround for "2. UX for dev workflows" :-( (at least not one that doesn't involve "using an external helper native application and nativeMessaging").

There is actually another non-standard feature (coming from chrome/webkit), which would allow a user to provide read access to an entire directory tree (e.g. by let the user to drag and drop a directory instead of a single file, or with a special option on an input element), but it doesn't provide write access to that directory tree (and no watching):
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API#Getting_access_to_a_file_system

It may be probably useful for an extension that wants/needs to allow a user to transfer a directory tree into a number of IDBMutableFile object stored in IDB, to be modified by the extension (but currently then there is no easy/performant way to sync those changes back into the original directory tree on the filesystem).

In the long run, once an actual FileSystem WebExtension API may finally be implemented, that API is very likely to provide "sandboxed read/write" to a directory (or directories) that the user explicitly "specify / give access" to the extension (e.g. to reduce the number of security concerns that have been raised during the past discussions about providing such a powerful/dangerous API to an extension).

But "watching the directory tree for changes" seems also an interesting feature to keep in mind, so that we do not forget about it once an actual API implementation is being proposed.

Respondig to @rpl

We try to avoid to run heavy tasks on the main thread because it creates "user perceivable" performance issues, especially the main thread on the main process (which if it is too busy, it would make the browser UI to lag)

And so, given that the child process are sandboxes by default and cannot access the filesystem, IndexedDB ensure that we run the most expensive code in a separate thread of the main process.

As things stand now we were planning on using OS.File API that does all the IO off the main thread. As you also pointed out there is no way to do IO anywhere other the parent / main process so sadly that would imply some overhead of pumping data from Extension Process ->  Parent Process ->  OS.FIle Thread  and reverse. I imagine that is also more or less what IndexedDB API has to do is it not ?
Only other option I see (and seem to be getting increasingly more in favor of) to expose a ServiceWorker like API say ProtocolWorker that would be sandboxed version of ChromeWorker in the parent process with an access to TCP / UDP sockets, MDNS, FileSystem. That way all of the IO will actually happen right there and no data juggling will be required  across all of these processes, except when data will be read from nsIChannel of the corresponding nsIProtocolHandler in the child process (which is sadly what happens when document is loaded).
Major downside of this approach is that I would need to replicate large portion of what WebExtensions do (like permissions, lazy loading, and probably a lot more). Still I would love to hear your opinion in this regard.

There is actually another non-standard feature (coming from chrome/webkit), which would allow a user to provide read access to an entire directory tree (e.g. by let the user to drag and drop a directory instead of a single file, or with a special option on an input element), but it doesn't provide write access to that directory tree (and no watching):
https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API#Getting_access_to_a_file_system

This actually more or less what Beaker is doing right now except it's not drag and drop based but rather they provide a prompt where user can choose a directory, which I imagine should not be too difficult to add. Write & Watch is essential though.
@pfrazee I wonder what requirements would FileSystem API would have to satisfy to not limit beaker in any way while at the same time was scoped limited in scope like FileSystem.requestFileSystem() allowing user to choose a target directory to expose. It seems that it would be a better option from the Firefox WebExtensions perspective as it reduces the harm malicious add-on could cause.
@rpl If we were to design our FileSystem API in the following principal would there be any way to persist access that user granted across the browser restarts ?

But "watching the directory tree for changes" seems also an interesting feature to keep in mind, so that we do not forget about it once an actual API implementation is being proposed.

That reminds me that this used to be an API not present in any way in Gecko back in Add-on SDK days at least.

The ProtocolWorker idea is interesting - is there any precedent for putting an extension in the main thread? Other than the security implications it may not be a total performance win: we'll want the Dat networking stack to be off main so that it doesn't hurt overall perf.
RE the file access: yeah I think we could work within requestFileSystem() if it let the user pick the directory and then gave us full capabilities.

The ProtocolWorker idea is interesting - is there any precedent for putting an extension in the main thread?

Up until WebExtensions Firefox used to run all of the add-on's in the main thread (which is different from the content threads), but it also used to be a reason why Firefox was becoming a lot less responsive for users with many add-ons installed.
With WebExtensions as far as I understand actual add-on code is loaded in separate extension process, content scripts are loaded in the content processes (usually referred to as child processes). Still all the IO happens on in the main process (usually referred to as parent process) as far as I understand intentionally so to enable sandboxing. APIs exposed to the extensions usually have corresponding code (implemented by WebExtensions team) run in the main (thread of the main) process with which they exchange async messages to do IO related tasks.

Other than the security implications it may not be a total performance win: we'll want the Dat networking stack to be off main so that it doesn't hurt overall perf.

I should elaborate how protocol handlers work I think to explain why I think  ProtocolWorker would be a better option.
Protocol handlers in gecko need to be installed both in main process and each content process. As far as I can tell one in main process is only used to create URLs while the one's in content processes are used to load content. So when tab say is attempting to load dat://${hash} it will as corresponding content process provide nsIChannel (which is similar to stream in node) since content process needs to do IO it will have to send message to main process, but even though main process can do IO it needs to pass the request to the extension process which has protocol implementation logic, but extension process need to perform some IO to read / fetch that content so it needs to send message back to main process which will stream chunks of data back to extension process which will pre-process it and send it back to main process so that it can finally forward it to the corresponding content process so tab can load it. In summary this turns out be at least 6 steps that requires copying actual data ArrayBuffer 3 times (as it goes across processes), and that is if the whole thing can be served in single round-trip.

#
content process
main process
extension process

1
:email: Request url
:mailbox_with_no_mail:
:zzz:

2
:zzz:
:email: Request url
:mailbox_with_no_mail:

3
:zzz:
:mailbox_with_no_mail:
:email:fs.read(file)

4
:zzz:
:email: ReadArrayBuffer
:recycle:  Copy ArrayBuffer

5
:zzz:
:recycle:  Copy ArrayBuffer
:email:  Respond ArrayBuffer

6
:recycle:  Copy ArrayBuffer
:email:  Respond ArrayBuffer
:zzz:

If protocol handler doesn IO operations for a request and responds in k chunks total number of copying for that request will be n + 2*k.
It's not necessarily going to be slow, but it also does not seems to me that there is much value in running protocol handler logic in extension process. I believe main reason why add-on code runs in the extension process in first place is to provide it with DOM access, which in case of protocol handler does not seem to make much sense.
Now what I was suggesting to do was to spawn a dedicated worker thread on the main process and load protocol handler code there. It still should not block main process, but unlike the above case it would be possible to transfer ArrayBuffers across main threads without copying.
So in this case if protocol handler does n IO operations for a requqest and responds in k chunk total number of copying for that request will be k.

@mafintosh @lidel @olizilla Do you care about having control of file open / close files ? Or would sparse read / write with automatic close satisfy requirements ?

I wrote down the interface definition for this API and could use some feedback:
https://github.com/mozilla/libdweb/blob/master/src/FileSystem/API.js

If there is something missing please speak up.
If there is something strictly unnecessary please let me know, I'd be happy to reduce the scope.
If for whatever reason mounting (as describe in the comment)[https://github.com/mozilla/libdweb/blob/66aeb6d57086e2f6c4526ee2687ce949b7173e49/src/FileSystem/API.js#L4-L11] isn't going to work for you please speak up.

P.S: API mostly follows existing OS.File. I do understand that node fs compatible API would have being likely more desirable, but that would have introduced extra layer of adapters and node Stream implementation, which I'd rather see happen in user land.

Seems right. I'll pass it on to maf. Is the idea of createUnique to create a file with an unused name?

Seems right. I'll pass it on to maf.

👍

Is the idea of createUnique to create a file with an unused name?

Yes (I think it just prefixes number to the basename). It's just already existed in the gecko (see OS.File.openUnique for more details), presumably because there was a demand for it internally, but I'm not sure if it's going to be at all useful in other context.

I've changed my mind on the proposed API a bit, let me elaborate and please let me know if you see concerns with it.
I am considering removing path manipulation utils and instead expose root URL on the mounted FileSystem instance in the form of file:///path/to/chosen/dir/. This has two benefits IMO:

We no longer need all the path manipulation stuff as you'd be able to use URL for that.
Unix / Windows differences get abstracted away

Maybe there's a good reason against it (if you think of one please let me know), I can't think of one myself.

@Gozala using the API you propose in the link above how would I do a read/write at a specific byte offset? As I read your spec that seems to be two different async operations?
Other than that it looks pretty solid. In general we rely on this storage API https://github.com/random-access-storage/random-access-storage#var-storage--randomaccessstorageoptions btw
For the auto open/close stuff ... I'd prefer this to be as low level as possible. Having control over open/close allows us to serve 1000s of files in the browser potentially as we can tune when to open and close them (we already do this in our node code). If that is really tricky I'm sure we can live without it as long as the file isn't opened/closed for every write/read op as that would prob kill our perf.

@mafintosh to read the second kilobyte: open(path, {read: true}).read({byteSize: 1024, byteOffset: 1024})
I would definitely want control of open,close, link, unlink, move (aka rename).
move is important to get atomic updates - for example, stream a file in, and then move it into place when it's complete. move is a single operation so if the streaming fails, you don't move the file and the system stays consistent.
I'd recommend using fd instead of path as the first argument to read. Oh, I see that it becomes the OO style by opening the file and getting a ReadableFile which has read on it (and no path or fd argument). I think i personally prefer simpler positional args for low level stuff read(fd, start, end, buffer, cb) because that is a lower common denomenator and already close to node's api. If you went with the OO interface, I would probably end up polyfilling it back down to the simpler api anyway.
important: read options should include a buffer to read into so that it's possible to reuse memory - for high performance it's necessary to avoid memory allocations, also it would enable reading directly into a webassembly context without another memory copy. This will make a big difference to high performance applications!

@Gozala using the API you propose in the link above how would I do a read/write at a specific byte offset? As I read your spec that seems to be two different async operations?

Exactly what @dominictarr said (quoting below)

@mafintosh to read the second kilobyte: open(path, {read: true}).read({byteSize: 1024, byteOffset: 1024})

For the auto open/close stuff ... I'd prefer this to be as low level as possible. Having control over open/close allows us to serve 1000s of files in the browser potentially as we can tune when to open and close them (we already do this in our node code). If that is really tricky I'm sure we can live without it as long as the file isn't opened/closed for every write/read op as that would prob kill our perf.

👍 I assumed so, but still wanted to make sure. I expect that proposed open, close APIs would cover that.

@Gozala I would definitely want control of open,close, link, unlink, move (aka rename).

👍 I assume existing open, close, removeFile, removeDirectory and move capture all of the listed operations except link which is unfortunately not available in gecko.
I don't know on why API to create hard links isn't available it could be simply because it was not necessary from with in gecko or it could be related to platform portability or anything else. I can try to find that out. In the meantime I can provide some pointers:
Filesystem access in gecko is achieved via ctypes that allows loading native system libraries, on Unix it seems to use libc.so /  libSystem.B.dylib and on windows it's kernel32.dll I think all of them have link so technically it should be possible to implement it.
Now that being said how important is fs.link ? Asking because there are two roadblocks:

It is not something we would be able to do with-in the WebExtensions experimantal APIs and would require changes to be made with-in mozilla central that is far more difficult and will consume a lot more time (assuming no push-back). Never the less I have filed Bug 1465929 to request it.

There is consensus with-in web-extensions team use of indexd-db using moz proprietary IDBMutableFile extension is a preferred solution allowing virtualized Filesystem API. Which would be able to provide most of the API described, but as far as I can tell it won't have fs.link or fs.symlink not natively anyway. I'll touch more on this in a separate comment.

I'd recommend using fd instead of path as the first argument to read. Oh, I see that it becomes the OO style by opening the file and getting a ReadableFile which has read on it (and no path or fd argument). I think i personally prefer simpler positional args for low level stuff read(fd, start, end, buffer, cb) because that is a lower common denomenator and already close to node's api. If you went with the OO interface, I would probably end up polyfilling it back down to the simpler api anyway.

👍
Truth is under the hood I pass around file descriptors across processes anyway so I see no reason to not expose fs.read(ReadableFile, byteOffset, byteLength, buffer):Promise<ArrayBuffer> as on the host process that's how it is anyhow. I'll just rename fs.read to fs.readFile.
As of the callbacks, as implementation does cross process resource juggling and underlying primitives to do so exposes promise based APIs and does all the bookkeeping I see no benefit to exposing callback based API other than compatibility with node. But even then API won't be compatible and would require boilerplate to do additional bookkeeping which I find hard to justify. It also worth pointing out that I expect that users will end up abstracting these APIs to some common API so I'd prefer not to avoid any extra work that would go into API compatibility layer.
If you still think there is a reason I should reconsider this please pursue me to do so.

important: read options should include a buffer to read into so that it's possible to reuse memory - for high performance it's necessary to avoid memory allocations, also it would enable reading directly into a webassembly context without another memory copy. This will make a big difference to high performance applications!

I'm afraid that's not going to be possible. Short version is due to "sandboxing" all the IO is performed on separate OS process and then data is being copied to the process that consumes this data. I have described this into more detail above. So even if I were to allow passing buffers to write into, I'd still have buffers allocated in this process and be copying from them into buffer you pass so at the end of the day it would be less performant.
That being said I've being told that since all of the IO in gecko is done the same way it's well optimized and likely to get even better over time and it should not be a bottleneck. I have being discussing of maybe running protocol handlers in main process in a separate thread, but it seems that really defeats security guarantees of "sandboxing" and so it's very unlikely to happen.

As I have being working towards implementation and discussing aspects of it with WebExtensions team I came to realize that there is a need to reconsider some of the API choices, I'd like to bring those up here provide some insight on why and describe alteration I'm considering instead.
Background

Security aspects of FileSystem access are overwhelmingly difficult. To quote my colleague  "designing the method by which users make an informed decision to grant an extension access to the filesystem is tricky".
It is important to reduce amount of privileges user can grant to an add-on to reduce attack vectors.
It is hard to design UX that would allow add-ons to request set of "must have" privileges and "nice to have" privileges that later allow turning some of the nice to haves to must haves, especially so that user can make sense what is going on and by who's behalf.
Cases that can be served with virtualized file system using indexed-db and IDBMutableFile extension must is it as it greatly reduces harm that malicious add-on can do. It could also avoid unnecessary user prompting.
As @pfrazee pointed out there are cases where actual files are better as that allows use of other tools to make changes.

Next
I have also discovered @rpl put togather idb-file-storage library that already provides Virtualized FileSystem access using IDBMutableFile that provides random file read / write requested by @mafintosh and it works completely in user-land. I think it would be best to converge on a common API with idb-file-storage as that would allow one to use virtual filesystem access without any user prompts for default case and have compatible scoped FileSystem API for cases where actual FileSystem access is desired. Later case on FileSystem.mount(...) would prompt user where user will be able to choose desired directory for restricted storage.
Your feedback
There are some consequences if we were to do this:

We would need to emulate directories somehow maybe via index or a custom files ? I'm also unsure of performance characteristics that would have.
There will be no way to set permissions. Do any of you actually care ?
There are no symlinks or hardlinks but those could probably be emulated as well.
There is no watch but given that virtual filestore will be per addon it can be emulated as well.

Essentially I wonder how much do you all care about the list above, do we even care to emulate it for virtual FS case ?
For now I'm concentrating on non virtual filesystem access that would prompt user to choose directory to get access to. In that regard I'm also wondering if you have some thoughts on:
Say you do FileSystem.mount({read:true}) and user chose some directory, but later you want to also an ability to write and watch what's do you think is reasonable ?

Just ask user to choose directory again but pre-select one that has limited access ? (That might confuse user).
Ask user somehow if (s)he's willing to also grant write access ? (What if they don't want to grant write into that directory but would rather choose a different one ?). Difficulty here is in displaying directory path).

@dominictarr in regards to

for example, stream a file in, and then move it into place when it's complete. move is a single operation so if the streaming fails, you don't move the file and the system stays consistent.

Please not that currently I don't expose any streaming into / out of file primitives, maybe once https://streams.spec.whatwg.org/ are available in gecko we'll do that, but until now it's lot of work, increased surface for bugs and is doomed to be obsolete in longer term.

@Gozala regards streaming: if we have low level write (append) and read, then I will implement streaming my self. Any built in streaming thing is only gonna wrap those primitives anyway. (in my opinion, whatwg streams are very heavy and complicated)
So what I say "stream in" that's what I meant, but I need move.
Personally, I don't have any designs using links, so I can live without those.
Also, allowing the user to select a directory is not important to me, I want files for backend stuff that the user does not directly interact with. The permission could just say "do you give this website file storage" and assign it a directory somewhere far away from the user's home folder.
clarification of the buffer and callbacks, you say:

as implementation does cross process resource juggling and underlying primitives to do so exposes promise
so this means the actual file access happens in a separate process, and then is copied into the process were the javascript runs? This isn't just a firefox api, this is an api we want other engines to also implement. Do you think the architecture will be similar in chrome and others. Even without the buffer option it this will still be much better than nothing.

I didn't know about IDBMutableFile! investigating this now!

I tried to get IDBMutableFile working... but only got to:

InvalidStateError: A mutation operation was attempted on a file storage that did not allow mutations.
and various othe things that don't make sense...

although the idb-file-storage demos do seem to work. I want a file system api that actually looks like a file system api. it should make sense to someone who understands ordinary file systems... implementing a polyfill that works on top of IDBMutableFile would be good but I would be very sad if IDB's warts end up on this file system api.

okay, I got IDBMutableFiles working via idb-file-storage module.

@Gozala  from IPFS perspective: key use for this new File System API would be a new backend for js-ipfs-repo, a more powerful alternative to current level-js store on top of IndexedDB that we could use in web-ext contexts. User does not directly interact with backend storage and ideally use of this API in default mode should not trigger any user prompts apart from approving  'storage' permission during extension install. Use of virtual filesystem and the four issues you raised (dirs, links, permissions, watch) do not impact this use case, as far I can tell.
The FileSystem.mount introducing real filesystem feels like a thing on its own, as it is bound to abstractions closer to the end user. It could enable use cases such as syncing arbitrary directories over pubsub/libp2p, but exposing user-picked paths comes with significant UX and security challenges.
It should require a separate permission in extension's manifest, unless there is a mode for mounting anonymous, writable directory within user's profile without any prompt (eg. ~/.mozilla/firefox/<profile>/extension/<ext-id>/fs/<fs-uuid>), which essentially makes it work like a virtual fs but with perks of being a real fs. I suspect a big chunk of use cases will just require a storage without the need for asking user for target location.

Say you do FileSystem.mount({read:true}) and user chose some directory, but later you want to also an ability to write and watch what's do you think is reasonable ? [..]

Just ask user to choose directory again but pre-select one that has limited access

If I had to pick, this one feels less confusing. Or just keep the API super simple and throw an Error and let extension developer to solve UX of communicating the need for unmounting and mounting a directory with extended privileges.

@dominictarr in regards to

for example, stream a file in, and then move it into place when it's complete. move is a single operation so if the streaming fails, you don't move the file and the system stays consistent.

Please not that currently I don't expose any streaming into / out of file primitives, maybe once https://streams.spec.whatwg.org/ are available in gecko we'll do that, but until now it's lot of work, increased surface for bugs and is doomed to be obsolete in longer term.

@Gozala regards streaming: if we have low level write (append) and read, then I will implement streaming my self. Any built in streaming thing is only gonna wrap those primitives anyway. (in my opinion, whatwg streams are very heavy and complicated)
So what I say "stream in" that's what I meant, but I need move.

👍 I don't really like whatwg streams all that much either, but they will have one very important feature that would be impossible to match in userland, which is if you have readable in a process A and some native transformer and then that is piped into a Writable browsers will be able to do all the IO and processing without ever entering JS event loop or copying data back and forth. That's not to justify  whatwg streams API complexity, I wish it was simple (I failed to pursue working group in that)* but that ship is sailed.

Personally, I don't have any designs using links, so I can live without those.

👍

Also, allowing the user to select a directory is not important to me, I want files for backend stuff that the user does not directly interact with. The permission could just say "do you give this website file storage" and assign it a directory somewhere far away from the user's home folder.

I've decided to go with a following:

If you just want efficient read/writes to disk, you should choose IDBMutableFile. It is already available and does not requires complex user interactions for permission etc.. I might pursue writing user-space library that wraps it to provide drop-in replacement for FileSystem API.
If you want to actually operate on filesystem (to allow users use other tools on the same files) then you should choose FileSystem API I'm currently working. It would allow you to mount directories and will prompt user for permissions. (Readme has a demo of it in action).

I could be pursueded  to also expose VirtualFileSystem API which would be just like FileSystem API except it will write files on the disk somewhere in firefox profile and will prompt user asking if it's ok to do so. I think it would only make sense if we find it impossible to implement VirtualFileSystem on top of IDBMutableFile.

@Gozala from IPFS perspective: key use for this new File System API would be a new backend for js-ipfs-repo, a more powerful alternative to current level-js store on top of IndexedDB that we could use in web-ext contexts. User does not directly interact with backend storage and ideally use of this API in default mode should not trigger any user prompts apart from approving 'storage' permission during extension install. Use of virtual filesystem and the four issues you raised (dirs, links, permissions, watch) do not impact this use case, as far I can tell.

👍 Sounds like what I'm aiming for (see https://github.com/mozilla/libdweb/issues/8#issuecomment-395538065) would fit this perfectly.

The FileSystem.mount introducing real filesystem feels like a thing on its own, as it is bound to abstractions closer to the end user. It could enable use cases such as syncing arbitrary directories over pubsub/libp2p, but exposing user-picked paths comes with significant UX and security challenges.

I think mostly this useful for whenever you want to allow users to operate on the content with other tools. Currently there is a subset of the API implemented with demo and .gif in readme showing UX interaction.

It should require a separate permission in extension's manifest, unless there is a mode for mounting anonymous, writable directory within user's profile without any prompt (eg. ~/.mozilla/firefox//extension//fs/), which essentially makes it work like a virtual fs but with perks of being a real fs.

I think this use case should just use IDBMutableFile. Am I missing use case where real fs but hidden from user is preferred over IDBMutableFile ignoring the API part of things. Only one I can think of is when you started off with VirtualFileSystem and then on users request need to move it to real directory. That would be a very simple OP if backend used real FS but then I don't think it's enough to justify this.

I suspect a big chunk of use cases will just require a storage without the need for asking user for target location.

Yes that is why I prefer IDBMutableFile base solution for that, it also has benefit of having quota management built-in. With a real FS backend it would be lot more difficult to constraint as other tools could exceed your quota etc...

If I had to pick, this one feels less confusing. Or just keep the API super simple and throw an Error and let extension developer to solve UX of communicating the need for unmounting and mounting a directory with extended privileges.

Current flow act's as follows:

If you FileSystem.mount({ read:true }) that will prompt user and will allow picking desired directory. That will return Promise<{url:"file:///Users/gozala/picked/dir/', readable:true, writable:false, watchable:false }> if and when user followed through, or promise will be rejected if user did not. It's your responsibility to store (associated with virtual fs id) URL  (will elaborate why below).
You could optionally provide url when mounting FileSystem.mount({ url:volumeURL, read:true }) returned promise will reject unless user had previously picked that directory and will succeed without prompting a user otherwise. This will work across browser sessions.
You could request additional privileges following example above FileSystem.mount({url:"file:///Users/gozala/picked/dir/', read:true, write:true}) that would prompt user but in this case popup will just ask if it's ok to also write to that directory, in this case user won't be choosing any directories.
If you ask for less privileges next time around, say user already granted read+write and in next session you just ask for read this won't cause any prompts, furthermore asking read+write in the next session will still succeed without user prompts. In other words you don't need to remember permissions you have just ask for minimum we will still keep max permissions user granted.
You can mount multiple directories. Although user will have to pick each one.

I am not really happy that user prompt is a doorhanger which can be confusing as it may seem as if page is asking you permission instead of an add-on and it's also associated with a tab, which makes very little sense. I would love if it pointed to the add-on button instead or to a hamburger firefox button if add-on does not have it, but that is something I'll look to improve after I can get APIs out.

One more piece of communication I want to do here. It turns out that exposing any kind of classes under web-extensions API is really difficult (as far as I can tell not something that can be done without landing pieces into Firefox) which is why I end up going with a sugar-free API (that might please @dominictarr 😉). I'll update all the interface definitions to reflect  that but here is a short summary:

All the path manipulation stuff will be omitted, in fact all the places that were took file paths will take file:// URLs instead (Might have to switch to filesystem:// URLs in the future). Reasons being:

Cuts down huge API surface.
There are user space libraries for it.
URL resolutions avoids all kind of cross-platform issues.

There will be no longer FileSystem instances that are scoped to mounted directory. 😞 Instead when you mount you'll get object like { url:'file:///path/to/dir', readable:true, writable:true, watchable:false} and it will be on you to remember root url and resolve to it.
All the described APIs will become static:

FileSystem.open(url, {read:true}):Promise<Reader>
FileSystem.open(url, {write:true}):Promise<Writer>
File.read(Reader, ?{?offset, ?size}):Promise<ArrayBuffer>
File.write(Writer, ArrayBuffer, ?{?offset, ?size}):Promise<number> // bytes writter
File.stat(Reader|Writer):Promise<Stat>
File.close(Reader|Writer):Promise<void>
FileSystem.read(url, ?{?offset, ?size})
FileSystem.write(url, ArrayBuffer, ?{?offset, ?size}):Promise<number> // bytes writter
FileSystem.stat(url):Promise<Stat>

I will drop APIs that don't exist in node and no-one seem to care about:

writeAtomic
openUnique

:+1: on the sugar free api.

@Gozala did we loose move?

@Gozala did we loose move?

Nope, I just did not list everything. Will only drop what's mentioned in the drop list.

Unfortunately I found out that file watching implementation in Gecko had was only implemented for windows. There is a very old Bug 958280 on file.

That's too bad!

That's too bad!

Yeah that is unfortunate. We could likely get an implementation over time, but in the meantime I would suggest using Native Messaging API in combination with a tiny node app that would notify changes back.

That's too bad!

Yeah that is unfortunate. We could likely get an implementation over time, but in the meantime I would suggest using Native Messaging API in combination with a tiny node app that would notify changes back.

I also have discovered by following bugzilla issues on the watch subject that @Noitidart did js-ctypes based implementation for watching https://github.com/Noitidart/jscFileWatcher which might be another way to go about it.

And Bug 958280 is where OS.File.watch addition had being proposed / discussed.

Submitted bug to add support for writing in given offsets https://bugzilla.mozilla.org/show_bug.cgi?id=1469974

Implementation (that lacks file watching) has landed. I don't think having this open makes sense, all the followup work should get tracked in corresponding issues.


Druid doesn't explicitly support C4 garbage collector

Description
Symptom
Running JvmMonitorTest on Azul Platform Prime (formerly known as Azul Zing, an OpenJDK based JVM) with C4 garbage collector results in timeout:
JvmMonitorTest.testGcCounts:49 TestTimedOut test timed out after 60000 milliseconds

Investigation and root cause
We investigated and additional logging in GcTrackingEmitter showed:
G1 GC:
event to map = {feed=metrics, metric=jvm/gc/cpu, service=test, host=localhost, gcName=[g1], value=0, gcGen=[old], timestamp=2023-02-21T16:56:15.839Z}

Prime:
event to map = {feed=metrics, metric=jvm/gc/count, service=test, host=localhost, gcName=[GPGC New], value=0, gcGen=[GPGC New], timestamp=2023-02-21T16:57:17.964Z}

gcGen set correctly for G1 because of the following method JvmMonitor.java#L223(there are no correct processing of Prime managers)
Due to this switch accepts an invalid string in 'emit' method(JvmMonitorTest.java#L89), GcTrackingEmitter does not update {old|young}GcCount and {old|young}GcSeen never return true.
We further found out that C4 is not in the list of explicitly known garbage collectors by Druid.
Workaround
There are two possible workarounds which make Prime "look like" it's G1. To be precise, they change the strings of memory managers to the values that G1 uses. The workarounds:

Adding -XX:+MimicG1GCMemoryManagerNames
Adding -XX:GPGCOldGCMemoryManagerName="G1 Old Generation"

Fix
We're happy to contribute the change, it seems rather straightforward. Perhaps some guidance from the Druid's team would be helpful to make sure we don't overlook any place where this needs to be changed. Any thoughts?

This is really a problem with that test more than anything.  The names that C4 is generating are fine and would "normally" flow out through metrics, just that test really wants to have some indication of young vs. old so that it can try to decide when it should stop.  The test itself is dubious if you ask me (is it trying to validate that the JVM does GC?  Or trying to validate things that the monitor does.  Likely, the JvmMonitor itself should be getting its values from an interface (with an overloaded, default implementation that delegates to the MXBeans) and the test should be passing in its own definition of that interface to generate values that the test would validate.  The fragility of the test seems to be rooted in trying to validate that the JVM does what's on the tin, which is something that I don't think our tests should be attempting to validate.

@imply-cheddar Thanks for the reply.
How do you think we should proceed? I don't really like the idea that anybody that tries to run Druid on Prime (e.g. as a sanity check) will get a failure. It will look bad for Prime, while the root cause is actually in the test. I know that there won't be really many people like this, but still, the QA guys in me just can't live with it :) Additionally, we're probably going to test Druid internally, so we don't want such false positives either.
I'm happy to contribute the change, but I don't really have that much time for it. If you could provide some pointers, that would be great.


alluxio2.6.1 on k8s,master总是无缘无故挂掉TableMatser: Journal shutdown complete,删除journal日志，才可以正常

MetricsMaster: journal checkpoint thread has been shutdown.no new logs have been found during the quied period.

@jameszd12 do you mind copying the log here? These pictures are unclear


mirror background image when repeated in x

Description
i use an 16:9 monitor an the most pictures are in 9:16 format.
nicely it is possible to repeat the picture in X, thanks for that.
but i think it will look nicer if the repeated pictures are mirrored, so they will fit together on the borders.
Please tick the boxes

[X] You've read the docs
[X] You've checked for duplicate issues

Maybe you can try going into Customize Board -> Custom CSS and using something like:
div.mantine-AppShell-root.dashboard-app-shell.mantine-gin8xc {
  background-repeat: repeat-x;
}

Hi, you can repeat / not repeat the image in the customization page:

yes repeat is clear and ok,
but i mean, that every 2. repeatet picture is mirrored,
so that the borders of the pictures match together

Without any screenshots or images of what you mean, I'm unable to help you.
Consider using custom CSS if the built in options are not enough.

row repeat x
row repeat x with mirroring

Sadly this is not possible with current web standards:
https://stackoverflow.com/questions/17949490/flip-vertically-a-background-image-every-time-it-repeat-y

@real-easy but you can mirror it yourself and upload that image. Then it will work

sure i can make my image an can upload by myself,
but if i will use random pics from unsplash.com then a mirroring feature will be very nice.

As Meier mentioned, this is not possible with CSS. You must mirror yourself.

sure i understand,
i asked for an feature,
so i know that this is actualy not possible.


fix: prevent fenced instances from using all the CPUs

After receiving the exit status, this patch clears up the postmaster error channel.
This avoids entering into a continuous spin loop.
Closes: #4623

/test limit=local

/ok-to-merge


Removes useful whitespaces

Describe the bug
A clear and concise description of what the bug is.
See here: https://github.com/lowlighter/metrics/issues/172
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error
n/a
Expected behavior
A clear and concise description of what you expected to happen.
Shouldn't remove these useful whitespaces
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

SVGO Version [e.g. 2.0.3]
NodeJs Version [e.g 14.0.4]
OS: [e.g. iOS]
NodeJS, SVG) latest
Additional context
Add any other context about the problem here.

Could you please submit svg example which is broken by svgo? I didn't find any in issue you mentioned.

Check some of the screenshots in the image

@Milo123459 Screenshots are not enough. It's hard to guess without proper reproduction.

@lowlighter will be able to shed more light. It's his project.

I didn't started investigating yet on this issue from my side so I'm not sure yet of the root cause (that's why I didn't want to open an issue here before I could confirm that it issue was from SVGO first).
I haven't a use case to share for now, though I know whitespace removal can be reproduced with v2.2 with the following:
import SVGO from "svgo"

const svg = `
<svg xmlns="http://www.w3.org/2000/svg">
  <foreignObject x="0" y="0" width="100%" height="100%">

      Lorem ipsum dolor

  </foreignObject>
</svg>`

const {data} = await SVGO.optimize(svg, {multipass:true})
console.log(data)

<svg xmlns="http://www.w3.org/2000/svg"><foreignObject x="0" y="0" width="100%" height="100%">
Loremipsumdolor
</foreignObject></svg>

There's whitespaces around the  tag which should not be removed (using xml:space="preserve" on parent does not change anything) but maybe it's the wanted behaviour.
I know using <foreignObject> with html/css inside is a bit stretching the use of svg images.
My guess is that the parser is not able to detect implicit text nodes or handle them incorrectly.

Would the txml parser fix this issue?
https://github.com/svg/svgo/pull/1301

Maybe, it seems that txml got a keepWhiteSpace option so I guess it could fix this


Add setting to display label outside of circles

Right now the labels appear on top of the circles / images. It would be great to have a setting for displaying labels outside of the circles.

Sounds good to me. The vertical space is often limited, especially on small screens, so I propose we put them immediately before the names, in bold.


Add toolbar to Word Edit screen

Requirements
In anticipation of adding new features to this dialog (besides just "suggest"), replace the suggest button
with a general-purpose toolbar having two entries:

Suggest (replacing the suggest button)
Reset (replacing the reset button)

Added Suggest and Reset items to toolbar.  Ready for more; the infrastructure is there.


Gauss Hypergeometric function (hyp2f1) diverges in two small regions of the complex plane

There are two narrow wedges in the complex plane where gauss's hypergeometric function (hyp2f1) gives implausibly large values when the function there is well defined.  In polar coordinates these wedges are approximately given by:
0.9 < r < 1.0
pi/3 < theta < pi/2
0.9 < r < 1.0
-pi/2 < theta < -pi/3
When I looked at the source code (the subroutine HYGFZ in scipy/special/specfun/specfun.f), I noticed that in the half annulus defined by 0.9 < |z| < 1.0 and real(z)>0, HYGFZ attempts to use the "1-z" transformation (see eq 15.8.4) to evaluate the hypergeometric function. However the series associated with this transformation only converges when |1-z|<1. In the wedge regions given above, |1-z|>1 and so the method fails.
Reproducing code example:
>>> import numpy as np
>>> from scipy.special import hyp2f1
>>> theta=np.linspace(np.pi/3.0,np.pi/2.0,10,dtype=np.float)
>>> z=0.95*np.exp(1.j*theta)
>>> hyp2f1(1.54,1.67,5.21,z)
array([ -2.14630605e+03 +6.71599145e+03j,
        -2.31991069e+14 +1.69689842e+14j,
        -2.50252397e+24 -3.16737713e+23j,
        -2.97640356e+33 -4.56037250e+33j,
         1.21082099e+42 -3.00909950e+42j,
         5.82402044e+50 -8.54809272e+49j,
         2.01184470e+58 +2.92349095e+58j,
        -4.16032387e+65 +6.43973917e+65j,
        -6.17050365e+72 -1.47233313e+72j,  -1.20089983e+78 -2.12896064e+79j])

In contrast, the first value in the z array should be (according to mpmath):
>>> import mpmath
>>> mpmath.hyp2f1(1.54,1.67,5.21,z[0])
mpc(real='0.9894407614789662', imag='0.52327754379886682')

Scipy/Numpy/Python version information:
scipy, numpy, sys versions
>>> print sc.__version__,np.__version__,sys.version_info
1.0.0.dev0+b579459 1.13.1 sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0)

The routine in specfun.f is probably dead code. hyp2f1 sources are here:
https://github.com/scipy/scipy/blob/59d44488320cca317cee802f80e29af6eb77b731/scipy/special/cephes/hyp2f1.c#L89

I'd like to emphasize that this issue isn't just something I saw when looking at the source code, but is something that is reproducible; see my example above in "Reproducing code example."
Also I'm pretty sure that specfun.f is the source code for hyp2f1 when z is complex.
The source code for hyp2f1 with real argument z is given in /scipy/special/cephes/hyp2f1.c.
At least that is what I gathered when looking at the python script _generate_pyx.py which generates the cython code that links the hyp2f1 ufunc with the source files of hyp2f1.c and specfun_wrappers.c--the later of which is the c wrapper for the Fortran library of special functions in specfun.f.

That's correct and it is in fact why I deleted my comment.

@FormerPhysicist Do you have a computable approximation that we can use for those parameters?

I've been using mpmath's version to benchmark scipy's implementation. So for example when I evaluate hyp2f1 at z=0.95 exp(pi/3 j) using mpmath I get the following:
>>> mpmath.hyp2f1(1.54,1.67,5.21,z[0])
mpc(real='0.9894407614789662', imag='0.52327754379886682')

In contrast, scipy's version of hyp2f1 gives the following (from my example above):
array([ -2.14630605e+03 +6.71599145e+03j,

Assuming mpmath is right, this means scipy is about 3 orders of magnitude off...

mpmath is probably correct. hyp2f1 is just a bunch of specific cases that need to be handled. Ultimately, someone will need to come up with a formula for the r and theta values. I was simply wondering whether you knew what the formula would be.

Oh I see what you mean; the exact region in the complex plane where hyp2f1 fails are those points z that satisfy the following:
0.9 < |z| < 1.0 and real(z)>0 and |z-1|>1.0
There is an analytic continuation formula that contains these regions; I've actually am thinking about submitting a PR to fix this issue.  I've emailed the scipy-dev email list with my idea to see what they think. An excerpt of my email:

My PR would basically implement the analytic continuation formula given in this paper: (Buhring, An Analytic Continuation of the Hypergeometric Series). I've already implemented this series in some prototype code written in Fortran and it agrees well with the values returned by mpmath's implementation of hyp2f1.


Duplicate issues

With each additional pipeline run, the same issues are created if they have not been resolved.
This floods the issues with duplicates.
I think this is not intended.

@the-tatanka,
Are you using GitHub online, or Enterprise (cloud or server)?

GitHub online

@the-tatanka ,
Please try v1.0.8
There was a problem with the query to pull existing issues from GitHub. The specific problem resolved and tested (by me).
Please let me know if it also solve your problem.

This solved my problem.
Thank you :)


Kubernetes Deployment & Security Patterns added

What does this PR do?
Add resource
For resources
Description
Deployment and security strategies for Kubernetes
Why is this valuable (or not)?
Published by Cloud Native Computing Foundation, where Kubernetes project graduated from, it's practical guide for deploying and securing Kubernetes clusters
How do we know it's really free?
Published by CNCF in their website
For book lists, is it a book? For course lists, is it a course? etc.
Book
Checklist:

[X] Read our contributing guidelines
[X] Search for duplicates.
[X] Include author(s) and platform where appropriate.
[X] Put lists in alphabetical order, correct spacing.
[X] Add needed indications (PDF, access notes, under construction)

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

you've added the book into the index; it would fit better into the kubernetes section on the languages page.

Hi, I've checked the languages page first in fact, and couldn't find Kubernetes section there. There were two books related with the Kubernetes but one is under Java, the other is under .NET. Then I found Cloud Computing section under books by subjects file, and in fact Kubernetes fits to Cloud Computing indeed, that's why I filed it here. Would you like me to create a Kubernetes section in languages file?

just put it with the other kubernetes books - might be under containers

Sorry for stealing your time, I've just noticed what you mean, it was in index. Just moved it into Containers section.


On ios, no audio when create webrtc connection after accept incoming call

I show incoming call from native with
    let nameCaller = alert!["caller"] as? String ?? ""
    let avatar = alert!["avatar_url"] as? String ?? ""
    let handle = alert!["handle"] as? String ?? ""
    let type = alert!["type"] as? String ?? ""

    let data = flutter_callkit_incoming.Data(id: id, nameCaller: nameCaller, handle: handle, type: type == "video" ? 1 : 0)
    SwiftFlutterCallkitIncomingPlugin.sharedInstance?.showCallkitIncoming(data, fromPushKit: true)

After tap answer button from Callkit, i will create stream and establish webrtc connection, but no audio in connection, just video works. I guest it conflict with audio session in Callkit.
The problem occurs when didActiveAudiosession callback run before webrtc connected. If after, it works fine.
Is it a bug or Is there something I missed? Thanks
P/s: If i set category is AVAudioSessionCategoryPlayback instead of AVAudioSessionCategoryPlayAndRecord it has audio but button enable speaker cannot toggle
Test on iOS 12.5
Plugin version 2.0.0

You can try with 1.0.2+1

same issue in android. Some calls have no sound, some calls have sound but very low

package version: 2.0.1+12


Dropdown Menu item stylings are hard-coded and not configurable

Hi, we're using DropdownMenuItem(), and as you can see here, such as min width, max width, and min height are hard-coded and not configurable: https://github.com/JetBrains/androidx/blob/e62838f496d592c019a3539669a9fbfd33928121/compose/material/material/src/commonMain/kotlin/androidx/compose/material/Menu.kt#L187-L193
private val MenuElevation = 8.dp
internal val MenuVerticalMargin = 48.dp
private val DropdownMenuItemHorizontalPadding = 16.dp
internal val DropdownMenuVerticalPadding = 8.dp
private val DropdownMenuItemDefaultMinWidth = 112.dp
private val DropdownMenuItemDefaultMaxWidth = 280.dp
private val DropdownMenuItemDefaultMinHeight = 48.dp

Can we make these parameters configurable, please?

Those values are used here: https://github.com/JetBrains/androidx/blob/e62838f496d592c019a3539669a9fbfd33928121/compose/material/material/src/commonMain/kotlin/androidx/compose/material/Menu.kt#L155-L159

+1

+1

+1

+1

+1. Any news about this?

+1

A lot of paddings and sizes are hardcoded in Material widgets. We should decide on a strategy to deal with them across all widgets.
Some options:

Add a CompositionLocal configuration/theme object (with defaults equal to the current Material values).
Add a configuration parameter to each widget (with defaults equal to the current Material values).

Both these options can be done by either changing the implementation of the material widgets themselves (which would require upstreaming) or by copy/pasting the widgets to a different package/module.

Has there been any progress on this?

We cannot change common public API in fork - it won't be available on Android in this case. Such things are better to track in Google issue tracker.

Thanks for the info.

+1. Any news about this?

As I already wrote above

We cannot change common public API in fork - it won't be available on Android in this case. Such things are better to track in Google issue tracker.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Feat/new sidebar

Adding fixed sidebar on above large checkpoint
screen-capture (8).webm
screen-capture (17).webm
screen-capture (19).webm

when this is ready to review?


download as an image feature is not working

I tried downloading the visualization, I was working on and the export as image feature did not work

Fix is coming

This should be resolved. Closing it for now

The export to image feature is still not working for me. The animation circle keeps on rotating, and nothing happens further.

Hi @clintanp, which browser are you using? Can you open your browser console while you export and take a screenshot of the errors if there is any?

Please see attached. I am using Firefox 61.0 (64-bit) on Windows 10.

@chintanp
Are you using the kepler.gl/#/demo app or running kepler.gl in your local environment
Seems like firefox throws an error when requesting CORS stylesheets.
I can't seem to repoduce this error in my firefox at the moment. (I m on mac).
You can try to use chrome on windows as a workaround

I am using the http://kepler.gl/#/demo app and it doesn't work in Chrome (67.0) on my machine too.  Error in chrome as below:

@chintanp are you still seeing this issue? If so, could you clear your cache and try again?
I'm unable to reproduce it and I do see the required Access-Control-Allow-Origin header sent by the server:

I tried again after clearing cache etc. but I am still getting the same error and it doesn't work for me. If it works for everyone else, then maybe something wrong with my setup.

@chintanp if you can open your network tab, find the refresh.css request, and send me a screenshot of the Header, that would be really helpful. I just helped someone debug this issue using chrome. As soon as I check the disable cache box, the image showed up.

@heshan0131 : Thank you for your persistence in helping me. I can confirm that it works for me on Chrome now. I did have to click on "Disable Cache" once, and then it has been working on Chrome since. However, this option doesn't work for Firefox, and we still have a rotating disk when trying to export in Firefox.

https://github.com/uber/kepler.gl/pull/360


Until exit condition expression adds extra @

Describe the Bug with repro steps

Add until loop in designer
Add dynamic content on left side of "Loop until" exit condition (e.g. variable named "done")
Add expression on right side of "Loop until" exit condition (e.g. "true")

The code representation of the exit condition becomes:
"expression": "@equals(@variables('done'),@true)",
Workflow can be saved in vscode, but it does not load in Azure. Function host log contains an error:
"The template language expression 'equals(@variables('done'),@true)' is not valid: the string character '@' at position '7' is not expected."
The generated code representation should be:
"expression": "@equals(variables('done'),true)",
What type of Logic App Is this happening in?
Standard (VSCode)
Are you using Preview Designer or GA Designer
Generally Available
Workflow JSON
No response
Screenshots or Videos

Browser
N/A
Additional context
No response

HI @maakku, thanks for reporting this issue, this is something we've fixed in #2270. This will be in our vscode release expected to complete by 5/17


Add allow_issuer_mismatch to the quirks type

@filmor This quirk is deprecated and therefore is not listed in the types on purpose.
https://github.com/erlef/oidcc/blob/9bba708401a7694096bac6d1d24e9eddbff4237c/src/oidcc_provider_configuration.erl#L212
Use the document overrides instead.


make cli demo data use real  subject terms

When default supported subjects are selected, the demo data cli should use some to generate entries. It is (or will be) using ror/orcid identifiers which are not topical terms for now.

Since there are no default subjects and loading subjects at demo data creation is much more involved, this should be closed.


[WIP][Help needed] Scala Native Support Fixed.

I messed up with commits, I'm not so expert of git :/
Downgraded Scalatest native version to 3.2.0-SNAP10 which is more source compatible with 3.0.x.
Cleaned up  the buid

Travis is failing because there is no scoverage for Scala Native. I have to find a way to deactivate scoverage for Native subproject:
[error] cannot link: @scoverage.Invoker$
[error] cannot link: @scoverage.Invoker$::invoked_i32_java.lang.String_unit
[info] Linking (51994 ms)
[error] cannot link: @scoverage.Invoker$
[error] cannot link: @scoverage.Invoker$::invoked_i32_java.lang.String_unit

Now I'm having problems of memory. Don't know if in last commit I increased the heap size in the right file/environment variable.

@lolgab Try increasing the -J-Xmx in build.sh. This also might be a system level issue (i.e. the system actually doesn't have enough memory). You can try uncommenting some of the other commands in show_mem in build.sh to see some more detailed info about memory usage. Also, this could be a ulimit issue. Add the following to the show_mem method to get the relevant info about this:
ulimit -Hn # Let's find out what the hard limit is
ulimit -Sn # Let's find out what the soft limit is
ps -eaf | egrep -i "sbt|java" | awk '{system("echo "$8"; lsof -p "$2" | wc -l")}' # How many files does SBT/JVM have open?

We can restructure the build to do the native compile in a different JVM if it is absolutely needed but I'd like to avoid that if possible.

We need to know memory settings after the build fail.

Whoops. Please. Change to this:
if [[ $modules == "db" ]]; then
    echo "Build Script: Doing Database Build"
    db_build || echo "Doing Database Build" && show_mem()
elif [[ $modules == "finagle" ]]; then
    echo "Build Script: Doing Finagle Database Build"
    finagle_build || echo "Doing Finagle Database Build Failed" && show_mem()
elif [[ $modules == "async" ]]; then
    echo "Build Script: Doing Async Database Build"
    async_build || echo "Async Database Build Failed" && show_mem()
elif [[ $modules == "codegen" ]]; then
    echo "Build Script: Doing Code Generator Build"
    codegen_build || echo "Code Generator Build Failed" && show_mem()
elif [[ $modules == "bigdata" ]]; then
    echo "Build Script: Doing BigData Build"
    bigdata_build || echo "BigData Build Failed" && show_mem()
else
    echo "Build Script: Doing Full Build"
    full_build || echo "Full Build Failed" && show_mem()
fi

This is probably going to take some back-and-forth so I appreciate your patience.


db-patch is not writing the file (contrary to output)

Hey, I see some really odd behaviour with v5 command line tooling for generating database patch files. Despite seeing a message that a file has been written, it never appears in my filesystem. Any pointers on how to figure out what's going on here? I can work around it by manually copying the stuff I need out of the db-dump output so it's not blocking me. I didn't have any issues on v4 so a bit stumped on what might have changed to cause this in the upgrade.
db-patch
Example: dotnet run --project my-project -- db-patch 20220406_AddMeasures.sql
Output:
Building...
Searching 'LamarCodeGeneration.Commands, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null' for commands
Searching 'Weasel.CommandLine, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null' for commands
Searching 'Marten.CommandLine, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null' for commands
Wrote migration file to /Users/me/Code/strategy/my-project/20220406_AddMeasures.sql

However, no file is actually written to disk.
db-apply
Example: dotnet run --project my-project -- db-apply
Outputs the expected DDL commands*
The schema objects are created in the database.
*It also erroneously creates tables for SelfAggregates registered with Live lifecycle. I only do that so the codegen command generates the AggregationRuntimeXyZclasses but this could be a mistake on my part.
db-dump
Example: dotnet run --project my-project -- db-dump ./dump.sql
Outputs all the DDL correctly into the specified file*
*It also erroneously creates tables for SelfAggregates registered with Live lifecycle. I only do that so the codegen command generates the AggregationRuntimeXyZclasses but this could be a mistake on my part.
Note that unlike db-patch, if I do not specify ./ as part of the file I see:
Writing SQL file to dump.sql

ERROR: System.ArgumentException: Path cannot be the empty string or all whitespace. (Parameter 'path')
   at System.IO.Directory.CreateDirectory(String path)
   at Weasel.Core.Migrations.DatabaseBase`1.WriteCreationScriptToFile(String filename)
   at Weasel.CommandLine.DumpCommand.Execute(DumpInput input)
   at Oakton.CommandExecutor.execute(CommandRun run)

Marten and Marten.CommandLine are at 5.0.0, Weasel all at 5.2.0 and Oakton at 4.1.0

db-patch works perfectly with an absolute/rooted path. When given a relative path, it outputs the file in my bin/Debug/net6.0 directory.

Fixed by a weasel update


Import "blacksheep" could not be resolved

Note: consider using Discussions to open a conversation about new features…
from datetime import datetime
from blacksheep import HttpResponse, TextContent
from blacksheep.server import Application

app = Application()

@app.route('/')
async def home(request):
    return HttpResponse(200, content=TextContent(f'Hello, World! {datetime.utcnow().isoformat()}'))

app.start()

**from blacksheep import HttpResponse, TextContent

ModuleNotFoundError: No module named 'blacksheep'**
i already install blacksheep but still not working and no module found how i can solve it? please someon gve me help

Hi @zakyyusuff
Are you perchance using Vercel? Could this be a duplicate of https://github.com/Neoteroi/BlackSheep/issues/275?
If not, can you please describe your setup, how are you using blacksheep?


Push Monitor in down not using a &msg= value for notification

📑 I have found these related issues/pull requests
Didn't find similar feature request.
🛡 Security Policy

[X] I agree to have read this project Security Policy

Description
I'm using Push Monitor with custom &msg=somemessage and with &status=up somemessage is shown at notification alert and events, but with ?status=down it only prints No heartbeat in the time window
👟 Reproduction steps
Send POST to
https://example.com/api/push/token/?status=up&msg=disk%20space%20${3}%25&ping=
https://example.com/api/push/token/?status=down&msg=disk%20space%20${3}%25&ping=
👀 Expected behavior
Expected to receive custom message also with ?status=down
😓 Actual Behavior
Receiving default No heartbeat in the time window
🐻 Uptime-Kuma Version
1.23.11
💻 Operating System and Arch
Ubuntu 20.04 LTS
🌐 Browser
Google Chrome
🖥 Deployment Environment
Docker version 24.0.7
📝 Relevant log output
No response

Currently setting the status via the push monitor is not supported.
See https://github.com/louislam/uptime-kuma/issues/1386 for further details
Our contribution guide is here: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md
=> closing as a duplicate

@CommanderStorm

it works already, we can set status up or down via Push Monitor
my request is about using/forwarding &msg= for down status to the event/notification

Please reopen this issue as Bug or Feature request

Looking into the code, indeed status is already supported:
https://github.com/louislam/uptime-kuma/blob/3cea7d4eb23eb69140a79f2eb58d1d45a98dc88e/server/routers/api-router.js#L53C13-L53C25

Cannot reproduce this not working though:

https://demo.kuma.pet/api/push/S4HVNJ6Lle?status=down&msg=abc&ping=213
https://demo.kuma.pet/api/push/S4HVNJ6Lle?status=up&msg=abc&ping=213
don't send a ping in this timeslot
https://demo.kuma.pet/api/push/S4HVNJ6Lle?status=up&msg=disk space ${3}%25&ping=213
https://demo.kuma.pet/api/push/S4HVNJ6Lle?status=down&msg=disk space ${3}%25&ping=213

@CommanderStorm
Sorry about the mistake, it works!

I can get up and down to work OK but msg isn't being passed through for me? On v1.23.13
Have tried msg=sometext and also msg="some text" but only get an OK regardless...

Again: cannot reproduce
https://demo.kuma.pet/api/push/bwOJKeirIF?status=up&msg=FALSE&ping=

Could you share your setup?
I suspect you have a second ?msg=OK somewhere or are encoding the url wrong..

Thanks for the quick reply and interesting!
After you said it was working OK for you I've tried again and interestingly found it I post the request in my browser it does indeed update the message, however if I just enter a straight curl request from the command line on my Ubuntu machine although I get a {"ok":true} response it doesn't seem to process the msg. So perhaps it's around how the URL is called?
Curl request I'm using is curl https://status.ediflyer/api/push/FhlIVwTOL0?status=up&msg=testup&ping=

OK so turns out putting quotes around the entire string seems to have the desired effect!


URL input field won't update on "Random".

When you click the "random" button the URL input field at the footer won't update itself until the next click event.
Steps:

Choose a color dragging the sliders.
Look at the Hex field. Compare with the URL input field. They are the same.
Click the "random" button.
Look at the URL input field. The value is still the same, although the Hex field has been updated.
Click anywhere in the page. The URL input field gets updated.

Thanks for the report. I've updated this to a new version and for now the random button is gone. Should I add it back this will be fixed though.


feat: add examples

Add examples folder and a project that demonstrates how to get started with templates.
Resolves: #31
A review would be appreciated @Kludex, this is nearly the first Python code that i wrote in the last 7-8 months 😬

Codecov Report

Merging #64 (154d7ca) into master (59eb9ff) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #64   +/-   ##
=======================================
  Coverage   83.68%   83.68%
=======================================
  Files           7        7
  Lines         141      141
=======================================
  Hits          118      118
  Misses         23       23

Continue to review full report at Codecov.

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

Is it enough, tho? It looks like ppl want the step by step :thinking:

Let's wait some feedback, if it is the case i need to rework on this PR and document a lot.  😬


No access to InfoWindow for Clusters and ClusterItems

I can't see a way to populate the infoWindow for a Cluster or a ClusterItem with the getTitle() and getSnippet() methods.
I'm overriding the onClick methods but are the infoWindows not accessible here? I may be missing something glaringly obvious, and if so I apologise.
Also, thanks for this library. Performance is amazing and I'm loading up to 450k markers, 200 at a time. :-)

Have just found it in ClusterItem, both getTitle() and getSnippet() were set to return null. Will close, thanks again!!


Kubeup scaleout mizar support

What type of PR is this?

/kind feature

What this PR does / why we need it:

kube-proxy of rp nodes connecting to tp masters2.
multitenancy network isolation for n-TP x n-RP scale out architecture3.
Deploy mizar daemon and operator after tp and rp ready4.
mizar preliminary installtion does not have binary installed

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Tested on scenarios blow:
1.Kubeup (scale up) with mizar: successfully except known pods issue (event-exporter, kubernetes-dashboard pods failure)
$ kubectl get pods -AT | grep mizar
system   default       mizar-daemon-blvc5<PHONE_NUMBER>282533227   1/1     Running            0          15m
system   default       mizar-daemon-rgjk6<PHONE_NUMBER>129480042   1/1     Running            0          15m
system   default       mizar-operator-5c97f7478d-rxpm6<PHONE_NUMBER>653413385   1/1     Running            0          15m

2.Kubeup (scale out 2x2) with mizar: successfully except known pods issue (event-exporter, kubernetes-dashboard pods failure)
$ kubectl get pods -AT --kubeconfig=/home/sonyali/go/src/k8s.io/arktos/cluster/kubeconfig.tp-1 -owide | grep mizar
system   default       mizar-daemon-4rd98<PHONE_NUMBER>105095960   1/1     Running            0          7m14s   <IP_ADDRESS>      sonyaperf2-022822-rp-2-minion-group-j1lr   <none>           <none>
system   default       mizar-daemon-7r94p<PHONE_NUMBER>207198367   1/1     Running            0          7m14s   <IP_ADDRESS>      sonyaperf2-022822-rp-1-minion-group-ftpx   <none>           <none>
system   default       mizar-daemon-9887b7c44-9h4rg<PHONE_NUMBER>300579381   1/1     Running            0          7m13s   <IP_ADDRESS>      sonyaperf2-022822-tp-1-master              <none>           <none>
system   default       mizar-daemon-c79bg<PHONE_NUMBER>871473986   1/1     Running            0          7m14s   <IP_ADDRESS>      sonyaperf2-022822-rp-1-minion-group-k3f2   <none>           <none>
system   default       mizar-daemon-jv7jq<PHONE_NUMBER>106541144   1/1     Running            0          7m14s   <IP_ADDRESS>      sonyaperf2-022822-rp-1-master              <none>           <none>
system   default       mizar-daemon-mnsf4<PHONE_NUMBER>211035679   1/1     Running            0          7m14s   <IP_ADDRESS>      sonyaperf2-022822-rp-2-minion-group-z89f   <none>           <none>
system   default       mizar-daemon-wnmzj<PHONE_NUMBER>320992722   1/1     Running            0          7m14s   <IP_ADDRESS>      sonyaperf2-022822-rp-2-master              <none>           <none>
system   default       mizar-operator-599b5f46b8-tmv5n<PHONE_NUMBER>710504061   1/1     Running            0          7m12s   <IP_ADDRESS>      sonyaperf2-022822-tp-1-master              <none>           <none>

$ kubectl get pods -AT --kubeconfig=/home/sonyali/go/src/k8s.io/arktos/cluster/kubeconfig.tp-2 -owide | grep mizar
system   default       mizar-daemon-58b54dc75f-l7kr7<PHONE_NUMBER>180179002   1/1     Running   0          8m9s    <IP_ADDRESS>     sonyaperf2-022822-tp-2-master              <none>           <none>
system   default       mizar-operator-d9c67967d-hsp6c<PHONE_NUMBER>099338008   1/1     Running   0          8m9s    <IP_ADDRESS>     sonyaperf2-022822-tp-2-master              <none>           <none>

3.Kubeup (scale up with default network): successfully
4.Kubeup (scale up with default network) + kubemark ( scale up with default network): successfully
5.Kubeup (scale up with default network) + kubemark ( scale out 1x1 with default network): successfully
Does this PR introduce a user-facing change?:

/approve


Remove click?

For code that signs documents on the user's behalf, I believe auditability is important. I took a brief look at click; the latest version weighs in around 5000 lines of code and has many features we don't need. Also, that its developers do not sign their release tarballs or git tags suggests that protecting developers' systems is not a high priority for them.
And I see you're duplicating some of its functionality anyway in configure() (though maybe that was just a quick band-aid that can be fixed).
Any objections to replacing click with optparser or argparse, or just doing it manually?
Incidentally, what minimum Python version do you want to target? Personally I'd go with 2.6.

Simple example of self-documenting subcommands without dependencies: http://www.welshcomputing.com/code/clock.html (doesn't handle options, but might be a starting point)

I'm fine with using argparse. Honestly, this is the first time I've used click and just wanted to try it. It works well, but I agree that the argparse could do the same with greater trust and stability.


Gandi.net annual PO Purchase Order

Functional Requirements:

[x] Complete Delegated Authority Tracker
[x] Commercial Renewals/New Request of Software requisition appendix
[x] Submit PO request to finance (inc details of all of the above, plus approvals.

Acceptance Criteria:
PO request submitted

Request submitted.


Mobius (Bulkrax): properly attach thumbnails

Story
Ref:

#27
#170

In the sample tar files, some records appear to have thumbnails. These thumbnails should be handled similarly to how we handle normal files (see #170). Instead of using these, Hyku should generate new ones.
Acceptance Criteria

[ ] Instead of using the provided thumbnails, Hyku should generate new ones based on the primary file(s)

Archived

[ ] When a matching thumbnail file is found, it should attach to the imported record

[ ] Thumbnail derivative generation should be skipped for these records

[ ] When a matching thumbnail file is not found, one should be generated by Hyrax as normal

Testing Instructions and Sample Files
Sample files

Notes
Originally the plan was to use the provided thumbnails, but not anymore.

SoftServ QA: ✅