Allow configuration values to be evaluated from appSettings and/or ConnectionStrings

This issue is related to my attempts to utilise ImageProcessor (and the Umbraco Filesystem provider) in a project where we do not want to store any sensitive configuration information within the code base.  As we deploy our solutions to Azure we use the appSettings and connectionStrings section configurations from the Azure portal.  However image processors configuration is read from custom configuration sections that can not be managed via the Azure portal.
My proposal is to define a method by which a custom configuration object can be defined or injected into the various configured objects, either:

Refactor the configuration setup out of the various constructors and allow things like the cache and processor to be inherited by custom implementations that can provide the required configuration by other means (i.e. appsettings, or other custom mechanism)

Support a formatting within the existing configuration sections and elements that allows one to indicate that a specific configuration value should be read from an alternate source:

    <cache name="AzureBlobCache" type="ImageProcessor.Web.Plugins.AzureBlobCache.AzureBlobCache, ImageProcessor.Web.Plugins.AzureBlobCache" maxDays="365">
      <settings>
        <setting key="CachedCDNRoot" value="+connectionStrings:cachedCDNRoot" />
      </settings>

      <connectionStrings>
            <add name="cachedCDNRoot" connectionString="" />
      </connectionStrings>

Happy to open discussions on whether this is feasible and what your expectations on such an implementation would be.

Hi Philo,
This sounds like a lot of work with a strong possibility of breaking backwards compatibility. My focus is now very firmly on the new Core ImageProcessor so I'm loath to add new functionality to the Framework branch as managing these changes becomes an extra burden.
Although I wrote the Umbraco FileSystemProvider I consider them to be entirely separate entities and I wrote that code in accordance to the way configuration works within Umbraco. How would you propose to manage the changes while ensuring that developers can continue with business a usual.
I must ask... Why are your source control systems not secure enough?

I am appreciate any implementation would not be trivial and would need to be carefully considered to maintain compatibility.
Will the new Core version support a more abstract configuration sub-system?

I must ask... Why are your source control systems not secure enough?

It is not a question of the security of the source control system, that is secured vna PKI, the question is about the access the sensitive information provides to the underlying systems.  IN some cases and for projects that need to access sensitive data it is important to minimise the potential for accidental (or malicious) use of production resources.  With an Azure based setup, as developers we can happily develop and test without ever seeing a production password or connection string as they can be managed with the portal by the infrastructure or devops team...I'm more than happy to have less access to these resources :)
I would love to find a way forward that would allow me to maintain the following best practices:

Do not store sensitive information in a source control repository (regardless of how secure it is)
Be able to produce a single release ready set of build artifacts from a CI server
Perform a robust, reproducible (100% fidelity) automated deployment of these build artifacts to one or multiple environments where the environment manages any sensitive or per environment configuration settings (like the azure portal is capable of doing).

reproducible (100% fidelity) - means that we could run the deployment against a clean, empty environment or an existing environment and end up with the exact same deployment footprint, and that no additional steps are required to get the environment up and running.
This is where environment based configuration provides us with major advantages.
Back to the implementation suggestions.  If the configuration singleton was maintained as the source of configuration, would it not be possible to allow a custom "configuration adapter" to be set on that singleton from which it can call to retrieve configuration values (the example is rudimentary):
    public interface IImageProcessorSettings
    {
        string ConfigValue { get; }
        string AnotherConfigValue { get; }
    }

    public static class ImageProcessorSettings
    {
        private static IImageProcessorSettings _current;

        static ImageProcessorSettings()
        {
            _current = new DefaultImageProcessorSettings();
        }

        public static IImageProcessorSettings Current
        {
            get
            {
                if (_current == null)
                    throw new ConfigurationErrorsException(
                        "Settings have not been configured, please ensure Set() is called before accessing this configuration");
                return _current;
            }
        }

        public static void Set(IImageProcessorSettings settings)
        {
            _current = settings;
        }
    }

    public class DefaultImageProcessorSettings : IImageProcessorSettings
    {
        public string ConfigValue => ConfigurationManager.AppSettings[nameof(ConfigValue)];
        public string AnotherConfigValue => ConfigurationManager.AppSettings[nameof(AnotherConfigValue)];
    }

Such an implementation would then be able to maintain compatibility but also support more advanced scenerios for configuration, such as those I would be interested in.
I would be happy to look into this as a proof of concept, assuming you believe that such a setupo is even feasible or desired.

Thanks for your thoughtful response.

Will the new Core version support a more abstract configuration sub-system?

I would love it to do so. I've been concentrating on pure image manipulation functionality so far but would like to move to extensibility code soon. When It comes to creating the .Web component I definitely want something as flexible as possible.
I do see your point regarding sensitivity of information so if you can design a usable way of doing this then I am in favour of implementing such a system.

If you happen to be using the latest for ASP.NET (5/Core or RC1), you have a couple options already...  one (which you want to avoid) by using json configuration files to save key/value pairs...  but you also have the ability to use environment variable.  These should also work in Azure.
This is done by injecting IApplicationEnvironment into your Startup ctor, and including the .AddEnvironmentVariables() to your configuration builder.  Such as:
        public Startup(IApplicationEnvironment appEnv)
        {
            var builder = new ConfigurationBuilder()
                .SetBasePath("")
                .AddJsonFile("config.json")
                .AddEnvironmentVariables();

            Configuration = builder.Build();

        }

These are applied 'in-order'.  Say you have in your "config.json" the following:
{
  "AppSettings": {
    "SiteEmailAddress"<EMAIL_ADDRESS>    "BingKey":  "DO-NOT-PUT-SECURITY-KEYS-IN-CONFIGURATION"
  },
  "Data": {
    "DbConnection": "Server=..."
  }
}

And the server has the following key/value pair applied to its' environment variables:

(System Variables)
Variable:  "AppSettings:BingKey"
Value: "ABCDEFG123456"

When you 'need' to get the value for the key (say in your decryption service):
var bingKey = Startup.Configuration["AppSettings:BingKey"];
Since .AddEnvironmentVariables comes 'after' the .AddJsonFile directive in your startup... it will override any settings found within the config.json (such as in this case "BingKey").  You could create a service (hint:  decryptionService)  that takes that key and decrypts it using your own algorithm, to be used temporarily.. or however you like.
This way, absolutely no required key/values are stored in your repositories and can be configured during installation or later through some other process you've defined.

Thanks @razblack We're talking about the Framework version though, this won't be available on Asp.NET core. I'll bear your advice in mind though when designing the new system.

I've decided that additional configuration to this extent would require a major version and as such is out of scope of the project just now. I will bear this in mind in the Core version though


Support for mac key map.

What's new
Support for mac key map.

Summary of additions
Instead of using ctrl+key shortcuts, osx is using ⌘(Command)+key shortcuts.
In Recaf's code viewer,default key binding for copy and paste is  ⌘(Command)+C and ⌘(Command)+V , I need use both ⌘(Command)+key and Ctrl+Key to get work done without supporting mac's keymap .

What's fixed
NONE

Summary of bugs fixed

Is it possible to update KeybindingField to support ⌘?
I don't have a Mac but I recall somebody mentioned it doesn't work.
As for changing the default binds, I don't have an issue with it, but am leaning on opposing it. I would rather have everyone use the same keybinds by default and allow them to make changes on their own. For instance, each time a bind is mentioned having to say "Its this XYZ unless you're on mac the nits ABC" is a bit tedious. If a user changes they keybinds they're probably already aware they have done so.

Is it possible to update KeybindingField to support ⌘?
I don't have a Mac but I recall somebody mentioned it doesn't work.
As for changing the default binds, I don't have an issue with it, but am leaning on opposing it. I would rather have everyone use the same keybinds by default and allow them to make changes on their own. For instance, each time a bind is mentioned having to say "Its this XYZ unless you're on mac the nits ABC" is a bit tedious. If a user changes they keybinds they're probably already aware they have done so.

Because some of the key binding are using command instead using control( Copy and paste etc.) ,this is bit of annoying
, those key bindings changed their control key to command depends on what system you are using right now, i think other keybindings should follow too.

Because some of the key binding are using command instead using control( Copy and paste etc.) ,this is bit of annoying
, those key bindings changed their control key to command depends on what system you are using right now, i think other keybindings should follow too.


Make the 1.0.0 release

Delete dataset package caches – we need to recalculate stats for them
Re-run dev release CI for all datasets to incorporate doc generation code fixes
Make tagged versions of all datasets (1.0.0)
Tag the main repo
Double-check if all is fine

Done! :heart: :tada:


MM should flatten the property when the property only includes id

Terraform suggests us to flatten the property when the property only includes id. See the comment in the link https://github.com/neil-yechenwei/terraform-provider-azurerm/pull/5

I think Magic-Modules supports it well, and let's take the following block as an example.
  - !ruby/object:Api::Type::NestedObject
        name: 'vpnGateway'
        description: 'The VpnGateway associated with this VirtualHub.'
        required: false
        azure_sdk_references: ['/vpnGateway', '/properties/vpnGateway']
        properties:
          - !ruby/object:Api::Type::String
            name: 'id'
            description: 'Resource ID.'
            required: false
            azure_sdk_references: ['/vpnGateway/id', '/properties/vpnGateway/id']

When you want to flatten the property id in vpnGateway, just move it to an upper layer and delete its father property if necessary.
   - !ruby/object:Api::Type::String
        name: 'vpnGatewayID'
        description: 'Resource ID.'
        required: false
        azure_sdk_references: ['/vpnGateway/id', '/properties/vpnGateway/id']

Remember: DO NOT modify the paths in azure_sdk_references and the declarations in azure_sdk_definitions.


xComputer changes settings on a computer with Certification Authority Service installed.

xComputer will currently attempt to change the settings on a computer with certificate authority (which is not supported by Windows as far as I'm aware).
Is this something that should change? Got some code here that'll run a test, let me know if you want a PR in.

Hi @TheFish92 - I'm not sure I understand. What settings does it change? Sorry if I'm being dumb :grin:

Hi @PlagueHO, during tests xComputer changed the computer name of the CA server. (If you try and do this manually you're stopped in your tracks as you're not meant to do it). I've not tested any of the other functionality features of xComputer. May be something to test! :)

@PlagueHO would changing the CA's computer name not break all certificates issued by that CA? That's the issue. Sorry for not being as clear 🤓

So this is an issue ONLY when changing the name of a CA server and nothing to do with changing the name of a computer that has certificates issued by a CA? I can see how that wouldn't end well!
I've never tried it, but presumably Windows stops you doing this via the GUI?  Now for the political battle, is it Rename-Computer than should change, or xComputer! 😋

And yeah, the UI stops you in your tracks.

@TheFish92, @iainbrighton - ah right! Now I understand what you mean.
Wouldn't similar problems happen with other workloads? Where would we draw the line on what to prevent and what not? I can think of at least 3 or 4  other workloads or situations that renaming a computer would cause damage to the system.
I'm not sure it is the job of DSC resources to prevent a user from creating configs that could damage their system. The usual workflow used to create and deploy DSC configurations should always contain a "test" step where the DSC configuration is tested to ensure it produces the desired results. Deploying a workload without first testing that it doesn't result in a configuration that corrupts a node or environment is careless.
But that is just my 2c. :grin:

@PlagueHO Fair point. We could still display a warning of some sort though? Not every developer is going to understand the ramifications of renaming a CA. I'll close this for now though.
Liam


likes not working

First and foremost, bravo! and thanks for sharing your work.
As per title of this, the liking feature doesn't seem to be hitting my fly.io pocketbase instance.
Fwiw, I hope to translate some of this into solidjs running in vite. You might find the lighter feel of that worthwhile.
Thanks again,
Darren

Hey thanks for checking it out.
It should work. (It works for me on my local instance)
Make sure that your likes table is correct and that you have also set a unique index and that the API rules are set correct.

This is what it should look like.
I was using pocketbase v0.22.10 or v0.22.09 I believe.
I don't know about fly.io specifically.
If you followed the tutorial on Medium I recommend to use the following repo:  Tutorial github , they are probably the same but I am not completely sure.
I hope this helped and good luck in translating it into solidjs :).


