Dual front end for egglog

Currently, egglog does repetitive work by having two front-end compilers. For example, if one adds a rule with the add_rule function, it will directly call the query compiler at typecheck.rs::typecheck_query. However, if the rule is added via run_program, then it will go through the desugaring process, which transforms the rule into a normal form, then resugars it, and again sends it to the query compiler.
There are several options here:

The fact that we need to transform to a normal form and recover from that seems to suggest we can just get rid of this normalization process.
We can also make sure that everything goes through the normalization process and simplify the typecheck module by assuming the input is normalized.

I'm strongly in favor of option 2 over option 1.
The normalization pass simplifies the interface to the back end. In addition, it enables easier analysis and encodings (such as proofs, which are still in a branch)

Ideally, proofs should just be some user-defined macros... but I see why that would be very difficult.
Another thing is that typecheck itself also produces a normalized IR: for example, for query
(rule ((= (f x) (f y))
       (= (f y) (f z))
       (= (+ x y) z)
       (= w (+ x z)))
      ())

The NormRule form is
(rule ((= v0___ (f x))
           (= v2___ (f y))
           (= v1___ v2___)
           (= v3___ (f z))
           (= v4___ (+ x y))
           (= w (+ x z))
           (= v2___ v0___)
           (= v3___ v1___)
           (= v4___ z))
          ()

While Query produced by typecheck is
(f x v0___)
(f z v0___)
(f y v0___)
    where
(+ x y z)
(+ x z w)

which is arguably clearer.
Also, it is a bit unusual to have the distinction between AssignVar (let-bound var definition) and ConstrainEq (equality check) in a relational query compiler front end.
I'm planning to work on this issue and front-end related issues like #133 next week in parallel to eggcc, and I'm trying to figure out the best front-end IR that works for egglog's use case (a design doc maybe). @oflatt any recommendations on where I can get started to understand your proof code to see what normalized form we need?

I agree it is easier to view normalized form from typecheck, but reading the IR is a separate problem in my mind and the reason I wrote the --resugar flag.
The reason AssignVar exists is that there are situations where one variable is bound and the other isn't, and there are also situations where both are already bound (which is when we use ConstrinEq and this distinguishes the two.
Here is the proofs file on my proofs branch:
https://github.com/oflatt/egg-smol/blob/oflatt-term-proofs/src/proofs.rs
Lmk if you have questions. You can get proof outputs with the --proofs flag and --resugar flag and read them

@oflatt Thanks for the pointer! I'll take a look at it.
I think I still don't understand why we need AssignVar. If you look at the output of typecheck, I guess you can say v0___ is bounded in the first atom ((f x v0___)) and checked in the rest, but it does not really matter here- they are just conjunctive queries. We can discuss more in person.


Background color looks different in powershell and standalone command prompt

Windows Terminal version
1.11.34710
Windows build number
10.0.19044.1415
Other Software
.net core 6.0
Steps to reproduce

Create a .net core 6 console application
Use the following snippet

static void Main(string[] args)
        {

            Console.BackgroundColor = ConsoleColor.Blue;
            Console.Clear();
            Console.WriteLine("Hello World!");
}

The colors look different

Expected Behavior
I expect the colors to match
Actual Behavior
The colors look different

In my opinion it depends on the settings of the 16 base colors of the console.

0..15 | Foreach-Object { Write-Host $([consoleColor] $_) -ForegroundColor $_ }

@237dmitry Thanks, I think you are right it somehow chooses the bright color in the colorscheme. It must map the color

Yep, this is due to the Terminal and Conhost using different color schemes by default. When you're using ConsoleColor.Blue, you're merely telling the console/terminal "please draw this text in whatever color you think blue is"


Disable introspection on prod sizing

Feature or Bugfix

Detail

Disable introspection on prod_sizing

Relates

Security
Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

Does this PR introduce or modify any input fields or queries - this includes
fetching data from storage outside the application (e.g. a database, an S3 bucket)?

Is the input sanitized?
What precautions are you taking before deserializing the data you consume?
Is injection prevented by parametrizing queries?
Have you ensured no eval or similar functions are used?

Does this PR introduce any functionality or component that requires authorization?

How have you ensured it respects the existing AuthN/AuthZ mechanisms?
Are you logging failed auth attempts?

Are you using or adding any cryptographic features?

Do you use a standard proven implementations?
Are the used keys controlled by the customer? Where are they stored?

Are you introducing any new policies/roles/users?

Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

testing:

[ ] CICD Pipeline Successful
[ ] Updates to Env Vars in API Handler Lambda
[ ] Introspection Disabled (query returns error if attempt introspection with ALLOW_INTROSPECTION False - i.e. prod_sizing True)
[ ] Field Suggestions Disabled (query error message does not includ 'Did you mean ....?' if provided mistyped return field with ALLOW_INTROSPECTION False - prod_sizing True)


Cached Tokens are not Updated Immediately after Deletion of OAuth Client Applications

Describe the issue

When an OAuth client application, which previously issued an access token for a specific set of scopes, is deleted and then, a new application bearing the same client ID is created, we get the same revoked access token when a new token is requested for the same set of scopes.

https://github.com/wso2/product-is/assets/57411348/de2d66e9-ca0b-40d3-a774-f30b58cb0a55

After some time (most probably after the cached is cleared periodically) or after we restart the IS, we get a new authorized token.

How to reproduce

Download the IS pack and start it up.
Create an OAuth client application with a specific client ID [1].
Create an access token for the above client with client_credentials as the grant type [2] and specify a set of scopes as well (ex: openid).
Access some API end point with the retrieved token (ex: Applications Management API [3]). You should be able to successfully access it.
Delete the created client application [4].
Now create another OAuth client application with the same client ID as in step 2.
Now request an access token for the new client with the same attributes (grant type, scopes and etc.) as mentioned in Step 3. You can see that it returns the same access token that was received in Step 3.
Now try to access some API end point (as in Step 4) and you should get an unauthorized response with 401 code.

Expected behavior

In Step 7 you should get a new access token.
In Step 8, you should be able to access the API successfully.

Additional Note

If we revoke [5] the tokens of the application before deletion, then this issues does not persist.

https://github.com/wso2/product-is/assets/57411348/e714c227-65e8-4ea5-89d8-9a2e089642b2
Environment information

Product Version: IS 7.0.0-m1
OS: macos Ventura 13.5.1
Database: Defaut
Userstore: Default

Optional Fields
Related issues:
(None)
References
[1] - https://is.docs.wso2.com/en/latest/guides/access-delegation/oauth-dynamic-client-registration/#register-an-oauth-application
[2] - https://is.docs.wso2.com/en/latest/guides/access-delegation/client-credentials-playground/#try-client-credentials-grant
[3] - https://is.docs.wso2.com/en/5.10.0/develop/application-rest-api/#/Applications/getAllApplications
[4] - https://is.docs.wso2.com/en/latest/guides/access-delegation/oauth-dynamic-client-registration/#delete-an-oauth-application
[5] - https://is.docs.wso2.com/en/latest/guides/access-delegation/oauth-token-revocation/

https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/2294/files


The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior

mysql:
interactive_timeout	7200
wait_timeout	7200
druid 1.2.12:
initial-size: 5
min-idle: 5
max-active: 50
max-wait: 60000
time-between-eviction-runs-millis: 60000
min-evictable-idle-time-millis: 300000
test-on-borrow: false
test-on-return: false
validation-query: SELECT 1
test-while-idle: true

and what's your question?


Translate August 14 sit-rep into Greek

Greetings @nextstrain/greek,
It’s really great to work with you again after a long situation report hiatus.
Our August update on genomic epidemiology of COVID-19 is ready to be translated to Greek. This is just a one-off situation report, and we are not planning to resume weekly situation reports at this time. Translation of this report is less time sensitive than previous ones, so feel free to take a bit longer on the translation. I won’t be available for much of the weekend, so may not be able to publish it until Sunday anyway.
Branch to translate on: sit-rep_el
File to translate: https://github.com/nextstrain/translations/blob/sit-rep_el/narratives/translations_ncov_sit-rep_el_2020-08-14.md. You can translate directly in this file, but please remember to push often.
Link to preview: https://nextstrain.org/community/narratives/nextstrain/translations@sit-rep_el/ncov/sit-rep/el/2020-08-14
Please translate the Twitter post below too :)
Thank you so much! Sending warm, safe thoughts to you and your loved ones and hoping for wisdom in our respective leaders.
Take care,
Cassia
Twitter post
Check out our August report on COVID-19 genomic epidemiology in Greek. In it, we explore the global spread of the virus broadly and provide specific updates for each world region.
Thank you to @, @, and @ for their rapid translation!
Logistics
Please update the translations board as you work on the translation: https://github.com/orgs/nextstrain/projects/7
Please assign yourself to the translation if you’re working on it this week.
When a translation is ready for publication -- at minimum meaning two people have worked on it and both agree that it’s ready -- please create a pull request to merge to master and tag me and the issue in it!
Discussion board for your team is here: https://github.com/orgs/nextstrain/teams/greek
Standard rules for translation:
Note that the file to translate is in Markdown. In general, it is important not to change any formatting or links. Feel free to update internal links to refer to the Greek version of the narrative(s). I can also update those when I publish it though.
Please keep the number of and text for Table of Contents links the same in your translation as in the English narrative.
Please add your name under translators: with new line, tab, and dash, formatted just like authors are. Please also add a link to your professional page (can use Twitter) under translatorLinks:.
Note: You may know of other great resources available in Greek; please don’t add them to the situation report. We need to keep content the same across all translations, so we can be confident in the accuracy.
At minimum, I require two sets of eyes on every translation; one of those people should have a background in phylogenetics. Although if you have more, that’s fine too.

@codergr here is the hackmd link: https://hackmd.io/Gu0K-9yLSJu3Zv0PsWKeZQ?edit
I am through until Oceania, where Europe starts. Again following the line-to-line original text maintenance scheme :)
Will continue tomorrow morning!

@codergr here is the hackmd link: https://hackmd.io/Gu0K-9yLSJu3Zv0PsWKeZQ?edit
I am through until Oceania, where Europe starts. Again following the line-to-line original text maintenance scheme :)
Will continue tomorrow morning!

Nice ! reviewed  and finished rest. Ready for hackmd review @akifoss

@codergr Thanks for translating!
@cassiawag File ready for publication!
Tweet translation:
Διαβάστε την αναφορά του Αυγούστου σχετικά με τη γονιδιωματική επιδημιολογία της νόσου COVID-19 στα ελληνικά. Εξερευνούμε την παγκόσμια διασπορά του ιού και παρέχουμε ενημερώσεις σχετικά με κάθε περιοχή του κόσμου.
Ευχαριστούμε @akifoss και @codergr για τη γρήγορη μετάφραση!

wowowowowowow, that was fast. I'll get this online.

Published and tweeted: https://nextstrain.org/narratives/ncov/sit-rep/el/2020-08-14
Thanks ya'll. Have a good weekend!


Update secp256k1 to 0.3.2

The new code was dropped directly in src/secp256k1 without changes. We can consider changing to a Git submodule, though that will require changes to the build instructions because we are not using submodules anywhere else.

In your PR description, can you link to where you got the secp256k1 source code from, and (if possible) the commit hash of the code used?

Hey John,
Do we need to manually update the code for every new version of secp256k1 ?
If we adopt a git submodule approach and if there is a mistake in the bitcoin-core's implementation of the secp256k1, isn't that a risk for rippled?

We don't have to update to every new version of any dependency. Our update cadence is up to us. We always manually update dependencies.
A mistake can be found in the implementation whether or not we use submodules. If a mistake is found in a dependency, the most common fix is to switch to a different version.

@thejohnfreeman  Okay. What are the tradeoffs between manually copying the code versus performing an import using #include ? Does it have an impact on the size of the generated binary or the developer productivity?
In an ideal world, if this piece of code were exported as a library by the bitcoin-core developers, we could import it. That is a better solution right?

@ckeshava I don't understand your questions. Manually copy the code where? We are #include-ing it no matter what. There is no choice between the two. Export how? Right now they are publishing it on GitHub. If they were to publish their own Conan recipe, and make it available in Conan Center, then that would be easiest, but using add_subdirectory as we do now is not much more difficult.

ok, I misunderstood that using git submodules has an impact on the size of the rippled binary. thanks for the clarification.

note: confirmed with @thejohnfreeman that this looks good to go

could check what bitcoin-core does for testing this
expect any issues to be caught by existing end to end tests


Feature Request: Support react-custom-scrollbars

Please could you consider supporting react-custom-scrollbars on your menu

