Helm chart

Hi @alexandrevilain! First of all, I come to say you've done great work!
I made a test setup of the operator and would like to use it as the main way to manage our Temporal clusters in the future and it would be great if the operator will have the ability to install it through the helm.

I've prepared PR #437 with a chart generation. Would be great if you add it to your release pipeline.

Thanks for your contribution!
That's a really great idea!
Don't you think it could be better to run the helmify command only one time and push the first version of the helm chart in the PR ?
Then we'll have to:

update the "prepare-release" target to update helm chart
find a way to host charts maybe using github pages
update the release workflow to push the helm chart for each new releases.
What do you think ?

I think the best option is to use https://github.com/helm/chart-releaser-action as starting point.
The final release action will look like that
But you already have a static site on the operator repo, so might be good to set up publishing in another repo

Also, a possible way is to push the chart package to GitHub's package registry.
Here is an example from my fork repo:

Chart publication

$ make helm
$ helm package charts/temporal-operator
$ helm registry login ghcr.io --username ganievs
$ helm push ./temporal-operator-0.1.0.tgz oci://ghcr.io/ganievs/temporal-operator

Chart installation

$ helm template temporal-operator oci://ghcr.io/ganievs/temporal-operator/temporal-operator --version 0.1.0
$ helm install temporal-operator  oci://ghcr.io/ganievs/temporal-operator/temporal-operator --version 0.1.0

Good idea!
Pushing the chart as oci artifact is IMO the best option!

Don't you think it could be better to run the helmify command only one time and push the first version of the helm chart in the PR ?`

Don't you want to update the pull request with my previous comment ? Then we could add the chart to the oci repo !
Thanks again for your work 👍

Ok, will do

Hi @alexandrevilain! So, I rebased from the main and add pushed generated chart in the PR.

Cool! Thanks @ganievs ! I'll take time to carefully review it after the 0.15.0 release.
Looks like the generated values.yaml is a little bit complicated, IMO the controllerManager.manager it too much.
I like simpler formats like cert-manager: https://github.com/cert-manager/cert-manager/blob/master/deploy/charts/cert-manager/values.yaml
But I'll try provide valuable comments on the PR  👍

Now that:

https://github.com/alexandrevilain/temporal-operator/pull/592
https://github.com/alexandrevilain/temporal-operator/pull/437
Are merged, closing.


More interactive styling of opportunity section. Can do the same for other sections too.

@kaal-coder Please assign me this issue.

i want to contribute in this

i want to work on the issue

I want to contribute in this issue under JWOC

@rohhhit31 go for it in all the pages except home page.

@purbakundu @Codey001 @AgnishaDe raise an issue and start working on it.

@kaal-coder look into this.

good work @rohhhit31


Android: Application stuck on splashscreen

What is the current behavior?
sometimes the app stay on the splashscreen and doesn't load anything.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://jsfiddle.net or similar.
on debug mode:

launch the app
debug js remotely
kill the application
launch again

on release:
hard to reproduce but it seems to appear when the app is on background for too long.
What is the expected behavior?
launch the application.
Which versions of Redux, and which browser and OS are affected by this issue? Did this work in previous versions of Redux?
I use:
"react": "16.0.0-alpha.6",
"react-native": "0.43.3",
"react-redux": "^5.0.5",
"redux": "^3.7.0",
"redux-logger": "^3.0.1",
"redux-observable": "^0.14.1",
"redux-persist": "^4.8.1",
"redux-persist-transform-filter": "0.0.13",
And the bug appears on android
More Informations
my App.js file:
import React from 'react';

import { Provider } from 'react-redux';

import { registerScreens } from '@screens/';

import store from '@situaction/store';

import { startLogin } from '@screens/goToLogin'
import { startLoading } from '@screens/goToLoading'

import Config from 'react-native-config'

import * as session from '@session/';

// Init registers screens
registerScreens(store, Provider);

export default class Situaction {
  constructor() {
    if (__DEV__) {
      console.log(Config);
    } else {
      console.disableYellowBox = true; // -> Disable Warning in RELEASE
    }

    // LINK STORE REDUX TO APP
    console.log("will it work ?")
    const unsubscribe = store.subscribe(() => {
      console.log("yes !")
			if (store.getState().services.persist.isHydrated) {
        console.log("it works !")
				unsubscribe();
				this.autoLogin();
			}
		});
    console.log("nope")
  }

  // AUTO LOGIN CHECK IF SESSION EXIST AND VALIDITY
  autoLogin() {
    session.refreshToken().then(() => {
      startLoading() // HAVE SESSION
    }).catch(() => {
      startLogin() // NO SESSION
    });
	}
}

output when bug appears:

will it work ?
nope

output when bug doesn't appear:

will it work ?
nope
yes !
yes !
it's working !

This is a bug tracker, not a support system. For usage questions, please use Stack Overflow or Reactiflux where there are a lot more people ready to help you out - you'll probably get a better answer faster. Thanks!

Thanks for your  answer, I'll put this issue on Stack Overflow, have a nice day !


Prep for paid version(s)

Discounted for early-adopters of course!