add golden tests for script_data_hash

since the introduction of PlutusV3 script_data_hash calculation for some downstream tools broke, including plu-ts.
I am querying v3 costs models directly from a fully synced cardano-node on sanchonet, as follows:
cardano-cli query protocol-parameters --$sancho | jq .costModels.PlutusV3

which gives me back the following array:
[100788,420,1,1,1000,173,0,1,1000,59957,4,1,11183,32,201305,8356,4,16000,100,16000,100,16000,100,16000,100,16000,100,16000,100,100,100,16000,100,94375,32,132994,32,61462,4,72010,178,0,1,22151,32,91189,769,4,2,85848,123203,7305,-900,1716,549,57,85848,0,1,1,1000,42921,4,2,24548,29498,38,1,898148,27279,1,51775,558,1,39184,1000,60594,1,141895,32,83150,32,15299,32,76049,1,13169,4,22100,10,28999,74,1,28999,74,1,43285,552,1,44749,541,1,33852,32,68246,32,72362,32,7243,32,7391,32,11546,32,85848,123203,7305,-900,1716,549,57,85848,0,1,90434,519,0,1,74433,32,85848,123203,7305,-900,1716,549,57,85848,0,1,1,85848,123203,7305,-900,1716,549,57,85848,0,1,955506,213312,0,2,270652,22588,4,1457325,64566,4,20467,1,4,0,141992,32,100788,420,1,1,81663,32,59498,32,20142,32,24588,32,20744,32,25933,32,24623,32,43053543,10,53384111,14333,10,43574283,26308,10,16000,100,16000,100,962335,18,2780678,6,442008,1,52538055,3756,18,267929,18,76433006,8868,18,52948122,18,1995836,36,3227919,12,901022,1,166917843,4307,36,284546,36,158221314,26549,36,74698472,36,333849714,1,254006273,72,2174038,72,2261318,64571,4,207616,8310,4,1293828,28716,63,0,1,1006041,43623,251,0,1]

After checking with the plutus team I'm confident in saying that these parameters are preserved.
I have a simple transaction, with a single redeemer and no datums;
The only redeemer is the following:
{
    "tag": "Spend",
    "index": 0,
    "execUnits": {
        "steps": "1922100",
        "memory": "10500"
    },
    "data": {
        "int": "0"
    }
}

with conway allowing for multiple representations of the redeemer witnesses, I'm testing for both, even though I am aware that the intended representation should be "as-is" from the cbor, the tool used to build the transaction is the same used for testing.
The expected hash, part of the error message is:
9a0726be60d68003c541953ded2489526eedc607cd07622c68366a64c264038b

yet nothing seems to get me the same result:
exhibit 1: redeemers as map
input data:
a18200008200821929041a001d5434a10298fb1a000189b41901a401011903e818ad00011903e819ea350401192baf18201a000312591920a404193e801864193e801864193e801864193e801864193e801864193e80186418641864193e8018641a000170a718201a00020782182019f016041a0001194a18b2000119568718201a0001643519030104021a00014f581a0001e143191c893903831906b419022518391a00014f580001011903e819a7a90402195fe419733a1826011a000db464196a8f0119ca3f19022e011999101903e819ecb2011a00022a4718201a000144ce1820193bc318201a0001291101193371041956540a197147184a01197147184a0119a9151902280119aecd19021d0119843c18201a00010a9618201a00011aaa1820191c4b1820191cdf1820192d1a18201a00014f581a0001e143191c893903831906b419022518391a00014f5800011a0001614219020700011a000122c118201a00014f581a0001e143191c893903831906b419022518391a00014f580001011a00014f581a0001e143191c893903831906b419022518391a00014f5800011a000e94721a0003414000021a0004213c19583c041a00163cad19fc3604194ff30104001a00022aa818201a000189b41901a401011a00013eff182019e86a1820194eae182019600c1820195108182019654d182019602f18201a0290f1e70a1a032e93af1937fd0a1a0298e40b1966c40a193e801864193e8018641a000eaf1f121a002a6e06061a0006be98011a0321aac7190eac121a00041699121a048e466e1922a4121a0327ec9a121a001e743c18241a0031410f0c1a000dbf9e011a09f2f6d31910d318241a0004578218241a096e44021967b518241a0473cee818241a13e62472011a0f23d40118481a00212c5618481a0022814619fc3b041a00032b00192076041a0013be0419702c183f00011a000f59d919aa6718fb0001

resulting hash:
3faebd87a3f87898331d155f146aeaa5c5ce1815285f47d3fdb57d73f36bd861

exhibit 2: redeemers as array
8184000000821929041a001d5434a10298fb1a000189b41901a401011903e818ad00011903e819ea350401192baf18201a000312591920a404193e801864193e801864193e801864193e801864193e801864193e80186418641864193e8018641a000170a718201a00020782182019f016041a0001194a18b2000119568718201a0001643519030104021a00014f581a0001e143191c893903831906b419022518391a00014f580001011903e819a7a90402195fe419733a1826011a000db464196a8f0119ca3f19022e011999101903e819ecb2011a00022a4718201a000144ce1820193bc318201a0001291101193371041956540a197147184a01197147184a0119a9151902280119aecd19021d0119843c18201a00010a9618201a00011aaa1820191c4b1820191cdf1820192d1a18201a00014f581a0001e143191c893903831906b419022518391a00014f5800011a0001614219020700011a000122c118201a00014f581a0001e143191c893903831906b419022518391a00014f580001011a00014f581a0001e143191c893903831906b419022518391a00014f5800011a000e94721a0003414000021a0004213c19583c041a00163cad19fc3604194ff30104001a00022aa818201a000189b41901a401011a00013eff182019e86a1820194eae182019600c1820195108182019654d182019602f18201a0290f1e70a1a032e93af1937fd0a1a0298e40b1966c40a193e801864193e8018641a000eaf1f121a002a6e06061a0006be98011a0321aac7190eac121a00041699121a048e466e1922a4121a0327ec9a121a001e743c18241a0031410f0c1a000dbf9e011a09f2f6d31910d318241a0004578218241a096e44021967b518241a0473cee818241a13e62472011a0f23d40118481a00212c5618481a0022814619fc3b041a00032b00192076041a0013be0419702c183f00011a000f59d919aa6718fb0001

resulting hash:
06c087dd394976edf9806e981ddec70f6f6aba24b63db9b5061cd440b7f3bd82

additionally to golden tests, since this issue is likely to re-appear for each time new builtins are added, or some costs modified It would be great if the error message could report the input data used to get to the final, expected hash

@lehins tagging you to get this under your radar
This is a major blocker on my side, but of course, I understand there is a lot of stuff going on other than this.

Script hash mechanism has not changed in Conway, so I am not sure what exactly is the problem that you are experiencing. Worth noting that it is not relevant how the redeemers are represented, we use the original bytes that were submitted over the wire for script integrity hash computation.

additionally to golden tests, since this issue is likely to re-appear for each time new builtins are added, or some costs modified

Golden tests are not gonna help in this case, since as I mentioned algorithm has not changed, while cost models can change at any point. Are you sure you are using the correct cost model for computing the hash?

It would be great if the error message could report the input data used to get to the final, expected hash.

This is definitely a good idea to report original bytes that where used to compute the correct script integrity hash, since that would make debugging issues like that much easier. Unfortunately we won't be able to add this feature until the next era or at the earliest the next intra-era hard fork, since we can't change predicate failures at an arbitrary point.
If you include the offending transaction as hex encoded cbor, I could assist a little better, until then I can't really tell what is giving you trouble.


MacOS X El Capitan Installation

README leads me to believe that all that I need to do is this:
go get -tags=embed github.com/tecbot/gorocksdb

That goes without a problem (though, as docs say - takes a while),
but then if I try to use it (stripped to simple case):
package main

import "github.com/tecbot/gorocksdb"

func main() {
    opts := gorocksdb.NewDefaultOptions()
    opts.SetCreateIfMissing(true)
    gorocksdb.OpenDb(opts, "test.db")
}

I get:
➜  go build
# github.com/tecbot/gorocksdb
../../tecbot/gorocksdb/backup.go:4:11: fatal error: 'rocksdb/c.h' file not found
 #include "rocksdb/c.h"
          ^

I even tried to use this:
➜  CGO_CFLAGS="-I/..../gopath/src/github.com/cockroachdb/c-rocksdb/internal/include" go build
# github.com/tecbot/gorocksdb
ld: library not found for -lrocksdb
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Anything missing in docs?
Thanks!

As a workaround I used shared route and it worked, but still would be interesting to understand what's wrong with embedded way.
brew install rocksdb
CGO_CFLAGS="-I/usr/local/Cellar/rocksdb/4.4/include" \
CGO_LDFLAGS="-L/usr/local/Cellar/rocksdb/4.4 -lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy" \
  go get github.com/tecbot/gorocksdb

Don't forget to include the 'embed' tags when compiling
go build -tags-embed

I had the same problem, but I was able to install by doing this:
brew install rocksdb --with-tools --without-lite export CGO_CFLAGS="-I/usr/local/Cellar/rocksdb/5.0.1/include" CGO_LDFLAGS="-L/usr/local/Cellar/rocksdb/5.0.1/lib -lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy -llz4" go get github.com/tecbot/gorocksdb

I tried the above with rocksdb 5.1.2 but am getting "could not determine kind of name for C.rocksdb_options_set_allow_os_buffer" on install and use.

@jvsteiner same issue what did you do to fix it?

pulled latest from this repo - it should be fixed now.

Broken again  MacOS12
CGO_CFLAGS="-I/opt/homebrew/opt/rocksdb/include" CGO_LDFLAGS="-L/opt/homebrew/opt/rocksdb -lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy -llz4" make install
################################################################
building network: mainnet
building with ledger support
# runtime/cgo
ld: library not found for -lrocksdb
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [install] Error 2

# github.com/tecbot/gorocksdb
../../../go/pkg/mod/github.com/soothing-rain/gorocksdb@v0.0.1/array.go:4:11: fatal error: 'rocksdb/c.h' file not found
 #include "rocksdb/c.h"
          ^~~~~~~~~~~~~
1 error generated.

Same issue. Error happens only on debug mode while It's normal under run mode.


Kombu==2.1.3 calls non-existing msgpack method -- need to use newer celery/kombu?

Cross-post of ckanext-archiver issue 8: both archiver and qa use an older version of celery, which pulls in an older version of kombu, which falls over non-installed msgpack, and tries to use non-existing msgpack methods.