I've not used it myself but would be open to trying to support it. I don't envision bringing the dependency in directly, but if we can allow a way to wrap Menu to support this, I don't see why not.
A quick search shows that integrating react-virtualized and react-custom-scrollbars might require a little additional effort:

https://github.com/bvaughn/react-virtualized/issues/692
https://github.com/bvaughn/react-virtualized/issues/143

The comments towards the bottom if 692 seem to show some working examples.
I've been keeping an eye on @bvaughn's new react-window (rewrite of react-virtualized) so whatever we come up with I'd like to make sure it doesn't hinder switching over to it at some point.  I'm awaiting for some features to be ported over before I can take a hard look at it though.

I will be looking forward to this as well. I have a virtualized Table with a scroll bar and unfortunately I cannot have a cross browser solution with CSS. Tried implementing from the linked comments to no avail.


Collision detection

Hey I'm wondering how I would implement collision detection and get the x2 y2 of a collision.

See if something like this helps... https://stackoverflow.com/questions/12550635/how-can-i-improve-on-this-javascript-collision-detection

Thanks. I'll take a look at that.


fixes#25 Added banner

Hope that helps ;) with issue #25

@YannickLeRoux Great, thanks for your contribution!


Add support for parallel multi-watershed analysis (8)

How do we use parallelism to do this ?

@julemai Could you give us an example of configuration files that would run the same model on multiple watersheds (each with a different parameter set) but with common netCDF input files?

Performance wise, is there a large difference between running the model once with n watersheds or running it n times with one watershed each time?

The difference is negligible. The total computing power required is the same. However, from an algorithmic point of view, you always want to run the optimization n times with one watershed at a time, and parallelize the watersheds.

It could be that read-in of data is more efficient when we setup Raven once for multiple watersheds. I’m assuming that this only makes a difference for large watersheds. If you get me an example, I could set it up and we would have some numbers.

I agree for the case of large models, but in our case (for now) we only have lumped models so in theory the differences are pretty insignificant (maybe larger float values...?) :)

@richardarsenault Yep, that would be my bet too for lumped models. Let me know if you want to have it confirmed.

Correct, thanks !

In Matlab I use a parpool and loop over each watershed, not sure how to do this in the PAVICS architecture.  I think this would have to be limited to simple tasks (i.e a single climate model over the entire domain defined by the user.

Le's recap. We want to be able to run one model over a number of different basins in a way that's simple to the user. Raven (C++) does not support this, so we need to loop within the python interface, as we do for multiple parameters. Here however, it's not only the parameters that change. All of these inputs must be provided, one for each basin:

model parameters
basin information (name, area, elevation, latitude, longitude)
meteorological inputs

I fear this could get hairy pretty fast unless we restrict the scope of what is possible to do. My initial suggestion for discussion would be that to trigger multi-basin simulation, the user would pass a vector of parameters and minimally, a matching vector of region_ind.
We would assume that netCDF variables have two dimensions (region, time), and the region_ind value would indicate the index (starting at 0) of the times series for each region.
For the region attributes (names, area, elevation, lat, lon), the user would either pass them explicitly as vectors in the call, or let them set to their default (None). The code would then look into the netCDF forcing files if it can find variables with matching names (name, area, elevation, latitude/lat, longitude/lon) and would set them automatically.

1- Yes, we need to loop within the python interface.
2- Correct, the model parameters, basin info and meteo inputs are required for each catchment. Eventually we might want to calibrate multiple basins in parallel, in which case the model parameters would not be required.
3- I think your suggestion is a great idea. Ideally the variables would be in the NetCDF file, stored as vectors of size [region_ind x 1] for each property (lat, long, area, elevation, etc.). Maybe there are some cases where we will want to pass those properties explicitly (not in NetCDF) but for now I fail to see them.
4- If we look at the bigger picture, imagine someone who has, for example, 5 hydro stations where they'd like to calibrate a hydrological model and have an estimate of simulated streamflow for forecasting purposes / climate change / whatever. They could simply pass the station coordinates to the GIS analysis tools to get the basin properties, then the code could extract a reference meteo dataset intersecting the catchment boundaries, send that to OSTRICH for calibration, then return the optimized parameter sets. Would want the whole thing to be done in parallel? If so, we can force the code to write the properties, meteo and parameters to a NetCDF that gets updated incrementally as the process advances. If, instead, the user calls this function directly to run simulations in parallel, then we can probably simply require them to add the basin info to the NetCDF. All this to say that I don't think we need to give the option to send the basin properties explicitly, but we can do a check to make sure they are present (and in the right format) in the NetCDF.

Ok. @richardarsenault I suggest you open an issue for "Input dataset preparation", that would help with the task of going from gridded climate variables to basin-specific time series in a raven-compatible format.

RAVEN can technically be setup to run multiple basins in parallel. You can provide different sets of parameters for the different basins if the parameters are basin-specific and not process-specific. the process description would need to be the same for all simulated basins.
Hence, I think, the handling of running only individual basins with RAVEN and implementing the loop over the basins in Python is way more elegant. :)
The NetCDF inputs (forcings) can be two-dimensional (stations x time or time x stations). One would need to specify  the ":StationIdx" in the data block (one for each forcing). The block looks like this:
:Data [forcing type] [unit]
   :ReadFromNetCDF
      :FileNameNC  [path/filename of .nc file]
      :VarNameNC  [name of variable in .nc file]
      :DimNamesNC  [stations_name] [time_name] | [time_name]
      :StationIdx  [ID of station of interest (starts with 1)]
      :TimeShift  [fractional day to shift time stamp of data]
      :LinearTransform [slope] [intercept]
   :EndReadFromNetCDF
:EndData

More information can be found in the current RAVEN manual for v2.9 here.

Hi @julemai,
I've created a 2D file for testing this and I'm having a weird core dump with Raven. The unit_t variable (time units) is causing an error on Line 1324 of TimeSeries.cpp. There is no colon in the time units, it's just days since 1954-01-01. When I print unit_t_str, I get days since 1954-01-01U, and I guess that U is causing problems. Ideas ?

Is it possible that you add this U to identify unicode strings ? Since I've created this file using Python3, it's possible it converted the original ascii string to unicode.

You can test it using branch fix-12 and running the test_parallel_basins in test_emulators.py

@huard I tried to run make test in this branch. This creates the following error for each test:
    import fiona
E   ModuleNotFoundError: No module named 'fiona'

I tried to run another make install. But that one gives me the error:
[j6mai@JulieUW:/Users/j6mai/Documents/GitHub/raven/]:
make install
Installing Anaconda ...
Updating conda environment raven ...
"/bin/conda" create --yes -n raven python=3.6
/bin/sh: /bin/conda: No such file or directory
make: *** [conda_env] Error 127

Any idea?

I assumed in Raven that the time unit string is following the pattern:
days since YYYY-MM-DD HH:MM:SS

You could try to add HH:MM:SS in your unit and it should work. I will work on fixing this in RAVEN assuming that if time is not given it is midnight.

New Raven version (rev183) is available here. It will throw an error if the time string is not YYYY-MM-DD HH:MM:SS.

Thanks, you're right. I had not noticed that when I created the new file, the 00:00:00 disappeared.


Can't print image base64

Normal values can be printed, but the incoming picture base64, but the printer can not print the picture, when printing the picture, what to do to print out

You need to provide more information to resolve your issue. What type of device you are using, what's the defined protocol for it, how are you communicating with it.


Store TimeDB in RocksDB

Use RocksDB to store TimeDB

RocksDB does not provide a native call to get the last record in O(1) time. Instead, a timestamp is maintained as the index to the last time record in the TimeDB. Therefore, the latest global time can be obtained by fetching timeDB[last_timestamp].


Chefdk 0.9.0 and ~/.chefdk

Hello,
I just upgraded to chefdk 0.9.0 and knife command started to fail:
knife search node 'fqdn:*'
/opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:128:in `require': cannot load such file -- hashie/mash (LoadError)
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:128:in `rescue in require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:39:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-zero-4.3.2/lib/chef_zero/chef_data/cookbook_data.rb:2:in `<top (required)>'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-zero-4.3.2/lib/chef_zero/server.rb:31:in `<top (required)>'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.5.1/lib/chef/http/socketless_chef_zero_client.rb:46:in `<top (required)>'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.5.1/lib/chef/http.rb:28:in `<top (required)>'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.5.1/lib/chef/rest.rb:24:in `<top (required)>'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.5.1/lib/chef/knife.rb:29:in `<top (required)>'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.5.1/lib/chef/application/knife.rb:18:in `<top (required)>'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
	from /opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.5.1/bin/knife:23:in `<top (required)>'
	from /usr/bin/knife:54:in `load'
	from /usr/bin/knife:54:in `<main>'

Downgrading to chefdk 0.8.1 solves the problem.
So does keeping chefdk 0.9.0 and removing ~/.chefdk. But I need to keep it because I use kitchen-docker gem which is not provided in chefdk.

It seems that you need to clean ~/.chefdk after upgrade.
berkshelf gem was installed in ~/.chefdk.
Removing it solves the issue.

This is a duplicate of https://github.com/chef/chef-dk/issues/530
What happens is you have gems installed to ~/.chefdk which depend on gems (or specific versions of gems) in the main ChefDK package, which then are not available after upgrade. We're looking at ways to fix this, such as: https://github.com/chef/chef-dk/issues/531


alot: init module

alot is a python mail user agent (MUA) built around a notmuch database.
Extracted from https://github.com/rycee/home-manager/pulls

alot support got merged in another PR.


HADOOP-18869: [Backport to branch-3.3] [ABFS] Fixing Behavior of a File System APIs on root path.

Jira Ticket: https://issues.apache.org/jira/browse/HADOOP-18869
Trunk PR: https://github.com/apache/hadoop/pull/6003
Cherry-picked Commit: https://github.com/apache/hadoop/commit/594e9f29f5d89563bd9afc2e45553d624a6accc7
Test Results:

:::: AGGREGATED TEST RESULT ::::
HNS-OAuth
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   TestAccountConfiguration.testConfigPropNotFound:386->testMissingConfigKey:399 Expected a org.apache.hadoop.fs.azurebfs.contracts.exceptions.TokenAccessProviderException to be thrown, but got the result: : "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider"
[INFO]
[ERROR] Tests run: 141, Failures: 1, Errors: 0, Skipped: 5
[INFO] Results:
[INFO]
[WARNING] Tests run: 339, Failures: 0, Errors: 0, Skipped: 41
HNS-SharedKey
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   TestAccountConfiguration.testConfigPropNotFound:386->testMissingConfigKey:399 Expected a org.apache.hadoop.fs.azurebfs.contracts.exceptions.TokenAccessProviderException to be thrown, but got the result: : "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider"
[INFO]
[ERROR] Tests run: 141, Failures: 1, Errors: 0, Skipped: 5
[INFO] Results:
[INFO]
[WARNING] Tests run: 339, Failures: 0, Errors: 0, Skipped: 41
NonHNS-SharedKey
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   TestAccountConfiguration.testConfigPropNotFound:386->testMissingConfigKey:399 Expected a org.apache.hadoop.fs.azurebfs.contracts.exceptions.TokenAccessProviderException to be thrown, but got the result: : "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider"
[INFO]
[ERROR] Tests run: 141, Failures: 1, Errors: 0, Skipped: 11
[INFO] Results:
[INFO]
[WARNING] Tests run: 590, Failures: 0, Errors: 0, Skipped: 274
[INFO] Results:
[INFO]
[WARNING] Tests run: 339, Failures: 0, Errors: 0, Skipped: 44
AppendBlob-HNS-OAuth
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   TestAccountConfiguration.testConfigPropNotFound:386->testMissingConfigKey:399 Expected a org.apache.hadoop.fs.azurebfs.contracts.exceptions.TokenAccessProviderException to be thrown, but got the result: : "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider"
[INFO]
[ERROR] Tests run: 141, Failures: 1, Errors: 0, Skipped: 5
[INFO] Results:
[INFO]
[WARNING] Tests run: 339, Failures: 0, Errors: 0, Skipped: 41
Time taken: 25 mins 33 secs.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m  0s

Docker mode activated.

-1 :x:
docker
2m 21s

Docker failed to build run-specific yetus/hadoop:tp-6753}.

Subsystem
Report/Notes

GITHUB PR
https://github.com/apache/hadoop/pull/6274

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6274/1/console

versions
git=2.34.1

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

looks like yetus is playing up

07:32:57  #3 [internal] load metadata for docker.io/yetus/hadoop:3400e8257e1b
07:32:58  #3 ERROR: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

can you add an empty commit and push it up, this will trigger a rebuild

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
5m 50s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
xmllint
0m  0s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ branch-3.3 Compile Tests _

+1 :green_heart:
mvninstall
48m 29s