[ ] Stripe billing page thingy
[ ] Binary distribution / licensing
[ ] Some kind of way to signal that parts of the docs are pro/ent only
[ ] Decide on monthly / annual or both
[ ] Decide how versioning will work
[ ] Decide if licenses are metered at all (# of domains, etc)
[ ] Add plan to analytics
[ ] Add up upgrade support

Tempted to do annual only, less serious people could just pay the $x, download the bin and cancel right away, at least unless I do periodic checks to verify the license.
I'm fine with it being Sketch-like in that you only pay while you want it to stay current, but if that were monthly I may have to charge more to account for all the people who would just pay/bail.
Another alternative is to do annual only and provide money-back guarantees of some sort, but that may become annoying. I think annual would be ok, less serious people can just stick with the OSS version.
Metering would be great to some extent, a few people plan on using Up for hundreds of domains, so paying say $15/m (or whatever it is) is maybe not proportionate to the value.

#375


Error compiling Dart Debug Extension with DDC

Encountered an error compiling the Dart Debug Extension with DDC (dart2js succeeds).

Here are the changes that have caused it to fail (works on master branch): https://github.com/dart-lang/webdev/compare/master...elliette:dde-mv3
Instructions on how to compile: https://github.com/dart-lang/webdev/blob/master/dwds/debug_extension/CONTRIBUTING.md#building

 $ dart run build_runner build web -o build
[INFO] Generating build script completed, took 456ms
[INFO] Reading cached asset graph completed, took 224ms
[INFO] Checking for updates since last build completed, took 750ms
[WARNING] extension|tool/copy_builder.dart was not found in the asset graph, incremental builds will not work.

[WARNING] Invalidating asset graph due to build script update!
[INFO] Cleaning up outputs from previous builds. completed, took 209ms
[INFO] Generating build script completed, took 89ms
[WARNING] Invalidated precompiled build script due to missing asset graph.
[INFO] Precompiling build script... completed, took 826ms
[WARNING] extension|tool/copy_builder.dart was not found in the asset graph, incremental builds will not work.

[INFO] Building new asset graph completed, took 1.3s
[INFO] Checking for unexpected pre-existing outputs. completed, took 1ms
[SEVERE] build_web_compilers:ddc on web/background.ddc.module:
Error compiling dartdevc module:extension|web/background.sound.ddc.js

We're sorry, you've found a bug in our compiler.
You can report this bug at:
    https://github.com/dart-lang/sdk/issues/labels/web-dev-compiler
Please include the information below in your report, along with
any other information that may help us track it down. Thanks!
-------------------- %< --------------------
    dartdevc -k arguments: --dart-sdk-summary=/Users/elliottbrooks/.dart-sdks/2.17.3/lib/_internal/ddc_outline_sound.dill --modules=amd --no-summarize -o web/background.sound.ddc.js --source-map --summary=packages/js/js.sound.ddc.dill=packages/js/js --summary=packages/js/js_util.sound.ddc.dill=packages/js/js_util --summary=packages/meta/meta_meta.sound.ddc.dill=packages/meta/meta_meta --summary=packages/meta/meta.sound.ddc.dill=packages/meta/meta --summary=packages/collection/src/utils.sound.ddc.dill=packages/collection/src/utils --summary=packages/collection/src/algorithms.sound.ddc.dill=packages/collection/src/algorithms --summary=packages/collection/src/iterable_zip.sound.ddc.dill=packages/collection/src/iterable_zip --summary=packages/collection/src/comparators.sound.ddc.dill=packages/collection/src/comparators --summary=packages/collection/src/priority_queue.sound.ddc.dill=packages/collection/src/priority_queue --summary=packages/collection/src/canonicalized_map.sound.ddc.dill=packages/collection/src/canonicalized_map --summary=packages/collection/collection.sound.ddc.dill=packages/collection/collection --summary=packages/pub_semver/pub_semver.sound.ddc.dill=packages/pub_semver/pub_semver --summary=packages/path/path.sound.ddc.dill=packages/path/path --summary=packages/stack_trace/src/chain.sound.ddc.dill=packages/stack_trace/src/chain --summary=packages/async/async.sound.ddc.dill=packages/async/async --summary=packages/pool/pool.sound.ddc.dill=packages/pool/pool --summary=packages/logging/logging.sound.ddc.dill=packages/logging/logging --summary=packages/stream_channel/stream_channel.sound.ddc.dill=packages/stream_channel/stream_channel --summary=packages/sse/client/sse_client.sound.ddc.dill=packages/sse/client/sse_client --summary=packages/typed_data/src/typed_buffer.sound.ddc.dill=packages/typed_data/src/typed_buffer --summary=packages/typed_data/typed_buffers.sound.ddc.dill=packages/typed_data/typed_buffers --summary=packages/typed_data/src/typed_queue.sound.ddc.dill=packages/typed_data/src/typed_queue --summary=packages/crypto/crypto.sound.ddc.dill=packages/crypto/crypto --summary=packages/web_socket_channel/src/copy/io_sink.sound.ddc.dill=packages/web_socket_channel/src/copy/io_sink --summary=packages/web_socket_channel/html.sound.ddc.dill=packages/web_socket_channel/html --summary=packages/built_value/json_object.sound.ddc.dill=packages/built_value/json_object --summary=packages/built_collection/built_collection.sound.ddc.dill=packages/built_collection/built_collection --summary=packages/fixnum/fixnum.sound.ddc.dill=packages/fixnum/fixnum --summary=packages/built_value/serializer.sound.ddc.dill=packages/built_value/serializer --summary=packages/built_value/built_value.sound.ddc.dill=packages/built_value/built_value --summary=packages/dwds/data/devtools_request.sound.ddc.dill=packages/dwds/data/devtools_request --summary=packages/dwds/data/isolate_events.sound.ddc.dill=packages/dwds/data/isolate_events --summary=packages/dwds/data/build_result.sound.ddc.dill=packages/dwds/data/build_result --summary=packages/dwds/data/extension_request.sound.ddc.dill=packages/dwds/data/extension_request --summary=packages/dwds/data/connect_request.sound.ddc.dill=packages/dwds/data/connect_request --summary=packages/dwds/data/run_request.sound.ddc.dill=packages/dwds/data/run_request --summary=packages/dwds/data/debug_event.sound.ddc.dill=packages/dwds/data/debug_event --summary=packages/dwds/data/register_event.sound.ddc.dill=packages/dwds/data/register_event --summary=packages/dwds/data/error_response.sound.ddc.dill=packages/dwds/data/error_response --summary=packages/dwds/data/serializers.sound.ddc.dill=packages/dwds/data/serializers --summary=packages/dwds/src/utilities/batched_stream.sound.ddc.dill=packages/dwds/src/utilities/batched_stream --summary=web_api/chrome_browser_action.sound.ddc.dill=web_api/chrome_browser_action --summary=web_api/chrome_debugger.sound.ddc.dill=web_api/chrome_debugger --summary=web_api/api.sound.ddc.dill=web_api/api --summary=packages/dwds/src/sockets.sound.ddc.dill=packages/dwds/src/sockets --packages=.dart_tool/package_config.json --module-name=web/background --multi-root-scheme=org-dartlang-app --multi-root=. --track-widget-creation --inline-source-map --libraries-file=file:///Users/elliottbrooks/.dart-sdks/2.17.3/lib/libraries.json --experimental-emit-debug-metadata --used-inputs-file=/var/folders/wy/0pdp3vd16xv2q3d5dfqb1x7400lsm6/T/ddk_builder_h96W9N/used_inputs.txt web/background.dart --sound-null-safety
    dart --version: 2.17.3 (stable) (Wed Jun 1 11:06:41 2022 +0200) on "macos_x64"

Unsupported operation: static members do not support "." in their names. See https://github.com/dart-lang/sdk/issues/27926
#0      ProgramCompiler._emitJSInteropStaticMemberName (package:dev_compiler/src/kernel/compiler.dart:2599:9)
#1      ProgramCompiler._emitStaticMemberName (package:dev_compiler/src/kernel/compiler.dart:2542:20)
#2      ProgramCompiler._emitStaticTarget (package:dev_compiler/src/kernel/compiler.dart:5598:11)
#3      ProgramCompiler.visitStaticInvocation (package:dev_compiler/src/kernel/compiler.dart:5532:14)
#4      StaticInvocation.accept (package:kernel/ast.dart:6289:44)
#5      ProgramCompiler._visitExpression (package:dev_compiler/src/kernel/compiler.dart:3858:20)
#6      ProgramCompiler.visitExpressionStatement (package:dev_compiler/src/kernel/compiler.dart:3939:12)
#7      ExpressionStatement.accept (package:kernel/ast.dart:8829:43)
#8      ProgramCompiler._visitStatement (package:dev_compiler/src/kernel/compiler.dart:3764:20)
#9      MappedListIterable.elementAt (dart:_internal/iterable.dart:413:31)
#10     ListIterator.moveNext (dart:_internal/iterable.dart:342:26)
#11     new _GrowableList._ofEfficientLengthIterable (dart:core-patch/growable_array.dart:189:27)
#12     new _GrowableList.of (dart:core-patch/growable_array.dart:150:28)
#13     new List.of (dart:core-patch/array_patch.dart:51:28)
#14     ListIterable.toList (dart:_internal/iterable.dart:213:44)
#15     ProgramCompiler.visitBlock (package:dev_compiler/src/kernel/compiler.dart:3952:62)
#16     Block.accept (package:kernel/ast.dart:8885:43)
#17     ProgramCompiler._visitStatement (package:dev_compiler/src/kernel/compiler.dart:3764:20)
#18     ProgramCompiler._emitFunctionScopedBody (package:dev_compiler/src/kernel/compiler.dart:3797:18)
#19     ProgramCompiler._emitSyncFunctionBody.<anonymous closure> (package:dev_compiler/src/kernel/compiler.dart:3566:17)
#20     ProgramCompiler._withLetScope (package:dev_compiler/src/kernel/compiler.dart:2366:25)
#21     ProgramCompiler._withCurrentFunction (package:dev_compiler/src/kernel/compiler.dart:3600:18)
#22     ProgramCompiler._emitSyncFunctionBody (package:dev_compiler/src/kernel/compiler.dart:3562:17)
#23     ProgramCompiler._emitFunction (package:dev_compiler/src/kernel/compiler.dart:3379:11)
#24     ProgramCompiler._emitLibraryFunction (package:dev_compiler/src/kernel/compiler.dart:2748:14)
#25     MappedIterator.moveNext (dart:_internal/iterable.dart:391:20)
#26     new _GrowableList._ofOther (dart:core-patch/growable_array.dart:202:26)
#27     new _GrowableList.of (dart:core-patch/growable_array.dart:152:26)
#28     new List.of (dart:core-patch/array_patch.dart:51:28)
#29     Iterable.toList (dart:core/iterable.dart:470:12)
#30     ProgramCompiler._emitLibraryProcedures (package:dev_compiler/src/kernel/compiler.dart:2713:10)
#31     ProgramCompiler._emitLibrary (package:dev_compiler/src/kernel/compiler.dart:578:7)
#32     List.forEach (dart:core-patch/growable_array.dart:416:8)
#33     ProgramCompiler.emitModule (package:dev_compiler/src/kernel/compiler.dart:431:15)
#34     _compile (package:dev_compiler/src/kernel/command.dart:441:27)
<asynchronous suspension>
#35     compile (package:dev_compiler/src/kernel/command.dart:50:12)
<asynchronous suspension>
#36     _CompilerWorker.performRequest (package:dev_compiler/ddc.dart:68:18)
<asynchronous suspension>
#37     AsyncWorkerLoop.run (package:bazel_worker/src/worker/async_worker_loop.dart:35:20)
<asynchronous suspension>
#38     internalMain (package:dev_compiler/ddc.dart:31:5)
<asynchronous suspension>

[WARNING] build_web_compilers:entrypoint on web/background.dart:
Unable to read extension|web/background.sound.ddc.js, check your console or the `.dart_tool/build/generated/extension/web/background.sound.ddc.js.errors` log file.
[SEVERE] build_web_compilers:entrypoint on web/background.dart:

AssetNotFoundException: extension|web/background.sound.ddc.js.metadata
[INFO] Running build completed, took 8.2s
[INFO] Caching finalized dependency graph completed, took 180ms
[SEVERE] Failed after 8.4s

It seems like that PR introduces some non-top-level @JS members with .. Is it possible to make the edits suggested in https://github.com/dart-lang/sdk/issues/27926 for those classes?

That is strange that this isn't caught before the backend by _js_interop_checks (see https://dart-review.googlesource.com/c/sdk/+/247180 for the CL that added this change). I believe methods like:
@JS()
class ChromeBrowserAction {
  @JS('chrome.browserAction.onClicked.addListener')
  external static void onClickedAddListener(Function callback);
}

are intended to be kept as a top-level instead (or a class member through nested interfaces to avoid the '.'). cc @sigmundch for more details.

Oops I completely missed that bug link! Everything is working with refactoring to avoid .s in the method namespaces: https://github.com/dart-lang/webdev/commit/7ffb9fad3d52c62cd07cbd22a08fa46b56a3c123
Personally I think:
@JS('chrome.browserAction')
class ChromeBrowserAction {
  @JS('setIcon')
  external static void setIcon(IconInfo iconInfo);

  @JS('onClicked.addListener')
  external static void onClickedAddListener(Function callback);
}

is nicer than:
@JS('chrome.browserAction')
class ChromeBrowserAction {
  @JS('setIcon')
  external static void setIcon(IconInfo iconInfo);
}

@JS('chrome.browserAction.onClicked')
class ChromeBrowserActionOnClicked {
  @JS('addListener')
  external static void addListener(Function callback);
}

but it's understandable if it doesn't work that way. This is something nested static classes could help solve as well.

I agree. That 2nd snippet feels much more clunky (and difficult to logically associate) than the former (or something with nested classes). Here's hoping the language team chimes in on that thread.
Glad things are working now!

Indeed, I expect this will be reported as a static error in the future. It appears the crash above was with the current stable 2.17.3 SDK, which doesn't have this change. It is available in the current 2.18 beta, though.
@elliette - sorry our documentation on JSInterop is really lacking at the moment. Here are a couple suggestions that may help here.
In some cases, it makes sense to expose those static members as top-level methods directly:
@JS('chrome.browserAction.onClicked.addListener')
external addOnClickedListener(Function callback);

You can also avoid multiple static entry classes if you use a static member for each non-dotted name. For instance,
@JS('chrome.browserAction')
class ChromeBrowserAction {
  @JS('setIcon')
  external static void setIcon(IconInfo iconInfo);

  external static ChromeBrowserActionOnClicked get onClicked;
}

@JS()
@anonymous
class ChromeBrowserActionOnClicked {
  @JS('addListener')
  external static void addListener(Function callback);
}

which allows you to write:
ChromeBrowserAction.onClicked.addListener(f);

instead of
  ChromeBrowserActionOnClicked.addListener(f);

More often than not, it's nice to only use a static/top-level for the first entry in the dotted name, and then use regular instance member for each property in the dotted name:
That would look more like this:
@JS()
Chrome get chrome;

@JS()
@anonymous
class Chrome {
   // Note: static is gone, now it is treated as an instance method of
   // the chrome instance returned by the getter above.
  external BrowserAction get browserAction;
}

@JS()
@anonymous
class BrowserAction {
  // Note: @JS not needed here (the js name is inferred from the Dart name)
  external void setIcon(IconInfo iconInfo);
  external OnClickedHandler get onClicked;
}

@JS()
@anonymous
class OnClickedHandler {
  external void addListener(Function callback);
}

Which allows you to write:
chrome.browserAction.onClicked.addListener(f)

Note that this last approach gives you a better IDE experience too (e.g. discoverability, completion).
The quality of the generated interop code is not optimal today with this approach, that will improve with static interop (which we are actively working on at the moment). Unfortunately today static interop is a bit more verbose until we get a new language feature (view classes). Under the current prototype, the example above would need to be tweaked as follows to use static interop:
@JS()
Chrome get chrome;

@JS()
@anonymous
@staticInterop // new!
class Chrome {}

extension ChromeExtension on Chrome { // code split into an extension
  external BrowserAction get browserAction;
}

@JS()
@anonymous
@staticInterop
class BrowserAction {}

extension BrowserActionExtension on BrowserAction {
  external void setIcon(IconInfo iconInfo);
  external OnClickedHandler get onClicked;
}

@JS()
@anonymous
@staticInterop
class OnClickedHandler { }

extension OnClickedHandlerExtension on OnClickedHandler {
  external void addListener(Function callback);
}

With this you can access the API just like in the previous example:
chrome.browserAction.onClicked.addListener(f)

However, the code generated with dart2js will likely match that of the code using the dotted names in the JS annotation.
Hope you find this useful!

Thank you @sigmundch for the detailed examples, that is very helpful!


Correct spelling mistakes

Coverage decreased (-15.8%) to 56.977% when pulling e4020e6a4ce76b9402478628c27326b553e90132 on EdwardBetts:spelling into 7730144dec01b4cdbf0205b936a200e54a287ebb on Miserlou:master.


Pixel Launcher crashing

Device name: Realme C55
Rom name: RMX3710226AE_11_A.59
Android version: 13
Pixelify version: v3
Bug Description: The module installs correctly but when setting the Pixel Launcher as the system launcher it just crashes, unlike the previous version of Pixelify (v2.2).

Crashing on OnePlus Open running OxygenOS as well.

crashing in miui 14 as well
device:Redmi note 10t 5g

Crashing on OnePlus Open running OxygenOS as well.

Same OOS 13.2 / Android 13


Update RGFW

General quality of life updates

fix bugs in monitor support
fix warnings
reduce xDnD and X Clipboard code
I don't remember

@ColleagueRiley Thanks for the review, is this PR ready for merge or some more commits need to be added?

This should be good to be merged.

@ColleagueRiley Thanks! Merged!


RKManagedObjectCache delete everything and re-fetch every time

It looks like everything is deleted and re-fetched every time I load data (where is caching?).
Main problem for me is that I load data partially, and as a result, at the end I have only data from last call. Is this correct?
if is I load resource
/some/23/data.json

then
/some/56/data.json

I have only data from "56" because "23" was deleted.
This is how my RKManagedObjectCache is declared.
- (NSArray*)fetchRequestsForResourcePath:(NSString*)resourcePath {
if ([resourcePath<EMAIL_ADDRESS>{
    NSFetchRequest* fetchRequest = [MyManagedClass fetchRequest]; // A fetch request with an entity set, but nothing else fetches all objects
    return [NSArray arrayWithObject:fetchRequest];
}
}

and data is loaded with
[[RKObjectManager sharedManager] loadObjectsAtResourcePath [NSString stringWithFormat<EMAIL_ADDRESS>currentId] delegate:nil];

Is it intended to work this way?

Closing the issue as invalid


Loading split .pdb files for large structures

Is there a syntax for loading multiple/split .pdb files? Large structures (e.g. 5XTH) are not contained in a single .pdb file, but rather multiple ones (either that or a single .cif/.xlm file). I suspect there must be a way since the web interface has no problem fetching the complete structure from the PBD ID alone, but I'm having trouble pulling that off using the command file.

Currently, no. The program is limited to single files with traditional PDB format. A kludgey work-around is to append all the files into one big file. I think the current version is limited to 350,000 atoms, so if you end up with something larger, you'll need to go into the Fortran and increase the size of the arrays.


Bump wasm-opt to alleviate CPU idle in optimization phase

💡 Feature description
Bump the bundled wasm-opt's version
💻 Basic example
In the current bundled wasm-opt (which is v0.111.0), the optimization phase takes a very long time (~7mins) in my project. And from htop most of the CPU are red.
I've tried to run the latest wasm-opt (8854bd8a58d7393c7bacd950884aea521ce8e19f) and it only takes 1min now:
time ./target/release/wasm-opt datafusion-wasm-bindings/pkg/datafusion_wasm_bg.wasm -o  datafusion-wasm-bindings/pkg/datafusion_wasm_bg.wasm-opt.wasm -O
./target/release/wasm-opt  -o  -O  241.60s user 1.79s system 404% cpu 1:00.12 total

Update:
For those who find the wasm-opt takes abnormal long time, try download it yourself instead of letting wasm-pack to install one with cargo install wasm-opt. wasm-pack will now try to use the local installed wasm-opt first.


feat: add hydra_lsp

Add hydra language server for Hydra yaml config files.
Really popular in Python research community for configuration of experiments.

doesn't support single file mode ?

doesn't support single file mode ?

Yes, you are right. Added single_file_support


Feature subpages

I have extended Minimal with a feature that allows users to add pages to a folder called _sitepages and to automatically get links to those pages just below the header. I added this feature to one of my own projects and wanted to contribute it back to the Minimal-project. I would love to get a review and your thoughts around this. I kept this feature as simple as possible, so no highlighting of selected page or other fancy styling.
What I have commited:
I have updated the default layout, added a new layout called "page.html", added 3 sample pages in the _sitepages folder and updated the README file with how-to. I have also added the "--assume-extension" flag to html-proofer in cibuild to correctly test the pages.
This is my first time contributing to a GitHub-theme, so I am not sure whether to keep the 3 samples pages (in the _sitepages folder) or to delete them. I kept them for now so you could take a look at it.
How does it look:
Below is an image of how these 3 sample pages will look on the generated site.

@dervism thanks for this! Rather than creating a new collection, (what's the difference between a page and a sitepage?), would a subpage or similar front-matter or config flag make more sense?

@benbalter You are absolutely correct. I have simplified the code now. It uses site.pages instead now. All pages (if their title property is defined) will be included in the sidebar. A user can now hide a page by setting sidebar to false. I have updated the documentation about this.
With this change, I do not need the demo pages I added (I can test it another-page.html that exists in your repo), so I deleted that folder to keep this PR as small as possible. I can add it back if you think it's ok to have them there.

Exactly one of the simple yet useful features I've been looking for in this theme! 👍

@benbalter I love to have a second review of the changes you requested.

I am closing this due to no answer. Please feel free to open it if anyone wishes the same feature.


Problem with CSS and ALT image

Issue description:
I want to create a content slider carousel, and set css for each element, as soon as I set the css, the carousel does not work.
if I set the image width from css, the carousel does not work.
also adding the altimage, the carousel does not work.
if set position: absolute; image, the carousel does not work.
premise with owl-carousel, it worked
Demo link/slider setting:
------------------SCRIPT------------------
var slider_= tns({
container: '#slider-home',
controls: false,
nav: false,
autoplayButtonOutput: false,
autoplay: true,
speed: 800,
loop: true,
items: 1,
mouseDrag: true,
lazyload: true,
autoWidth: true,
//autoHeight: true,
});
------------------HTML------------------
|div id="slider-home" |a href="url" |div class="slider_home_container" |div class="slider_home_img" |img id="slider_home_img_img" class="tns-lazy-img" width="500" data-src="image" alt="alt" |/div  |div class="slider_home_txt" |h1 title /h1 |/div |/div |/a |/div`
------------------CSS------------------
#slider-home  #slider_home_img_img {
position: relative;
margin: auto;
width: auto !important;
max-height: 300px;
top: 50%;
left: 50%;
transform: translate(-50%,-50%);
}

Tiny-slider version:
Browser name && version:
OS name && version:

Hi Guys I solved, I rewrote everything from scratch again and now it works. I reviewed the code, a quotation mark was missing.


[Feature] link x and y axisPointers to snap to series

What problem does this feature solve?
The current snapping functionality snaps to the x or y value that is the closest to the cursor. What would be even more useful is to snap simultaneously to the closest x and y value of the series since users mostly are not interested in seeing values of x and y values that are independent. Further it would simplify and streamline the user experience of using the chart.
Please find an example below how that would look if snapping would be linked.

https://codepen.io/djdjoko/full/xxzKJYJ
What does the proposed API look like?
axisPointer property would need to be added to 'grid' property or axisPointers need or axisPointer snap defined on xAxis needs to be linked to axisPointer snap on yAxis

Duplicate of #16675

Has the function of line chart been realized?

This would be really convenient to include, has any progress been made with it?


Use Pod with an existing PV without PVC

In your example with azure file PV. Can I use an existing PV in my pod.yml without PVC?

no, pods can only use PVs via PVCs
/close


Deductions aren't boosted

*Description of issue:
The permissions for the job boost (jobs.boost.[jobname].money.[amount] + jobs.boost.[jobname].exp.[amount]) only increase exp and money earnings, but don't boost negative values. Therefore, subtractions under Place are not calculated according to the boost. This causes the anti-cheat mechanism to be overridden by deductions when the boost is removed.
Example:
config values:
  Break:
      diamond_ore:
        income: 20.32
        experience: 20.32
  Place:
      diamond_ore:
        income: -20.32
        experience: -20.32

With an income-boost of 25% and an exp-boost of 100% the player actually gets an income of 25.40 and 40.64 exp. However, the deductions are not calculated based on the permission, but drawn from the config, so only 20.32 income/exp is deducted when placing diamond_ore.

Therefore it is possible to cheat by simply placing and breaking diamond_ore when boosts are active. It would be great if this could be fixed.
Server Type (Spigot/Paperspigot/etc):
Paper build 466
Server Version (using /ver):
1.16.5
Relevant plugins (Delete if this isn't needed):
Jobs  4.17.0

https://github.com/Zrips/Jobs/commit/7a17a982da88b0d84c83ca18353324c04a82dcee


Disable noisy _BetaConfiguration warnings using PYTHONWARNINGS=ignore:BetaConfiguration

Discussed in https://github.com/pypa/setuptools/discussions/3895

Originally posted by @ssbarnea April 18, 2023
Apparently setuptools is polluting the console logs with lots of unactionable warnings, like the one below:
_BetaConfiguration: Support for `[tool.setuptools]` in `pyproject.toml` is still *beta*

The reality is that there is nothing actionable about it as if the package maintainer decided to make use of the new standard, there is no point to spam them with every installation happening.
There are two other warnings that I find annoying but these might prove to be a little bit useful, especially as one of them seems to be have an open bug.

Getting build dependencies for wheel...
/tmp/build-env-k3gfydhv/lib/python3.9/site-packages/setuptools_scm/git.py:295: UserWarning: git archive did not support describe output
warnings.warn("git archive did not support describe output")
/tmp/build-env-k3gfydhv/lib/python3.9/site-packages/setuptools_scm/git.py:312: UserWarning: unexported git archival found
warnings.warn("unexported git archival found")
/tmp/build-env-k3gfydhv/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py:108: _BetaConfiguration: Support for [tool.setuptools] in pyproject.toml is still beta.
warnings.warn(msg, _BetaConfiguration)
running egg_info
writing src/ansible_lint.egg-info/PKG-INFO
writing dependency_links to src/ansible_lint.egg-info/dependency_links.txt
writing entry points to src/ansible_lint.egg-info/entry_points.txt
writing requirements to src/ansible_lint.egg-info/requires.txt
writing top-level names to src/ansible_lint.egg-info/top_level.txt
listing git files failed - pretending there aren't any
reading manifest file 'src/ansible_lint.egg-info/SOURCES.txt'
adding license file 'COPYING'
writing manifest file 'src/ansible_lint.egg-info/SOURCES.txt'
Installing packages in isolated environment... (wheel)
Building wheel...
/tmp/build-env-k3gfydhv/lib/python3.9/site-packages/setuptools_scm/git.py:295: UserWarning: git archive did not support describe output
warnings.warn("git archive did not support describe output")
/tmp/build-env-k3gfydhv/lib/python3.9/site-packages/setuptools_scm/git.py:312: UserWarning: unexported git archival found
warnings.warn("unexported git archival found")
/tmp/build-env-k3gfydhv/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py:108: _BetaConfiguration: Support for [tool.setuptools] in pyproject.toml is still beta.
warnings.warn(msg, _BetaConfiguration)
running bdist_wheel

Proposal
Like with other warnings, a project maintainer should be allowed to disable this warning. The act of setting an environment variable like PYTHONWARNINGS=ignore:BetaConfiguration should be acknowledgement enough that the using project has accepted that it is using a beta feature.

_BetaConfiguration should be gone in the latest release.


baseLocationService.d.ts:BaseLocationServices needs onChange overload

[x] Bug Report
[ ] Feature Request
[ ] General Query

My version of UI-Router is: 1.0.20
tsconfig.json compiler options:
{
  "compilerOptions": {
    "strict": true,
    "module": "commonjs",
    "outDir": "www/staging/js",
    "rootDir": "src/",
    "sourceMap": false,
    "target": "es5",
    "experimentalDecorators": true
  }, //..
}

Typescript v3.1.3 reports:
node_modules/@uirouter/core/lib/vanilla/baseLocationService.d.ts(43,5): error TS2416: Property
'onChange' in type 'BaseLocationServices' is not assignable to the same property in base type
'LocationServices'.
  Type '(cb: EventListener) => () => Function[]' is not assignable to type '(callback: Function) =>
Function'.
    Types of parameters 'cb' and 'callback' are incompatible.
      Type 'Function' is not assignable to type 'EventListener'.
        Type 'Function' provides no match for the signature '(evt: Event): void'.

>> 1 non-emit-preventing type warning
>> Error: tsc return code: 2

There seems to be an incompatibility with the onChange method on LocationServices, which implements the UrlService.onChange signature of (callback: Function) => Function;
Was able to resolve this by adding the required overload, which satisfies the LocationServices interface:
onChange(cb: Function): Function;
I'm not sure if this is a sound fix, but it worked for me.

Realized this should be in "core". Closing.


Invalidate cache load status on historical as soon as it is served

Description
Follow up to #11717
This PR attempts to fix the behaviour in the following scenarios:
Case 1: Coordinator gets incorrect response in case of a quick load-drop-load

Historical receives HTTP request to load segment S.
Load succeeds and the cache now has an entry to the effect "LOAD S was SUCCESS".
HTTP request completes with SUCCESS but the entry is still there in the cache.
Historical receives request to drop segment S and request finishes successfully but cache still has entry for "LOAD S was SUCCESS"
Historical receives request to reload segment S. Since we already have an entry in cache, historical incorrectly responds with "LOAD S was SUCCESS" even though the segment has already been dropped from the historical.

Case 2: Coordinator sees a repeatedly failing load as PENDING rather than FAILED

Coordinator requests Historical to load segment.
Request completes while load is still in progress and gets back a PENDING response
Then load fails and FAILED status is cached
Coordinator checks with the Historical if it has loaded the segment.
Since we already have a cached FAILED status, we retry the load and send back a PENDING response instead (see snippet below)
Repeat

https://github.com/apache/druid/blob/efb32810c48fd9c0bf81cefb15179f74a4cde661/server/src/main/java/org/apache/druid/server/coordination/SegmentLoadDropHandler.java#L562-L563
Case 3:

Coordinator requests historical to load segment.
Historical queues load task on executor.
Coordinator requests historical to drop segment and the Historical

unannounces the segment immediately
adds an entry to segmentsToDrop
schedules drop task on executor for 30s later

Load task starts and removes this segment from segmentsToDrop and proceeds with downloading the segment.
Load task finishes and announces the segment but is not able to update success status since the latest request is a Drop.
Drop task does not do anything since the segment is not present in segmentsToDrop anymore. Thus the result holder remains stuck in pending state.
All subsequent drop requests will be answered with PENDING (at least until the cache entry expires) without ever actually trying to drop the segment.
Only a subsequent load request will clear this state.

Similarly a drop that comes before a load might result in partial or complete delete of segment files but the load task might continue to think that it succeeded.
Classes to review

SegmentLoadDropHandler
SegmentLoadDropHandlerTest

Changes

Rename DataSegmentChangeRequestAndStatus to DataSegmentChangeResponse
Move DataSegmentChangeResponse out of SegmentLoadDropHandler as it is a POJO returned to the client and need not be tied to a specific loader implementation.
Update requestStatuses cache to be a map from DataSegment to the full DataSegmentChangeResponse
Remove entry from cache as soon as it is consumed to be sent back to the client
Remove entry from cache if a different type of request is received for the same segment
Rename and rearrange some methods for readability
Clean up tests and add more test cases for the new behaviour

Release note
Fix bug on historical when a load-drop-load of a segment happens in quick succession.

This PR has:

[x] been self-reviewed.

[ ] using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)

[ ] added documentation for new or modified features or behaviors.
[x] a release note entry in the PR description.
[x] added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
[ ] added or updated version, license, or notice information in licenses.yaml
[x] added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
[x] added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
[ ] added integration tests.
[x] been tested in a test Druid cluster.

Also moved out DataSegmentChangeResponse into a class of its own.

@gianm , there is another case which the current code was behaving weirdly. If a load keeps failing repeatedly on a historical, the coordinator may always get a PENDING response rather than FAILED.
Typical scenario:

Coordinator requests Historical to load segment.
Request completes while load is still in progress and gets back a PENDING response
Then load fails and FAILED status is cached
Coordinator checks with the Historical if it has loaded the segment.
Since we already have a cached FAILED status, we retry the load and send back a PENDING response (see snippet below)
Repeat

https://github.com/apache/druid/blob/efb32810c48fd9c0bf81cefb15179f74a4cde661/server/src/main/java/org/apache/druid/server/coordination/SegmentLoadDropHandler.java#L562-L563

Trying to handle all these case, I have made the following changes:

Invalidate the cache if a different request type is received
Rearrange and rename some methods to simplify the code
Add javadocs where applicable
Clean up SegmentLoadDropHandlerTest and add some more test cases

@gianm , let me know what you think.

There is one more case that requires handling, a concurrent load and drop of the same segment. I am currently working on this, will update the PR soon.

concurrent load and drop of the same segment

When would this occur?

@kfaraz Thanks for outlining the scenario. IMO, it makes sense to include this fix, since it seems straightforward.

A couple of doubts :

DROP task does not do anything since the segment is not present in segmentsToDrop anymore. Thus the result holder remains stuck in pending state.

Are we sure that the DROP request actually gets stuck in pending state? It appears from the current code (https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/coordination/SegmentLoadDropHandler.java#L463) that the status is marked success after either the delete request is scheduled async or run inline.

Since we changed the return type object of the HTTP call, will it be backwards compatible? For instance if the historicals are updated before coordinator (as we suggest), could it happen that the historicals return new object types which an old coordinator wouldn't be able to understand?

Are we sure that the DROP request actually gets stuck in pending state? It appears from the current code (https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/coordination/SegmentLoadDropHandler.java#L463) that the status is marked success after either the delete request is scheduled async or run inline.

Yes, @rohangarg , thanks for pointing this out. I have updated my comment. The DROP request is marked a success immediately after unannouncing the segment.

Since we changed the return type object of the HTTP call, will it be backwards compatible? For instance if the historicals are updated before coordinator (as we suggest), could it happen that the historicals return new object types which an old coordinator wouldn't be able to understand?

The response payload has not changed, only the Java class name has changed. So the changes are backward compatible. Please let me know if you notice a discrepancy in this.

Removed from 27.0 in favor of #14670.

Closing this as this implementation is still buggy and the design requires some further thought.
I will create a fresh PR soon.


Async calls should use async deserialization

Our otherwise async calls use sync deserialization starting with KeyVaultPipeline.CreateResponse. Since the response stream is buffered, this isn't blocking the release but we should fix it, especially when #8232 gets fixed.
When fixed, in KeysEventSourceTests, change:
MockTransport transport = new MockTransport(response);

To:
MockTransport transport = new MockTransport(response)
{
    ExpectSyncPipeline = !IsAsync,
};

For JSON-based responses, the response is already buffered in memory so this really isn't worth it.


schedulers: improve store-load-based scheduler

Signed-off-by: lhy1024<EMAIL_ADDRESS>
What problem does this PR solve?
cherry pick from #1754
What is changed and how it works?

[x] merge pending influence struct
[x] ensure why remove AggregateScores and NormalizeStoresStats
[x] fix test

Check List
Tests

Unit test

/run-all-tests

Codecov Report

Merging #2053 into master will increase coverage by 0.06%.
The diff coverage is 92.63%.

@@            Coverage Diff             @@
##           master    #2053      +/-   ##
==========================================
+ Coverage   76.79%   76.85%   +0.06%
==========================================
  Files         186      186
  Lines       19049    19179     +130
==========================================
+ Hits        14628    14740     +112
- Misses       3305     3318      +13
- Partials     1116     1121       +5

Impacted Files
Coverage Δ

server/schedulers/shuffle_hot_region.go
67.67% <100%> (ø)
:arrow_up:

server/cluster/coordinator.go
78.57% <100%> (+0.17%)
:arrow_up:

server/schedulers/utils.go
85.63% <85.18%> (-3.2%)
:arrow_down:

server/schedulers/hot_region.go
86.54% <93.11%> (+1.24%)
:arrow_up:

pkg/testutil/operator_check.go
90.62% <0%> (-9.38%)
:arrow_down:

pkg/etcdutil/etcdutil.go
82.6% <0%> (-8.7%)
:arrow_down:

server/member/leader.go
76.53% <0%> (-4.6%)
:arrow_down:

server/tso/tso.go
77.37% <0%> (-2.92%)
:arrow_down:

server/server.go
82.98% <0%> (+0.38%)
:arrow_up:

... and 6 more

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 a607642...33acaf0. Read the comment docs.

Have you tested the effect of this PR？

PTAL @Luffbee

/run-all-tests

@nolouch @rleungx PTAL

would you like to show the test result @Luffbee

The most important change of this PR is that it balance hot leader by count. So, I will only give leader distribution graph

There are 3 part of this graph. The first one comes from the latest master branch, the other two comes from this PR. We can see that the leader distribution is balanced in this PR.

/merge

/run-all-tests

/run-all-tests

/rebuild

/build

/merge

/merge

/merge


Object.clone fails to set toString on IE8

This issue was imported from Closure Library's previous home at http://closure-library.googlecode.com
The link to the original issue is:
https://code.google.com/p/closure-library/issues/detail?id=539

Tested internally. This works on IE8 now, AFAICT.


Windows (I don't know which version) for android

Type of issue
Typo
Feedback
The best windows of android
Page URL
https://learn.microsoft.com/es-es/windows/android/emulator
Content source URL
https://github.com/MicrosoftDocs/windows-dev-docs/blob/docs/hub/android/emulator.md
Author
@mattwojo
Document Id
00c65f36-a194-58d3-3796-ff5868474ff3

Please don't waste time by opening issues without a clear description. If you have an actual issue to raise regarding this documentation, feel welcome to re-open and explain the issue that you've found.


fix: mysql 5.7 pitr restore failed

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 0.00%. Comparing base (bed4a08) to head (ec9cb21).

Additional details and impacted files
@@          Coverage Diff          @@
##            main   #1343   +/-   ##
=====================================
  Coverage   0.00%   0.00%
=====================================
  Files         69      69
  Lines       6685    6685
=====================================
  Misses      6685    6685

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Support for running via a docker image?

Could this be supported out of the box?
Looks like there's been some teething problems getting it to work here: https://github.com/cloudflare/workerd/issues/20#issuecomment-1259542697

This is what I am using:
FROM node:18

RUN apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -qy tini libc++1

WORKDIR /app
RUN npm install workerd
COPY config.capnp hello.js ./

CMD ["tini", "./node_modules/.bin/workerd", "serve", "config.capnp"]

I have the following Dockerfile but I get an error, running on M1 MacOS:
FROM node:18

RUN apt-get update && apt-get -y install libc++-dev libunwind-dev

WORKDIR /app
RUN npm install workerd
COPY workerd.capnp worker.js health-check.js ./

CMD ["./node_modules/.bin/workerd", "serve", "workerd.capnp"]

/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory
node:child_process:910
    throw err;
    ^

Error: Command failed: /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd serve workerd.capnp
    at checkExecSyncError (node:child_process:871:11)
    at Object.execFileSync (node:child_process:907:15)
    at Object.<anonymous> (/app/node_modules/workerd/bin/workerd:134:26)
    at Module._compile (node:internal/modules/cjs/loader:1119:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1173:10)
    at Module.load (node:internal/modules/cjs/loader:997:32)
    at Module._load (node:internal/modules/cjs/loader:838:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:18:47 {
  status: 127,
  signal: null,
  output: [ null, null, null ],
  pid: 14,
  stdout: null,
  stderr: null
}

Node.js v18.9.1

You removed libc++1 and added two unnecessary -dev libraries. This is why it fails. libc++1 install libunwind as requirement.

@frafra I tried that, same error:
FROM node:18

RUN apt-get update && apt-get -y install libc++1 libunwind8

ENV LD_LIBRARY_PATH /usr/lib
RUN ldconfig

WORKDIR /app
RUN npm install workerd
COPY workerd.capnp worker.js health-check.js ./

CMD ["./node_modules/.bin/workerd", "serve", "workerd.capnp"]

This is an error with your modified version of your Dockerfile. Please stick with the suggested packages. There is no need to install libunwind explicitly, since it is a dependency of libc++1. You are specifying a version of libunwind which is not the one required by libc++1 currently. Look at the Debian packages webpage for more information.
I followed the Getting Started section of this repository and made a new one, with the suggested hello world example and a simple Dockefile, which works flawlessly. I would suggest you start there: https://github.com/frafra/workerd-docker

I haven't written out everything I've tried, all of the changes to dockerfiles would probably blow through the character limit on a GitHub comment.
I have of course tried your dockerfile with no luck. Anything I try throws back the error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory error.

You said to use M1. That could explain why you are having different results.  Have you just tried to build the Dockerfile within the repository I linked? Do you get the very same error even when using that repository and the hello world files?
libunwind8 does not provide libunwind.so.1. libunwind is a requirement of libc++ only staring from Debian Bookworm (v12, current testing), but node:18 uses Debian Buster (v11, current stable). The package is named libunwind-14 in Debian Sid and libunwind-13 in Debian Buster: https://packages.debian.org/search?suite=bullseye&section=all&arch=any&searchon=contents&keywords=libunwind.so.1.
Could it be that libunwind.so.1 is a (indirect) dependency of workerd only on M1? Try to add libunwind-13.

I made a branch with the additional dependency: https://github.com/frafra/workerd-docker/tree/fix-missing-libunwind

Ah, adding libunwind-13 gives me a different error:
/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd)
/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd)
/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd)

I have a basic docker image for amd64 here: https://github.com/Cyb3r-Jak3/docker-workerd. Smaller than installing it via npm. Arm64 support is on the way.
Also, happy to merge it into this repo.

Zooming out a bit, a broader problem here may be that our binary has too many dependencies on shared libraries that lack stable ABIs across distros. We should try to statically link more of these, at least in our npm releases.
When it comes to glibc specifically, though, we do need to dynamically link. Fortunately glibc has strong ABI compatibility. However, we need to make sure to link against an older version of glibc, since generally a binary will only work with the version it was linked against and newer versions, but not older ones.
cc @penalosa

Ah, adding libunwind-13 gives me a different error:

Have you installed it together with libc++1?
workerd in my container is a static binary, so I wonder what the result of ldd is on your container running on M1, giving the different requirements.

workerd in my container is a static binary

Hmm are you sure? I don't think any of our binaries are static.

workerd in my container is a static binary

Hmm are you sure? I don't think any of our binaries are static.

My bad, I was looking at the wrong executable:
node@da718d2232c1:~$ ldd ./node_modules/workerd/bin/workerd
	not a dynamic executable
node@da718d2232c1:~$ ldd ./node_modules/@cloudflare/workerd-linux-64/bin/workerd
	linux-vdso.so.1 (0x00007ffd7bd24000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5db8eb6000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5db8e94000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5db8d50000)
	libc++.so.1 => /usr/lib/x86_64-linux-gnu/libc++.so.1 (0x00007f5db8c86000)
	libc++abi.so.1 => /usr/lib/x86_64-linux-gnu/libc++abi.so.1 (0x00007f5db8c4e000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5db8c34000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5db8a5d000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f5dbbd86000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5db8a53000)
	libatomic.so.1 => /usr/lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f5db8a49000)

I managed to build workerd binary within Docker using the following Dockerfile
FROM ubuntu:22.04

RUN apt-get update && apt-get install -y build-essential git clang libc++-dev libc++abi-dev curl gnupg git python3-pip python3-distutils
RUN curl -L "https://github.com/bazelbuild/bazelisk/releases/download/v1.14.0/bazelisk-linux-arm64" -o /bin/bazelisk && chmod 755 /bin/bazelisk

RUN cd /tmp && git clone https://github.com/cloudflare/workerd.git
RUN cd /tmp/workerd && bazelisk build -c opt //src/workerd/server:workerd

The compiled binary is located under /tmp/workerd/bazel-bin/src/workerd/server/workerd.
Appreciate it's still an early Beta.... but an official Dockerfile in the repo would be really helpful for those who wants to try workerd in VSCode Dev Containers environment.

💯 for static binaries. This is something Deno got sooooo right.

Trying to build the project in ubuntu:20.04
root@vm1:/home/ubuntu# git clone https://github.com/cloudflare/workerd.git \
>     && cd workerd \
>     && bazel build -c opt //src/workerd/server:workerd --verbose_failures
Cloning into 'workerd'...
remote: Enumerating objects: 2064, done.
remote: Counting objects: 100% (2064/2064), done.
remote: Compressing objects: 100% (687/687), done.
remote: Total 2064 (delta 1224), reused 1973 (delta 1193), pack-reused 0
Receiving objects: 100% (2064/2064), 1.85 MiB | 2.44 MiB/s, done.
Resolving deltas: 100% (1224/1224), done.
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
INFO: Analyzed target //src/workerd/server:workerd (201 packages loaded, 16218 targets configured).
INFO: Found 1 target...
ERROR: /home/ubuntu/workerd/BUILD.bazel:7:17: GenCapnp icudata-embed.capnp.h failed: (Exit 1): capnp_tool failed: error executing command
  (cd /root/.cache/bazel/_bazel_root/b3fbc4211153c5d2f26c97321a65891b/sandbox/linux-sandbox/208/execroot/workerd && \
  exec env - \
  bazel-out/k8-opt-exec-2B5CBBC6/bin/external/capnp-cpp/src/capnp/capnp_tool compile --verbose -obazel-out/k8-opt-exec-2B5CBBC6/bin/external/capnp-cpp/src/capnp/capnpc-c++:bazel-out/k8-opt/bin -I external/capnp-cpp/src icudata-embed.capnp)
# Configuration: d2d1d592403ef6a825f2862044013ce88fb1c177866ebc360e1e17809f6b2a5f
# Execution platform: @local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
bazel-out/k8-opt-exec-2B5CBBC6/bin/external/capnp-cpp/src/capnp/capnpc-c++: plugin failed: Killed
Target //src/workerd/server:workerd failed to build
INFO: Elapsed time: 1523.757s, Critical Path: 146.27s
INFO: 1751 processes: 1544 internal, 206 linux-sandbox, 1 local.
FAILED: Build did NOT complete successfully

Any ideas?

I also receive the following error using Docker (arm):
error while loading shared libraries: libc++.so.1: cannot open shared object file
docker compose:
wrangler:
    image: node
    command: >
        sh -cx "yarn install && yarn wrangler dev --experimental-local"

I also receive the following error using Docker (arm):
error while loading shared libraries: libc++.so.1: cannot open shared object file

My guess is you need to install libc++-dev and libc++abi-dev in your container.

I'm working in a WSL Ubuntu VM and installing libc++-dev and libc++abi-dev in addition to libc++1 does not help. I'm still getting:
Error: Command failed: /home/<redacted>/.nvm/versions/node/v19.3.0/bin/node /home/<redacted>/node_modules/workerd/bin/workerd --version
/home/<redacted>/node_modules/@cloudflare/workerd-linux-64/bin/workerd: error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory
node:child_process:924
    throw err;
    ^

Error: Command failed: /home/<redacted>/node_modules/@cloudflare/workerd-linux-64/bin/workerd --version
    at checkExecSyncError (node:child_process:885:11)
    at Object.execFileSync (node:child_process:921:15)
    at Object.<anonymous> (/home<redacted>/node_modules/workerd/bin/workerd:135:26)
    at Module._compile (node:internal/modules/cjs/loader:1218:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1272:10)
    at Module.load (node:internal/modules/cjs/loader:1081:32)
    at Module._load (node:internal/modules/cjs/loader:922:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:82:12)
    at node:internal/main/run_main_module:23:47 {
  status: 127,
  signal: null,
  output: [ null, null, null ],
  pid: 30212,
  stdout: null,
  stderr: null
}

Node.js v19.3.0

Which version of Ubuntu are you using in WSL? There have been some issue with Ubuntu 20—trying Ubuntu 22 should work?

Ah I do have Ubuntu 20. I'll try 22 at some point, thanks!

If anyone has this working in Github Codespaces I'd love to know how.

It's the same thing on ArchLinux.. Seems like that libunwind is version 1.6 and it definitely doesn't contain libunwind.so.1 but without the 1.
I have all devel things, like base-devel, libc++ 15, libunwind 1.6, llvm 15, clang 15.0.7, glibc, and etc.
It definitely would be better to lower the dependencies.

We should try to statically link more of these, at least in our npm releases.

Yep.

Does anyone have it working on WSL without the dreaded error while loading shared libraries: libc++.so.1: cannot open shared object file?

Now that Miniflare v3 (with workerd) is the default dev command in Wrangler, this issue is more important to robustly solve.
To summarise the above: The two packages that are most commonly concurrently out of date in this thread are glibc and libunwind. Unfortunately, glibc can’t be upgraded without upgrading the OS version that your Docker image is based on. In the Ubuntu, the minimum supported version is 22.04, and for Debian, it’s Debian 12 (Bookworm), which is still a few weeks away from stably releasing. I can’t speak to Alpine because it has a different libc setup that might require some extra configuration.
The workaround is to upgrade your Docker image—or really, to upgrade whatever base images you’re relying on—to one of those OS versions. In my case, the stack of images I was relying on was:

debian:bullseye (Bookworm available)
buildpack-deps:bullseye (Bookworm available)
node (Bookworm proposed)
mcr.microsoft.com/devcontainers/javascript-node
mcr.microsoft.com/devcontainers/typescript-node

(The last two images are commonly used by GitHub Codespaces)
I was able to adapt the images pretty easily by combining them into one Dockerfile and adapting the deepest dependency from buildpack-deps:bullseye to buildpack-deps:bookworm.
My Dockerfile is below, but don’t copy-paste this. Your setup is going to be different to mine depending on your container/OS.

ENV PATH=${NPM_GLOBAL}/bin:${PATH}

RUN \
    # Configure global npm install location, use group to adapt to UID/GID changes
    if ! cat /etc/group | grep -e "^npm:" > /dev/null 2>&1; then groupadd -r npm; fi \
    && usermod -a -G npm ${USERNAME} \
    && umask 0002 \
    && mkdir -p ${NPM_GLOBAL} \
    && touch /usr/local/etc/npmrc \
    && chown ${USERNAME}:npm ${NPM_GLOBAL} /usr/local/etc/npmrc \
    && chmod g+s ${NPM_GLOBAL} \
    && npm config -g set prefix ${NPM_GLOBAL} \
    && su ${USERNAME} -c "npm config -g set prefix ${NPM_GLOBAL}" \
    # Install eslint
    && su ${USERNAME} -c "umask 0002 && npm install -g eslint" \
    && npm cache clean --force > /dev/null 2>&1

#
# Adapted from Microsoft's `typescript-node` repo
#

ARG NODE_MODULES="tslint-to-eslint-config typescript"
RUN su node -c "umask 0002 && npm install -g ${NODE_MODULES}" \
    && npm cache clean --force > /dev/null 2>&1

# Install `libc++-dev` for workerd to work
RUN apt-get update && apt-get -y install libc++-dev

This is too much to expect a normal user to do, however, and at least being clearer about minimum OS versions in Wrangler would be a good move.

I was able to get this working with the proposed node Bookworm Docker images. I git pulled the proposed repo, switched to the Bookworm branch and built the image locally that I needed.

It's the same thing on ArchLinux.. Seems like that libunwind is version 1.6 and it definitely doesn't contain libunwind.so.1 but without the 1.

For Arch users, it seems we can make a soft link to libunwind.so.1 -> libunwind.so and it just works. I know it is a very bad practice, but I have no better workaround now.

A (temporary) solution for Fedora 38 is to install llvm-libunwind via DNF. For example:
$ ./node_modules/workerd/bin/workerd --version
./node_modules/workerd/bin/workerd: error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory
$ dnf install -y llvm-libunwind
$ ./node_modules/workerd/bin/workerd --version
workerd 2023-05-12

The library has a different soname (libunwind.so.1) so it can live together with GCC's libunwind (libunwind.so.8).
For distros that doesn't distribute LLVM's libunwind, one could attempt to symlink libunwind.so.8 (or the unversioned one) to libunwind.so.1. However, I cannot recommend this, since GCC's libunwind does not have exactly the same ABI as the one provided by LLVM.

If anyone has this working in Github Codespaces I'd love to know how.

I got this working by selecting a newer devcontainer image (f.ex. ubuntu 22.04, see https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers#using-a-predefined-dev-container-configuration for instructions).

I can confirm the above suggestion by @jormaj works on docker (managed by VS Code) running mcr.microsoft.com/devcontainers/base:ubuntu (ubuntu 22.04) image.

I am using image 'mcr.microsoft.com/vscode/devcontainers/javascript-node:16', with wrangler 3.0.1 after installing libc++-dev and libunwind-dev shared lib errors were fixed, but still get the error Error: write EPIPE .... https://github.com/cloudflare/workers-sdk/issues/3262#issuecomment-1564106293 will fix it soon, right?

You guys can also run the official node packages with this command (example below is for docker-compose using yarn):
    command: >
        sh -cx "apt-get update &&
                apt-get install -y clang libc++-dev libc++abi-dev &&
                yarn wrangler dev --experimental-local"

For Arch Linux users:
yay -Sy extra/libc++ aur/llvm-libunwind

Cannot get wrangler dev working on Debian ('mcr.microsoft.com/vscode/devcontainers/javascript-node:16'). I've installed libc++-dev, libc++abi-dev and libunwind-dev to no avail, installing clang didn't help either. wrangler 3.1.0

Wrangler does not work on Debian 11 , I installed clang libc++-dev libc++abi-dev by apt install command , however, does not work correctly.  Please let me know, I think Debian and Ubuntu are most popular Linux OS on Interent server.  Thanks.
-- log
? Compiled Worker successfully
?? wrangler 3.1.0
wrangler dev now uses local mode by default, powered by ? Miniflare and ? workerd.
To run an edge preview session for your Worker, use wrangler dev --remote
Your worker has access to the following bindings:

KV Namespaces:

KVDATA: 83e2f6aae8664bf89a......xxxxx
? Starting local server...
[mf:wrn] The latest compatibility date supported by the installed Cloudflare Workers Runtime is "2023-05-18",
but you've requested "2023-06-15". Falling back to "2023-05-18"...
lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x [b] open a browser, [d] open Devtools, [c] clear console, [x] to exit                                   x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
/home/hodota/sonicjs/node_modules/wrangler/wrangler-dist/cli.js:30632
throw a;
^

Error: write EPIPE
at afterWriteDispatched (node:internal/stream_base_commons:160:15)
at writeGeneric (node:internal/stream_base_commons:151:3)
at Socket._writeGeneric (node:net:905:11)
at Socket._write (node:net:917:8)
at writeOrBuffer (node:internal/streams/writable:391:12)
at _write (node:internal/streams/writable:332:10)
at Socket.Writable.write (node:internal/streams/writable:336:10)
at Runtime.updateConfig (/home/hodota/sonicjs/node_modules/miniflare/dist/src/index.js:5121:26)
at async Miniflare.#assembleAndUpdateConfig (/home/hodota/sonicjs/node_modules/miniflare/dist/src/index.js:9138:23)
at async Miniflare.#init (/home/hodota/sonicjs/node_modules/miniflare/dist/src/index.js:8898:5)
Emitted 'error' event on Socket instance at:
at emitErrorNT (node:internal/streams/destroy:157:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -32,
code: 'EPIPE',
syscall: 'write'
}
ERROR: "dev:wrangler" exited with 7.

Not working in BunsenLabs GNU/Linux 10.5 (Lithium)


Feature/i18n

Added dynamic language switch controls

On 8th June we identified following issues requiring fixes:

workflow.js L214 join campaign to campaignContact and then inject 'c_' + campaign.customerId as tenantId into the email template

adjust email template to use tenantId in landingpage and transition api urls

/public/landingpage/:tenantId/:campaignId/:contactId

strip the tenant prefix c_ from the tenantId in order to generate customerId (edited)

exactly as 3), strip c_ and get customerId, error message if not c_

/api/campaigns/start/:campaignId
add customerId to the query as where condition, get customerId from current user (req.opuscapita.userData('customerid'))


Fixed Incorrect mp4upload Parsing & Animeflv downloading

See Issue #258 and Issue #252.

Why did you remove natsuki?

Because, as far as I can tell, animeflv no longer has a content host server called natsuki.  The only servers I saw were mega, zippyshare, openload and streamango.

Ok, I made some additional changes to the code and added some error handling with a descriptive error message.  That should eliminate certain bug reports.
Also noticed that the build fails the auto test.  Builds just fine for me in Python 3.7 on Mac, though.


Reimplementation of Archival features to avoid conflict with FindCommand

CHANGES: I have modified InternshipDiary.java to hold 3 internship lists: 1) displayedInternships, 2) archivedInternships, 3) unarchivedInternships
IDEA
Basically, the reason why we use a displayedInternships is to toggle between viewing archivedInternships and unarchivedInternships. This is triggered upon "archival" and "list" commands respectively.
STORAGE
How it will work is that when storage retrieves the internships from JSON, resetData function will filter the internship data into archivedInternships and unarchivedInternships depending on whether the isArchived() boolean is true.
Likewise, when saving, we will combine the 2 lists, archivedInternships and unarchivedInternships into 1 and save it. This implementation is to avoid having to excessively modify our storage (and its test cases).
REACTIVITY AND DATA BINDING ISSUES
By implementing the toggling between archivedInternships and unarchivedInternships by using displayedInternships, we face a host of issues (especially reactivity and data binding).
The problem extends to: 1) Find, 2) Sort, 3) UI. Basically anything to do with ObservableList and modifying the view via predicates.
This is because we are reassigning new reference to displayedInternships each time and the different components are not aware of the new updates to the reference. They are still holding the old reference. Essentially, this is a reactivity issue.
We can solve this via Observer / Observable paradigm by using the Observer package by Java. But since it is deprecated, I opted for PropertyEventListener package instead. The idea behind both are the same -- when the observables changes, fire an update to the observers.
So, now we have the following two-tiered structure:
InternshipDiary's displayedInternship (OBSERVABLE)
--- (OBSERVED BY) ModelManager
ModelManager (OBSERVABLE)
--- (OBSERVED BY) StatisticsBarFooter, StatisticsWindow, InternshipApplicationListPanel
A short summary of how this works is that when displayedInternship changes, it fires an event to ModelManager to pass the new reference for ModelManager to update it's filteredInternshipApplicationList (and sorted).
Then, ModelManager will fire an event to the relevant UI components with the latest SortedFilteredInternshipApplicationList to update the underlying data for user interface (and for statistics computation).

good job


Use a single connect(scheme, options) method for futureproofing

and unifying with android/java bindings

Pls merge


Bump assorted dependencies

As per title.
/assign @nak3

@markusthoemmes Do you have any idea why github action Verify is failing?


Transfer service ecs task

Will replace with da-terraform-modules when available.

I guess my only question would be how much work would it be to take the opportunity to add the necessary modules to da-terraform-modules now?
@annielh I will need to add the new modules, I've started this work, but it will take a while for me to do it all. I want to get this ECS task stood up for a longer period of time to test stuff out in preparation to the SharePoint work. Which is why I'm using the tdr modules for now. Does that make sense?


Support for Volume Control Endpoint

Hi,
I've updated roonapi from very old version and i've noticed that support for volume control endpoints was removed.
Is it possible to bring it back?
I'm using this functionality in my plugin for controlling volume on soekris Dam1021 DAC.
With current version of pyroon it is not achievable.
Thanks in advance for your reply.
BR,
Seba

Hi Seba,
When I took over the library I couldn't understand how that code worked - or find a way to use it.
I didn't want to have something in the library that I wasn't able to support - so I removed it.
I'd welcome a PR to add it back - as long as you can also provide an example of how it's used to the example directory.

I should perhaps add that my focus has been on tidying up and improving the integration with Home Assistant - hence removing things that weren't needed for that.
And should you need the old code - you can get the library before I modified it here: https://github.com/pavoni/pyroon/tree/64103fec69289ef1de16fdc489a18235e75ef2f9

FWIW, I have patched these features back in on my local fork, it works fine, when I have time I will do a PR with an example. (Fine to leave this closed.)


Database schema upgrade error

Please see report: http://is.gd/LScmdh

Could you do the following for me:

Go into preferences-> advanced, go to the "Files and Folders" tab, and click "Show Data Directory". The finder will open, you will see files "betterbibtex.sqlite" and "betterbibtex.sqlite-journal"
Close Firefox. The file "betterbibtex.sqlite-journal" will disappear.
Drop the file "betterbibtex.sqlite" into https://dbinbox.com/allthatisthecase

Sorry, that should be https://dbinbox.com/retorquere

I don't use Firefox. Just standalone on Mac OSX.
Let me know what you need.
On Jun 7, 2015 3:42 AM, "retorquere"<EMAIL_ADDRESS>wrote:

Could you do the following for me:

Go into preferences-> advanced, go to the "Files and Folders" tab,
and click "Show Data Directory". The finder will open, you will see files
"betterbibtex.sqlite" and "betterbibtex.sqlite-journal"
Close Firefox. The file "betterbibtex.sqlite-journal" will
disappear.
Drop the file "betterbibtex.sqlite" into
https://dbinbox.com/allthatisthecase

—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-109654172
.

Ah, OK. Same procedure, just with standalone.

Done!
On Sun, Jun 7, 2015 at 2:24 PM, retorquere<EMAIL_ADDRESS>wrote:

Ah, OK. Same procedure, just with standalone.
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-109722779
.

Test are running, 0.11.4 will be released when they pass.

And apologies for the disruption.

No worries.
Thanks for making Zotero BibTeX so much better.
Is there a plan in the works to set the default to the following conditions:

All keys, once generated, are fixed. (This is what a vast (if not
everyone) majority of people would want). Currently, the pin preferences
are hidden.
Set default key format to author_lastname:year:x, where x=1,2,3,4.
Make the key visible in the right pane in Zotero (this is what Mendeley
does - and it is a huge time saver).
Auto-update a user-defined file (don't base it off a given export - just
do it more logically - user specifies the file against which the database
is sync'ed.).

Of course, users should be able to change this, but I can tell you the
above are the defaults that nearly everyone wants (have about 16 years of
experience with LaTeX and have worked with a very large number of
collaborators).
Thanks once again!
On Sun, Jun 7, 2015 at 6:41 PM, retorquere<EMAIL_ADDRESS>wrote:

And apologies for the disruption.
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-109754667
.

All keys, once generated, are fixed. (This is what a vast (if not everyone) majority of people would want). Currently, the pin preferences are hidden.

By hidden, you mean buried in the myriad of options BBT offers? :). Yeah, they're not too prominent. This would be doable (and is in fact one of the preferences: Better BibTeX - Citation - Auto-pin: on item change. The problem in making this the default is that it actually changes the extra field of the reference, as there is currently no other way to have these keys sync that doesn't upset the Zotero devs, and I'm not too keen on modifying references without explicit consent from the user. Also, each change marks the reference for sync, and the current sync infrastructure of Zotero is not equipped to handle large amounts of changes in one go; enabling this by default would mean everyone's entire library would sync to the Zotero servers, and bad stuff happens if this times out. Not my preference, but until the new sync infra they;re working on is online, it is what I have to work with.
The default is to "soft-pin"; as long as nothing changes in a reference that is used in your citation key formatter, the key ought not to change. So if you have [auth][year], and you change the title, the key shouldn't be affected.

Set default key format to author_lastname:year:x, where x=1,2,3,4.

This seems to me a personal, not a universal preference. No accounting for taste.

Make the key visible in the right pane in Zotero (this is what Mendeley does - and it is a huge time saver).

That's on my to-do list, but you can have it show up in the reference list in the interim by enabling the extra column, and enabling Show cite key instead of extra in the BBT preferences.

Auto-update a user-defined file (don't base it off a given export - just do it more logically - user specifies the file against which the database is sync'ed.).

I don't understand -- what would this entail other than the existing auto-export?

Of course, users should be able to change this, but I can tell you the
above are the defaults that nearly everyone wants (have about 16 years of
experience with LaTeX and have worked with a very large number of
collaborators).

You wouldn't believe the amount of variability I've seen over time with regards to preferences here :). One thing I'm still considering is to have per-group syncable settings, but the UI work for this is off-putting, and it requires circumventing a whole heap of stuff in Zotero to get it to work, which is fragile. With a guaranteed-to-break-all-plugins Zotero 5.0 slated, I'm deferring all fragile stuff until that has dropped.
But please do feel free to lodge feature-request issues for these. I have terrible memory, so I rely on these sitting in the issues list for when sudden inspiration hits me for a clean fix.

Showing the citation key in the item pane itself is more involved than showing it in the overview (as tricky as that was), as the item pane uses one of the more esoteric features of Firefox to work, and one that is sort of actively hostile to the regular mechanisms of extending the UI in Firefox (standalone is built on xulrunner, which is simply Firefox stripped to its bare essentials, so the same problem exists there).

(meh, involved equals challenge. tests are running)

new release has citekey display.

Thanks!
The cite key display works beautifully. I just ran generate bibtex key for
all the publications in my new Zotero collection (~ 1000) and it did not
appreciably hang. Took a minute, but I got all the keys done.
However, the export library is still not working (same error as before).
Shall I enable debugging, and restart Zotero to get you a full trace?
On Mon, Jun 8, 2015 at 5:42 AM, retorquere<EMAIL_ADDRESS>wrote:

new release has citekey display.
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-109816865
.

That would be much appreciated.

Done.
Don't know if you need a new tracker for this, but I got:
http://is.gd/nW09lq
On Mon, Jun 8, 2015 at 11:12 AM, retorquere<EMAIL_ADDRESS>wrote:

That would be much appreciated.
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-109871372
.

.7 is now out, should take care of that.

I don't know if I'm having the same issue as in this thread, but I am now also get an error when trying to export a library using this plugin.  I'm using version 0.11.8 of the plugin.
Do you want me to upload an sqlite file?

@dmbortz Report ZotPlus Error will suffice. Could you please open a separate issue?

@madhusudansingh if the original issue is fixed for you, can you close this issue? Thanks.

The issue is not fixed :(
Still get that JavaScript error upon trying to export library. I did
restart Zotero before testing this, so Better BibTeX should have updated.
On Mon, Jun 8, 2015 at 7:45 PM, retorquere<EMAIL_ADDRESS>wrote:

@madhusudansingh https://github.com/madhusudansingh if the original
issue is fixed for you, can you close this issue? Thanks.
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-110009181
.

Ok, can you generate a new debug log?

Hold on, a restart doesn't automatically update extensions. You need to go into the addins screen and have it check for updates.

I'd really appreciate feedback on this issue. Are you sure you are currently on 0.11.11, and can you generate a new debug log if you are?

Sorry, I was busy with something and didn't check my email.
You were right - the version did not update with a Zotero restart. I was
stuck at 0.11.6. Its updated now, and working like a charm.
Thanks!!
On Thu, Jun 11, 2015 at 12:03 AM, retorquere<EMAIL_ADDRESS>wrote:

I'd really appreciate feedback on this issue. Are you sure you are
currently on 0.11.11, and can you generate a new debug log if you are?
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-110866545
.

Glad it's working for you. Could you still elaborate on

Auto-update a user-defined file (don't base it off a given export - just do it more logically - user specifies the file against which the database is sync'ed.).

It's not that big a deal. It's just that the current method of auto update
relies on you going to a different screen, enabling an easily missable
option, and then it works.
Instead, there should be a field to enter a file name which Zotero would
sync to, automatically by default, with an extra radio button allowing a
person to opt out of auto sync to bibtex.
That would make it simpler, mirror the most common case of use, and not
have this untidy method of having to leave preferences to set it up.
On Jun 11, 2015 11:06 PM, "retorquere"<EMAIL_ADDRESS>wrote:

Glad it's working for you. Could you still elaborate on
Auto-update a user-defined file (don't base it off a given export - just
do it more logically - user specifies the file against which the database
is sync'ed.).
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-111217500
.

I still don't understand, I'm sorry

It's not that big a deal. It's just that the current method of auto update relies on you going to a different screen, enabling an easily missable option, and then it works.

But which option? What screen? And different from what? The default for auto export is "on idle", not "off". It's the only option I could think of that sort of matches your description, but "on idle" fits my description of "it just works".

Instead, there should be a field to enter a file name which Zotero would sync to, automatically by default, with an extra radio button allowing a person to opt out of auto sync to bibtex.

But where should this field be? And if "sync to bibtex" would be disabled there, what would it do?

That would make it simpler, mirror the most common case of use, and not have this untidy method of having to leave preferences to set it up.

You hardly ever have to be in preferences for auto export. I never go there unless I made an error. You can see the existing auto exports in the preferences, and you can remove them there, but that's all you can do. I think I'm missing something important in your description, I'm always up to make the UI better, but I just honestly don't understand what your request is.

Right now, if I want to enable an export, I have to browse to the
preferences screen for the auto export (under better bibtex), that tells me
that I need to tick Keep updated when I go to do an export. This is messy.
I call it the export dance.
Just change the auto export preferences screen to accept a filename and the
rest of the controls (I would change the default to on change (and not on
idle) - but that is a minor point).
Don't tell the user what to do on that screen and force him to browse away.
Its unintuitive.
Look at how Mendeley. It does not do the export dance.
Am I making any headway in explaining myself?
On Fri, Jun 12, 2015 at 8:15 PM, retorquere<EMAIL_ADDRESS>wrote:

I still don't understand, I'm sorry
It's not that big a deal. It's just that the current method of auto update
relies on you going to a different screen, enabling an easily missable
option, and then it works.
But which option? What screen? And different from what? The default for
auto export is "on idle", not "off". It's the only option I could think of
that sort of matches your description, but "on idle" fits my description of
"it just works".
Instead, there should be a field to enter a file name which Zotero would
sync to, automatically by default, with an extra radio button allowing a
person to opt out of auto sync to bibtex.
But where should this field be? And if "sync to bibtex" would be disabled
there, what would it do?
That would make it simpler, mirror the most common case of use, and not
have this untidy method of having to leave preferences to set it up.
You hardly ever have to be in preferences for auto export. I never go
there unless I made an error. You can see the existing auto exports in the
preferences, and you can remove them there, but that's all you can do. I
think I'm missing something important in your description, I'm always up to
make the UI better, but I just honestly don't understand what your request
is.
—
Reply to this email directly or view it on GitHub
https://github.com/ZotPlus/zotero-better-bibtex/issues/208#issuecomment-111516052
.

Right now, if I want to enable an export, I have to browse to the preferences screen for the auto export (under better bibtex), that tells me that I need to tick Keep updated when I go to do an export. This is messy. I call it the export dance.

But that simply isn't required. Why do you go to the preferences for auto-export? Simply ticking "Keep updated" during export will do.

Just change the auto export preferences screen to accept a filename and the rest of the controls (I would change the default to on change (and not on idle) - but that is a minor point).

You mean that in the preferences screen you could fill out a filename and have that set up a new auto-export? That would be very inconvenient, as you'd still have to select which library or collection you want to export. It's actually one step more than the current setup.
I have chosen "on idle" on purpose -- I don't want the default settings to have too much of a performance impact. Firefox (and therefore also Zotero, either standalone or the Firefox plugin) lock up the UI while doing an export. I don't want that to be the user experience unless the user chooses it.

Don't tell the user what to do on that screen and force him to browse away. Its unintuitive.

The text is there for those who end up there by accident. It's not meant to be the primary experience. You make it sound like the user has to be there for every auto-export, and that simply isn't the case. Not even close. Mendeley makes you go to the preferences for auto-export, but that is not the case for Zotero+BBT.

Look at how Mendeley. It does not do the export dance.

For starters, the dance you propose is entirely unnecessary. You want a collection updated automatically, you just select that collection, tick "Keep updated", and that's that. Secondary, the only option Mendele has is to bulk export to a single file (hardly useful), one-per-reference (even less useful), or one per collection, but layed out in a single directory structure that must directly mirror your collection layout. There is no dance, because there are no options (I don't consider the first two serious options).

I think I now do understand what you were explaining, so thanks for sticking with it until I got it, but I respectfully disagree. When you say that

Instead, there should be a field to enter a file name which Zotero would sync to, automatically by default, with an extra radio button allowing a person to opt out of auto sync to bibtex.

What would be the purpose of filling out a filename and then disabling sync? The only purpose for the filename being present could be sync, and then specifically bibtex sync, because my auto-export facility doesn't universally work with all Zotero translators. It could perhaps, but it doesn't, because it requires changes in the translators that want to use it. The BBT translators are heavily instrumented for caching to make background export possible -- any other translator would grind Zotero to a halt when exporting even a modest 100 entry file. With the BBT translators, 100 entries is unnoticable. In fact I have export set to "on change" myself. I know of others doing crazy auto-exports of 22k references, which takes under a minute with BBT, but would take anywhere between 5 to 15 minutes with any other translator. So that file-field could really only have one sensible use, and that is to auto-export using BBT.

That would make it simpler

OK, we agree on this, but it would make it simpler by reducing all choice to a single option, and that option doesn't match my own use-case. I collaborate with others on articles and these files sometimes live in Dropbox, sometimes in Owncloud, sometimes in Google drive... to allow for that in Mendeley you'd have to set up a forest of symlinks, which is not simpler.

mirror the most common case of use,

Only if you're using auto-export to keep a backup of your full library, but that is not the case of use I have in mind. For backup, I think a script that downloads your library straight from the Zotero server is vastly superior. The most common case of use I have in mind is paper-specific bib files. If I submit for publishing, I don't generally want to submit a 2000+ entry bibfile, just those that belong to that paper. I would venture to guess that that is a common enough use case, and the feedback I've been getting seems to validate that belief.

and not have this untidy method of having to leave preferences to set it up.

But this method is only yours. I hardly ever go into the prefs now that they're set up to my liking, certainly not to set up auto-export. For auto-export, I select a collection, Export, select "Keep updated", done. There's no trip to the preferences involved. I don't even understand why you wound up there, other than possibly curiosity. There's nothing you can do there except remove exports you no longer want to have running, and even that is hardly necessary, because if you re-export to the same file, it gets silently overwritten. There's no need to remove it in the prefs to set up a new sync if that's the reason you went to the prefs. In the case that seems to have your preference, a single file that exports your whole library, would not require any trip to the prefs. You just set it up once and done.

You might find http://rokdd.de/b/zotero-autoexport interesting -- I think it does exactly what you want. I haven't tested it beyond installing it, but it looks very much like the Mendeley interface.

And it should work with the BBT exporters -- I see no reason why they should conflict.


updated dependencies and reduced min sdk to 15

Thank you for trying to contribute. However, there are a couple of issues with this pull request:

minSdkVersion 16 was chosen deliberately because that's the first Android version that properly handles URI permissions with a content:// URI in EXTRA_STREAM
I don't want to use snapshot versions of libraries
There are some unrelated and unwanted changes (the Jitpack link, commented out android-mvn-push.gradle script)

Generally, I prefer pull requests that change just one thing, not multiple things at once.

thanks for the feedback, generelly i just wanted to share the update of all dependencies
minSdkVersion 16 was chosen deliberately because that's the first Android version that properly handles URI permissions with a content:// URI in EXTRA_STREAM
in my opinion this should be a passive requirement not a hard one, because applications lower than 16 couldn't even compile due to manifest merging, even though just this one feature is not supported below 16 for stated reasons
I don't want to use snapshot versions of libraries
jitpack is mainly based on tags and less about snapshots, although both are possible
There are some unrelated and unwanted changes (the Jitpack link, commented out android-mvn-push.gradle script)
i prefer to your maven depency but i can't use it since i don't own the credentials, so feel free to re-add it, it's just jitpack couldn't build and i sort of needed this library now. also the library hasn't been updated in quite a while so, forgive me for assuming the pull request might take a while to be considered
other than that, neat library, thanks for sharing, stay awesome~

If you really have to, you can override the library's minSdkVersion. See tools:overrideLibrary-marker.
The snapshot comment was because of the inclusion of Sonatype's snapshot repository and testCompile 'org.robolectric:robolectric:3.2-SNAPSHOT'.


Added delete test

Closes issue: #45

[x] Have added test for remove() method

Thank you @vishalda!
What happens when you try to delete a non existent item? Should we not test that too? 🤔

Also, please sign your commits so I can merge them once ready. Check this tutorial out https://docs.github.com/articles/about-gpg/

Hmm, the interface expects to return a ResourceInexistentError:

but the implementation skipped over that from what it seems:

Would you like to implement that too? If not I can open another issue. Thank you!

Yes I would like to try


Typo "semicolin"

(https://learn.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-blobs-download#specify-multiple-complete-blob-names)
Current text:

Separate individual blob names by using a semicolin (;).

This should probably read "... by using a semicolon".

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

ID: 3fd974f3-db51-380b-af01-f488b69fbe84
Version Independent ID: 24591144-e636-6405-4164-9f665bc18f42
Content: Download blobs from Azure Blob Storage by using AzCopy v10
Content Source: articles/storage/common/storage-use-azcopy-blobs-download.md
Service: storage
Sub-service: common
GitHub Login: @normesta
Microsoft Alias: normesta

@smuehlst
Thanks for your feedback! We will investigate and update as appropriate.

@smuehlst
Thanks for reporting this! We have created a PR for this issue and the changes should go live soon.


feat!: add the sonarjs/recommended set of rules

closes #4

Looks good, will "feature" be picked up by semantic-release up instead of using "feat" as mentioned in the docs?

Thanks, possibly not. Now fixed to use "feat". If we use squash and merge then the final commit message is defined at that point. Ideally I will find a way to check the merge commit follows conventional commits...

A new release was not created. It looks like semantic-release actually uses the angular preset by default.
https://github.com/semantic-release/commit-analyzer#options
We can either continue to use that or I can look at installing and configuring conventionalcommits. I'm inclined to switch the CI to conventionalcommits and then the next run of semantic-release will pick up the sonarjs change. If not,I will need to merge a commit just to pick up the feat! breaking change.
Thoughts?

Created #17

Agreed, conventional commits specification looks clearer and the usage of "!" is simpler than adding BREAKING CHANGE at the footer.

Thanks. I've created a PR #17 for this change.

Looks good, will "feature" be picked up by semantic-release up instead of using "feat" as mentioned in the docs?

Thanks, possibly not. Now fixed to use "feat". If we use squash and merge then the final commit message is defined at that point. Ideally I will find a way to check the merge commit follows conventional commits...

On submitting a PR to semantic-release I happened across https://github.com/zeke/semantic-pull-requests which looks like it would do the job.