Haven't got this issue now. BTW: see https://github.com/ckan/ckanext-qa/issues/43


TypeError: init() takes 1 positional argument but 6 were given

"D:\soft\PyCharm 2018.1.2\bin\runnerw.exe" E:\workspace\python\PycharmProjects\MxShop\venv\Scripts\python.exe "D:\soft\PyCharm 2018.1.2\helpers\pycharm\django_manage.py" makemigrations E:/workspace/python/PycharmProjects/MxShop
Tracking file by folder pattern:  migrations
Traceback (most recent call last):
File "D:\soft\PyCharm 2018.1.2\helpers\pycharm\django_manage.py", line 52, in
run_command()
File "D:\soft\PyCharm 2018.1.2\helpers\pycharm\django_manage.py", line 46, in run_command
run_module(manage_file, None, 'main', True)
File "D:\develop\python3.6.5\Lib\runpy.py", line 205, in run_module
return run_module_code(code, init_globals, run_name, mod_spec)
File "D:\develop\python3.6.5\Lib\runpy.py", line 96, in run_module_code
mod_name, mod_spec, pkg_name, script_name)
File "D:\develop\python3.6.5\Lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "E:/workspace/python/PycharmProjects/MxShop\manage.py", line 15, in
execute_from_command_line(sys.argv)
File "E:\workspace\python\Envs\VueShop\lib\site-packages\django\core\management_init.py", line 371, in execute_from_command_line
utility.execute()
File "E:\workspace\python\Envs\VueShop\lib\site-packages\django\core\management_init.py", line 347, in execute
django.setup()
File "E:\workspace\python\Envs\VueShop\lib\site-packages\django_init.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "E:\workspace\python\Envs\VueShop\lib\site-packages\django\apps\registry.py", line 120, in populate
app_config.ready()
File "E:\workspace\python\PycharmProjects\MxShop\extra_apps\xadmin\apps.py", line 14, in ready
self.module.autodiscover()
File "E:\workspace\python\PycharmProjects\MxShop\extra_apps\xadmin_init_.py", line 29, in autodiscover
from xadmin.views import register_builtin_views
File "E:\workspace\python\PycharmProjects\MxShop\extra_apps\xadmin\views_init_.py", line 10, in
from .dashboard import Dashboard, BaseWidget, widget_manager, ModelDashboard
File "E:\workspace\python\PycharmProjects\MxShop\extra_apps\xadmin\views\dashboard.py", line 316, in
class ModelBaseWidget(BaseWidget):
File "E:\workspace\python\PycharmProjects\MxShop\extra_apps\xadmin\views\dashboard.py", line 321, in ModelBaseWidget
model = ModelChoiceField(label=_(u'Target Model'), widget=exwidgets.AdminSelectWidget)
File "E:\workspace\python\PycharmProjects\MxShop\extra_apps\xadmin\views\dashboard.py", line 285, in init
*args, **kwargs)
TypeError: init() takes 1 positional argument but 6 were given
Process finished with exit code 1

change
forms.Field.__init__(self, required, widget, label, initial, help_text, *args, **kwargs)
to
forms.Field.__init__(self)

code does not work with django 2.1, lots of issues

change
forms.Field.init(self, required, widget, label, initial, help_text, *args, **kwargs)
to
forms.Field.init(self, required=required, widget=widget, label=label, initial=initial, help_text=help_text, **kwargs)
because------------------
django 2.1 form filed param use *
def __init__(self, *, required=True, widget=None, label=None, initial=None,
             help_text='', error_messages=None, show_hidden_initial=False,
             validators=(), localize=False, disabled=False, label_suffix=None):

I don't know if it still works, but I had the same problem with a "modelform" of Django and I solved it by changing the name of the form.
It turns out that I had a "New_Exercise" view and the form was called "New_Exercise" ... I don't know why but I conclude that the subject was a "name conflict" issue. I changed the name of the form and everything worked perfect. Well just one opinion, I hope it helps ...


Reimplement CLI in rust

Node binding should export runCLI.
This would help lots of cases.

Hey @kdy1, I keep looking at the Typescript CLI entry points and wonder why they exist and it's not just straight Rust binaries using clap (or structopt).
Is there functionality that is enabled by having the command line programs exposed as node executables? Is it part of a plan for a Javascript-based plugin system maybe?
I just wanted to look into the reason why --ignore isn't working for example and it seems like it was never implemented from what I can tell. Implementing this would be much more straightforward if it was all just Rust :pray:

Is there functionality that is enabled by having the command line programs exposed as node executables? Is it part of a plan for a Javascript-based plugin system maybe?

No. It's because to make managing version more convenient for the end-user

Thanks, that helps! I will try to find some time to tackle this one as I think it would simplify things quite a bit - we should be able to remove out quite a bit of typescript :+1:
I assume you would prefer to use clap over structopt?

It's quite late to realize but I forget js-side plugin support in @swc/cli. This may be some headache if we want 100% feature parity.
For now I'll skip those until new cli becomes stable enough. This is also related with experimental plugin stablization and may possible to think about whole plan accordingly based on those.

swc_cli is a ground to implement this. Roughly, these are the tasks need to be implemented and if anyone want to dive in, please feel free to send PR

compile command

port rest of cli flag features in subcommand flag struct
watch mode implementation

minify command
lint command
bundle command - accept JSON based configs

Currently, implementations are sort of exploration, does not have to be 1:1 match to existing @swc/cli's behavior. Specifically, there will be rough edges to deal with dynamic values which requires js runtime. We want to give suffecient time to iterate, finalize behaviors based on feedbacks & some constraints we have.

I would really like to work on one of the commands, but I need some guidance
Anyone could help me to start ?

Hi @kwonoj
Is this PR still valid? https://github.com/swc-project/swc/pull/5003

Hey @kwonoj,
Is this still a good first issue? I am looking back at some of the PRs referenced in the ticket and am trying to get an understand at whats going on. I am still kind of unsure whats being asked.
If I had to guess its replace the entire nodejs cli into thats a rust/node bind gen?


Some boolean settings are displayed as strings

Yesterday I turned on "bundler 2 mode" by dropping the following file in ~/.bundle/config
---

BUNDLE_GEM__TEST: "rspec"
BUNDLE_GEM__MIT: "true"
BUNDLE_GEM__COC: "true"
BUNDLE_ALLOW_BUNDLER_DEPENDENCY_CONFLICTS: "true"
BUNDLE_ALLOW_OFFLINE_INSTALL: "true"
BUNDLE_AUTO_CLEAN_WITHOUT_PATH: "true"
BUNDLE_AUTO_CONFIG_JOBS: "true"
BUNDLE_CACHE_ALL: "true"
BUNDLE_CACHE_COMMAND_IS_PACKAGE: "true"
BUNDLE_CONSOLE_COMMAND: "true"
BUNDLE_DEFAULT_INSTALL_USES_PATH: "true"
BUNDLE_DEPLOYMENT_MEANS_FROZEN: "true"
BUNDLE_DISABLE_MULTISOURCE: "true"
BUNDLE_ERROR_ON_STDERR: "true"
BUNDLE_FORGET_CLI_OPTIONS: "true"
BUNDLE_GLOBAL_PATH_APPENDS_RUBY_SCOPE: "true"
BUNDLE_GLOBAL_GEM_CACHE: "true"
BUNDLE_INIT_GEMS_RB: "true"
BUNDLE_LIST_COMMAND: "true"
BUNDLE_LOCKFILE_USES_SEPARATE_RUBYGEMS_SOURCES: "true"
BUNDLE_ONLY_UPDATE_TO_NEWER_VERSIONS: "true"
BUNDLE_PATH_RELATIVE_TO_CWD: "true"
BUNDLE_PLUGINS: "true"
BUNDLE_PREFER_GEMS_RB: "true"
BUNDLE_PRINT_ONLY_VERSION_NUMBER: "true"
BUNDLE_SETUP_MAKES_KERNEL_GEM_PUBLIC: "false"
BUNDLE_SKIP_DEFAULT_GIT_SOURCES: "true"
BUNDLE_SPECIFIC_PLATFORM: "true"
BUNDLE_SUPPRESS_INSTALL_USING_MESSAGES: "true"
BUNDLE_UNLOCK_SOURCE_UNLOCKS_SPEC: "true"
BUNDLE_UPDATE_REQUIRES_ALL_FLAG: "true"
BUNDLE_USE_GEM_VERSION_PROMOTER_FOR_MAJOR_UPDATES: "true"
BUNDLE_VIZ_COMMAND: "false"
BUNDLE_DEFAULT_CLI_COMMAND: "cli_help"

Everything is working as expected so far, but I see something "weird" when I run bundle config. This is the output I get:
$ bundle config
Settings are listed in order of priority. The top value will be used.
gem.test
Set for the current user (/home/deivid/.bundle/config): "rspec"

gem.mit
Set for the current user (/home/deivid/.bundle/config): true

gem.coc
Set for the current user (/home/deivid/.bundle/config): true

allow_bundler_dependency_conflicts
Set for the current user (/home/deivid/.bundle/config): true

allow_offline_install
Set for the current user (/home/deivid/.bundle/config): true

auto_clean_without_path
Set for the current user (/home/deivid/.bundle/config): true

auto_config_jobs
Set for the current user (/home/deivid/.bundle/config): "true"

cache_all
Set for the current user (/home/deivid/.bundle/config): true

cache_command_is_package
Set for the current user (/home/deivid/.bundle/config): true

console_command
Set for the current user (/home/deivid/.bundle/config): true

default_install_uses_path
Set for the current user (/home/deivid/.bundle/config): true

deployment_means_frozen
Set for the current user (/home/deivid/.bundle/config): true

disable_multisource
Set for the current user (/home/deivid/.bundle/config): true

error_on_stderr
Set for the current user (/home/deivid/.bundle/config): true

forget_cli_options
Set for the current user (/home/deivid/.bundle/config): true

global_path_appends_ruby_scope
Set for the current user (/home/deivid/.bundle/config): "true"

global_gem_cache
Set for the current user (/home/deivid/.bundle/config): true

init_gems_rb
Set for the current user (/home/deivid/.bundle/config): true

list_command
Set for the current user (/home/deivid/.bundle/config): true

lockfile_uses_separate_rubygems_sources
Set for the current user (/home/deivid/.bundle/config): true

only_update_to_newer_versions
Set for the current user (/home/deivid/.bundle/config): true

path_relative_to_cwd
Set for the current user (/home/deivid/.bundle/config): "true"

plugins
Set for the current user (/home/deivid/.bundle/config): true

prefer_gems_rb
Set for the current user (/home/deivid/.bundle/config): true

print_only_version_number
Set for the current user (/home/deivid/.bundle/config): true

setup_makes_kernel_gem_public
Set for the current user (/home/deivid/.bundle/config): false

skip_default_git_sources
Set for the current user (/home/deivid/.bundle/config): true

specific_platform
Set for the current user (/home/deivid/.bundle/config): true

suppress_install_using_messages
Set for the current user (/home/deivid/.bundle/config): true

unlock_source_unlocks_spec
Set for the current user (/home/deivid/.bundle/config): true

update_requires_all_flag
Set for the current user (/home/deivid/.bundle/config): true