branch-3.3 passed

+1 :green_heart:
compile
0m 36s

branch-3.3 passed

+1 :green_heart:
checkstyle
0m 30s

branch-3.3 passed

+1 :green_heart:
mvnsite
0m 43s

branch-3.3 passed

+1 :green_heart:
javadoc
0m 36s

branch-3.3 passed

+1 :green_heart:
spotbugs
1m 10s

branch-3.3 passed

+1 :green_heart:
shadedclient
34m 55s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 37s

the patch passed

+1 :green_heart:
compile
0m 29s

the patch passed

+1 :green_heart:
javac
0m 29s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 19s

the patch passed

+1 :green_heart:
mvnsite
0m 34s

the patch passed

+1 :green_heart:
javadoc
0m 22s

the patch passed

+1 :green_heart:
spotbugs
1m  6s

the patch passed

+1 :green_heart:
shadedclient
34m 33s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 19s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 37s

The patch does not generate ASF License warnings.

136m 34s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6274/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/6274

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets xmllint

uname
Linux e80ef1eed695 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.3 / e9808b837497562ea1b5a076dea4b03cd91107f1

Default Java
Private Build-1.8.0_362-8u372-ga~us1-0ubuntu1~18.04-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6274/2/testReport/

Max. process+thread count
745 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-6274/2/console

versions
git=2.17.1 maven=3.6.0 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


crypto: mechanism to enable FIPS mode

As tracked in #69536 we are pursuing a FIPS 140-3 validation for the Go cryptography packages. This proposal is about the mechanism to selectively enable and disable FIPS mode.
All Linux binaries will be FIPS-capable, so there will be no need for a compile-time on-switch. We believe we can make the build-time overhead low enough that we can remove this entire layer of complexity, so there will be no need for a "FIPS build". Note however that the module will not be FIPS validated on all architectures[^a].
A run-time GODEBUG flag, fips140 defaults to off but can be set to on to operate the binary in FIPS mode. Primarily, this enables the slower and more complex RNG system, and the slow runtime self-tests. The GODEBUG can also be set to only to make any non-approved crypto return errors.[^b]
~A build tag, fips140, can be used to switch the GODEBUG default from off to on. It has no other effect. This allows building arbitrary programs so that they will run in FIPS mode by default.~ Note that //go:debug annotations can also be used to enable or disable the GODEBUG.
If fips140=on is set (in any way) and the binary can't operate in FIPS mode (because it was not built for Linux or it was built for an architecture that was not validated, for example), the binary will immediately panic at runtime.
A new package, crypto/fips140 will be added with a single function Enabled() bool which can be used to check at runtime if the binary is operating in FIPS mode.
Changing the GODEBUG after the binary started is not supported, it will not result in compliant FIPS operations, and may or may not cause the binary to panic. This is unlikely to change.
This proposal does not address how to select the FIPS module to compile against, which will require either a go build flag or a build tag. We are discussing this with @rsc. By default, binaries will build against the latest unvalidated version of the module[^c], but it will be possible to select both the latest In Process modules and the latest certified module. This will be transparent, although some newly introduced functionality may not be available when compiling against frozen versions of the module.
/cc @golang/security @cpu
[^a]: The current tentative plan is to validate on some Linux OSes on some amd64, arm64, mips64, ppc64le, and s390x. If you need specific OEs validated, reach out to me ASAP.
[^b]: We're aware this is usually less granularity than required by production applications, which sometimes need to use non-approved crypto for non-security purposes, as allowed by FIPS 140-3. We'll share precise plans later, but in short this only mode will be implemented in terms of an internal API that can be used by downstream forks (without explicit backward compatibility guarantees) to enforce such a fine-grained policy. We don't plan to provide an exposed upstream mechanism at this time.
[^c]: Running the latest unvalidated version in FIPS mode still makes sense in some settings, hopefully more and more over time.

Related Issues and Documentation

crypto: obtain a FIPS 140-3 validation #69536
crypto: FIPS Mode and Validation of Crypto Provider? #11658 (closed)

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

If changing the FIPS mode is not possible at runtime, it's a property fixed when building the binary, then IMO it would make sense to define fips140.Enabled as a const instead of as a func. This way it is clearer for that caller that the value can't change at runtime and that the compiler will strip any branch conditioned by fips140.Enabled.
Also, will FIPS mode affect the Go runtime behavior (or even other packages outside crypto)? If that's the case, then I would consider moving the fips140.Enabled flag to the runtime package.

If changing the FIPS mode is not possible at runtime, it's a property fixed when building the binary, then IMO it would make sense to define fips140.Enabled as a const instead of as a func. This way it is clearer for that caller that the value can't change at runtime and that the compiler will strip any branch conditioned by fips140.Enabled.

The idea is that FIPS mode will be selected only at runtime, by the GODEBUG env var. I think you might have been confused by my poorly worded "Changing the GODEBUG at runtime is not supported", edited to "Changing the GODEBUG after the binary started is not supported". I just meant that you can't do os.Setenv halfway through the run.

Also, will FIPS mode affect the Go runtime behavior (or even other packages outside crypto)? If that's the case, then I would consider moving the fips140.Enabled flag to the runtime package.

There is a bit of runtime support, but I think logically the package makes more sense under crypto/. It will be a package with no dependencies anyway.

By default, binaries will build against the latest unvalidated version of the module3, but it will be possible to select both the latest In Process modules and the latest certified module.

Isn't it going to cause confusion that, by default, when you set the fips140 build tag, what you get is not actually FIPS 140 certified?

Isn't it going to cause confusion that, by default, when you set the fips140 build tag, what you get is not actually FIPS 140 certified?

In general, "FIPS 140 certified" is more of a spectrum than a binary state, and for example with the new FedRAMP rules a binary that's in FIPS mode would be acceptable even if it's an updated version of the one that underwent validation.
Still, I agree that the build tag is confusing, also because people will end up assuming it does more than just set the default GODEBUG. Let's just drop it. Instead, we discussed with @rsc making the module version selection mechanism (which is out of scope for this proposal) also flip the GODEBUG default to on any time it's used.

The module details are a separate proposal, #70200.

We've been discussing with @rolandshoemaker how to let applications enforce the use of NIST-approved algorithms implemented within the module, and for now we want to offer a coarse binary choice, and then add more fine-grained mechanisms in the future based on feedback.
We propose adding a third documented GODEBUG=fips140 option, enforce which:

behaves like on
makes crypto/tls and golang.org/x/crypto/ssh silently consider only FIPS-compliant algorithms (like crypto/tls/fipsonly in Go+BoringCrypto)
makes non-approved cryptographic functions return errors or panic

The last point includes wholly non-approved algorithms implemented by the standard library or (an updated version of) golang.org/x/crypto, as well as approved algorithms used with non-approved parameters (such as HMAC with too short a key). This is to be considered a best-effort mechanism, since we can't for example detect applications implementing non-approved crypto with math/big or third-party modules, of course.
Here is a list of functions that would fail entirely:

crypto/cipher.NewGCM
crypto/cipher.NewGCMWithNonceSize
crypto/cipher.NewGCMWithTagSize
crypto/cipher.NewCFBDecrypter [p]
crypto/cipher.NewCFBEncrypter [p]
crypto/cipher.NewOFB [p]
crypto/des.NewCipher
crypto/des.NewTripleDESCipher
crypto/dsa.GenerateKey
crypto/dsa.GenerateParameters
crypto/dsa.Sign
crypto/dsa.Verify [p]
crypto/ecdh.X25519.ECDH
crypto/md5.New [p]
crypto/md5.Sum [p]
crypto/rand.Prime
crypto/rc4.NewCipher
crypto/rsa.EncryptPKCS1v15
crypto/rsa.DecryptPKCS1v15
crypto/sha1.New [p]
crypto/sha1.Sum [p]
golang.org/x/crypto/argon2.IDKey [p]
golang.org/x/crypto/argon2.Key [p]
golang.org/x/crypto/bcrypt.CompareHashAndPassword
golang.org/x/crypto/bcrypt.GenerateFromPassword
golang.org/x/crypto/blake2b.New*
golang.org/x/crypto/blake2b.Sum* [p]
golang.org/x/crypto/blake2s.New*
golang.org/x/crypto/blake2s.Sum* [p]
golang.org/x/crypto/blowfish.NewCipher
golang.org/x/crypto/blowfish.NewSaltedCipher
golang.org/x/crypto/cast5.NewCipher
golang.org/x/crypto/chacha20.NewUnauthenticatedCipher
golang.org/x/crypto/chacha20poly1305.New
golang.org/x/crypto/chacha20poly1305.NewX
golang.org/x/crypto/curve25519.ScalarBaseMult [p]
golang.org/x/crypto/curve25519.ScalarMult [p]
golang.org/x/crypto/curve25519.X25519
golang.org/x/crypto/md4.New [p]
golang.org/x/crypto/poly1305.New
golang.org/x/crypto/poly1305.Sum [p]
golang.org/x/crypto/poly1305.Verify [p]
golang.org/x/crypto/ripemd160.New [p]
golang.org/x/crypto/salsa20.XORKeyStream [p]
golang.org/x/crypto/sha3.NewLekacyKeccak256 [p]
golang.org/x/crypto/sha3.NewLekacyKeccak512 [p]
golang.org/x/crypto/tea.NewCipher
golang.org/x/crypto/tea.NewCipherWithRounds
golang.org/x/crypto/twofish.NewCipher
golang.org/x/crypto/xtea.NewCipher
golang.org/x/crypto/xts.NewCipher

Note that scrypt is missing because it has been successfully described as approved due to its use of PBKDF2.
(Internally, we'll still let forks apply more fine-grained policy with a mechanism akin to #65265, but that's not part of this proposal.)

crypto/cipher.NewGCM
crypto/cipher.NewGCMWithNonceSize
crypto/cipher.NewGCMWithTagSize

Doesn't this preclude AES-GCM?

Doesn't this preclude AES-GCM?

It will require #69981, yes, or a special internal TLS mode we will probably not expose. That's FIPS 140-3 IG C.H for you.

We propose adding a third documented GODEBUG=fips140 option, enforce which:

Why would someone chose enforce versus on?

Why would someone chose enforce versus on?

Having a FIPS module laying around is not enough to comply with anything, you also have to use it for all cryptographic operations, and use only its approved "services" (a NIST-ism for algorithms and modes). It's ok to do that by just being very careful not to use anything that's not approved, but enforce mode offers better assurance of it. Go+BoringCrypto doesn't have that mode (aside from crypto/tls/fipsonly) but some of the forks do.

Why would someone chose enforce versus on?

Having a FIPS module laying around is not enough to comply with anything, you also have to use it for all cryptographic operations, and use only its approved "services" (a NIST-ism for algorithms and modes). It's ok to do that by just being very careful not to use anything that's not approved, but enforce mode offers better assurance of it. Go+BoringCrypto doesn't have that mode (aside from crypto/tls/fipsonly) but some of the forks do.

This mode I think is very important. Within the golang-fips/go fork we have a strict FIPS mode we operate in by default which essentially matches the description of enforce. It takes the burden off the consumer of the toolchain to ensure they are using the crypto libraries in a FIPS compliant way by ensuring any violation is met with an error and ensuring that higher level packages such as tls are also operating in a FIPS compliant way.

Okay, in that case why would someone chose on over enforce?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.

Okay, in that case why would someone chose on over enforce?

There's the concept of non-security purposes. E.g. the AWS APIs use MD5 as a checksum. That's not a security purpose, so it's allowed, but it involves the use of non-approved cryptography, so requires operating in on rather than enforce mode.
Ultimately, we'll want some finer-grained mechanism to make that coexist with the safety of enforce, but I don't think we can design it for Go 1.24, and having the two modes matches what's being used in the field at the moment.

We noticed I called enforce mode force in the proposal and enforce in https://github.com/golang/go/issues/70123#issuecomment-2459809925. Both are kind of confusing. Let's go with only since in that mode you can only use FIPS 140-3 cryptography.

A new package, crypto/fips140 will be added with a single function Enabled() bool which can be used to check at runtime if the binary is operating in FIPS mode.

Does this need to distinguish on and only?

It's worth noting that we believe this will have little effect on binary size, even though all binaries will be built with the ability to turn on FIPS mode. We're not going to be compiling in two different crypto trees. There will be a little extra code to support the dynamic selection between off and on, but not much.

Does this need to distinguish on and only?

To be clear, I think we would still want an Enabled() bool function since that's all people care about the vast majority of the time. That also means we can add functions to interrogate this more deeply in the future if we need to. @rolandshoemaker says people will let us know if they need this. :)

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
The proposal is to add a fips140 GODEBUG setting that can take the following three values:

fips140=off - The binary does not operate in FIPS mode.
fips140=on - The binary operates in FIPS mode. Primarily, this enables the slower and more complex RNG system, and the slow runtime self-tests. If for any reason the binary can't operate in FIPS mode, it will immediately panic during startup.
fips140=only - Like "on", but additionally any non-approved crypto will return errors.

The default value of fips140 will depend on the GOFIPS140 build-time environment variable (see #70200), but if no GOFIPS140 is set, it defaults to off.
The fips140 GODEBUG cannot be changed at runtime. Attempting to do so may or may not panic.
A new package, crypto/fips140 will be added with a single function Enabled() bool which can be used to check at runtime if the binary is operating in FIPS mode.

The description says:

A run-time GODEBUG flag, fips140 defaults to off but can be set to on to operate the binary in FIPS mode
...
Changing the GODEBUG after the binary started is not supported

The accepted summary says:

The fips140 GODEBUG cannot be changed at runtime. Attempting to do so may or may not panic.

For clarity, is the description still accurate, that the fips140 GODEBUG can be set at runtime but not changed after the binary started? Or did the proposal shift to make this a build-time decision only?

the fips140 GODEBUG can be set at runtime but not changed after the binary started

Correct. The summary probably left "after the binary started" implied.

I am not sure if on/only are sufficient.
Currently in many places md5 is used as a CRC and no longer used as a cryptographically secure message digest, most notably for calculating MD5 for AWS S3 storage.
I sort of wish to move crypto/md5 to hash/md5, which is then never used by any other cryptographically secure things (TLS, RSA/ECDSA signatures, x509 and so on). Or at least have some other toggles to turn md5 back on, but to calculate a hash without it being usable in secure context.
Effectively it needs to be a service indicator, or explicit opt-in. Another option is to create a new API that allows to access unapproved hashes similar to what python has - usedforsecurity=True|False kwarg (hashlib doc)
Has there been any discussion on how to enable selective ability to allow access to unapproved algorithms with a specific context? Something more granular than on|off|only; without registristing MD5 in the crypto digests subsystem.
Note SHA1 will be similarly affected with FIPS modules submitted with support dates post 2030.

Such an API wasn't proposed for the initial implementation, because a reasonable design is not immediately obvious, and because we heard from most consumers that on/only would be acceptable for the majority of their uses.
We'll likely work on a API design for this for either 1.25 or 1.26.

Such an API wasn't proposed for the initial implementation, because a reasonable design is not immediately obvious, and because we heard from most consumers that on/only would be acceptable for the majority of their uses.
We'll likely work on a API design for this for either 1.25 or 1.26.

Cool! Note, I am in full support of the current 1.24 plan; as off|on|only will indeed cover 90% of usecase and is an ultramassive improvement over the current status.


Find final solution to publish npm packages from Travis

The current solution is a ~/.npmrc file. It requires to set and export NPM_TOKEN  in the local .bash_profile which should not be necessary.

@axelchalon I'm also not that familiar with travis. I already had a quick chat with @amaurymartiny, he'll look into this issue. I just created the ticket to document and not forget about it.


large amounts of extraneous data included in JS

I'm using vite-imagetools.
Here's a JS output file from my site: https://c3.ventures/_app/pages/index.svelte-77e56e84.js
I imported a file like this:
import Ben from '$img/ben-mccann-cf.jpg?format=avif;webp;jpg&meta';

And then it ends up in the JS as a very large object due to a sizable icc property
{format:"webp",width:450,height:450,space:"srgb",channels:3,depth:"uchar",density:300,chromaSubsampling:"4:4:4",isProgressive:!0,hasProfile:!0,hasAlpha:!1,orientation:1,icc:{"0":0,"1":0,"2":12,"3":72,"4":76,"5":105,"6":110,"7":111,"8":2,"9":16,"10":0,"11":0,"12":109,"13":110,"14":116,"15":114,"16":82,"17":71,"18":66,"19":32,"20":88,"21":89,"22":90,"23":32,"24":7,"25":206,"26":0,"27":2,"28":0,"29":9,"30":0,"31":6,"32":0,"33":49,"34":0,"35":0,"36":97,"37":99,"38":115,"39":112,"40":77,"41":83,"42":70,"43":84,"44":0,"45":0,"46":0,"47":0,"48":73,"49":69,"50":67,"51":32,"52":115,"53":82,"54":71,"55":66,"56":0,"57":0,"58":0,"59":0,"60":0,"61":0,"62":0,"63":0,"64":0,"65":0,"66":0,"67":0,"68":0,"69":0,"70":246,"71":214,"72":0,"73":1,"74":0,"75":0,"76":0,"77":0,"78":211,"79":45,"80":72,"81":80,"82":32,"83":32,"84":0,"85":0,"86":0,"87":0,"88":0,"89":0,"90":0,"91":0,"92":0,"93":0,"94":0,"95":0,"96":0,"97":0,"98":0,"99":0,"100":0,"101":0,"102":0,"103":0,"104":0,"105":0,"106":0,"107":0,"108":0,"109":0,"110":0,"111":0,"112":0,"113":0,"114":0,"115":0,"116":0,"117":0,"118":0,"119":0,"120":0,"121":0,"122":0,"123":0,"124":0,"125":0,"126":0,"127":0,"128":0,"129":0,"130":0,"131":17,"132":99,"133":112,"134":114,"135":116,"136":0,"137":0,"138":1,"139":80,"140":0,"141":0,"142":0,"143":51,"144":100,"145":101,"146":115,"147":99,"148":0,"149":0,"150":1,"151":132,"152":0,"153":0,"154":0,"155":108,"156":119,"157":116,"158":112,"159":116,"160":0,"161":0,"162":1,"163":240,"164":0,"165":0,"166":0,"167":20,"168":98,"169":107,"170":112,"171":116,"172":0,"173":0,"174":2,"175":4,"176":0,"177":0,"178":0,"179":20,"180":114,"181":88,"182":89,"183":90,"184":0,"185":0,"186":2,"187":24,"188":0,"189":0,"190":0,"191":20,"192":103,"193":88,"194":89,"195":90,"196":0,"197":0,"198":2,"199":44,"200":0,"201":0,"202":0,"203":20,"204":98,"205":88,"206":89,"207":90,"208":0,"209":0,"210":2,"211":64,"212":0,"213":0,"214":0,"215":20,"216":100,"217":109,"218":110,"219":100,"220":0,"221":0,"222":2,"223":84,"224":0,"225":0,"226":0,"227":112,"228":100,"229":109,"230":100,"231":100,"232":0,"233":0,"234":2,"235":196,"236":0,"237":0,"238":0,"239":136,"240":118,"241":117,"242":101,"243":100,"244":0,"245":0,"246":3,"247":76,"248":0,"249":0,"250":0,"251":134,"252":118,"253":105,"254":101,"255":119,"256":0,"257":0,"258":3,"259":212,"260":0,"261":0,"262":0,"263":36,"264":108,"265":117,"266":109,"267":105,"268":0,"269":0,"270":3,"271":248,"272":0,"273":0,"274":0,"275":20,"276":109,"277":101,"278":97,"279":115,"280":0,"281":0,"282":4,"283":12,"284":0,"285":0,"286":0,"287":36,"288":116,"289":101,"290":99,"291":104,"292":0,"293":0,"294":4,"295":48,"296":0,"297":0,"298":0,"299":12,"300":114,"301":84,"302":82,"303":67,"304":0,"305":0,"306":4,"307":60,"308":0,"309":0,"310":8,"311":12,"312":103,"313":84,"314":82,"315":67,"316":0,"317":0,"318":4,"319":60,"320":0,"321":0,"322":8,"323":12,"324":98,"325":84,"326":82,"327":67,"328":0,"329":0,"330":4,"331":60,"332":0,"333":0,"334":8,"335":12,"336":116,"337":101,"338":120,"339":116,"340":0,"341":0,"342":0,"343":0,"344":67,"345":111,"346":112,"347":121,"348":114,"349":105,"350":103,"351":104,"352":116,"353":32,"354":40,"355":99,"356":41,"357":32,"358":49,"359":57,"360":57,"361":56,"362":32,"363":72,"364":101,"365":119,"366":108,"367":101,"368":116,"369":116,"370":45,"371":80,"372":97,"373":99,"374":107,"375":97,"376":114,"377":100,"378":32,"379":67,"380":111,"381":109,"382":112,"383":97,"384":110,"385":121,"386":0,"387":0,"388":100,"389":101,"390":115,"391":99,"392":0,"393":0,"394":0,"395":0,"396":0,"397":0,"398":0,"399":18,"400":115,"401":82,"402":71,"403":66,"404":32,"405":73,"406":69,"407":67,"408":54,"409":49,"410":57,"411":54,"412":54,"413":45,"414":50,"415":46,"416":49,"417":0,"418":0,"419":0,"420":0,"421":0,"422":0,"423":0,"424":0,"425":0,"426":0,"427":0,"428":18,"429":115,"430":82,"431":71,"432":66,"433":32,"434":73,"435":69,"436":67,"437":54,"438":49,"439":57,"440":54,"441":54,"442":45,"443":50,"444":46,"445":49,"446":0,"447":0,"448":0,"449":0,"450":0,"451":0,"452":0,"453":0,"454":0,"455":0,"456":0,"457":0,"458":0,"459":0,"460":0,"461":0,"462":0,"463":0,"464":0,"465":0,"466":0,"467":0,"468":0,"469":0,"470":0,"471":0,"472":0,"473":0,"474":0,"475":0,"476":0,"477":0,"478":0,"479":0,"480":0,"481":0,"482":0,"483":0,"484":0,"485":0,"486":0,"487":0,"488":0,"489":0,"490":0,"491":0,"492":0,"493":0,"494":0,"495":0,"496":88,"497":89,"498":90,"499":32,"500":0,"501":0,"502":0,"503":0,"504":0,"505":0,"506":243,"507":81,"508":0,"509":1,"510":0,"511":0,"512":0,"513":1,"514":22,"515":204,"516":88,"517":89,"518":90,"519":32,"520":0,"521":0,"522":0,"523":0,"524":0,"525":0,"526":0,"527":0,"528":0,"529":0,"530":0,"531":0,"532":0,"533":0,"534":0,"535":0,"536":88,"537":89,"538":90,"539":32,"540":0,"541":0,"542":0,"543":0,"544":0,"545":0,"546":111,"547":162,"548":0,"549":0,"550":56,"551":245,"552":0,"553":0,"554":3,"555":144,"556":88,"557":89,"558":90,"559":32,"560":0,"561":0,"562":0,"563":0,"564":0,"565":0,"566":98,"567":153,"568":0,"569":0,"570":183,"571":133,"572":0,"573":0,"574":24,"575":218,"576":88,"577":89,"578":90,"579":32,"580":0,"581":0,"582":0,"583":0,"584":0,"585":0,"586":36,"587":160,"588":0,"589":0,"590":15,"591":132,"592":0,"593":0,"594":182,"595":207,"596":100,"597":101,"598":115,"599":99,"600":0,"601":0,"602":0,"603":0,"604":0,"605":0,"606":0,"607":22,"608":73,"609":69,"610":67,"611":32,"612":104,"613":116,"614":116,"615":112,"616":58,"617":47,"618":47,"619":119,"620":119,"621":119,"622":46,"623":105,"624":101,"625":99,"626":46,"627":99,"628":104,"629":0,"630":0,"631":0,"632":0,"633":0,"634":0,"635":0,"636":0,"637":0,"638":0,"639":0,"640":22,"641":73,"642":69,"643":67,"644":32,"645":104,"646":116,"647":116,"648":112,"649":58,"650":47,"651":47,"652":119,"653":119,"654":119,"655":46,"656":105,"657":101,"658":99,"659":46,"660":99,"661":104,"662":0,"663":0,"664":0,"665":0,"666":0,"667":0,"668":0,"669":0,"670":0,"671":0,"672":0,"673":0,"674":0,"675":0,"676":0,"677":0,"678":0,"679":0,"680":0,"681":0,"682":0,"683":0,"684":0,"685":0,"686":0,"687":0,"688":0,"689":0,"690":0,"691":0,"692":0,"693":0,"694":0,"695":0,"696":0,"697":0,"698":0,"699":0,"700":0,"701":0,"702":0,"703":0,"704":0,"705":0,"706":0,"707":0,"708":100,"709":101,"710":115,"711":99,"712":0,"713":0,"714":0,"715":0,"716":0,"717":0,"718":0,"719":46,"720":73,"721":69,"722":67,"723":32,"724":54,"725":49,"726":57,"727":54,"728":54,"729":45,"730":50,"731":46,"732":49,"733":32,"734":68,"735":101,"736":102,"737":97,"738":117,"739":108,"740":116,"741":32,"742":82,"743":71,"744":66,"745":32,"746":99,"747":111,"748":108,"749":111,"750":117,"751":114,"752":32,"753":115,"754":112,"755":97,"756":99,"757":101,"758":32,"759":45,"760":32,"761":115,"762":82,"763":71,"764":66,"765":0,"766":0,"767":0,"768":0,"769":0,"770":0,"771":0,"772":0,"773":0,"774":0,"775":0,"776":46,"777":73,"778":69,"779":67,"780":32,"781":54,"782":49,"783":57,"784":54,"785":54,"786":45,"787":50,"788":46,"789":49,"790":32,"791":68,"792":101,"793":102,"794":97,"795":117,"796":108,"797":116,"798":32,"799":82,"800":71,"801":66,"802":32,"803":99,"804":111,"805":108,"806":111,"807":117,"808":114,"809":32,"810":115,"811":112,"812":97,"813":99,"814":101,"815":32,"816":45,"817":32,"818":115,"819":82,"820":71,"821":66,"822":0,"823":0,"824":0,"825":0,"826":0,"827":0,"828":0,"829":0,"830":0,"831":0,"832":0,"833":0,"834":0,"835":0,"836":0,"837":0,"838":0,"839":0,"840":0,"841":0,"842":0,"843":0,"844":100,"845":101,"846":115,"847":99,"848":0,"849":0,"850":0,"851":0,"852":0,"853":0,"854":0,"855":44,"856":82,"857":101,"858":102,"859":101,"860":114,"861":101,"862":110,"863":99,"864":101,"865":32,"866":86,"867":105,"868":101,"869":119,"870":105,"871":110,"872":103,"873":32,"874":67,"875":111,"876":110,"877":100,"878":105,"879":116,"880":105,"881":111,"882":110,"883":32,"884":105,"885":110,"886":32,"887":73,"888":69,"889":67,"890":54,"891":49,"892":57,"893":54,"894":54,"895":45,"896":50,"897":46,"898":49,"899":0,"900":0,"901":0,"902":0,"903":0,"904":0,"905":0,"906":0,"907":0,"908":0,"909":0,"910":44,"911":82,"912":101,"913":102,"914":101,"915":114,"916":101,"917":110,"918":99,"919":101,"920":32,"921":86,"922":105,"923":101,"924":119,"925":105,"926":110,"927":103,"928":32,"929":67,"930":111,"931":110,"932":100,"933":105,"934":116,"935":105,"936":111,"937":110,"938":32,"939":105,"940":110,"941":32,"942":73,"943":69,"944":67,"945":54,"946":49,"947":57,"948":54,"949":54,"950":45,"951":50,"952":46,"953":49,"954":0,"955":0,"956":0,"957":0,"958":0,"959":0,"960":0,"961":0,"962":0,"963":0,"964":0,"965":0,"966":0,"967":0,"968":0,"969":0,"970":0,"971":0,"972":0,"973":0,"974":0,"975":0,"976":0,"977":0,"978":0,"979":0,"980":118,"981":105,"982":101,"983":119,"984":0,"985":0,"986":0,"987":0,"988":0,"989":19,"990":164,"991":254,"992":0,"993":20,"994":95,"995":46,"996":0,"997":16,"998":207,"999":20,"1000":0,"1001":3,"1002":237,"1003":204,"1004":0,"1005":4,"1006":19,"1007":11,"1008":0,"1009":3,"1010":92,"1011":158,"1012":0,"1013":0,"1014":0,"1015":1,"1016":88,"1017":89,"1018":90,"1019":32,"1020":0,"1021":0,"1022":0,"1023":0,"1024":0,"1025":76,"1026":9,"1027":86,"1028":0,"1029":80,"1030":0,"1031":0,"1032":0,"1033":87,"1034":31,"1035":231,"1036":109,"1037":101,"1038":97,"1039":115,"1040":0,"1041":0,"1042":0,"1043":0,"1044":0,"1045":0,"1046":0,"1047":1,"1048":0,"1049":0,"1050":0,"1051":0,"1052":0,"1053":0,"1054":0,"1055":0,"1056":0,"1057":0,"1058":0,"1059":0,"1060":0,"1061":0,"1062":0,"1063":0,"1064":0,"1065":0,"1066":2,"1067":143,"1068":0,"1069":0,"1070":0,"1071":2,"1072":115,"1073":105,"1074":103,"1075":32,"1076":0,"1077":0,"1078":0,"1079":0,"1080":67,"1081":82,"1082":84,"1083":32,"1084":99,"1085":117,"1086":114,"1087":118,"1088":0,"1089":0,"1090":0,"1091":0,"1092":0,"1093":0,"1094":4,"1095":0,"1096":0,"1097":0,"1098":0,"1099":5,"1100":0,"1101":10,"1102":0,"1103":15,"1104":0,"1105":20,"1106":0,"1107":25,"1108":0,"1109":30,"1110":0,"1111":35,"1112":0,"1113":40,"1114":0,"1115":45,"1116":0,"1117":50,"1118":0,"1119":55,"1120":0,"1121":59,"1122":0,"1123":64,"1124":0,"1125":69,"1126":0,"1127":74,"1128":0,"1129":79,"1130":0,"1131":84,"1132":0,"1133":89,"1134":0,"1135":94,"1136":0,"1137":99,"1138":0,"1139":104,"1140":0,"1141":109,"1142":0,"1143":114,"1144":0,"1145":119,"1146":0,"1147":124,"1148":0,"1149":129,"1150":0,"1151":134,"1152":0,"1153":139,"1154":0,"1155":144,"1156":0,"1157":149,"1158":0,"1159":154,"1160":0,"1161":159,"1162":0,"1163":164,"1164":0,"1165":169,"1166":0,"1167":174,"1168":0,"1169":178,"1170":0,"1171":183,"1172":0,"1173":188,"1174":0,"1175":193,"1176":0,"1177":198,"1178":0,"1179":203,"1180":0,"1181":208,"1182":0,"1183":213,"1184":0,"1185":219,"1186":0,"1187":224,"1188":0,"1189":229,"1190":0,"1191":235,"1192":0,"1193":240,"1194":0,"1195":246,"1196":0,"1197":251,"1198":1,"1199":1,"1200":1,"1201":7,"1202":1,"1203":13,"1204":1,"1205":19,"1206":1,"1207":25,"1208":1,"1209":31,"1210":1,"1211":37,"1212":1,"1213":43,"1214":1,"1215":50,"1216":1,"1217":56,"1218":1,"1219":62,"1220":1,"1221":69,"1222":1,"1223":76,"1224":1,"1225":82,"1226":1,"1227":89,"1228":1,"1229":96,"1230":1,"1231":103,"1232":1,"1233":110,"1234":1,"1235":117,"1236":1,"1237":124,"1238":1,"1239":131,"1240":1,"1241":139,"1242":1,"1243":146,"1244":1,"1245":154,"1246":1,"1247":161,"1248":1,"1249":169,"1250":1,"1251":177,"1252":1,"1253":185,"1254":1,"1255":193,"1256":1,"1257":201,"1258":1,"1259":209,"1260":1,"1261":217,"1262":1,"1263":225,"1264":1,"1265":233,"1266":1,"1267":242,"1268":1,"1269":250,"1270":2,"1271":3,"1272":2,"1273":12,"1274":2,"1275":20,"1276":2,"1277":29,"1278":2,"1279":38,"1280":2,"1281":47,"1282":2,"1283":56,"1284":2,"1285":65,"1286":2,"1287":75,"1288":2,"1289":84,"1290":2,"1291":93,"1292":2,"1293":103,"1294":2,"1295":113,"1296":2,"1297":122,"1298":2,"1299":132,"1300":2,"1301":142,"1302":2,"1303":152,"1304":2,"1305":162,"1306":2,"1307":172,"1308":2,"1309":182,"1310":2,"1311":193,"1312":2,"1313":203,"1314":2,"1315":213,"1316":2,"1317":224,"1318":2,"1319":235,"1320":2,"1321":245,"1322":3,"1323":0,"1324":3,"1325":11,"1326":3,"1327":22,"1328":3,"1329":33,"1330":3,"1331":45,"1332":3,"1333":56,"1334":3,"1335":67,"1336":3,"1337":79,"1338":3,"1339":90,"1340":3,"1341":102,"1342":3,"1343":114,"1344":3,"1345":126,"1346":3,"1347":138,"1348":3,"1349":150,"1350":3,"1351":162,"1352":3,"1353":174,"1354":3,"1355":186,"1356":3,"1357":199,"1358":3,"1359":211,"1360":3,"1361":224,"1362":3,"1363":236,"1364":3,"1365":249,"1366":4,"1367":6,"1368":4,"1369":19,"1370":4,"1371":32,"1372":4,"1373":45,"1374":4,"1375":59,"1376":4,"1377":72,"1378":4,"1379":85,"1380":4,"1381":99,"1382":4,"1383":113,"1384":4,"1385":126,"1386":4,"1387":140,"1388":4,"1389":154,"1390":4,"1391":168,"1392":4,"1393":182,"1394":4,"1395":196,"1396":4,"1397":211,"1398":4,"1399":225,"1400":4,"1401":240,"1402":4,"1403":254,"1404":5,"1405":13,"1406":5,"1407":28,"1408":5,"1409":43,"1410":5,"1411":58,"1412":5,"1413":73,"1414":5,"1415":88,"1416":5,"1417":103,"1418":5,"1419":119,"1420":5,"1421":134,"1422":5,"1423":150,"1424":5,"1425":166,"1426":5,"1427":181,"1428":5,"1429":197,"1430":5,"1431":213,"1432":5,"1433":229,"1434":5,"1435":246,"1436":6,"1437":6,"1438":6,"1439":22,"1440":6,"1441":39,"1442":6,"1443":55,"1444":6,"1445":72,"1446":6,"1447":89,"1448":6,"1449":106,"1450":6,"1451":123,"1452":6,"1453":140,"1454":6,"1455":157,"1456":6,"1457":175,"1458":6,"1459":192,"1460":6,"1461":209,"1462":6,"1463":227,"1464":6,"1465":245,"1466":7,"1467":7,"1468":7,"1469":25,"1470":7,"1471":43,"1472":7,"1473":61,"1474":7,"1475":79,"1476":7,"1477":97,"1478":7,"1479":116,"1480":7,"1481":134,"1482":7,"1483":153,"1484":7,"1485":172,"1486":7,"1487":191,"1488":7,"1489":210,"1490":7,"1491":229,"1492":7,"1493":248,"1494":8,"1495":11,"1496":8,"1497":31,"1498":8,"1499":50,"1500":8,"1501":70,"1502":8,"1503":90,"1504":8,"1505":110,"1506":8,"1507":130,"1508":8,"1509":150,"1510":8,"1511":170,"1512":8,"1513":190,"1514":8,"1515":210,"1516":8,"1517":231,"1518":8,"1519":251,"1520":9,"1521":16,"1522":9,"1523":37,"1524":9,"1525":58,"1526":9,"1527":79,"1528":9,"1529":100,"1530":9,"1531":121,"1532":9,"1533":143,"1534":9,"1535":164,"1536":9,"1537":186,"1538":9,"1539":207,"1540":9,"1541":229,"1542":9,"1543":251,"1544":10,"1545":17,"1546":10,"1547":39,"1548":10,"1549":61,"1550":10,"1551":84,"1552":10,"1553":106,"1554":10,"1555":129,"1556":10,"1557":152,"1558":10,"1559":174,"1560":10,"1561":197,"1562":10,"1563":220,"1564":10,"1565":243,"1566":11,"1567":11,"1568":11,"1569":34,"1570":11,"1571":57,"1572":11,"1573":81,"1574":11,"1575":105,"1576":11,"1577":128,"1578":11,"1579":152,"1580":11,"1581":176,"1582":11,"1583":200,"1584":11,"1585":225,"1586":11,"1587":249,"1588":12,"1589":18,"1590":12,"1591":42,"1592":12,"1593":67,"1594":12,"1595":92,"1596":12,"1597":117,"1598":12,"1599":142,"1600":12,"1601":167,"1602":12,"1603":192,"1604":12,"1605":217,"1606":12,"1607":243,"1608":13,"1609":13,"1610":13,"1611":38,"1612":13,"1613":64,"1614":13,"1615":90,"1616":13,"1617":116,"1618":13,"1619":142,"1620":13,"1621":169,"1622":13,"1623":195,"1624":13,"1625":222,"1626":13,"1627":248,"1628":14,"1629":19,"1630":14,"1631":46,"1632":14,"1633":73,"1634":14,"1635":100,"1636":14,"1637":127,"1638":14,"1639":155,"1640":14,"1641":182,"1642":14,"1643":210,"1644":14,"1645":238,"1646":15,"1647":9,"1648":15,"1649":37,"1650":15,"1651":65,"1652":15,"1653":94,"1654":15,"1655":122,"1656":15,"1657":150,"1658":15,"1659":179,"1660":15,"1661":207,"1662":15,"1663":236,"1664":16,"1665":9,"1666":16,"1667":38,"1668":16,"1669":67,"1670":16,"1671":97,"1672":16,"1673":126,"1674":16,"1675":155,"1676":16,"1677":185,"1678":16,"1679":215,"1680":16,"1681":245,"1682":17,"1683":19,"1684":17,"1685":49,"1686":17,"1687":79,"1688":17,"1689":109,"1690":17,"1691":140,"1692":17,"1693":170,"1694":17,"1695":201,"1696":17,"1697":232,"1698":18,"1699":7,"1700":18,"1701":38,"1702":18,"1703":69,"1704":18,"1705":100,"1706":18,"1707":132,"1708":18,"1709":163,"1710":18,"1711":195,"1712":18,"1713":227,"1714":19,"1715":3,"1716":19,"1717":35,"1718":19,"1719":67,"1720":19,"1721":99,"1722":19,"1723":131,"1724":19,"1725":164,"1726":19,"1727":197,"1728":19,"1729":229,"1730":20,"1731":6,"1732":20,"1733":39,"1734":20,"1735":73,"1736":20,"1737":106,"1738":20,"1739":139,"1740":20,"1741":173,"1742":20,"1743":206,"1744":20,"1745":240,"1746":21,"1747":18,"1748":21,"1749":52,"1750":21,"1751":86,"1752":21,"1753":120,"1754":21,"1755":155,"1756":21,"1757":189,"1758":21,"1759":224,"1760":22,"1761":3,"1762":22,"1763":38,"1764":22,"1765":73,"1766":22,"1767":108,"1768":22,"1769":143,"1770":22,"1771":178,"1772":22,"1773":214,"1774":22,"1775":250,"1776":23,"1777":29,"1778":23,"1779":65,"1780":23,"1781":101,"1782":23,"1783":137,"1784":23,"1785":174,"1786":23,"1787":210,"1788":23,"1789":247,"1790":24,"1791":27,"1792":24,"1793":64,"1794":24,"1795":101,"1796":24,"1797":138,"1798":24,"1799":175,"1800":24,"1801":213,"1802":24,"1803":250,"1804":25,"1805":32,"1806":25,"1807":69,"1808":25,"1809":107,"1810":25,"1811":145,"1812":25,"1813":183,"1814":25,"1815":221,"1816":26,"1817":4,"1818":26,"1819":42,"1820":26,"1821":81,"1822":26,"1823":119,"1824":26,"1825":158,"1826":26,"1827":197,"1828":26,"1829":236,"1830":27,"1831":20,"1832":27,"1833":59,"1834":27,"1835":99,"1836":27,"1837":138,"1838":27,"1839":178,"1840":27,"1841":218,"1842":28,"1843":2,"1844":28,"1845":42,"1846":28,"1847":82,"1848":28,"1849":123,"1850":28,"1851":163,"1852":28,"1853":204,"1854":28,"1855":245,"1856":29,"1857":30,"1858":29,"1859":71,"1860":29,"1861":112,"1862":29,"1863":153,"1864":29,"1865":195,"1866":29,"1867":236,"1868":30,"1869":22,"1870":30,"1871":64,"1872":30,"1873":106,"1874":30,"1875":148,"1876":30,"1877":190,"1878":30,"1879":233,"1880":31,"1881":19,"1882":31,"1883":62,"1884":31,"1885":105,"1886":31,"1887":148,"1888":31,"1889":191,"1890":31,"1891":234,"1892":32,"1893":21,"1894":32,"1895":65,"1896":32,"1897":108,"1898":32,"1899":152,"1900":32,"1901":196,"1902":32,"1903":240,"1904":33,"1905":28,"1906":33,"1907":72,"1908":33,"1909":117,"1910":33,"1911":161,"1912":33,"1913":206,"1914":33,"1915":251,"1916":34,"1917":39,"1918":34,"1919":85,"1920":34,"1921":130,"1922":34,"1923":175,"1924":34,"1925":221,"1926":35,"1927":10,"1928":35,"1929":56,"1930":35,"1931":102,"1932":35,"1933":148,"1934":35,"1935":194,"1936":35,"1937":240,"1938":36,"1939":31,"1940":36,"1941":77,"1942":36,"1943":124,"1944":36,"1945":171,"1946":36,"1947":218,"1948":37,"1949":9,"1950":37,"1951":56,"1952":37,"1953":104,"1954":37,"1955":151,"1956":37,"1957":199,"1958":37,"1959":247,"1960":38,"1961":39,"1962":38,"1963":87,"1964":38,"1965":135,"1966":38,"1967":183,"1968":38,"1969":232,"1970":39,"1971":24,"1972":39,"1973":73,"1974":39,"1975":122,"1976":39,"1977":171,"1978":39,"1979":220,"1980":40,"1981":13,"1982":40,"1983":63,"1984":40,"1985":113,"1986":40,"1987":162,"1988":40,"1989":212,"1990":41,"1991":6,"1992":41,"1993":56,"1994":41,"1995":107,"1996":41,"1997":157,"1998":41,"1999":208,"2000":42,"2001":2,"2002":42,"2003":53,"2004":42,"2005":104,"2006":42,"2007":155,"2008":42,"2009":207,"2010":43,"2011":2,"2012":43,"2013":54,"2014":43,"2015":105,"2016":43,"2017":157,"2018":43,"2019":209,"2020":44,"2021":5,"2022":44,"2023":57,"2024":44,"2025":110,"2026":44,"2027":162,"2028":44,"2029":215,"2030":45,"2031":12,"2032":45,"2033":65,"2034":45,"2035":118,"2036":45,"2037":171,"2038":45,"2039":225,"2040":46,"2041":22,"2042":46,"2043":76,"2044":46,"2045":130,"2046":46,"2047":183,"2048":46,"2049":238,"2050":47,"2051":36,"2052":47,"2053":90,"2054":47,"2055":145,"2056":47,"2057":199,"2058":47,"2059":254,"2060":48,"2061":53,"2062":48,"2063":108,"2064":48,"2065":164,"2066":48,"2067":219,"2068":49,"2069":18,"2070":49,"2071":74,"2072":49,"2073":130,"2074":49,"2075":186,"2076":49,"2077":242,"2078":50,"2079":42,"2080":50,"2081":99,"2082":50,"2083":155,"2084":50,"2085":212,"2086":51,"2087":13,"2088":51,"2089":70,"2090":51,"2091":127,"2092":51,"2093":184,"2094":51,"2095":241,"2096":52,"2097":43,"2098":52,"2099":101,"2100":52,"2101":158,"2102":52,"2103":216,"2104":53,"2105":19,"2106":53,"2107":77,"2108":53,"2109":135,"2110":53,"2111":194,"2112":53,"2113":253,"2114":54,"2115":55,"2116":54,"2117":114,"2118":54,"2119":174,"2120":54,"2121":233,"2122":55,"2123":36,"2124":55,"2125":96,"2126":55,"2127":156,"2128":55,"2129":215,"2130":56,"2131":20,"2132":56,"2133":80,"2134":56,"2135":140,"2136":56,"2137":200,"2138":57,"2139":5,"2140":57,"2141":66,"2142":57,"2143":127,"2144":57,"2145":188,"2146":57,"2147":249,"2148":58,"2149":54,"2150":58,"2151":116,"2152":58,"2153":178,"2154":58,"2155":239,"2156":59,"2157":45,"2158":59,"2159":107,"2160":59,"2161":170,"2162":59,"2163":232,"2164":60,"2165":39,"2166":60,"2167":101,"2168":60,"2169":164,"2170":60,"2171":227,"2172":61,"2173":34,"2174":61,"2175":97,"2176":61,"2177":161,"2178":61,"2179":224,"2180":62,"2181":32,"2182":62,"2183":96,"2184":62,"2185":160,"2186":62,"2187":224,"2188":63,"2189":33,"2190":63,"2191":97,"2192":63,"2193":162,"2194":63,"2195":226,"2196":64,"2197":35,"2198":64,"2199":100,"2200":64,"2201":166,"2202":64,"2203":231,"2204":65,"2205":41,"2206":65,"2207":106,"2208":65,"2209":172,"2210":65,"2211":238,"2212":66,"2213":48,"2214":66,"2215":114,"2216":66,"2217":181,"2218":66,"2219":247,"2220":67,"2221":58,"2222":67,"2223":125,"2224":67,"2225":192,"2226":68,"2227":3,"2228":68,"2229":71,"2230":68,"2231":138,"2232":68,"2233":206,"2234":69,"2235":18,"2236":69,"2237":85,"2238":69,"2239":154,"2240":69,"2241":222,"2242":70,"2243":34,"2244":70,"2245":103,"2246":70,"2247":171,"2248":70,"2249":240,"2250":71,"2251":53,"2252":71,"2253":123,"2254":71,"2255":192,"2256":72,"2257":5,"2258":72,"2259":75,"2260":72,"2261":145,"2262":72,"2263":215,"2264":73,"2265":29,"2266":73,"2267":99,"2268":73,"2269":169,"2270":73,"2271":240,"2272":74,"2273":55,"2274":74,"2275":125,"2276":74,"2277":196,"2278":75,"2279":12,"2280":75,"2281":83,"2282":75,"2283":154,"2284":75,"2285":226,"2286":76,"2287":42,"2288":76,"2289":114,"2290":76,"2291":186,"2292":77,"2293":2,"2294":77,"2295":74,"2296":77,"2297":147,"2298":77,"2299":220,"2300":78,"2301":37,"2302":78,"2303":110,"2304":78,"2305":183,"2306":79,"2307":0,"2308":79,"2309":73,"2310":79,"2311":147,"2312":79,"2313":221,"2314":80,"2315":39,"2316":80,"2317":113,"2318":80,"2319":187,"2320":81,"2321":6,"2322":81,"2323":80,"2324":81,"2325":155,"2326":81,"2327":230,"2328":82,"2329":49,"2330":82,"2331":124,"2332":82,"2333":199,"2334":83,"2335":19,"2336":83,"2337":95,"2338":83,"2339":170,"2340":83,"2341":246,"2342":84,"2343":66,"2344":84,"2345":143,"2346":84,"2347":219,"2348":85,"2349":40,"2350":85,"2351":117,"2352":85,"2353":194,"2354":86,"2355":15,"2356":86,"2357":92,"2358":86,"2359":169,"2360":86,"2361":247,"2362":87,"2363":68,"2364":87,"2365":146,"2366":87,"2367":224,"2368":88,"2369":47,"2370":88,"2371":125,"2372":88,"2373":203,"2374":89,"2375":26,"2376":89,"2377":105,"2378":89,"2379":184,"2380":90,"2381":7,"2382":90,"2383":86,"2384":90,"2385":166,"2386":90,"2387":245,"2388":91,"2389":69,"2390":91,"2391":149,"2392":91,"2393":229,"2394":92,"2395":53,"2396":92,"2397":134,"2398":92,"2399":214,"2400":93,"2401":39,"2402":93,"2403":120,"2404":93,"2405":201,"2406":94,"2407":26,"2408":94,"2409":108,"2410":94,"2411":189,"2412":95,"2413":15,"2414":95,"2415":97,"2416":95,"2417":179,"2418":96,"2419":5,"2420":96,"2421":87,"2422":96,"2423":170,"2424":96,"2425":252,"2426":97,"2427":79,"2428":97,"2429":162,"2430":97,"2431":245,"2432":98,"2433":73,"2434":98,"2435":156,"2436":98,"2437":240,"2438":99,"2439":67,"2440":99,"2441":151,"2442":99,"2443":235,"2444":100,"2445":64,"2446":100,"2447":148,"2448":100,"2449":233,"2450":101,"2451":61,"2452":101,"2453":146,"2454":101,"2455":231,"2456":102,"2457":61,"2458":102,"2459":146,"2460":102,"2461":232,"2462":103,"2463":61,"2464":103,"2465":147,"2466":103,"2467":233,"2468":104,"2469":63,"2470":104,"2471":150,"2472":104,"2473":236,"2474":105,"2475":67,"2476":105,"2477":154,"2478":105,"2479":241,"2480":106,"2481":72,"2482":106,"2483":159,"2484":106,"2485":247,"2486":107,"2487":79,"2488":107,"2489":167,"2490":107,"2491":255,"2492":108,"2493":87,"2494":108,"2495":175,"2496":109,"2497":8,"2498":109,"2499":96,"2500":109,"2501":185,"2502":110,"2503":18,"2504":110,"2505":107,"2506":110,"2507":196,"2508":111,"2509":30,"2510":111,"2511":120,"2512":111,"2513":209,"2514":112,"2515":43,"2516":112,"2517":134,"2518":112,"2519":224,"2520":113,"2521":58,"2522":113,"2523":149,"2524":113,"2525":240,"2526":114,"2527":75,"2528":114,"2529":166,"2530":115,"2531":1,"2532":115,"2533":93,"2534":115,"2535":184,"2536":116,"2537":20,"2538":116,"2539":112,"2540":116,"2541":204,"2542":117,"2543":40,"2544":117,"2545":133,"2546":117,"2547":225,"2548":118,"2549":62,"2550":118,"2551":155,"2552":118,"2553":248,"2554":119,"2555":86,"2556":119,"2557":179,"2558":120,"2559":17,"2560":120,"2561":110,"2562":120,"2563":204,"2564":121,"2565":42,"2566":121,"2567":137,"2568":121,"2569":231,"2570":122,"2571":70,"2572":122,"2573":165,"2574":123,"2575":4,"2576":123,"2577":99,"2578":123,"2579":194,"2580":124,"2581":33,"2582":124,"2583":129,"2584":124,"2585":225,"2586":125,"2587":65,"2588":125,"2589":161,"2590":126,"2591":1,"2592":126,"2593":98,"2594":126,"2595":194,"2596":127,"2597":35,"2598":127,"2599":132,"2600":127,"2601":229,"2602":128,"2603":71,"2604":128,"2605":168,"2606":129,"2607":10,"2608":129,"2609":107,"2610":129,"2611":205,"2612":130,"2613":48,"2614":130,"2615":146,"2616":130,"2617":244,"2618":131,"2619":87,"2620":131,"2621":186,"2622":132,"2623":29,"2624":132,"2625":128,"2626":132,"2627":227,"2628":133,"2629":71,"2630":133,"2631":171,"2632":134,"2633":14,"2634":134,"2635":114,"2636":134,"2637":215,"2638":135,"2639":59,"2640":135,"2641":159,"2642":136,"2643":4,"2644":136,"2645":105,"2646":136,"2647":206,"2648":137,"2649":51,"2650":137,"2651":153,"2652":137,"2653":254,"2654":138,"2655":100,"2656":138,"2657":202,"2658":139,"2659":48,"2660":139,"2661":150,"2662":139,"2663":252,"2664":140,"2665":99,"2666":140,"2667":202,"2668":141,"2669":49,"2670":141,"2671":152,"2672":141,"2673":255,"2674":142,"2675":102,"2676":142,"2677":206,"2678":143,"2679":54,"2680":143,"2681":158,"2682":144,"2683":6,"2684":144,"2685":110,"2686":144,"2687":214,"2688":145,"2689":63,"2690":145,"2691":168,"2692":146,"2693":17,"2694":146,"2695":122,"2696":146,"2697":227,"2698":147,"2699":77,"2700":147,"2701":182,"2702":148,"2703":32,"2704":148,"2705":138,"2706":148,"2707":244,"2708":149,"2709":95,"2710":149,"2711":201,"2712":150,"2713":52,"2714":150,"2715":159,"2716":151,"2717":10,"2718":151,"2719":117,"2720":151,"2721":224,"2722":152,"2723":76,"2724":152,"2725":184,"2726":153,"2727":36,"2728":153,"2729":144,"2730":153,"2731":252,"2732":154,"2733":104,"2734":154,"2735":213,"2736":155,"2737":66,"2738":155,"2739":175,"2740":156,"2741":28,"2742":156,"2743":137,"2744":156,"2745":247,"2746":157,"2747":100,"2748":157,"2749":210,"2750":158,"2751":64,"2752":158,"2753":174,"2754":159,"2755":29,"2756":159,"2757":139,"2758":159,"2759":250,"2760":160,"2761":105,"2762":160,"2763":216,"2764":161,"2765":71,"2766":161,"2767":182,"2768":162,"2769":38,"2770":162,"2771":150,"2772":163,"2773":6,"2774":163,"2775":118,"2776":163,"2777":230,"2778":164,"2779":86,"2780":164,"2781":199,"2782":165,"2783":56,"2784":165,"2785":169,"2786":166,"2787":26,"2788":166,"2789":139,"2790":166,"2791":253,"2792":167,"2793":110,"2794":167,"2795":224,"2796":168,"2797":82,"2798":168,"2799":196,"2800":169,"2801":55,"2802":169,"2803":169,"2804":170,"2805":28,"2806":170,"2807":143,"2808":171,"2809":2,"2810":171,"2811":117,"2812":171,"2813":233,"2814":172,"2815":92,"2816":172,"2817":208,"2818":173,"2819":68,"2820":173,"2821":184,"2822":174,"2823":45,"2824":174,"2825":161,"2826":175,"2827":22,"2828":175,"2829":139,"2830":176,"2831":0,"2832":176,"2833":117,"2834":176,"2835":234,"2836":177,"2837":96,"2838":177,"2839":214,"2840":178,"2841":75,"2842":178,"2843":194,"2844":179,"2845":56,"2846":179,"2847":174,"2848":180,"2849":37,"2850":180,"2851":156,"2852":181,"2853":19,"2854":181,"2855":138,"2856":182,"2857":1,"2858":182,"2859":121,"2860":182,"2861":240,"2862":183,"2863":104,"2864":183,"2865":224,"2866":184,"2867":89,"2868":184,"2869":209,"2870":185,"2871":74,"2872":185,"2873":194,"2874":186,"2875":59,"2876":186,"2877":181,"2878":187,"2879":46,"2880":187,"2881":167,"2882":188,"2883":33,"2884":188,"2885":155,"2886":189,"2887":21,"2888":189,"2889":143,"2890":190,"2891":10,"2892":190,"2893":132,"2894":190,"2895":255,"2896":191,"2897":122,"2898":191,"2899":245,"2900":192,"2901":112,"2902":192,"2903":236,"2904":193,"2905":103,"2906":193,"2907":227,"2908":194,"2909":95,"2910":194,"2911":219,"2912":195,"2913":88,"2914":195,"2915":212,"2916":196,"2917":81,"2918":196,"2919":206,"2920":197,"2921":75,"2922":197,"2923":200,"2924":198,"2925":70,"2926":198,"2927":195,"2928":199,"2929":65,"2930":199,"2931":191,"2932":200,"2933":61,"2934":200,"2935":188,"2936":201,"2937":58,"2938":201,"2939":185,"2940":202,"2941":56,"2942":202,"2943":183,"2944":203,"2945":54,"2946":203,"2947":182,"2948":204,"2949":53,"2950":204,"2951":181,"2952":205,"2953":53,"2954":205,"2955":181,"2956":206,"2957":54,"2958":206,"2959":182,"2960":207,"2961":55,"2962":207,"2963":184,"2964":208,"2965":57,"2966":208,"2967":186,"2968":209,"2969":60,"2970":209,"2971":190,"2972":210,"2973":63,"2974":210,"2975":193,"2976":211,"2977":68,"2978":211,"2979":198,"2980":212,"2981":73,"2982":212,"2983":203,"2984":213,"2985":78,"2986":213,"2987":209,"2988":214,"2989":85,"2990":214,"2991":216,"2992":215,"2993":92,"2994":215,"2995":224,"2996":216,"2997":100,"2998":216,"2999":232,"3000":217,"3001":108,"3002":217,"3003":241,"3004":218,"3005":118,"3006":218,"3007":251,"3008":219,"3009":128,"3010":220,"3011":5,"3012":220,"3013":138,"3014":221,"3015":16,"3016":221,"3017":150,"3018":222,"3019":28,"3020":222,"3021":162,"3022":223,"3023":41,"3024":223,"3025":175,"3026":224,"3027":54,"3028":224,"3029":189,"3030":225,"3031":68,"3032":225,"3033":204,"3034":226,"3035":83,"3036":226,"3037":219,"3038":227,"3039":99,"3040":227,"3041":235,"3042":228,"3043":115,"3044":228,"3045":252,"3046":229,"3047":132,"3048":230,"3049":13,"3050":230,"3051":150,"3052":231,"3053":31,"3054":231,"3055":169,"3056":232,"3057":50,"3058":232,"3059":188,"3060":233,"3061":70,"3062":233,"3063":208,"3064":234,"3065":91,"3066":234,"3067":229,"3068":235,"3069":112,"3070":235,"3071":251,"3072":236,"3073":134,"3074":237,"3075":17,"3076":237,"3077":156,"3078":238,"3079":40,"3080":238,"3081":180,"3082":239,"3083":64,"3084":239,"3085":204,"3086":240,"3087":88,"3088":240,"3089":229,"3090":241,"3091":114,"3092":241,"3093":255,"3094":242,"3095":140,"3096":243,"3097":25,"3098":243,"3099":167,"3100":244,"3101":52,"3102":244,"3103":194,"3104":245,"3105":80,"3106":245,"3107":222,"3108":246,"3109":109,"3110":246,"3111":251,"3112":247,"3113":138,"3114":248,"3115":25,"3116":248,"3117":168,"3118":249,"3119":56,"3120":249,"3121":199,"3122":250,"3123":87,"3124":250,"3125":231,"3126":251,"3127":119,"3128":252,"3129":7,"3130":252,"3131":152,"3132":253,"3133":41,"3134":253,"3135":186,"3136":254,"3137":75,"3138":254,"3139":220,"3140":255,"3141":109,"3142":255,"3143":255},src:"/_app/assets/ben-mccann-cf-e62380ba.webp"}

Perhaps some of this information could be filtered out? I don't think I'd be likely to use something like this icc property or many of the others and it results in a much larger download size. I really just need the src, width, height, and format.

I admit it's poorly documented, but metadata accepts a whitelist now. So import Ben from '$img/ben-mccann-cf.jpg?format=avif;webp;jpg&meta=src;width;height;format'
Should do the trick

Thanks!!
I wonder if something closer to that should be the default? Then if you want more like icc you could add those. I can't imagine many people use icc from JavaScript. Changing it would both make it a lot easier to call in most cases and also prevent people from accidentally ending up with huge files by forgetting to add the extra parameters

Yeah I was wondering that too, imagetools should be stripping those types of metadata unless you have set removeMetadata to false.

It was indeed a bug, will push a fix soon!

thank you!!


FoundationOverlays / OperationalImagery needs data permissions put on Box

In the Data folder on portal is a FoundationalOverlays folder. In this is an OperationalImagery folder. The data permissions needs to be put on Box.

just a note for the followers of this issue... the spreadsheet is there, but i did not move it, because it is not complete, it currently is only filled out for the landsat.... other data sources, as far as a i can see have not been added to it yet @nfeuerstein @Nekillims

previous comment was nonsense, the spreadsheet was opening up and only showing the last two entries in the spreadsheet.... i didn't realize the other permissions were above them in the part of the table not showing... spreadsheet is moved over.to box. @karlterrey you can verify and close

Verified as fixed. Closed.


Only show on coffeescript files

At the moment the sidebar shows even when I’m editing files in other languages. Would be cool if the sidebar remained hidden unless the language is coffeescript.
Thanks for a great plugin!

@NotBobTheBuilder well this is part of something bigger which is turning coffee-navigator into just navigator with pluggable language support :) I can still add option to hide it when current file isn't supported.