use_gem_version_promoter_for_major_updates
Set for the current user (/home/deivid/.bundle/config): "true"

viz_command
Set for the current user (/home/deivid/.bundle/config): false

default_cli_command
Set for the current user (/home/deivid/.bundle/config): "cli_help"

retry
Set for your local app (/home/deivid/Code/bundler/.bundle/config): 3

path
Set for your local app (/home/deivid/Code/bundler/.bundle/config): ".bundle"

jobs
Set for your local app (/home/deivid/Code/bundler/.bundle/config): "3"

As you can see, some of the boolean setting are printed as strings. Not sure if there's an underlying bug here, but it seems weird, right?

Are they listed as Boolean settings in Bundler::Settings ?

Yeah.
Also seeing the same thing on numeric settings, jobs' value is printed as a string, whereas retry's value as a number.

I can't reproduce this on master:
Settings are listed in order of priority. The top value will be used.
gem.test
Set for the current user (bundle_config): "rspec"

gem.mit
Set for the current user (bundle_config): true

gem.coc
Set for the current user (bundle_config): true

allow_bundler_dependency_conflicts
Set for the current user (bundle_config): true

allow_offline_install
Set for the current user (bundle_config): true

auto_clean_without_path
Set for the current user (bundle_config): true

auto_config_jobs
Set for the current user (bundle_config): true

cache_all
Set for the current user (bundle_config): true

cache_command_is_package
Set for the current user (bundle_config): true

console_command
Set for the current user (bundle_config): true

default_install_uses_path
Set for the current user (bundle_config): true

deployment_means_frozen
Set for the current user (bundle_config): true

disable_multisource
Set for the current user (bundle_config): true

error_on_stderr
Set for the current user (bundle_config): true

forget_cli_options
Set for the current user (bundle_config): true

global_path_appends_ruby_scope
Set for the current user (bundle_config): true

global_gem_cache
Set for the current user (bundle_config): true

init_gems_rb
Set for the current user (bundle_config): true

list_command
Set for the current user (bundle_config): true

lockfile_uses_separate_rubygems_sources
Set for the current user (bundle_config): true

only_update_to_newer_versions
Set for the current user (bundle_config): true

path_relative_to_cwd
Set for the current user (bundle_config): true

plugins
Set for the current user (bundle_config): true

prefer_gems_rb
Set for the current user (bundle_config): true

print_only_version_number
Set for the current user (bundle_config): true

setup_makes_kernel_gem_public
Set for the current user (bundle_config): false

skip_default_git_sources
Set for the current user (bundle_config): true

specific_platform
Set for the current user (bundle_config): true

suppress_install_using_messages
Set for the current user (bundle_config): true

unlock_source_unlocks_spec
Set for the current user (bundle_config): true

update_requires_all_flag
Set for the current user (bundle_config): true

use_gem_version_promoter_for_major_updates
Set for the current user (bundle_config): true

viz_command
Set for your local app (/Users/segiddins/Desktop/GemfileTest/.bundle/config): true
Set for the current user (bundle_config): false

default_cli_command
Set for your local app (/Users/segiddins/Desktop/GemfileTest/.bundle/config): "cli_help"
Set for the current user (bundle_config): "cli_help"

retry
Set for your local app (/Users/segiddins/Desktop/GemfileTest/.bundle/config): 5

jobs
Set for your local app (/Users/segiddins/Desktop/GemfileTest/.bundle/config): 3

config
Set via BUNDLE_CONFIG: "bundle_config"

Oh, yeah, forgot to say this is on 1.16.4.

I think we can close this as being fixed then? bundle config was rewritten shortly after 1.16 branched

Fine with me, since there's no specific misbehavior associated to problem, and it's fixed in master as you said :+1:

Ok, so I ended up getting to the bottom of this. The settings that are printed as strings are the only settings not available in 1.16-stable. Since bundler has no hint about them being boolean, it just prints them as strings.
This leads to 2 questions:

Should this settings be backported so people can start opting in?
Bundler currently gives no hint about unknown settings (like these four), so if you for example make a typo on a setting, it will go unnoticed. Should it gives a warning or error, should these warning/error behavior be configurable under a new setting?

Non-string Settings aren’t enumerated anywhere, so there’s no way to know (at present) which are expected


[Bug]: Error if I try to select more than 1 image

Summary
Since when I select a pin, it makes me choose only one picture, I used to select more pictures in "free mode" and then categorize them in the proper tab. After the latest updates, I can't do it anymore and I get an error.
Steps to reproduce

Go to the "Contributions" tab
click the "+" icon
choose the second icon
select two pictures and then I click in the upper-right corner "Select"
an error says: "An error occurred while selecting the images" (I'm roughly translating since my UI is in Italian).

Expected behaviour
Let me upload more pictures like it used to be
Actual behaviour
It works only with one picture at the time.
Device name
Google Pixel 6
Android version
Android 14
Commons app version
5.1.0
Device logs
No response
Screen-shots
No response
Would you like to work on the issue?
Prefer not

Seems like I can upload more picture if at step 3 I choose the third icon and not the second.

Unfortunately I can't reproduce the issue, I just uploaded successfully a set of two pictures using the second button.
Would you mind sending a screenshot of your settings, at the "Uploads" section?

I could trivially reproduce the issue on my phone as well as on a virtual device running API level 34

Would you mind sending a screenshot of your settings, at the "Uploads" section?

https://github.com/user-attachments/assets/22c17ca9-2899-44f1-9e89-2589e420e09d

Ah yes I can reproduce now, thanks a lot! 🙂

The issue appears because of improper handling of the result data when documents based photo picker is used. The other cases (camera, gallery and custom selector) are properly handled.
I'd like to work on this.


Grafana 4.4.x

Hello!
There will be a plugin for snap to support the version of grafana 4.4.x and higher.
I tried to use it on version 4.4.1.
The datasource has been added. But the data from snap does not get. I watched the sniffer - requests to the port api to snap from the grafana do not come

I did some tests with Grafana 4.4.1 and it seems to work.

Really works.
Thank you!


Fix MSAN out-of-bounds error

does this run actions...?

Oops, I didn't mean to make this pull request against the upstream repo 😬
I'll leave it here instead of deleting it only to (hopefully) recreate it later. But please ignore it for the moment!

OK, in fact since the code doesn't even build I will just delete it since I probably need to take a bit more time to actually make it not garbage :)

In case anyone is curious about this in the future - the issue has been fixed already. And the reason this PR didn't build is because it was just a git brainfart, mixing up code from Google's current legacy version (where there's an MSan bug) and the upstream version (where it's already fixed).


Add search api reference temporarily to avoid download during build

@aressem Please review.
This is the pragmatic short term solution until a better one is implemented.

@gjoranv Please review.


fix/NSS#1208

Fix for https://github.com/solid/node-solid-server/issues/1208

Okay this is now good to merge @RubenVerborgh

Just to confirm, I was able to get this from a test script with this branch:
logged in as <https://jeffzucker.dev.inrupt.net/profile/card#me>
Ok GET public resource from solid-server/5.1.3
Ok PUT resource in private container.

Thanks @jaxoncreed and @jeff-zucker.
@jaxoncreed Do you want to become a maintainer of the package? Then I'd give you the right permissions for merging and npm publishing. If you prefer not to, I can follow up.

@RubenVerborgh Sure. I can take that on.

:+1:  It will be great to have someone on the server side managing this  :-).  Please count on me for any testing or other help you need.

It will be great to have someone on the server side managing this :-)

Hey hey, I've done server work 😛 But not lately indeed.

Please count on me for any testing or other help you need.

Excellent, thanks!

I've done server work

Ha, yes, I'm sure you have.  I just meant that  given such strong (and in the long run inappropriate)  binding of app and server, it will be good to have the catching designed by someone who does the pitching :-).

@RubenVerborgh Could I also have npm access to this? My username is the same (jaxoncreed)

@jaxoncreed, if you npm it, please include https://github.com/solid/solid-cli/pull/5, otherwise rdflib will continue to show vulnerabilities.

@jaxoncreed Best to have access to the entire @solid group in npm; Inrupt can help you with that.

@jeff-zucker absolutely. Good catch


mlmmj: Fix invalid mailman entry and update dbs

Hi,
two things are contained in this PR that are somehow related.
Invalid Mailman Command
There is a "$domain mailman:" entry generated on creation which ends up in a warning and messages that cannot be delivered due to "mail transport unavailables"
Sep 16 09:22:05 nixe.k4cg.org postfix/qmgr[23117]: warning: connect to transport private/mailman: No such file or directory
Sep 16 09:22:05 nixe.k4cg.org postfix/error[23227]: 8973C8975E6C: to=<$mailaddr>, relay=none, delay=0.03, delays=0.02/0/0/0, dsn=4.3.0, status=deferred (mail transport unavailable)

virtual and transports databases are not updated
when new content is coming (or changed) the belonging virtuals.db and transports.db are not being updated by module
warning: database /var/lib/mlmmj/transports.db is older than source file /var/lib/mlmmj/transports

Both of these errors are fixed in the PR

Thanks!


Add helper for running the tutorials as tests

Add utils/test/test_tutorials for being able to run the notebooks as
unit tests manually using the standard Python unittest framework. The
implementation automatically discovers the "*.ipynb" files under
reference/, and attempts to run the Python code in each file as a
single unit test.
Some instructions on how to use it can be found in the docstring at utils/test/test_tutorials.py, but the goal was to keep it as close as regular tests as possible, ie:
python -m unittest

Solves #144 .

Thank you very much! As we have tutorials that can be used for testing, I am merging it.


Use webpack to create a module as output

We currently just use webpack to translate JSX in the JS files, then a script (cp_static.sh) to copy files around (plus some handlebars stuff - build_templates.sh). We should do all this build system stuff in one place - using webpack.

Since you are using React now, do you also plan to replace the remaning handlebar templates into React components?

Yes, I do


Disable codecov/patch

Mentioned in #255  "I tried to disable codecov/patch because some of our tests (pre-trained tests) are done locally. codecov/patch is also reported to be not very reliable. Some other projects have met such issues (argoproj/argo-cd#1926). I think codecov/project is good enough to check the code quality for now. I tried many ways to disable codecov/patch but failed. It seems that someone also met a similar problem (https://community.codecov.io/t/cannot-disable-codecov-patch-check/682/4). Do you think it is reasonable to merge PRs regardless of the status of codecov/patch?"

https://community.codecov.io/t/cannot-disable-codecov-patch-check/682/8


Feature : Clear Team Temp Survey Results at a regular interval

As a Team Temp Admin
I Want to clear the team temp results at a [given interval]
So that I do not have to manually clear the results every time as I might forget.
[given interval] is a Number Of Days

See Model Proposal on how we could support this in the data model.


Feature Request - disable more useless services

Hi, i'd like to give a suggestion: it'd be good if you added the services found in the sites below to make windows 10 faster/lighter:
https://windowsreport.com/disable-windows-services/
https://gist.github.com/2510/addc4d62b681b7ee3bf2

Disabling the services listed here is not a good move, in my opinion.
For example, although Remote Registry and Retail Demo Service can be safely disabled, the Print Spooler service is required for printing functionality. Similarly, the Bluetooth Support Service is required for Bluetooth connectivity and some people may use Bitlocker for encryption.
If you're really keen on disabling services, I would recommend following the Black Viper’s Windows 10 Service Configurations instead and selecting Manual instead of Disabled whenever in doubt.
You could also try the official Autoruns tool by Microsoft. It hides core services by default so you probably won't break anything.