is this still on cards..to have an option to hide the view when current file isnt coffeescript


Data Saturday Johannesburg

eventname
Data Saturday Johannesburg
date
2023-05-13 08:00:00 +02:00
description
Data Saturday Johannesburg is a free full day on volunteer led in person data platform training over various tracks and topics happening at Microsoft in Bryanston, 3012 William Nicol Drive, Bryanston, Johannesburg
The event will kick off at 8am with a keynote address and thereafter split into sessions breaking for lunch and refreshments. The final session and prizegiving will finish by 5pm
Previously year's events ran under the PASS SQL Saturday branding the organisers wanted to me more inclusive of the data community at large and felt that the Data Saturday guise was more accommodating
registrationurl
https://www.meetup.com/johannesburg-data-platform-user-group/events/291022594/
rooms
roomname1;roomurl1,roomname2;roomurl2,roomname3;roomurl3
scheduleurl
No response
sponsors
No response
speakerlisturl
https://sessionize.com/data-saturday-johannesburg3228
volunteerrequesturl
No response
organizers
Michael Johnson;@MikeJohnsonZA;michaelAdrianJohnson@live.com,Warren Rocchi<EMAIL_ADDRESS>

Deployed


How to implement Hooks when using a separate filedconfig file

@aitboudad appreciate all the great work from your side
Question
In my current implementation I have hooks and fieldconfig within the same component.
I am leaning to moving away from that model to separate the fieldconfig into a separate file. This introduces the issue of what to do with the hooks?
Is there a document/thread that covers this scenario?
I did look into the issues / docs, but could not find one. It is also possible that I might have overlooked it.
If yes, can you please share a pointer or provide guidance if what I am thinking is a good practice and how one would go about implementing it?
Thanks in advance for your help.

@aitboudad @juristr
Any updates on this request.
thanks

I tried to make all my events as declarative as possible, to use in the most common scenarios, for example the parent/child fields I created a parent array in the child component and after I load the json I make all of the connections

I did something like this
{
        "key": "SubTipo",
        "type": "multiselect",
        "className": "col-6",
        "templateOptions": {
          "label": "SubTipo",
          "required": true,
          "textField": "Descricao",
          "valueField": "Id",
          "textOrder": "asc",
          "primitive": false,
          "filterable": true,
          "minFilter": 1,
          "filterOperator": "contains",
          "parents": [
            {

              "key": "Tipo",
              "field": "Tipo.Id",
              "multiple": false,
              "primitive": false,
              "valueField": "Id",
              "operator": "eq",
              "observable": null,
              "relativeTo": 0
            }
          ]
        }
      }

and this code
public loadOptions(field: FormlyFieldConfig) {
    if (!field?.templateOptions?.parents?.length) {
      this.setOptionsValues(field,[]);
    }
    else {
      for (let i = 0; i < field.templateOptions.parents.length; i++) {
        const parent = field.templateOptions.parents[i];
        const form = this.GetFormGroup(field, parent);
        if (form) {
          const parentForm = form.get(parent.key);
          parent.observable = parentForm.valueChanges.pipe(
            distinctUntilChanged((x, y) => { return Object.is(JSON.stringify(x), JSON.stringify(y)); }),
            map((value) => { return { value: value, start: false }; }),
            takeUntil(this.Component.Destroy$),
            startWith({ value: parentForm.value, start:true }))
            .subscribe((value) => {

              this.setOptionsValues(field, []);
              if (!value.start) {
                field.formControl.setValue(null);
              }
            });
        }
      }
    }
  }

  private InitFields(fields: FormlyFieldConfig[]) {
      for (let i = 0; i < fields.length; i++) {
        fields[i].hooks = {
          onInit: field => this.Extensions.loadOptions(field)
        };
        if (fields[i]?.templateOptions?.filterable ?? false) {
            fields[i].templateOptions.filter = (field: string, operator: string, value: string) => {
              if (field && field.length > 0) {
                this.Extensions.filterOptions(fields[i], [{ operator, field, value }]);
              }
              else {
                this.Extensions.filterOptions(fields[i], []);
              }
            };
          }
          if (fields[i].fieldGroup) {
            this.InitFields(fields[i].fieldGroup);
          }
          if (fields[i].fieldArray && fields[i].fieldArray.fieldGroup) {
            this.InitFields(fields[i].fieldArray.fieldGroup)
          }
        }
    }