First of all thank you for the hint about sysinternals. :+1:
But i disagree about print spooler/bluetooth, i dont use any (and i think i'll hardly have any of them here) and i believe most of ppl dont use those stuff, it can be disabled safely (like every option in privatezilla it will be an optional setting in the end). ;)


Qpair function problem at cc.en transition

Hi
Sorry~ i have too many question
i tested qpair create / delete(del qpair)  => CC.EN transition (1->0->1)
but seems like qpair function still remaining in memory
qpair create (qpair=d.Qpair(nvme0,xx)) command to run SQ1,CQ1 create -> SQ1,CQ1 delete -> SQ1,CQ1 Create at 2nd loop
3rd loop more duplicate. SQ1,CQ1 create -> SQ1,CQ1 delete -> SQ1,CQ1 create -> SQ1,CQ1 delete -> SQ1,CQ1 create -> SQ1,CQ1 delete
but insted of using cc.en transition. use reset function no this issue.

Hi, Catogts,
Could you please share with me a minimized piece of script to reproduce these issues?
Thanks,
-Crane

Hi, Crane
minimized script is below
for a in range(100):
qpair=q.Qpair(nvme0,16)
buf=d.Buffer(512)
nvme0n1.write(qpair,buf,0,1).waitdone()
del qlist
del buf
nvme0[0x14]=int('00460000',16)
time.sleep(2)
nvme0[0x14]=int('00460001',16)
time.sleep(2)
result is starting  qpair create/delete SQ1,CQ1  * loop at test start and fail about 5~6 loops
i checked this problem at test device throught UART
reset is no problem. only issue at  cc.en toggle

ok~ right
I couldn't use the tab key because I wrote a portable device
qlist => qpair
miss typing

OK, so here is your script:
def test_issue_32(nvme0, nvme0n1):
    for a in range(100):
        qpair=d.Qpair(nvme0, 16)
        buf=d.Buffer(512)
        nvme0n1.write(qpair,buf,0,1).waitdone()
        del qpair
        del buf
        nvme0[0x14]=int('00460000',16)
        time.sleep(2)
        nvme0[0x14]=int('00460001',16)
        time.sleep(2)

In the above script, it resets NVMe controller by writing NVMe registers. However, pynvme host driver does not understand that the controller is resetted, and so its internal data and state are different from that in the device. For example, after CC.EN 1=>0=>1, the admin qpair head/tail pointers are different in host driver and NVMe device.
In order to reset both host driver and NVMe device, we suggest to use Controller.reset() method. For example:
def test_issue_32(nvme0, nvme0n1):
    for a in range(100):
        qpair=d.Qpair(nvme0, 16)
        buf=d.Buffer(512)
        nvme0n1.write(qpair,buf,0,1).waitdone()
        del qpair
        del buf
        nvme0.reset()

I think you have already tested this one, right?
Thanks,
-Crane

I tested with register backup(include aqs,acq tail,header) before cc.en transition and restore register after cc.en 1
How can i initialize host driver without reset?

We do not support to initialize host driver without reset.

We will consider this reset flow in our next phase of development.

Thank you!


Add oelint

Add a CI build with oelint analysis.

I'll remove the oelint.vars.homepageping rule as it requires internet access.


Fix for slow deletion of harvest resources in MySQL/MariaDB

In MySQL the Hibernate-generated statements for deleting records from harvest_resource and arc_harvest_resource lead to long running queries which might time-out in the case of large harvests. The fix is to use a simple ANSI-SQL native query and to add a cascaded delete to the schema. A fix without any alteration to the schema seems to be impossible, if the code is to run on all supported database platforms.

@hannakoppelaar are the code and db changes coupled together? Can I deploy the code without the db schema update or will that cause problems?

@hannakoppelaar are the code and db changes coupled together? Can I deploy the code without the db schema update or will that cause problems?

@obrienben I don't think it will work because ARC_HARVEST_RESOURCE will no longer be updated when HARVEST_RESOURCE is updated, which will cause the database to complain about referential integrity.

Tested with Mysql8. It cost 115 seconds to delete 1M Harvest Resources rows. It's fine from my opnion.
I'll test it with PostgreSQL and Oracle.


quiet mode to make bot responses less verbose for large chatrooms

Matrix was used as the event platform for the F40 release party. As people discovered the cookie-giving features, chat got a little spammy, especially with the !cookie count command.

I think it may be nice to have a "quiet" mode that does something like:

move bot replies to DMs or another room
reduce the verbosity of longer replies
rate limits replies or batches them into one message
.etc

hmmm, not sure if this is worth the hassle TBH.

People can DM zodbot itself and use these commands if they want.
the only command we really have that outputs all this is that one particular command. (and only for a handful of users too @nirik has been around for a while)

hmmm, not sure if this is worth the hassle TBH.

yeah i think you might be right. Been trying to figure out how to avoid doing too much Yak shaving lately haha. Apologies for the extraneous issue!


add Citi API

Add Citi API to Finance

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is ordered alphabetically
[x] My submission has a useful description
[x] The description does not have more than 100 characters
[x] The description does not end with punctuation
[x] Each table column is padded with one space on either side
[x] I have searched the repository for any relevant issues or pull requests
[x] Any category I am creating has the minimum requirement of 3 items
[x] All changes have been [squashed][squash-link] into a single commit

Relates to: #2107

Hi @pawelborkar @matheusfelipeog this PR should be ready for review / approval. Thanks!


Support testing with a local googletest checkout

Debian likes doing dependency management manually, so add support for testing against a local googletest checkout rather than one downloaded from GitHub. Add an ABSL_LOCAL_GOOGLETEST_DIR variable that can be used in conjunction with -DABSL_RUN_TESTS=ON -DABSL_USE_GOOGLETEST_HEAD=OFF to specify the googletest location manually, and do a bit of related cleanup.

As per https://github.com/abseil/abseil-cpp/blob/master/CONTRIBUTING.md#guidelines-for-pull-requests, Googlers should send out Piper CLs, they are much easier for us to handle. Sorry about this, we should try to make this more prominent.


Responsive Top Nav

Breakpoint of 768px will truncate the top nav options into a hamburger menu.
Clicking/tapping onto the hamburger menu will then trigger a dropdown of the top nav functionality.

Landing Page Example
https://www.figma.com/file/ChyT88EmP2Rmzx35I9erCL/Marketing-Site?node-id=6%3A0
Hamburger Icon
Hamburger.zip

I'll work on this


Token consumption issue in API calls by DeviseSqreener#Sqreen?

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've searched for any related issues and avoided creating a duplicate issue.

Description
Hey, let me first say thanks -- Sqreen is a wonderful service that helps me sleep better at night and I am very grateful for the work you all have put into it.
I've spent some time trying to rig devise_sqreener for some extra coverage on a project I maintain that's covered by service-level sqreen, and I'm having a little bit of difficulty. I apologize if this is a just me thing! It seems like either the API calls made by DeviseSqreener#Sqreen are either dropping the token or expecting something else than I'm giving it, and I can't quite figure out why. Steps to reproduce and a minimal reproduction app are included.
Reproducible in:
devise_sqreener version: 0.1.1
Rails version: 5.1
Ruby version: 2.4.3 (though also getting this failure on 2.5.1)
OS version(s): Mac OS High Sierra 10.13.4
Steps to reproduce:

Create a new sqreen app, application environment development, and get the API key
Clone https://github.com/colinxfleming/sqreencheck , a minimal reproduction I made that sets up devise and devise_sqreener
$ bundle install
$ export SQREEN_API_TOKEN=YOUR_TOKEN_HERE with the token from the new sqreen app you've set up
$ rails c

At this point, we confirm that the token is properly loaded into the Sqreener class:

User.class.sqreener  #=> #<DeviseSqreener::Sqreen:0x00007fde292cbc58 @sqreen_api_token="YOUR_TOKEN_HERE">

And we try to make the call -- I think this is basically what happens on login or user create --

<EMAIL_ADDRESS>
Expected result:
Based on the docs, I think I'm expecting a hash of the data back, since I'm making a request with the library containing an API token.
Actual result:
Request response was a 401 so it returned nil. The response body is as follows, which seems to indicate that either the token is getting dropped somehow, the token is bad for reasons I can't quite determine, or the API is expecting a different token than I think it does.
"{\"code\":401,\"details\":null,\"errno\":4011,\"error\":\"Unauthorized\",\"info\":null,\"message\":\"No key was found in this request. You can retrieve your free API key at https://www.sqreen.io/developers\"}\n"

Attachments:
https://github.com/colinxfleming/sqreencheck
Thanks very much for your time, and let me know if there's anything I can do to be helpful (or if I'm doing something silly by accident, in which case, sorry about that!)

Hello @colinxfleming , we've decided to sunset this API as we were not happy with the relevance of some data we provided. Plus, it was not aligned with our product roadmap. We may come back to it at later stages if our customers request such a feature.
Let me know if I can help you further!


Configure decimal places

Hi,
just found your package. Thx for fixing my exact niche problem :).
I have to use this plugin because I work in an environment where I can't control the root font-size, which is set to 14px.
The only remaining issue for me is the rounding. E.g. *-3 (=16px) gets converted to 0.8571428571428571rem. I don't realy need that many decimal places.
Would it be possible to add a cofiguration option for the maximum amount of decimal places?

Hey @MichaelBrunn3r,
thanks for reaching out!
I'm trying to wrap my head around your problem, but I don't really seem to get it. Could you give me an example of a tailwind class that uses spacing (like p-3 or text-lg) and which values your getting and what you are expecting with a base font size set to 14px?

I see what you mean. The issue here is that browsers handle rounding for fractional values differently. Some browsers just "cut off" decimal values, others round up or down to the nearest integer.
But, browsers still use the exact value for calculations that include those fractional values, and round/truncate afterwards.
Therefore, if we would add an option to limit the number of decimal places, we could actually see a difference between the "full" value with all decimal places and a "stripped" value with fewer decimal places.
Although, we could add the option with a disclaimer and it's up to the user to decide, if the tradeoff is relevant for their use case.
What do you think?

That sounds like a very good idea and would solve my issue.
As you say, I don't think it should be a default. Having the full precision is important to prevent unexpected behaviour. Users should decide on their own when to round the values and be warned of the downsides.

I will consider the option to configure the number of decimal places for the next release of this package and keep you updated on the changes in this thread.
Thanks again for the input!


Remove IComponentContext

Fixes part of: #12553
We don't believe that this is needed anymore. We no longer call
OnAfterRender when you're prerendering, so the main use case of this
type is gone.
The recommendation is to use OnAfterRender and track the state yourself if you want to know whether you're in prerendering or not.

Do you have any advice on how services that relied on IComponentContext to know the connection was complete can now test for that?
It seems like the only choices now will be to require a component to "inform" the service(s) that we are connected or to wrap anything that may fail if called too early in the lifecycle in a loop and a try..catch, neither of which are great solutions for testing connectivity.
Thanks