what do you think? @aitboudad

if your form is defined in a JSON file

you may check our demo example https://formly.dev/examples/other/json-powered which uses a map function to adjust the loaded JSON form.

if your form is defined in Ts File

I would recommend defined a function that returns the fields config and pass the form dependencies through the function arguments:
export function loginFormConfig(...) {
  return [
    { key: 'email', ... },
    { key: 'password', ... },
  ];
}

if your form is defined in a JSON file

you may check our demo example https://formly.dev/examples/other/json-powered which uses a map function to adjust the loaded JSON form.

if your form is defined in Ts File

I would recommend defined a function that returns the fields config and pass the form dependencies through the function arguments:
export function loginFormConfig(...) {
  return [
    { key: 'email', ... },
    { key: 'password', ... },
  ];
}

@aitboudad
Thanks for the pointer, I will try the json-powered way and let you know if I run into issues.

@aitboudad
Thanks for the pointer, I will try the json-powered way and let you know if I run into issues.

Uhm excuse me, I don't have a solution for this problem you're having, BUT you spelled fieldconfig wrong...

I recognize that this might be a challenging issue, but this seems like an inelegant solution for JSON powered forms. The common use case of needing to persist these in JSON, but then subsequently having to hard-code adjustments in client side to make the JavaScript (Ex. Hooks) usable is not good design. Hopefully this can be improved in the future, thanks for your consideration


Merge pull request #3 from colleenpridemore/main

Merge pull request #1 from colleenpridemore/colleenpridemore-patch-1

This was done in error and I"m not sure how to fix.  Little help?


Added support for SPARQL language

This is the support for SPARQL based on the W3C SPARQL specifications
https://www.w3.org/TR/sparql11-query/
All of the queries from the specifications are included in the tests and as examples.

Thank you for this PR @thomasdegroot18!
Before I'll review this, a few minor things:

Please move sparql below soy. The list is sorted alphabetically.
We use tabs for indentation. This is true for all files: .html, .js, .test.
Please remove the g flags from all patterns. Prism will add a g if it has to.
Travis failed because you forgot to rebuild Prism. Run npx gulp to rebuild Prism.

I'll properly review your PR soon.

Thanks for the quick comments.
I've updated the location, changed everything in tabs now, removed the g flags and reran npx gulp.
Thanks for the update.

After checking it, the SPARQL spec and the turtle spec are a bit to diverged to extend one onto the other. Due to most of the changes to both of the specs, both are similar but differ quite a lot in the basics.
I've updated the code with the comments about the quotes and the array.

While it's true that SPARQL and Turtle don't share a lot when it comes to semantics, their syntax is quite similar on purpose:

Most forms of SPARQL query contain a set of triple patterns called a basic graph pattern. Triple patterns are like RDF triples except that each of the subject, predicate and object may be a variable. (source)

Turtle provides levels of compatibility with the N-Triples [N-TRIPLES] format as well as the triple pattern syntax of the SPARQL W3C Recommendation. (source)

Also, extending in Prism doesn't have any strict definitions or restrictions. It's just a way to share common patterns and structures between language definitions. I suggested extending from Turtle because both language definitions seem very similar and because extending generally reduces redundancy across language definitions and the overall bundle size of Prism.
The only differences between Turtle and SPARQL that I see are the actual syntactical differences (new (e.g. variable) and drastically changed (e.g. keyword) patterns) and small differences where you abided to spec more closely than I and the author of #2012 did (e.g. iri) and where you didn't quite adhere to the spec (e.g. string).
I'll make an update to make Turtle adhere to its spec more closely and to fix a few small mistakes I found.

Thanks for the update, I will update the code accordingly and update the pull request.

Thank you for contributing!


Add Support for Per Actor Type Configuration

Describe the proposal
The Dapr Runtime added support for per actor type configurations in 1.7. This support needs to be added to the SDKs.
The new configuration looks like:
{
  "entities":["actorType1", "actorType2"],
  "actorIdleTimeout": "1h",
  "actorScanInterval": "30s",
  "drainOngoingCallTimeout": "30s",
  "drainRebalancedActors": true,
  "reentrancy": {
    "enabled": true,
    "maxStackDepth": 32
  },
  "entitiesConfig": [
      {
          "entities": ["actorType1"],
          "actorIdleTimeout": "1m",
          "drainOngoingCallTimeout": "10s",
          "reentrancy": {
              "enabled": false
          }
      }
  ]
}

Implementation can be varied per SDK but should output to the above JSON.
Docs: https://github.com/dapr/docs/pull/2334
Runtime: https://github.com/dapr/dapr/pull/4201

/assign

/assign

Fixed in https://github.com/dapr/java-sdk/pull/914

/assign


cigien: Watch blockchaindownload.store

cigien requests the watch of the watch_keyword blockchaindownload\.store. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

blockchaindownload\.store has been seen in 1 true positive, 0 false positives, and 0 NAAs.

blockchaindownload\.store has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by double-beep in Charcoal HQ

Approved by double-beep in Charcoal HQ


--override-spec not overriding lambda runtime versions

CloudFormation Lint Version
0.86.0
What operating system are you using?
Mac
Describe the bug
I'm trying to provide custom specs for E2531 via the --override-spec command, however the custom specs i am adding which are copied from https://github.com/aws-cloudformation/cfn-lint/blob/main/src/cfnlint/data/AdditionalSpecs/LmbdRuntimeLifecycle.json this file are not being used.
Weirdly if i add a custom spec file linked in the docs here:
{
  "IncludeResourceTypes": [
    "AWS::EC2::*"
  ],
  "ExcludeResourceTypes": [
    "AWS::EC2::SpotFleet"
  ]
}

This works and produced linting errors/warnings, which leads me to belive the spec file must be wrong for the runtime versions?
Expected behavior
When i pass an overriden spec, i expect those overrides to be utilised by cfn-lint.
Reproduction template
  Lambda:
    Type: AWS::Serverless::Function
    Properties:
      Architectures:
        - arm64
      AutoPublishAlias: live
      CodeUri: build/
      Handler: index.handler
      Runtime: nodejs18.x
      Tracing: Active
      Timeout: 20
      MemorySize: 256
      Environment:
        Variables:
          IOT_ENDPOINT:
            !FindInMap [Mappings, !Sub '${AWS::Region}.${AccountDataType}.${SSMParamAccountType}', iotEndpoint]
          QUALIFIER: !Ref Qualifier
      Policies:
        - Statement:
            - Effect: Allow
              Action:
                - iot:Publish
              Resource:
                - !Sub 'arn:aws:iot:${AWS::Region}:${AWS::AccountId}:topic/$aws/rules/telemetry_${Qualifier}/*'
      Events:
        Schedule:
          Type: Schedule
          Properties:
            Schedule: rate(1 minute)

Custom spec file:
{
  "nodejs18.x": {
    "deprecated": "2020-08-30",
    "eol": "2020-07-30",
    "successor": "nodejs20.x"
  }
}

(Sorry, --override-spec isn't a well-trodden feature, and AdditionalSpecs/ contains separate formats not intended for it)

Beyond individual overriding, everyone'll benefit from upstreaming Lambda runtime deprecation updates: https://github.com/aws-cloudformation/cfn-lint/pull/3116

-z / --custom-rules seems easier than --override-spec if you're deprecating runtimes before AWS

thanks @PatMyron ! Good to see that PR in flight, any idea when that will land?

The PR has been merged and released.

Awesome I'll close this 😀


[icp_node-2] process has died [pid 14603, exit code -6

Hi,
Anyone know how to solve this error ?
localizer_node: /usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h:118: Eigen::DenseCoeffsBase<Derived, 0>::CoeffReturnType Eigen::DenseCoeffsBase<Derived, 0>::operator()(Eigen::Index, Eigen::Index) const [with Derived = Eigen::Matrix<float, -1, -1>; Eigen::DenseCoeffsBase<Derived, 0>::CoeffReturnType = const float&; Eigen::Index = long int]: Assertion `row >= 0 && row < rows() && col >= 0 && col < cols()' failed.
No handlers could be found for logger "roslaunch"
[icp_node-2] process has died [pid 14603, exit code -6
Thank you.

Hi barkindagda,
did you build in Debug or Release mode?

Hi jelavice,
I built by using catkin_make_isolated command.

can you try to run this command (this will build it in release mode), and then recompile
catkin config -DCMAKE_BUILD_TYPE=RelWithDebInfo

(it's a workaround)

could you prepare a docker file where I could reproduce the error?

Hi jelavice,
If you have ROS melodic or higher version handy, it may be quicker for me to send the package itself ? If not, I will try to prepare a docker file.
Many Thanks.

Is it solved?

hi,I'm having the same problem, what should I do to fix it

are you simply running
roslaunch icp_localization icp_node_rosbag.launch
with the example bags provided by us?

hi @nubertj , I have also faced this issue. i am running in ROS Noetic Docker container with CARLA simulator. Map was created using FASTLIO-SAM and the pcd saved was provided to icp_localization.

I have the same problem , localizer_node: /usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h:117: Eigen::DenseCoeffsBase<Derived, 0>::CoeffReturnType Eigen::DenseCoeffsBase<Derived, 0>::operator()(Eigen::Index, Eigen::Index) const [with Derived = Eigen::Matrix<float, -1, -1>; Eigen::DenseCoeffsBase<Derived, 0>::CoeffReturnType = const float&; Eigen::Index = long int]: Assertion `row >= 0 && row < rows() && col >= 0 && col < cols()' failed.

@zwk0901  were you able to resolve?

@zwk0901 were you able to resolve?

Sorry, I still haven't been able to solve this problem.