I've had some discussions about this already here - https://github.com/aspnet/AspNetCore/issues/13296
Could you comment there are give me a little more concrete info about your scenarios? My guess is that IComponentContext wasn't a good fit for what you need either.


[3.0] Fix testDoRetry failure on windows

What is the purpose of the change
Fix FailbackRegistryTest.testDoRetry() test failure on windows.
Error
[ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.201 s <<< FAILURE! - in org.apache.dubbo.registry.support.FailbackRegistryTest
[ERROR] org.apache.dubbo.registry.support.FailbackRegistryTest.testDoRetry  Time elapsed: 1.187 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <0> but was: <1>
        at org.apache.dubbo.registry.support.FailbackRegistryTest.testDoRetry(FailbackRegistryTest.java:86)

Codecov Report

Merging #9169 (298b3c9) into 3.0 (e4415e5) will decrease coverage by 0.19%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                3.0    #9169      +/-   ##
============================================
- Coverage     64.91%   64.72%   -0.20%
+ Complexity      312      311       -1
============================================
  Files          1177     1177
  Lines         50946    50918      -28
  Branches       7581     7555      -26
============================================
- Hits          33074    32957     -117
- Misses        14276    14363      +87
- Partials       3596     3598       +2

Impacted Files
Coverage Δ

...a/org/apache/dubbo/rpc/filter/AccessLogFilter.java
24.35% <0.00%> (-44.88%)
:arrow_down:

...va/org/apache/dubbo/rpc/support/AccessLogData.java
53.16% <0.00%> (-37.98%)
:arrow_down:

...dubbo/common/status/support/LoadStatusChecker.java
46.15% <0.00%> (-15.39%)
:arrow_down:

...ache/dubbo/remoting/transport/AbstractChannel.java
75.00% <0.00%> (-12.50%)
:arrow_down:

.../common/threadpool/serial/SerializingExecutor.java
70.37% <0.00%> (-7.41%)
:arrow_down:

...pache/dubbo/remoting/transport/AbstractServer.java
57.14% <0.00%> (-4.29%)
:arrow_down:

...he/dubbo/remoting/transport/netty/NettyServer.java
70.17% <0.00%> (-3.51%)
:arrow_down:

...c/main/java/org/apache/dubbo/rpc/RpcException.java
83.33% <0.00%> (-3.34%)
:arrow_down:

.../org/apache/dubbo/qos/legacy/LogTelnetHandler.java
30.30% <0.00%> (-3.04%)
:arrow_down:

...nt/metadata/ServiceInstanceMetadataCustomizer.java
91.42% <0.00%> (-2.86%)
:arrow_down:

... and 28 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 e4415e5...298b3c9. Read the comment docs.


use origin local if release specific repo not found

If there is no release specific repo e.g. currently the repo
centos-paas-sig-openshift-origin38-rpms does not exist, then
just use the latest origin built on the devenv machine.

We're so close on my end to not need any of this nonsense and write jobs explicitly to use specific versions ... but until then -- let's do this

@stevekuznetsov ok, good to know - I've already pushed these, and they are working

Nice


add support for experimental headers

Update request_context.rs to hold all x-* headers, and send them in the final response.
schema @server(headers: {experimental: "x-csrf-token"}) {
  query: Query
}

The final response of the API should send the x-csrf-token headers.
Update the documentation for server here: https://tailcall.run/docs/operators/server

/bounty 200

/attempt

@tusharmath please assign to me. Thanks.

I'll give this a shot as I closed a few headers-related tickets recently /attempt #1413

@tusharmath I think the spec to this could be
schema @server(headers: {experimental: ["x-csrf-token"]}) {
  query: Query
}

instead of the original proposed on the issue. In this way, users could add multiple x-something headers. it does make sense?

Yes, I made a typo there.


Adding max items limit for form list editor

Related ticket: https://github.com/CartoDB/bigmetadata/issues/199
Adding max items limit for form editor list. If you reach the limit, the add-button will be hidden.
Acceptance.

Enable new DO analysis in your testing account.
Create a map with points.
Choose a DO analysis and try to add 10 measurements (crazy thing but...).
Check you can't add the 11th.
Celebrate it if works (:tada:).

Works like a charm ✨

🚀


Upgrade dependencies

Coverage decreased (-2.4%) to 97.619% when pulling cb5aeb4916cd3f6a31f891924a3c1f1adae13628 on upgrade into 4afc61c24d5b6aa0809c0851f8d1e59f3fd437b6 on master.


Part 8 integration specs and fix n+1

This pull request addresses two main issues:

fix the N+1 problem when fetching all posts and comments of a user
use Capybara to write integration tests for each view

The screenshots of the app's logs before and after implementing the fix for the N+1 problem are shown below.
Before

After

Summary

Fix n+1 query for post comments
Update database seeds script
Use db seed for all tests
Write test cases for each of the following views

posts index
post show
users index
user show

Remove outdated tests that check for placeholder text

All tests are passing

Hi @codepantha,
All the tests in the last commit are passing on my machine.

Please make sure that you run bin/rails db:environment:set RAILS_ENV=development and then 'bin/rails db:reset' to populate your database with the records in db/seeds.rb
You can open the /users route to double-check that the data that the tests depend on was successfully added.


Unix sockets as upstream

I have this in my Caddyfile and it works perfectly:
@grpc {
		protocol grpc
		path /endpoint/*
	}
	reverse_proxy @grpc unix//dev/shm/Xray-VLESS-gRPC.socket {
		transport http {
			versions h2c 2
		}
	}

But this is not working with caddy-l4:
{
                                            "match": [
                                                {
                                                    "http": [
                                                        {
                                                            "header": {
                                                                "Content-Type": [
                                                                    "application/grpc*"
                                                                ]
                                                            }
                                                        }
                                                    ]
                                                }
                                            ],
                                            "handle": [
                                                {
                                                    "handler": "proxy",
                                                    "upstreams": [
                                                        {
                                                            "dial": [
                                                                "unix//dev/shm/Xray-VLESS-gRPC.socket"
                                                            ]
                                                        }
                                                    ]
                                                }
                                            ]
                                        }

Caddy logs:
caddy  | {"level":"debug","ts":1668294136.750317,"logger":"layer4.matchers.tls","msg":"matched","remote":"x.x.x.x:46578","server_name":"sub1.example.com"}
caddy  | {"level":"debug","ts":1668294136.7626286,"logger":"events","msg":"event","name":"tls_get_certificate","id":"a471dd5e-77ef-4504-b366-dbf0a3488714","origin":"tls","data":{"client_hello":{"CipherSuites":[4865,4867,4866,49195,49199,52393,52392,49196,49200,49162,49161,49171,49172,156,157,47,53],"ServerName":"sub1.example.com","SupportedCurves":[29,23,24,25,256,257],"SupportedPoints":"AA==","SignatureSchemes":[1027,1283,1539,2052,2053,2054,1025,1281,1537,515,513],"SupportedProtos":["h2","http/1.1"],"SupportedVersions":[772,771],"Conn":{"Conn":{},"Context":{"Context":{"Context":0}}}}}}
caddy  | {"level":"debug","ts":1668294136.7645912,"logger":"tls.handshake","msg":"choosing certificate","identifier":"sub1.example.com","num_choices":1}
caddy  | {"level":"debug","ts":1668294136.7650096,"logger":"tls.handshake","msg":"default certificate selection results","identifier":"sub1.example.com","subjects":["sub1.example.com"],"managed":true,"issuer_key":"acme-v02.api.letsencrypt.org-directory","hash":"700af100c686af79ab90cf9c506c56b9af694f6e5abdda75ec519b24db5e0148"}
caddy  | {"level":"debug","ts":1668294136.7656264,"logger":"tls.handshake","msg":"matched certificate in cache","remote_ip":"x.x.x.x","remote_port":"46578","subjects":["sub1.example.com"],"managed":true,"expiration":1676052278,"hash":"700af100c686af79ab90cf9c506c56b9af694f6e5abdda75ec519b24db5e0148"}
caddy  | {"level":"debug","ts":1668294137.131996,"logger":"layer4.handlers.tls","msg":"terminated TLS","remote":"x.x.x.x:46578","server_name":"sub1.example.com"}
caddy  | {"level":"error","ts":1668294141.4762106,"logger":"layer4.handlers.subroute","msg":"matching connection","error":"EOF"}
caddy  | {"level":"error","ts":1668294141.4772484,"logger":"layer4.handlers.subroute","msg":"matching connection","error":"EOF"}
caddy  | {"level":"error","ts":1668294141.4773629,"logger":"layer4.handlers.subroute","msg":"matching connection","error":"EOF"}
caddy  | {"level":"debug","ts":1668294141.4775367,"logger":"layer4","msg":"connection stats","remote":"x.x.x.x:46578","read":682,"written":4857,"duration":4.73303315}

Are Unix sockets not supported or am I missing something here?

Seems like the issue was with the matcher! I moved to SNI matching and the issue went away!


⚠ Bofrost.fr has degraded performance

In dc4ee11, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1418 ms

Resolved: Bofrost.fr performance has improved in d427339 after 10 minutes.


Fix Dialog Path

The Path to Step 16 has a wrong prefix. This causes a 404.

Thanks for the fix, Dominik!


Release plugin for 1.0.0-M6

I'm running into issues in https://github.com/coursier/coursier/pull/560, which adds support for it. Latest one: it keeps compiling "compiler bridges" during the scripted tests, each of them taking ~45s, which slows the CI considerably... (and makes Travis time out...)

1.0.0-RC4 with support for sbt 1.0.0-M6 is out (since a few days).


Self closing tags

As far as i can see we can't use self closing tags () in HTML5. I tried using XHTML instead but that have problems with

Custom Elements can not be self-closing per spec. See w3c/webcomponents#624

Self-closing tags are not allowed for Custom Elements, because they are not allowed in HTML5 in general, outside foreign elements. Regular HTML elements allow the self-closing solidus only on void elements, on which they are optional and have no effect.
Lit-html uses the native template parser in browsers, so it will allow whatever syntax is allowed by the HTML5 specification (assuming the browsers implement correctly). The main advantage of this strategy is that we do not have to implement a parser, because we use the available builtin parsers. It is unlikely that we will want to deviate from this strategy to add support for features like self-closing tags that are not part of the HTML5 spec.

There are ways to do regex replacements on the template strings to support self-closing tags, but I don't think it's really worth the code or extra scans.
I'll leave this issue open to see if there's a lot of demand though.

Maybe we can create a config system for this kinda features ? I don't like bloated libraries too. But I think lit-html should be a solution for runtime problems. At future maybe there can be a typescript plugin(transformer) does this kinda compile time problems too which honestly i would prefer that and working about it. But since that time we need at least a temporary solution for this kinda problems i think. I'm developing a custom element library just like lit-element so i created symlink from lit-html's src folder to my lib folder now tsc compiles lit-html inside my project and i can implement some changes that i need so this is not really a problem for me currently. I think more people should prefer lit instead of solutions like react or vue but people who are used to jsx nags about this kinda small syntax problems constantly whenever i show to them. I tried not using a full regex search and some small string processing but im pretty sure somebody can write a better implementation that is good enough people would prefer losing that speed for this feature.

IMO I don't like the idea of supporting self-closing tags because that's not really a thing in HTML5, mostly it's just either void elements or normal elements. Adding more processing just to solve something that isn't standard and that any decent IDE/Text Editor will autocomplete anyways seems like a waste to me.

Having worked with Polymer since v1 and with React, I can say personally that the main thing that I found as a nice to have from the React/JSX self closing tag is the neatness of the code. I often found the autocomplete of an editor more than enough to handle the "burden" of a closing tag.
With that said, I don't see why someone couldn't write a basic compile plug-in to handle a self closing tag to what the DOM would expect. This would allow a user to opt-in knowing the pros and cons of it without affecting the runtime.

@stramel The downside to that approach is that either the element creator has to precompile their element before publishing, or expect the end user of the elements to add the plugin even if they don't want to use self closing tags themselves.

When needing to make a choice, we're going to optimize for familiarity to HTML over JSX. HTML doesn't support self-closing tags, so the impetus here is much less.
I'll point out that this can be pretty easily done with a custom TemplateResult class - so one should be able make their own fairly trivial subclass of TemplateResult that overrides getHTML() and runs the regex/replace that expands self-closing tags.

Good discussion. The key here, to me, is does a change comply with or run
counter to, in this case, the HTML5 specification? I understand a lot of
developers are used to and like self-closing tags, it seems like a change
that is either unnecessary or adds complexity beyond the scope of the
intended library. Maybe this would be a good tooling project, but I'm
hesitant to advocate for this type of change in lit-html itself.

Just saw this, htm by @developit https://github.com/developit/htm
Interesting that he is supporting self-closing tags in his library.

EmpatiElement/Template:EmpatiTemplate.getHTML() if anybody needs that's how im using it.

Here a way to implement this on top of lit-html, if anybody is looking for:
function htmlWithSelfClosingTags(strings, ...values) {
  let tagName
  strings = strings.map(part => {
    const hasEnd = part.indexOf('/>') >= 0
    if (tagName && hasEnd)
      part = part.replace(/^([^<]*?)\/>/, '$1></' + tagName + '>')
    if (!tagName || hasEnd)
      tagName = part.match(/<([^ >]+)[^>]*?$/)?.[1]
    return part
  })
  return html(strings, ...values)
}

I just export this as html and use it instead of lit-html's function.

Ok. So I just started migrating to Lit 2. Didn't find an implementation of self-closing tags, so I ended up doing it. It's mostly a copy of the existing parser.
https://github.com/aigan/lit-self-closing

Angular 15.1 just added self-closing tags

@DemiusAcademius Angular has a custom HTML parser and compiles templates at build time. We do neither of those things and hand off the HTML string to the browser, which doesn't support self-closing tags.

Do you have any plans for compile templates at build time in the future?
Thanks for answer

i can not agree with the "specification" reasoning
the whole purpose for Lit to exist, is to be a more convenient abstraction on top of that specification.
otherwise why would one use it?
everyone understand self-closing tags and use them in other frameworks.
i believe if Lit wants to gain at least some popularity, that (and not only that) feature should definitely be implemented.
and in case of "specification"... maybe let's get rid of everything that is not in there?
for consistency.
what about <button @click="${() => this.active = !this.active}">Toggle active</button> and alike... ?


016 delete location history

Ready for Review

@xxuejie when you get a moment, could you please review?

@xxuejie & @kristinpeterson Would you please undo the merge? It got merged directly to the public repo instead of the forked one.

@attsdk In general this code looks okay to merge(unless you have detected some bugs locally), so I don't think we need to undo that. Please be more careful with this next time :)


Every time I tapped on the reset button, the dimming view gets darken!!

Regeneration process:
Just modify the cropView and reset(repeat this process without tapping cancel button)
My observation:
When you resetting the crop process, the dimming layer is not removing. That's why every time a brand new dimming layer is adding on the previous dimming layer.
I'm guessing this issue is occurring for the method inside "CropDimmingView" & "CropMaskVisualEffectView":
func setMask(cropRatio: CGFloat) {
        let layer = createOverLayer(opacity: 0.5, cropRatio: cropRatio)
        self.layer.addSublayer(layer)
        innerLayer = layer
}

See the following method too inside the "CropMaskViewManager":
func setup(in view: UIView, cropRatio: CGFloat = 1.0) {
        maskViews.forEach { maskView in
            maskView.initialize(cropRatio: cropRatio)
            maskView.isUserInteractionEnabled = false
            view.addSubview(maskView)
        }

        showVisualEffectBackground()
}

func removeMaskViews() {
        maskViews.forEach { $0.removeFromSuperview() }
}

@asadullahpranto Thanks for reporting this bug! I will fix it in the next release.


content plugins reject options.routeBasePath = ''

Have you read the Contributing Guidelines on issues?

[X] I have read the Contributing Guidelines on issues.

Description
When I use default preset options
module.exports = {
  presets: [
    [
      '@docusaurus/preset-classic',
      {
        pages: {
          path: 'src/pages',
          routeBasePath: '',
          include: ['**/*.{js,jsx,ts,tsx,md,mdx}'],
          exclude: [
            '**/_*.{js,jsx,ts,tsx,md,mdx}',
            '**/_*/**',
            '**/*.test.{js,jsx,ts,tsx}',
            '**/__tests__/**',
          ],
          mdxPageComponent: '@theme/MDXPage',
          remarkPlugins: [require('remark-math')],
          rehypePlugins: [],
          beforeDefaultRemarkPlugins: [],
          beforeDefaultRehypePlugins: [],
        },
      },
    ],
  ],
};

It pointed out that ValidationError: "routeBasePath" is not allowed to be empty

Self-service

[X] I'd be willing to address this documentation request myself.

Hey
Somehow it's done on purpose because previously it lead to issues, although now with https://github.com/facebook/docusaurus/pull/3427 it shouldn't be an issue anymore.
We could either:

forbid '' but print a better error message suggesting to use "/" instead
allow '' to pass validation, as it should work fine now

Considering we have related validation for baseUrl (https://github.com/facebook/docusaurus/pull/8066) I guess we should do the same here, and apply this to all 3 content plugins: docs, pages, blog.
To make things more predictable I'd prefer if we apply the same logic as baseUrl and always normalize this URL segment to have leading/trailing slashes.
Cf https://github.com/facebook/docusaurus/pull/8066 for implementation
  baseUrl: Joi.string()
    .required()
    .custom((value: string) => addLeadingSlash(addTrailingSlash(value))),

Any opinion @Josh-Cena ?

Good issue for an external contributor looking to contribute.
Send directly the PR only if you can handle it. Do not claim it, we won't assign it to you unless there's a PR first.

@slorber
could you check my PR? i reflect your opinion

Hey
Somehow it's done on purpose because previously it lead to issues, although now with #3427 it shouldn't be an issue anymore.
We could either:

forbid '' but print a better error message suggesting to use "/" instead
allow '' to pass validation, as it should work fine now

Considering we have related validation for baseUrl (#8066) I guess we should do the same here, and apply this to all 3 content plugins: docs, pages, blog.
To make things more predictable I'd prefer if we apply the same logic as baseUrl and always normalize this URL segment to have leading/trailing slashes.
Cf #8066 for implementation
  baseUrl: Joi.string()
    .required()
    .custom((value: string) => addLeadingSlash(addTrailingSlash(value))),

Frankly I don't get the semantic difference between "/" and "". Is the latter only useful to hack around the "multiple root plugins" issue? If that's the case I think we should continue to reject it until the actual issue is properly remedied. We already normalize slashes, but I don't think we should allow empty strings unless it has clear semantics.

Frankly I don't get the semantic difference between "/" and "". Is the latter only useful to hack around the "multiple root plugins" issue? If that's the case I think we should continue to reject it until the actual issue is properly remedied. We already normalize slashes, but I don't think we should allow empty strings unless it has clear semantics.

I agree with your opinion, but here, even when routeBasePath is not defined, the root (/) path is entered by default. I'm not quite sure what the difference is with "" in this case.
I think it would be better to put it as an essential element rather than to remove the ambiguous case.

Frankly I don't get the semantic difference between '/' and ''. Is the latter only useful to hack around the "multiple root plugins" issue?

I don't even remember what this issue is exactly but I don't think it hacks around anything if we normalize '' to '/' anyway.

If that's the case I think we should continue to reject it until the actual issue is properly remedied.

'/' works so if we normalize '' to '/' there won't be issues, it would work as if user provided "/" 🤷♂

We already normalize slashes, but I don't think we should allow empty strings unless it has clear semantics.

To me using "docs" (default plugin routeBasePath value) instead of "/docs/" is not particularly more semantically wrong than using '' instead of '/'.

routeBasePath is somehow the "plugin baseUrl". It made sense to me to be consistent between baseUrl and routeBasePath
Now I didn't notice but we actually don't accept baseUrl: '' . I thought we did normalize it to "/" already, but instead it prints an error message:

"baseUrl" is not allowed to be empty

I suggest either:

allow '' for both baseUrl and routeBasePath, eventually emit a warning saying the value should rather be '/'
reject '' for both baseUrl and routeBasePath with a clearer error message explaining to use '/' instead (+ fix docs using '')

The first option looks better to me, as users will intuitively try to use ''.
Do we want to throw on start while we could handle the bad value more gracefully?

If the progress is stopped, how about we discuss it again?

allow '' for both baseUrl and routeBasePath, eventually emit a warning saying the value should rather be '/'

how about think that @Josh-Cena ?

routeBasePath is somehow the "plugin baseUrl". It made sense to me to be consistent between baseUrl and routeBasePath

Yeah, I'll agree with that stance. Well, I'll prefer to allow it, but normalize—I know it was previously used as a "multiple root plugins" hack, which is why I don't like ""; but if we always normalize, I do prefer the non-erroring side.

I know it was previously used as a "multiple root plugins" hack, which is why I don't like ""

is it happen in this repository? if some of case is exist. i want to know more. because i didn't hear vulnerabilities.
i readed docusaurus routing

routeBasePath is "plugin baseUrl".

i think it can be used "" because it works in root("/")


Update SCB acronym to read as "Secure Configuration Baseline" throughout repo

🗣 Description

We have been referencing SCB as both "Security Configuration Baseline" and "Secure Configuration Baseline". This PR and accompanying issue addresses the inconsistency and updates all references to "Secure Configuration Baseline" to match BOD language.
💭 Motivation and context

Change is required to have the acronym of SCB to be consistently referred as "Secure Configuration Baseline" matching the BOD language. Using a the replace functionality this has been done throughout the repo.
Closes #1432
🧪 Testing
Check throughout the repo that "Security Configuration Baseline" instances have been replaced with "Secure Configuration Baseline".
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] PR targets the correct parent branch (e.g., main or release-name) for merge.
[x] Changes are limited to a single goal - eschew scope creep!
[x] Changes are sized such that they do not touch excessive number of files.
[x] Related issues these changes resolve are linked preferably via closing keywords.
[x] All relevant type-of-change labels added.
[x] All relevant project fields are set.
[x] All relevant repo and/or project documentation updated to reflect these changes.
[x] All relevant functional tests passed.
[x] All automated checks (e.g., linting, static analysis, unit/smoke tests) passed.

✅ Pre-merge checklist

[ ] PR passed smoke test check.

[ ] Feature branch has been rebased against changes from parent branch, as needed
Use Rebase branch button below or use this reference to rebase from the command line.

[ ] Resolved all merge conflicts on branch

[ ] Notified merge coordinator that PR is ready for merge via comment mention

✅ Post-merge checklist

[ ] Feature branch deleted after merge to clean up repository.
[ ] Verified that all checks pass on parent branch (e.g., main or release-name) after merge.

@nanda-katikaneni good to merge


Create recruitment poster.

https://drive.google.com/drive/u/0/#folders/0B_7IPKiQjuIZUUJlZHN6NWRGeDA
The crank arm fundraiser poster is a great place to start. (mainly, I like the logo).

This is a modified version of the crankarm flyer
On Tue, May 12, 2015 at 9:10 PM, Ahmed Samara<EMAIL_ADDRESS>wrote:

https://drive.google.com/drive/u/0/#folders/0B_7IPKiQjuIZUUJlZHN6NWRGeDA
The crank arm fundraiser poster is a great place to start. (mainly, I like
the logo).
—
Reply to this email directly or view it on GitHub
https://github.com/IEEERobotics/bot2014/issues/357.

--
Thank you, and have a good day!
Sean Ketring
Electrical Engineering Undergraduate

Posted across campus


Using panic! doesn't show error message

If panic!(message) used in the contract, the resulting error doesn't contain the message:
"status":{"Failure":{"ActionError":{"index":0,"kind":{"FunctionCallError":{"HostError":{"GuestPanic":{"panic_msg":"panicked at src/lib.rs:202:23"}}}}

Expectation:
Either panic! behaves similar to env::panic or shows warning / error that should not be used.

It seems like it does show the message: panicked at src/lib.rs:202:23
Do you have a contract where it doesn't?

@evgenykuzyakov it doesn't show the message you logged. If you do panic!("PANIC") it doesn't show PANIC

I verified it does record the message. The reason you haven't seen the message is the panic!() was called without an argument.
See PR: https://github.com/near/near-sdk-rs/pull/230
Tested using near-vm-runner-standalone
near-vm-runner-standalone --wasm-file res/test_contract.wasm  --method-name=test_panic_macro
{"outcome":{"balance":"10000000000000000000000000","storage_usage":100,"return_data":"None","burnt_gas":115595266842,"used_gas":115595266842,"logs":[]},"err":{"FunctionCallError":{"HostError":{"GuestPanic":{"panic_msg":"panicked at 'PANIC!', src/lib.rs:31:9"}}}},"receipts":[],"state":{}}

Should we close this then @ilblackdragon ?


Changing GUI to prefab instead of changing Menu for Wrath

Blocked by:

Queue data management rework

Done, pushed to 0.2.0 branch


Unable to deploy with cloud_provider: azure

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Environment:

Cloud provider or hardware configuration:
Azure

OS (printf "$(uname -srm)\n$(cat /etc/os-release)\n"):

Linux 4.13.0-1009-azure x86_64
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Version of Ansible (ansible --version):

ansible <IP_ADDRESS>

Kubespray version (commit) (git rev-parse --short HEAD):
b31d905
Network plugin used:
calico originally (no azure configured), canal attempted, cloud attempted
Copy of your inventory file:

[all]
node-k8s-0     ansible_ssh_host=<IP_ADDRESS>
node-k8s-1     ansible_ssh_host=<IP_ADDRESS>
node-k8s-2     ansible_ssh_host=<IP_ADDRESS>
[kube-master]
node-k8s-0
node-k8s-1
[kube-node]
node-k8s-0
node-k8s-1
node-k8s-2
[etcd]
node-k8s-0
node-k8s-1
node-k8s-2
[k8s-cluster:children]
kube-node
kube-master
[vault]
node-k8s-0
node-k8s-1
node-k8s-2

Command used to invoke ansible:

ansible-playbook -i k8s-inventory/inventory.cfg kubespray/cluster.yml -b -v

Output of ansible run:

The deployment completes ok except for timeouts waiting on the apiserver to start at the end.
Anything else do we need to know:

There are a couple issues here. First I'm created PR  #2283 to address the issue with the config. When azure is set, the network_plugin check always fails because it is undefined.
The bigger issue is that after deploying, the kubelet does not run and the nodes are offline.
looking at the systemd logs, I see this:

CGroup: /system.slice/kubelet.service
└─101875 /usr/local/bin/kubelet --logtostderr=true --v=2 --address=<IP_ADDRESS> --node-ip=<IP_ADDRESS> --hostname-override=node-k8s-0 --allow-privileged=true --pod-manifest-path=/etc/kubernetes/manifests --cadvisor-port=0 --pod-infra-container-image=gcr.io/google_containers/pause-amd64:3.0 --node-status-update-frequency=10s --docker-disable-shared-pid=True --client-ca-file=/etc/kubernetes/ssl/ca.pem --tls-cert-file=/etc/kubernetes/ssl/node-node-k8s-0.pem --tls-private-key-file=/etc/kubernetes/ssl/node-node-k8s-0-key.pem --anonymous-auth=false --read-only-port=0 --cgroup-driver=cgroupfs --cgroups-per-qos=True --fail-swap-on=True --enforce-node-allocatable= --cluster-dns=<IP_ADDRESS> --cluster-domain=cluster.local --resolv-conf=/etc/resolv.conf --kubeconfig=/etc/kubernetes/node-kubeconfig.yaml --kube-reserved cpu=200m,memory=512M --node-labels=node-role.kubernetes.io/master=true,node-role.kubernetes.io/node=true --feature-gates=Initializers=False,PersistentLocalVolumes=False --hairpin-mode=promiscuous-bridge --network-plugin=kubenet --volume-plugin-dir=/var/lib/kubelet/volume-plugins --cloud-provider=azure --cloud-config=/etc/kubernetes/cloud_config
Feb 09 03:33:57 node-k8s-0 kubelet[101875]: E0209 03:33:57.646611  101875 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/kubelet.go:465: Failed to list *v1.Service: Get https://<IP_ADDRESS>:6443/api/v1/services?limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:6443: getsockopt: connection refused
Feb 09 03:33:57 node-k8s-0 kubelet[101875]: E0209 03:33:57.877383  101875 reflector.go:205] k8s.io/kubernetes/pkg/kubelet/config/apiserver.go:47: Failed to list *v1.Pod: Get https://<IP_ADDRESS>:6443/api/v1/pods?fieldSelector=spec.nodeName%3Dnode-k8s-0&limit=500&resourceVersion=0: dial tcp <IP_ADDRESS>:6443: getsockopt: connection refused

It fails because it /kubespray/kubernetes/preinstall/tasks/verify-settings.yml has a line that checks that the network_plugin is calico is cloud_provider is azure. The variable name should be kube_network_plugin. Change

- name: Stop if incompatible network plugin and cloudprovider
  assert:
    that: network_plugin != 'calico'
    msg: "Azure and Calico are not compatible. See https://github.com/projectcalico/calicoctl/issues/949 for details."
  when: cloud_provider is defined and cloud_provider == 'azure'
  ignore_errors: "{{ ignore_assert_errors }}"

to
- name: Stop if incompatible network plugin and cloudprovider
  assert:
    that: kube_network_plugin != 'calico'
    msg: "Azure and Calico are not compatible. See https://github.com/projectcalico/calicoctl/issues/949 for details."
  when: cloud_provider is defined and cloud_provider == 'azure'
  ignore_errors: "{{ ignore_assert_errors }}"

This is a bug I believe.

It is a bit more complicated than that. There are 2 issues.

The verify-settings check have is - I've submitted PR #2283 to resolve this
a.  The variable name appears to be wrong - should be kube_network_plugin
b.  There is no test to ensure the network plugin is actually defined.
Azure deployment does not work (even with corrected verify-settings). This appears to be much more involved than a broken config check.

The azure deployment can indeed work. I got it running and intergrating last week but it is not straight-forward and requires digging around in the ansible and jinja code. Officially, I believe kubespray does not work with azure cloud provider.

I believe Kubespray announced support for Azure a few releases ago. I'm not attempting to use with kubeadm.
How did you get it working? I'm not sure where to get the logs you're asking for. kube-apiserver is not running, that's where kubespray fails - 'Master | wait for the apiserver to be running'
I think this could be related:
https://github.com/kubernetes/kubernetes/issues/49402

Do you have any logs in /var/log/containers? Even if the containers don't start, they should be dumping something in there.

I have developed the necessary adaptions for a customer who is using Azure Germany in conjunction with calico. Legally, the code is his and I am currently aquiring the permission to push the code. I am optimistic to have that ready by the end of the week.


Error: Error setting TTL index on collection

Hi there,
When running 'grunt' after generating my Mean.JS project with Yoeman and visiting my localhost I get the following error:
 NODE_ENV is not defined! Using default development environment

MEAN.JS application started on port 3000

/Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:245
        throw message;
              ^
Error: Error setting TTL index on collection : sessions
    at /Users/Stayko/work/meanjs/node_modules/connect-mongo/lib/connect-mongo.js:161:23
    at /Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1288:11
    at Server.Base._callHandler (/Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:445:41)
    at /Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:478:18
    at MongoReply.parseBody (/Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
    at null.<anonymous> (/Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:436:20)
    at emit (events.js:95:17)
    at null.<anonymous> (/Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:201:13)
    at emit (events.js:98:17)
    at Socket.<anonymous> (/Users/Stayko/work/meanjs/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection.js:439:22)
[nodemon] app crashed - waiting for file changes before starting...

I have my mongo db listening for connections in the other tab. I started it using the command 'mongod'.
Thanks

This issue is still open.
server.js file
root@linux~/demo# vim server.js

var init = require('./config/init')(),
        config = require('./config/config'),
        mongoose = require('mongoose'),
        chalk = require('chalk');

/**
 * Main application entry file.
 * Please note that the order of loading is important.
 */

// Bootstrap db connection
var db = mongoose.connect(config.db, function(err) {
        if (err) {
                console.error(chalk.red('Could not connect to MongoDB!'));
                console.log(chalk.red(err));
        } else {
                var app = require('./config/express')(db);
                require('./config/passport')();
                app.listen(config.port);
                exports = module.exports = app;
                console.log('App running on port', config.port);
        }
});

// Init the express application
//var app = require('./config/express')(db);

// Bootstrap passport config
//require('./config/passport')();

// Start the app by listening on <port>
//app.listen(config.port);

// Expose app

// Logging initialization
//console.log('MEAN.JS application started on port ' + config.port);

grunt still throws error
App running on port 4000
/root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:246
        throw message;
              ^
Error: Error setting TTL index on collection : sessions
    at /root/demo/node_modules/connect-mongo/lib/connect-mongo.js:169:23
    at /root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1354:11
    at Server.Base._callHandler (/root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:453:41)
    at /root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:488:18
    at MongoReply.parseBody (/root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
    at null.<anonymous> (/root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:446:20)
    at emit (events.js:107:17)
    at null.<anonymous> (/root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:207:13)
    at emit (events.js:110:17)
    at Socket.<anonymous> (/root/demo/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection.js:440:22)
    at Socket.emit (events.js:107:17)
    at readableAddChunk (_stream_readable.js:163:16)
    at Socket.Readable.push (_stream_readable.js:126:10)
    at TCP.onread (net.js:538:20)
[nodemon] app crashed - waiting for file changes before starting...

@vko-online looks like you're using an old version of MEAN.JS