No -n option for compiling

https://github.com/aeternity/tutorials/blob/master/build-to-do-list-aepp-1.md#compiling-the-contract
→ forgae compile -n testnet

error: unknown option `-n'

Additionally without -n it fails as compiler is not yet started

cleaning up the repo now by making a new branch and updating most important tutorials. this issue won't be considered


Angular 7 and ng-library support

Note: for support questions, please use one of these channels: Chat: AngularClass.slack or Twitter: @TipeIO

I'm submitting a ...
[ ] bug report
[x] feature request
[ ] question about the decisions made in the repository

Do you want to request a feature or report a bug?
Angular 7 support and libraries

What is the current behavior?
There is not support

What is the motivation / use case for changing the behavior?
The base is already outdated, avoid the angular-cli dependency because of the libraries,

Please tell us about your environment:

Angular version: n/a
Browser: n/a

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

@Uter1007 sure, I suppose that is just increase the number but there is not support for libraries

Hi guys, is there a due date for this? is this repository currently maintained? I saw a lot of pull request just there without attention.

@Uter1007 did you had to adapt any of the code for it to work on angular 7? have you tried 8? I'm getting the types errors for rxjs
node_modules/rxjs/internal/types.d.ts(81,44): error TS1005: ';' expected.

Any update on this? I'm on Angular 6 and getting it. Using rxjs version ^6.5.3.

I fixed this by changing "typescript": "~2.7.2" to "typescript": "~2.8"


nccopy variable subsetting via OPeNDAP and global variables

OSX 10.12
netCDF library version <IP_ADDRESS> of Feb 23 2017 13:31:18 (Homebrewed)
When I do: $ nccopy https://cida.usgs.gov/thredds/dodsC/new_gmo?longitude[0:1:461],latitude[0:1:221],time[0:1:22644] out.nc
I get:
$ ncdump -h out.nc
netcdf out {
dimensions:
	latitude = 222 ;
	longitude = 462 ;
	time = 22645 ;
variables:
	float longitude(longitude) ;
		longitude:long_name = "Longitude" ;
		longitude:units = "degrees_east" ;
		longitude:standard_name = "longitude" ;
		longitude:axis = "X" ;
		longitude:bounds = "longitude_bnds" ;
	float latitude(latitude) ;
		latitude:long_name = "Latitude" ;
		latitude:units = "degrees_north" ;
		latitude:standard_name = "latitude" ;
		latitude:axis = "Y" ;
		latitude:bounds = "latitude_bnds" ;
	double time(time) ;
		time:units = "days since 1940-01-01 00:00:00" ;
		time:calendar = "standard" ;

// global attributes:
// (expected global attributes removed to be concise)
		:pr.units = "mm/d" ;
		:pr._FillValue = 1.e+20f ;
		:pr.long_name = "Precipitation" ;
		:tas.units = "C" ;
		:tas._FillValue = 1.e+20f ;
		:tas.long_name = "Average Temperature" ;
		:tasmax.units = "C" ;
		:tasmax._FillValue = 1.e+20f ;
		:tasmax.long_name = "Maximum Temperature" ;
		:tasmin.units = "C" ;
		:tasmin._FillValue = 1.e+20f ;
		:tasmin.long_name = "Minimum Temperature" ;
		:wind.units = "m/s" ;
		:wind.axis = "TYX" ;
		:wind.missing_value = 1.00000002004088e+20 ;
		:wind.associate = "time latitude longitude" ;
		:wind.long_name = "Wind Speed" ;
}

Should the variables and attributes that were not requested be showing up as global attributes? Adding the -v or -V options with those variables listed doesn't affect the output.

Hi, sorry for the delay responding. The output you're seeing is correct.  From the ncdump man page:
Show only the header information in the output, that is, output only the  declarations
for the dimensions, variables, attributes, groups, and user-defined types of the input
file, but no data values for any variables.  The output is identical to using  the  -c
option  except that the values of coordinate variables are not included.  (At most one
of -c or -h options may be present.)

I hope this answers your question!

Sorry, I wasn't clear the problem I'm pointing out. The nccopy command should not have included the global attributes I included above.
I should have said "Should the variables and attributes that were not requested in the nccopy command be showing up as global attributes? Adding the -v or -V options with those variables listed doesn't affect the output."
Have a look at the OPeNDAP endpoint: https://cida.usgs.gov/thredds/dodsC/new_gmo.info
The global attributes I get back from nccopy are actual variables and the variables' attributes that I did not ask for.

@WardF - Not sure if you can re-open this... should I create a new ticket?

My mistake thanks for clarifying! I'll reopen and revisit in the morning.

@dblodgett-usgs No need, I reopened this one. :).

@DennisHeimbigner Can you weigh in on this? I missed the subsetting that I now see in the nccopy request.  I don't know if this is expected behavior without doing a bit of research and I feel like you might know if this is how nccopy/subsetting is supposed to work off the top of your head :).

In the past, the request would just subset the actual global variables and the variables requested using OPeNDAP subsetting syntax. It is now adding the other variable (that I don't want) names and attributes as global attributes.

ok, Let me look at it.
=Dennis
On 3/9/2017 9:45 AM, Ward Fisher wrote:

@DennisHeimbigner https://github.com/DennisHeimbigner Can you weigh in
on this? I missed the subsetting that I now see in the nccopy request. I
don't know if this is expected behavior without doing a bit of research
and I feel like you might know if this is how nccopy/subsetting is
supposed to work off the top of your head :).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/netcdf-c/issues/373#issuecomment-285407761,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3P28k7BcX3J3LoykxLGBLhlDNbOvjUks5rkCylgaJpZM4MRjcO.

If you stick this into your browser
https://cida.usgs.gov/thredds/dodsC/new_gmo.das?longitude[0:1:461],latitude[0:1:221],time[0:1:22644]
you will see that the server is sending back attributes for non-requested variables like 'pr'.
The netcdf-c opendap code converts such "unattached" attributes to global ones, which is why you
are seeing those extra global attributes.
So, the real issue is: why is the server sending back those extra attributes.  Since this is apparently
a thredds server issue  I need to transfer this issue over there. I will do so and add a comment here
pointing to the new issue.

I have created issue  https://github.com/Unidata/thredds/issues/774
on the thredds repo to continue this problem.

Interesting. This is definitely different behavior than we used to get. This is a technique we've been using for a long time. Not sure if THREDDS or nccopy changed, but I guess you guys see what's up and can advise if I should change how I use nccopy or if it's an issue that should be fixed in THREDDS. Thanks!

I am trying to fix it, although the legacy opendap code is making this hard.
Looking at the code, I would have guessed that it has always been this way.

@dblodgett-usgs Can you say with any certainty what old version you used that had different behavior? If not no worries, I can step back through versions, but it would take the guess work out of figuring out what changed in netCDF and/or is this netCDF or Thredds.

We have nccopy on one of our cent OS machines... netCDF library version <IP_ADDRESS> of Apr 15 2015 15:18:07 $ I do NOT get the extra global variables with that version.

As far as I can tell, the problem should be on the server. Are you accessing the same URL?
If so, I am baffled.

Exactly the same request, yeah. If that old OPeNDAP code hasn't changed, maybe the C code was smart and worked around this before? Variable subsetting was added to nccopy recently right?
On March 9, 2017 9:50:21 PM CST, DennisHeimbigner<EMAIL_ADDRESS>wrote:

As far as I can tell, the problem should be on the server. Are you
accessing the same URL?
If so, I am baffled.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/Unidata/netcdf-c/issues/373#issuecomment-285566166

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Turns out this "feature" was added in response to a user issue:
https://github.com/Unidata/netcdf-c/issues/152
and was implemented by pull request:
https://github.com/Unidata/netcdf-c/pull/164
Looks like I need to modify the added code to be a little smarter.

Fixed by pull request https://github.com/Unidata/netcdf-c/pull/376


I'm not sure fetch_obs_info as a separate user-callable method makes sense

It has to be run for the instance of a mission to work, why is it user facing?

@jessicapilling you'll need to change the eROSITACalPV class to this as well.


Fix Docker compose containers not staying up

When running ./deploy-edgeX.sh some of the containers exit. These problems are due to misconfiguration for disabling security for the non-security related blackbox tests.

This was created as part of #282

Ignore this issue. This work will be tracked and addressed in #282


Documentation Sprint

This issue is to document our progress about the documentation.
Sure! Here's the updated table with an additional "reviewed" column:

Filename
Pull Request
In Charge
Reviewed

api/alias_generators.md

api/color.md

api/config.md

api/dataclasses.md

api/errors.md

api/fields.md

api/functional_serializers.md

api/functional_validators.md

api/json_schema.md

api/main.md

api/mypy.md

api/networks.md

api/pydantic_core_init.md

api/pydantic_core_schema.md

api/type_adapter.md

api/types.md

api/validate_call.md

errors/errors.md

index.md

install.md

integrations/datamodel_code_generator.md

integrations/devtools.md

integrations/hypothesis.md

integrations/mypy.md

integrations/pycharm.md

integrations/rich.md

integrations/visual_studio_code.md

migration.md

usage/computed_fields.md

usage/conversion_table.md

usage/dataclasses.md

usage/errors.md

usage/exporting_models.md

usage/model_config.md

usage/models.md

usage/postponed_annotations.md

usage/pydantic_settings.md

usage/schema.md

usage/types/booleans.md

usage/types/bytesize.md

usage/types/callables.md

usage/types/custom.md

usage/types/datetime.md

usage/types/dicts_mapping.md

usage/types/encoded.md

usage/types/enums.md

usage/types/extra_types/color_types.md

usage/types/extra_types/payment_cards.md

usage/types/file_types.md

usage/types/json.md

usage/types/list_types.md

usage/types/number_types.md

usage/types/secrets.md

usage/types/sequence_iterable.md

usage/types/set_types.md

usage/types/standard_types.md

usage/types/string_types.md

usage/validation_decorator.md

usage/validation_errors.md

usage/validators.md

Going beyond the table above — I think each of the "leaf" bullets in the following markdown need to be done:
# Update existing documentation files:
* Landing Page
    * index.md

* Installation
    * install.md

* API docs - create file for all public modules missing file in `docs/api`

* Docstrings
    * Establish and document the requirements for public module docstrings in the contribution guidelines
    * Establish and document the requirements for internal module docstrings in the contribution guidelines

    * Ensure public docstrings meet the requirements:
        * alias_generators.py
        * color.py
        * config.py
        * dataclasses.py
        * errors.py
        * fields.py
        * functional_serializers.py
        * functional_validators.py
        * json_schema.py
        * main.py
        * mypy.py
        * networks.py
        * type_adapter.py
        * types.py
        * validate_call.py
        * version.py

    * Ensure private docstrings meet the requirements:
        * _internal/_annotated_handlers.py
        * _internal/_config.py
        * _internal/_core_metadata.py
        * _internal/_dataclasses.py
        * _internal/_decorators.py
        * _internal/_decorators_v1.py
        * _internal/_discriminated_union.py
        * _internal/_fields.py
        * _internal/_forward_ref.py
        * _internal/_generate_schema.py
        * _internal/_generics.py
        * _internal/_internal_dataclass.py
        * _internal/_known_annotated_metadata.py
        * _internal/_model_construction.py
        * _internal/_repr.py
        * _internal/_schema_generation_shared.py
        * _internal/_std_types_schema.py
        * _internal/_typing_extra.py
        * _internal/_utils.py
        * _internal/_validate_call.py
        * _internal/_validators.py

* Errors
    * errors/errors.md

* Integrations
    * integrations/datamodel_code_generator.md
    * integrations/devtools.md
    * integrations/hypothesis.md
    * integrations/mypy.md
    * integrations/pycharm.md
    * integrations/rich.md
    * integrations/visual_studio_code.md

* Migration
    * migration.md

* Usage
    * usage/computed_fields.md
    * usage/conversion_table.md
    * usage/dataclasses.md
    * usage/errors.md
    * usage/exporting_models.md
    * usage/model_config.md
    * usage/models.md
    * usage/postponed_annotations.md
    * usage/pydantic_settings.md
    * usage/schema.md
    * usage/types/booleans
    * usage/types/bytesize
    * usage/types/callables
    * usage/types/custom
    * usage/types/datetime
    * usage/types/dicts_mapping
    * usage/types/encoded
    * usage/types/enums
    * usage/types/extra_types
    * usage/types/extra_types
    * usage/types/file_types
    * usage/types/json
    * usage/types/list_types
    * usage/types/number_types
    * usage/types/secrets
    * usage/types/sequence_iterable
    * usage/types/set_types
    * usage/types/standard_types
    * usage/types/string_types
    * usage/validation_decorator.md
    * usage/validation_errors.md
    * usage/validators.md

# Improve documentation of previously-existing functionality

* Config inheritance in subclasses (https://github.com/pydantic/pydantic/issues/1019)
* BaseModel.model_construct (see https://github.com/pydantic/pydantic/issues/3471#issuecomment-1528162198)
* Non-hashable defaults get deepcopied during model instantiation (e.g., `x: list = []`)
* Document that we copy some things, and leave something unchanged (?? @adriangb)

# Document new functionality

* Serialization decorators
	* @field_serializer, @model_serializer, @computed_field

* Other serialization improvements
	* functional serializers (`Annotated[MyType, PlainSerializer(...)]`, etc.)
	* mode='json'

* TypeAdapter
	* Search issues for AnalyzedType, and convert to TypeAdapter

* RootModel

* JSON schema
	* Validation vs. Serialization
	* Subclassing `GenerateJsonSchema`

* Strict mode

* Custom Types
	* __get_pydantic_core_schema__, __get_pydantic_json_schema__, __prepare_pydantic_annotations__
	* using annotations to integrate with third-party types (see https://github.com/pydantic/pydantic/pull/5620)
	* creating custom generic containers (see https://github.com/pydantic/pydantic/issues/4161#issuecomment-1527960500 and https://github.com/pydantic/pydantic/issues/2274#issuecomment-1528082601)

* Validation context
	* Also, use in __init__ by way of a ContextVar (see https://github.com/pydantic/pydantic/issues/1549#issuecomment-1526632046)

* "Wrap"-mode validator decorators

* Special generic annotations in pydantic.types
	* SkipValidation, InstanceOf, TransformSchema, etc.

* New things in pydantic.fields.Field
	* E.g., validation_alias, serialization_alias

* `from_attributes` as a validation time parameter

* Recursive models cyclic reference detection

* AliasPath and AliasChoices

# Update the migration guide

(Maybe add to PR https://github.com/pydantic/pydantic/pull/6006)

* Generic protocol annotations may not preserve original type in some scenarios (see: https://github.com/pydantic/pydantic/pull/5744/files#r1191552815)
	* We guarantee validity of the output type, not preserving the input type

* __fields__ and __validators__ have been removed (see https://github.com/pydantic/pydantic/issues/5694)

* Generics improvements
	* Handling of generic dataclasses and TypedDict
	* Removal of GenericModel
	* Automatic model_rebuild for recursive models (generic or not)

* Serialization reflects type schema, rather than "duck typing" (can override with SerializeAsAny or whatever, as @adriangb suggested)

# Document backwards-compatibility promises

* Document the set of things we reserve the right to change in minor releases (e.g., error message text)


Remove default vnet and route table creation when using Azure CNI.

Remove default vnet and route table creation when using Azure CNI.
This is the change in ACS-E side. Verified in manual test.

@JunSun17 you might want to rebase to see the newly added unit test coverage diff

What's the high level intention here?

@jackfrancis The intention here is when custom brings their own vnet/subnet, ACS-E should not create a default vnet/subnet.

@JunSun17 so currently, there is an identified bug that an "extra" vnet is created and left empty in the resource group for "bring your own VNET" cluster creation scenarios?
Is this bug observed in Azure CNI only, or also for kubenet network plugin flows?

@jackfrancis Yes, it is an existing issue for both Azure CNI and kubenet when custom brings in their own vnet/subnet.

@JunSun17 FYI I rebased to fix master merge conflict
Will merge when we have an lgtm from AKS rep

@jackfrancis Thanks! I need to make more changes on this PR, will let you know when it is ready for merge.

Please do not merge this yet, will do more testing and update when it is ready to merge.


Supabase Auth JS not working in local development

Bug report
Describe the bug
Im getting Preflight response is not successful. Status code: 301, Error: load failed in Safari, and I'm getting Access to fetch at 'http://************.supabase.co/auth/v1/token?grant_type=password' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
Im assuming its a CORS problem but I don't know how to go about it.
It works once I've hosted the project to vercel however.
To Reproduce

Install next js 13
Add supabase next js auth helper and supabase js
Use supabase on the client side with supabase auth helper based on supabase documentation.
do a login command in local development

Expected behavior
Be able to login In local development.
System information

Browser (if applies) [e.g. chrome, safari]: chrome, safari
Version of supabase-js: 2.1.0
Next js: 13.06

Additional context
This happened out of nowhere while i was changing something unrelated in local development. It logged me out and I suddenly couldn't log in.
Also experiencing this error on the client but I tried using the server with TRPC and it's still not working in local development.

Changing the supabase url from "http" to "https" in my .env solved the problem for me.


Skip reading files with incorrect extension

Closes https://github.com/NVIDIA/NeMo-Curator/issues/214.

We might need to expand the list of extensions since some files are format like .json.gz.
I wonder if an alternative could be to expand get_all_files_paths_under to also filter on an extension. That way users can specify what extension they want to filter on.
I'm hoping that #50 will make things easier in this regard.

Thanks @ayushdg. I like your idea of having it in get_all_files_paths_under so I changed it to use that instead.

Thanks @ayushdg ! Updated.

Thank you @praateekmahajan ! I have addressed all your comments.


Make a proper WeaveUnit class

A WeaveUnit class already exists - it's just a data container though. Change get_weave_unit to its constructor, add a plot function, make it produce some stats (area of coverage, relative areas of different strands, etc.

When a WeaveUnit is instantiated this would be a good place to catch any issues with the margin and aspect settings -- validate them as consistent and issue warnings or advice (see the R code where this was started). See also #4


[auto-bump] dependency by VinaiRachakonda

:coffee: An Automated Dependency Version Bump PR :crown:
Initial Changes
The initial changes contained in this PR were produced by go geting the dependency.
$ cd ./go
$ go get -u github.com/dolthub/<dependency>/go@<commit>

Before Merging
This PR must have passing CI and a review before merging.
Please ensure thego tests all pass successfully. If they do not, please implement the fixes
and re-run CI go tests until they do.
After Merging
An automatic PR will be opened against the LD repo that bumps the bounties version there.

This PR has been superseded by https://github.com/dolthub/bounties/pull/43


Updated astranaut version

@rultor release, tag is 0.1.3

@rultor release, tag is 0.1.3

@pollyvolk OK, I will release it now. Please check the progress here

@rultor release, tag is 0.1.3

@pollyvolk Done! FYI, the full log is here (took me 7min)


[IMPROVEMENT PROPOSAL] Upgrade python 2 to python 3

Is the issue already present in https://github.com/cloudera/hue/issues or discussed in the forum https://discourse.gethue.com?
No
Describe the bug:
Currently hue is using pyhton 2.7 and which has reached it EOL. It would be recomended to use python 3 for the entire project
Challanges :-
Hue uses many 3rd party libraries / packages which are cloned first and then build using makeFile. This breaks the alligment with the OSS version of those 3rd party libraries and makes the upgrade of those libraries difficult
e.g :- pysqlite , sasl-0.1.1 etc
Steps to reproduce it?
NONE / IMPROVEMENT PROPOSAL
Hue version or source? (e.g. open source 4.5, CDH 5.16, CDP 1.0...). System info (e.g. OS, Browser...).
HUE-VERSION-4.10, LINUX
can community help upgrading to python3. We are eager to work on this changes !
cc: @divincode

@Harshg999 @romainr .

Please sugest and help with your valuable thoughts ?

[curious query]

is this upgrade already on the pipeline ?

Hi @Samrat002, thank you for your questions!
Hue supports both Python2.7 and Python3 for sometime now. Previously supported Py3.6+ and now currently pegged to Py3.8 and future plan is to support Py3.9+ too.
Here is the list of package dependencies for different supported OS: https://docs.gethue.com/administrator/installation/dependencies/#os-packages
On the same page you can find more info for choosing Hue DB or the steps to build Hue (check MacOS section) via Python3.
Python3.8 CI checks (including ARM) for all PRs build Hue via its docker image, you can check the CircleCI or Github Action workflows in the repo for the same.
PR contributions are always welcomed!
Hope it helps!

Thanks @Harshg999 for redirecting to correct path !


Pass index to slot of Svelte VList

Any plans to pass index to slot in Vue implementation? We really need this feature in Vue!

I created an issue for it. Probably it will require a breaking change but it's ok.


Are the results of cifar10(resnet18) on msp odin energy and other methods are presented by the Pre-trained Model ResNet18_cifar10 in Pre-trained Models?

Are the results of cifar10(resnet18) on msp odin energy and other methods are presented by the Pre-trained Model ResNet18_cifar10 in Pre-trained Models?
I loaded the ResNet18_cifar10 weight from Pre-trained Models, but the results were different from those given in the paper.The results of my testing of ResNet18_cifar10 from Pre-trained Models are as follows:

We obtain the results for the different uncertainty estimation models using the pre-trained models provided. To do this, we use the implementations provided in the respective papers and the datasets listed in our paper.
You must ensure that you use the same test data for your evaluation.


Update document to the new platform.

All management are made now in the power platform administration center. This documentation is no longer valid.

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

ID: 984f5f38-9eea-ec47-f8e1-77be40e4ca57
Version Independent ID: 95ad777a-3d17-e24b-9e54-959db1b5df1f
Content: Find and apply updates to core and shared solutions (Dynamics 365 Marketing)
Content Source: ce/marketing/apply-updates.md
Service: dynamics-365-marketing
GitHub Login: @alfergus
Microsoft Alias: alfergus

Thank you, @leonardomizikami. This is on our radar and updated documentation is in progress.


logrep ommiting lines when no filter applied

Hello - I have an access log that contains ~42mil entries.  Using the command logrep -o cc,ip,ts,year,month,day,hour,minute,method,url,status,ref,refdom,ua access.log_all > access_logs_prepped, I intended to create a file containing all entries, but formated witht the logrep output.
The file access_logs_prepped contains 1,126 fewer lines than access.log_all.  Since I didn't apply a filter, I would expect the line count to be the same.  Does logrep contain options that can help account for this discrepency?

Is it possible that the access log contains invalid entries (ex. incomplete lines introduced during log rotation)?
Have you tried invoking it with -d and piping stdout to /dev/null to see if there are any helpful errors?


chore: Fixes failing spec, Uses a different template

Description
Marking dashboard is causing problems repeatedly, using another template(Vehicale maintenence app) - as this spec should be template agnostic.
PR fixes following issue(s)
Fixes # (issue number)
Type of change

Bug fix (non-breaking change which fixes an issue)
Chore (housekeeping or task changes that don't impact user perception)

Testing
How Has This Been Tested?

[x] Cypress

Test Plan
Issues raised during DP testing
Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test


Remove TF dependency from Strawberry Fields

Description of the Change:

Removes TF from setup.py (it is install in requirements.txt for our continuous integration).

Adds a try-except for tensorflow import in parameters.py. If there is an ImportError, the module tf is simply mocked out.

Added TensorFlow import logic and a useful exception message to the TFBackend, that checks whether TensorFlow is installed and is the correct version. If not, information is given to the user on how to install SF with TensorFlow support.

Benefits:

Strawberry Fields will now install and run correctly without TensorFlow dependence. The exception message above will only be triggered if the user specifically requests the 'tf' backend.

Possible Drawbacks:

This is a stopgap solution; at some point, we should aim to spin the TF simulator to its own package.

Related GitHub Issues: n/a

Note: we should start doing testing with Tox --- this would allow us to easily test different Python versions/TensorFlow versions etc., and is compatible with most CI services (including Travis and Circle).


Screen Shot not available

when i trying to see this library screen shot as this url i get error

screenshot added.


Add Infinity constant to enable windows tests with old busybox

Despite having recently updated busybox to a more recent version that does support sleep inf (#3617), it seems like the windows version of it that we depend on still does not.
(if you do have a windows rig available and can investigate what is going here that would be lovely)
Making more tests available for windows would thus require that we replace all calls to sleep inf or sleep infinity with sleep ARBITRARY_NUMBER.
This is not so good as it would be confusing if the duration is meaningful or not, and as different tests will likely start using different arbitrary numbers.
So this PR suggests we use a constant instead, Infinity, hiding the fact that we (for now) make this 3600.

Geez.
Git ate my commits 😭.
I want my money back!

Geez. Git ate my commits 😭. I want my money back!

FYI git reflog might be useful to recover lost commits

Merged via #3624


Update docs regarding printing variables

There seems to be a 'p' command (for print like in 'debugger'), but it results in its argument being printed twice:
p 1
1
1

No, there's not. p is a Ruby command.
I guess it's both printing the value (what p does) and the value returned by the p call (done for every command evaluated in byebug's prompt).
Closing since I don't think this is an issue. Reopen if you don't agree.

When using the debugger < ruby 2.0.0, the 'p' is used to print out the value. It is used when you have a variable named like one of the debugger commands - i.e. like 'step'. You quickly get into the habit of always using it to print something (or you accidentally, sometimes will hit one of the commands).
That makes it quite annoying when using this on byebug. I would be great if it did not print out the result of printing, and just printed once.

I don't know how debugger special-cased this, but it doesn't make much sense to me. Printing in a REPL (which already prints by default, the "P" in REPL) seems redundant. So these double prints seem correct.
Also, your reasoning about always using p to prevent command collapsing is a bit off, since it will collapse too whenever you have a variable called p.
I recommend you use the autoevaluation feature, i.e., use just 1 instead of p 1.

Your own guide https://github.com/deivid-rodriguez/byebug/blob/master/GUIDE.md shows p in action. The text says that p is used to print variables. If I just run the example in that guide p prints twice. The guide or the support for p is wrong.

I do not have permission to reopen it seems :-)

Right, so the story goes: I ported the Guide from old debugger. At some point, I removed the debugger command but I didn't update the Guide. As you said, the old command only printed the value once. So there's 2 possible solutions now:

Update the Guide to print the value twice.
Update the Guide to use something else to print variables.

Feel free to open a PR fixing this either way.

I do not have permission to reopen it seems :-)

Too bad... I reopened for you!

fwiw, puts prints the value and nil, which slightly better. (The problem with printing twice is mainly when the printed is a big chunk of data, and this makes it harder to scroll back and also harder to find where the output starts).
As with any command (e.g to print a variable), there is always the risk of it shadowing the debugged code. I really do think there should be a debugger way of ensuring that you always invoke the debugger command you intended instead of hitting Ruby in general. (i.e. if "Ruby puts" was overridden I don't want it when I am debugging).
I can help fix and put up a PR, but before doing that:

do you think adding p back as a command is out of the question?
is something like = a reasonable compromise for a "debugger print"?
should there also be a way of giving commands such that the debugger interpretation always wins (perhaps a setting for those that do not mind using say = p when there is a variable named p)?
something else?

fwiw, puts prints the value and nil, which slightly better.

I guess puts returns nil and p returns the printed value.

As with any command (e.g to print a variable), there is always the risk of it shadowing the debugged code. I really do think there should be a debugger way of ensuring that you always invoke the debugger command you intended instead of hitting Ruby in general. (i.e. if "Ruby puts" was overridden I don't want it when I am debugging).

I'm not sure I understand this. The current idea is that no debugger commands override any Ruby commands. Not sure if this is currently 100% true, but it's the overall intention. That's part of why I removed the p command: preventing surprises.
I'm still not sure why using eval, autoevaluation or other mechanism don't work for you. Note that the current behavior is the same in the other Ruby REPL's (irb or pry).

do you think adding p back as a command is out of the question?

No, but I'd like a good motivation.

is something like = a reasonable compromise for a "debugger print"?

You mean a command called =? Wouldn't that be the current autoevaluation or eval?

should there also be a way of giving commands such that the debugger interpretation always wins (perhaps a setting for those that do not mind using say = p when there is a variable named p)?

The debugger interpretation currently wins. If you have a variable named s, it will step instead of printing the s value. You can use Ruby's eval to override this behavior.

Good that debugger wins.
If it was up to me, I would like the p back :-) The motivation is:

you need an authoritative way to print things (i.e determined by the debugger). I may be debugging code written by someone using a lot of meta programming and there may be altered ruby behavior for anything, including eval, puts, p etc. I may not be aware of any of this and end up being confused.
Using p makes bybug compatible with the older debugger (over time that is less of a concern naturally, but when jumping between ruby versions (as I do) it is annoying as you have to actively remember which debugger you are using).
The commands s, n, and p are the most frequently used (at least by me)

you need an authoritative way to print things (i.e determined by the debugger). I may be debugging code written by someone using a lot of meta programming and there may be altered ruby behavior for anything, including eval, puts, p etc. I may not be aware of any of this and end up being confused.

Big no. If the debugged program changes the standard behavior of things, a debugger should help you noticing it, not hide it. Plus, the confusion can happen the other way around: people getting started with byebug can get surprised if behavior of standard ruby commands change.

Using p makes byebug compatible with the older debugger (over time that is less of a concern naturally, but when jumping between ruby versions (as I do) it is annoying as you have to actively remember which debugger you are using).

Compatibility with debugger has never been a goal of byebug.

The commands s, n, and p are the most frequently used (at least by me).

Sorry about that. You're a special case, but new developers getting started with byebug won't even know there once was a command called p.

I disagree strongly about being bit by altered behavior is a good thing - I am trying to debug the thing, I don't want to be bit by it. It does not help me one bit that the debugger does not work when someone "screwed up Ruby" with monkey patches. Also, the code may be an internal DSL where it is supposed to behave differently - I don't want to use the internal DSL's "print" or "p" or "eval" or whatever. That is just wrong.
So, restating, there needs to be an authoritative way of printing, just like an authoritative way of stepping. If it p or not is a minor problem in comparison.

It does not help me one bit that the debugger does not work when someone "screwed up Ruby" with monkey patches.

Wow, I thought we were talking about a double print here, not about a broken debugger.
I guess we'll have to agree to disagree! Thanks for your input.

p currently double prints, yes - which is annoying - it is based on "Ruby p". Hence there is no control in the debugger over printing. That is also a problem. The same problem as with any command that is not a debugger command for printing. I can help add one, it does not have to be p (although I would prefer that).
You said "big no" to having an authoritative printing command in the debugger. I explained why I think that is not good. I think you agree that an authoritative "step" is needed? Then why is printing different?

Ruby already has multiple ways of printing things, I don't get why we need an authoritative way of doing it. Or do you want puts and print and so on added as commands too? You still haven't answered what's wrong with using eval or just autoevaluating things. Your original example (p 1) is too simple to understand your needs.
In any case, my "big no" answer was meant to point out that I don't agree with the following:

I may be debugging code written by someone using a lot of meta programming and there may be altered ruby behavior for anything, including eval, puts, p etc. I may not be aware of any of this and end up being confused.

because it seems like trying to fix monkeypatching with monkeypatching.

What people do with monkeypatching is not always wrong in the sense it should be removed/fixed, especially when implementing an internal DSLs (where it may be desirable to prevent as much as possible of Ruby's normal behavior in that DSL).
eval certainly works for evaluation/printing (just like puts, p, inspect, etc.), but isn't that also just falling back to Ruby's eval ? Thus there is no print/eval in the debugger itself.
What I am asking for is not monkeypatching monkeypatching, I am asking for some kind of print that always works because the debugger implements it. Now if someone did actually monkeypatch Kernel it is a different thing, but if the current module/class has implemented "print", "puts", "p", etc. you would hit those instead of what you expect. Trying to prevent monkeypatching of Kernel and IO would be quite difficult - so that is not what I am proposing.
Does that better explain what I am asking for?

What people do with monkeypatching is not always wrong in the sense it should be removed/fixed

Agreed.

eval certainly works for evaluation/printing (just like puts, p, inspect, etc.), but isn't that also just falling back to Ruby's eval ? Thus there is no print/eval in the debugger itself.

Correct, but what eval returns is the only thing that gets printed in this case. So you don't get things printed twice, because you don't use a "Ruby printing command".

What I am asking for is not monkeypatching monkeypatching, I am asking for some kind of print that always works because the debugger implements it.

I think the best fit for your request would be a separate command that doesn't conflict with any standard Ruby command.

Does that better explain what I am asking for?

Yes, I think so. I still don't see the usefulness of this new command right now. But I will revisit this in the future with an open mind! How's that? In the mean time, I think you can easily extend byebug to add this new command. I think it shouldn't be too hard. Let me know if you go with this option and you need any help.

I think the best fit for your request would be a separate command that doesn't conflict with any standard Ruby command.

yes, exactly, great thanks - that makes it worth while making a PR, will dig into that.

Thanks.
Just keep in mind that, whereas you'll most likely be able to reuse the command in an extension, I'll most likely won't merge it into byebug since I still don't see the usefulness of it.

I did some experiments. And it seems like if I do this:
eval print_me

Then that does not hit a method named eval in my context. But if I do this:
eval(print_me)

it will. The rule seems to be that if there is a '(' without whitespace then it is a method call in context.
That seems to be the authoritative way I was looking for (except if someone monkeypatches Kernel.eval, but then they should be tarred and feathered).
here is my experiment:
class Evil
  def eval(*args)
    print_me = 10
    puts "Mwoah ha ha, ha ha"
  end
  def a_buggy_method(x)
    print_me = 10
    eval x + 1
  end
end

Evil.new.a_buggy_method(42)

And then, as you said, I don't really need to do anything except using eval.
Now, if I could alias that to my beloved p :P ...
Thanks for sticking with me here!
The resolution of this ticket is to change the guide to use 'eval'. Will edit that and make a PR.

Thanks for the investigation and the patch. I just reproduced the parenthesis thing, it's very weird to me... I'll investigate why that happens.

"the parenthesis thing" is actually valuable as a distinction between the "two evals" in my example even if it was unintentional :-)

Yeah. I'd still like to know the reason... :)


[BUG] - extract from duckdb (tutorial) not working with error java.sql.SQLException: Connection Error: Can't open a connection to same database

Description
extract from duckdb (tutorial) not working with error  Exception in thread "main" java.sql.SQLException: Connection Error: Can't open a connection to same database file with a different configuration than existing connections. connections are not closing correctly.
Expected behavior
extraction work properly with files extracted for duckdb
Current Behavior
A clear description of what the bug is.
What is affected? Who is it affecting? When does it occur? Where does it happen?
Steps to reproduce
Steps to reproduce the behavior:

download duckdb.db sample
configure an extract file
launch starlake extract-data --config metadata/extract/my_extract_config.sl.yml --outputDir datasets/incoming/starbake
See error
java.sql.SQLException: Connection Error: Can't open a connection to same database file with a different configuration than existing connections
at org.duckdb.DuckDBNative.duckdb_jdbc_startup(Native Method)
at org.duckdb.DuckDBConnection.newConnection(DuckDBConnection.java:51)
at org.duckdb.DuckDBDriver.connect(DuckDBDriver.java:41)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:681)
at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:190)
at ai.starlake.extract.JdbcDbUtils$StarlakeConnectionPool$.getConnection(JdbcDbUtils.scala:66)
at ai.starlake.extract.JdbcDbUtils$.$anonfun$withJDBCConnection$1(JdbcDbUtils.scala:105)
at scala.util.Try$.apply(Try.scala:217)
at ai.starlake.extract.JdbcDbUtils$.withJDBCConnection(JdbcDbUtils.scala:105)
at ai.starlake.extract.ExtractDataJob.$anonfun$extractTableData$4(ExtractDataJob.scala:522)
at scala.util.Using$.resource(Using.scala:296)
at ai.starlake.extract.ExtractDataJob.$anonfun$extractTableData$3(ExtractDataJob.scala:469)
at ai.starlake.extract.JdbcDbUtils$.$anonfun$withJDBCConnection$2(JdbcDbUtils.scala:111)

Context
Add any other context about the problem here: environment, custom data or schema, version...
Life cycle
Possible implementation
wecan enforce readonly and permit RW connection only on audit insertions with proper close connection.
Complexity estimation
T-Shirt Size: XS, S, M, L. If you would recommend XL or more, we advise you to discuss with the community how to split this issue.
Don't forget to tag this issue as a 'good first issue' if you think it is appropriate!

duplicate


document schema

document schema, including:

custom aggregator syntax "aggregator": { "custom": "{}*{}" }

Also, check how xml reacts to the new aggregator serde


PurchaseCompleted event is never fired

Hi Adapty team,
I wanted to integrate the paywall builder (thanks for this wonderful feature!) but encountered an issue with it. On iOS, the onPurchaseCompleted and onRestoreCompleted events are never fired. As a result app can't provide the user with the paid features after the purchase.
I found two things related to it in this RN module and in the AdaptyUI Swift code:

A mismatch in the method name:
RNAUICallHandler.swift:

public func paywallController(_ controller: AdaptyPaywallController,
                                  didFinishPurchase product: AdaptyPaywallProduct,
                                  profile: AdaptyProfile) {
...

when in fact the third argument should be different:
public func paywallController(_ controller: AdaptyPaywallController,
                                  didFinishPurchase product: AdaptyPaywallProduct,
                                  purchasedInfo: AdaptyPurchasedInfo) {
...

And another thing is in the AdaptyUI code. The problem is that the delegate instance is nil at the moment of handling the purchase result:
AdaptyPaywallController.swift:

private func handlePurchaseResult(_ result: AdaptyResult<AdaptyPurchasedInfo>,
                                      _ product: AdaptyPaywallProduct) {
        switch result {
        case let .success(info):
            delegate?.paywallController(self,
                                        didFinishPurchase: product,
                                        purchasedInfo: info)
        case let .failure(error):
            if error.adaptyErrorCode == .paymentCancelled {
                delegate?.paywallController(self, didCancelPurchase: product)
            } else {
                delegate?.paywallController(self, didFailPurchase: product, error: error)
            }
        }
    }

I was able to work around it by simply removing weak attribute from the delegate field declaration. I'm not a Swift expert so I'm not aware of any consequences of this solution.
Could you guys look into it and provide a solid solution? Thank you!

hi @akadko, thank you! Could you please check the latest release, 2.0.1?

Hello,
I have the same issue and I cannot upgrade to 2.0.1 because if the other issue here https://github.com/adaptyteam/AdaptyUI-React-Native/issues/2
"""
In Podfile:
react-native-adapty-sdk (from ../node_modules/react-native-adapty) was resolved to 2.9.1, which depends on
Adapty (= 2.9.2)
react-native-adapty-ui (from `../node_modules/@adapty/react-native-ui`) was resolved to 2.0.1, which depends on
  Adapty (>= 2.7.0)

"""
And when I forced to use Adapty 2.9.2, I see that AdaptyUI is bind to 2.7.0 and not supporting 2.9.2
Appreciate any help.

Hello @hasanfd
Neither v2.0.0 nor v2.0.1 can work with v2.9.x, could you please downgrade it to v2.7.x?

Thanks @vladd-g, the problem of 2.7.x is purchase completed never works. I am about the launch my product with adapty. However, I am not sure if I can trust just onLatestProfileLoad listener in prod.
adapty.addEventListener("onLatestProfileLoad", (profile) => {

This is the only way I can get if customer bought anything at the moment.
Any insight about this? Can I go prod with just this listener?

the problem of 2.7.x is purchase completed never works

@hasanfd sorry, maybe I didn't get you right; it wasn't the problem of 2.7.x, but of 2.0.0, fixed in 2.0.1. Did you check 2.0.1 with 2.7.x? If you still see the problem, could you please provide more details on it?

Thanks @vladd-g, looks like events are working on 2.0.1. However, I see an error after every time paywall closes,
 LOG  onCloseButtonPressed
 WARN  Possible Unhandled Promise Rejection (id: 0):
TypeError: Cannot read property 'forEach' of undefined
TypeError: Cannot read property 'forEach' of undefined
    at removeAllEventListeners (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:152289:32)
    at unsubscribe (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:151292:48)
    at ?anon_0_ (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:151254:41)
    at next (native)
    at fulfilled (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:150827:32)
    at tryCallOne (/Users/distiller/react-native/sdks/hermes/build_iphoneos/lib/InternalBytecode/InternalBytecode.js:53:16)
    at anonymous (/Users/distiller/react-native/sdks/hermes/build_iphoneos/lib/InternalBytecode/InternalBytecode.js:139:27)
    at apply (native)
    at anonymous (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:29717:26)
    at _callTimer (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:29636:17)
    at _callReactNativeMicrotasksPass (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:29666:17)
    at callReactNativeMicrotasks (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:29829:44)
    at __callReactNativeMicrotasks (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:2751:46)
    at anonymous (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:2563:45)
    at __guard (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:2735:15)
    at flushedQueue (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:2562:21)
    at invokeCallbackAndReturnFlushedQueue (http://<IP_ADDRESS>:8081/index.bundle//&platform=ios&dev=true&hot=false:2556:33)

Same warning coming after successfull payments as well. Do you think it is important?
Thanks for your quick responses

I am getting the same error as @hasanfd
@vladd-g When can we expect this fixed?

@hasanfd @ansh could you please check it on the 2.9.3 and 2.1.0?


[Font-weight] Add new font-weight

Problem
Need new font weight (between regular and blod)
Solution
Add medium(500) font weight
Figma / Jira Link
Typography

Medium font-weight was also added to the console.


Update help to support developers

Would it be possible to write down better documentation - what are steps to take this into use.
What tools you need to install (e.g. pandoc), etc...

I will improve this document, but these scripts are only prepared for GameMaker Manual. I don't know whether they are applicable to other documents made with RoboHelp.

I have tried on my own help project, it does works but html output is bit messed. That why missed doc on what and how was done.

If you need to make targeted adaptation for other projects, make modifications here to adapt your project:
https://github.com/GamemakerChina/robohelp-to-markdown-script/blob/main/main.py#L39


Feat: Add support for PKCS12 / PFX client certificates for mTLS

Description
This change allows bruno to use client certificates stored in PFX / PKCS12 files in addition to regular PEM cert/key pairs.
Updated the Client Certificate selection in Collection view so that the user can specify if they are using pfx format, in which case the key file becomes unnecessary, and the control disabled.  The passphrase field works for both formats.
Axios used by bruno has the support built-in so this change is a rather trivial one, with only the question of UI to solve.
resolves #1889
resolves #1698
Contribution Checklist:

[x] The pull request only addresses one issue or adds one feature.
[x] The pull request does not introduce any breaking changes
[x] I have added screenshots or gifs to help explain the change if applicable.
[x] I have read the contribution guidelines.
[x] Create an issue and link to the pull request.

For reference: Postman implementation

Thank you @pietrygamat !
@lohxt1 Lets target this to have it merged for next weeks release.
Assigning it to you.

+1 :-) I want to present bruno to my colleagues as the better alternative to postman - but I need the change bc of our client certificates environments

When clicking on the Add certificate button, it says "Successfully added client certificate" but nothing appears in the Client Certificates list

ignore my last comment.
when updating Bruno on windows using the Exe... the exe does not seem to update gracefully
we had to delete %LocalAppData%\Programs\bruno then run the exe to update. then it worked.

adding a +1 from community here. this fixed our problem.

Hey @pietrygamat There are some issues with this PR. The pfx flag is not persisted between app launches in bruno.json
"clientCertificates": {
    "enabled": true,
    "certs": [
      {
        "domain": "www.usebruno.com",
        "certFilePath": "/Users/anoop/foo.cert",
        "keyFilePath": "/Users/anoop/bar.key",
        "passphrase": ""
      }
    ]
  },

I recommend saving an additional key called pfxFilePath - and the logic being that

we use the pfxFilePath if it is present
else we use the certFilePath and keyFilePath

What do you think?

Hey @pietrygamat There are some issues with this PR. The pfx flag is not persisted between app launches in bruno.json
"clientCertificates": {
    "enabled": true,
    "certs": [
      {
        "domain": "www.usebruno.com",
        "certFilePath": "/Users/anoop/foo.cert",
        "keyFilePath": "/Users/anoop/bar.key",
        "passphrase": ""
      }
    ]
  },

Hmm... I cannot reproduce this... Once I click add, bruno.json is updated immediately with 5 fields, and the entry is added to the Client certificates list. Do you mean the UI state here? I guess it should be reset after clicking Add to confirm the operation is done, but that's that.

I recommend saving an additional key called pfxFilePath - and the logic being that

we use the pfxFilePath if it is present
else we use the certFilePath and keyFilePath

What do you think?

Let me clarify:
Are you proposing to change the json format, but keep the UI as proposed? That toggling the pfx checkbox would result in moving the file path between pfxFilePath and certFilePath of underlying object?
Or are you proposing to go Postman route and present the user with 3 input fields instead of 2, and prioritize the pfx when prepping request, but keep all 3 values in json? My problem with that is the logic to prioritize one over the other must be communicated to the user somehow. Postman sucks for just that - not communicating what happens here: do I have to fill all the fields? If I do, which will postman choose? Maybe both? But where does the passphrase apply then? To pfx or to encrypted key?

Insomnia does a better job at explaining that these are either-or values, but still accepts all inputs at once, ending up with confusing state of having pfx, key and passphrase (for key? pfx?) in the UI:

To avoid that, and do better, we should make the UI disable incompatible inputs depending on user first selection, but in a more complex scenario like this there is much more logic to add. For example something as easy as unselecting a file from input - we are missing a clear/reset button now, so to unload a file you have to open file chooser, select nothing and click cancel* . That's not ideal flow, but so far changing it has been out of scope of this PR. It will no longer be, if we aim to not be sloppy :).

Note, this crashes current release, btw, fixed in this PR

I guess it should be reset after clicking Add to confirm the operation is done, but that's that.

I added additional change to cover that.

This has been taken care in https://github.com/usebruno/bruno/pull/2482
Thanks for the work on this @pietrygamat for the initial work on this feature!
I deeply appreciate you helping us out in the review and approving the PR https://github.com/usebruno/bruno/pull/2482


Various default methods from java.util.Map don't work correctly if defRetValue is not null

Version: fastutil-8.2.1
Object2ObjectOpenHashMap<String, String> map = new Object2ObjectOpenHashMap<String, String>();
map.defaultReturnValue("undefined");

System.out.println(map.getOrDefault("bar", "nak")); //prints 'undefined' instead of 'nak'

map.putIfAbsent("foo", "one"); // 'foo=>one' is not added, see next line
System.out.println(map.get("foo")); //prints 'undefined' instead of 'one'

System.out.println(map.replace("bar", "two")); //prints 'undefined' instead of 'null' and 'bar=>two' is added (should not be)

System.out.println(map.computeIfAbsent("qux", s -> "three")); //prints 'undefined instead of 'three' and 'qux=>three is not added (should be)

System.out.println(map.computeIfPresent("def", (a, b) -> "four")); //prints 'four' instead of null and 'def=>four is added (should not be)

Ouch, I can see where we botched. We let Java's default implementation go through in the Object2Object case, but they don't take into account default values (which are a fastutil feature). Java's default implementation sees a non-null return value from the underlying map and returns that value.
I have to think what to do here. We might want just to document this behaviour.

It is also performance issue. computeIfAbsent in java hashmap is optimized and doesn't calculate hash twice (the same reason why there is addOrGet method for int set).

This should be fixed by 82e2ad359fd09fbe8dfb7ef40a0fc5a6abb60976.


Filtre revoked objects does not function

I use Python 3.6, with the latest github stix2 version
If you try to filtre for revoked (or not revoked) objects on FileSystemStore and MemoryStore you obtain errors or incorrect behaviours
Example
from stix2 import FileSystemStore, MemoryStore, Filter, AttackPattern
fs = FileSystemStore('/Users/andrea/test')
mem = MemoryStore()
filt_false = Filter('revoked', '=', False)
filt_true = Filter('revoked', '=', True)
patt1 = AttackPattern(name='test1')
patt2 = AttackPattern(name='test2')
fs.add(patt1)
mem.add(patt2)
fs.query(filt_false)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.6/site-packages/stix2/sources/init.py", line 90, in query
return self.source.query(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/stix2/sources/filesystem.py", line 298, in query
stix_obj = json.load(open(os.path.join(root, file_)))
File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/json/init.py", line 296, in load
return loads(fp.read(),
File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x85 in position 1083: invalid start byte
fs.query(filt_true)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.6/site-packages/stix2/sources/init.py", line 90, in query
return self.source.query(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/stix2/sources/filesystem.py", line 298, in query
stix_obj = json.load(open(os.path.join(root, file_)))
File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/json/init.py", line 296, in load
return loads(fp.read(),
File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x85 in position 1083: invalid start byte
mem.query(filt_false)
[]
mem.query(filt_true)
[]
patt1 = patt1.revoke()
patt2 = patt2.revoke()
fs.add(patt1)
mem.add(patt2)
fs.query(filt_true)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.6/site-packages/stix2/sources/init.py", line 90, in query
return self.source.query(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/stix2/sources/filesystem.py", line 298, in query
stix_obj = json.load(open(os.path.join(root, file_)))
File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/json/init.py", line 296, in load
return loads(fp.read(),
File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/codecs.py", line 321, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x85 in position 1083: invalid start byte
mem.query(filt_false)
[]
mem.query(filt_true)
[AttackPattern(type='attack-pattern', id='attack-pattern--3e65f786-25a0-471d-8ab8-1929313424a3', created='2018-01-19T09:29:36.104Z', modified='2018-01-19T09:30:49.983Z', name='test2', revoked=True)]

Do you have some news about it?

Took a quick look. There seem to be a couple issues involved:

The UnicodeDecodeError is caused by files in that directory that aren't valid JSON (like .DS_Store on macOS).
Even after I fixed that, I'm still not getting the data I expect returned, so there's something else going on that I'll have to look into more.

Decode errors. These should be fixed (or mitigated as best can), as now when the FileSystemStore/Source combs through the directory, it ignores non ".json" files, raises error if bad JSON, or raises error if bad STIX form. ( This patch is in Master branch as of 21-March-2018)
Query errors. I cannot reproduce them. @oliveriandrea , I reproduced your steps and got expected results. Maybe try again, with latest Master branch. Apologies for delay, we were off the project for a while. @gtback , do you remember what issues you were noticing.

I just tried out again with the latest master. The decode errors are gone, but I realized a significant limitation of the current filter implementation. Even though false is the default value for revoked, unless you explicitly set AttackPattern(..., revoked=False), it won't get returned by a query. I'm not sure the best way to fix this. Any ideas, @mbastian1135 ?

Right, so the filtering logic does this because "revoke" is not found as a property on the object (as its optional), and thus returns False because the filter cannot be applied.
If we reversed this logic, I think we would cause way more chaos than its worth.  Since then the filtering mechanism would return objects that are completely not inline with the filter (e.g. imagine querying for labels="Trojan" and any object that does not have the labels property would be returned)
An alternative is a hack within the filtering mechanism that checks if the filter being applied is evaluating a boolean property and that boolean property is True by default (as specified by STIX spec). In this case the STIX object would circumvent the normal disregarding and be returned. Id put that check here: https://github.com/oasis-open/cti-python-stix2/blob/master/stix2/datastore/filters.py#L141

If we reversed this logic, I think we would cause way more chaos than its worth. Since then the filtering mechanism would return objects that are completely not inline with the filter (e.g. imagine querying for labels="Trojan" and any object that does not have the labels property would be returned)

Unless the labels property has a default value, I don't think this is true.  Greg said that false is the default for the revoked property.  This means the property always has a value, though it may not have been explicitly given.  The "labels" property doesn't have a default (does it?), so it's not the same thing.
It sounds like the filter code cares whether the property value was explicitly given.  And that sounds wrong.  For most uses, it don't think it matters.  One case where it would, is during serialization, if you want to minimize verbosity (by omitting the property) when a value isn't explicitly given, and exactly reproduce the input on output when it is explicitly given.  But these are cosmetic issues, so from a correctness standpoint, they don't matter either.
The AttackPattern SDO looks like its revoked property was written as:
('revoked', BooleanProperty())

which doesn't give a default.  If it defaults to false, shouldn't a default be given here?  E.g.
('revoked', BooleanProperty(default=False))

Or am I misunderstanding?  (Maybe, it's been awhile since I've looked at the spec.)

We implemented property defaults, we assumed  having a default means the property is required, too. So that's why we didn't use BooleanProperty(default=False) in this case. I believe so far the only places we've used defaults are on timestamp properties that are also required. The revoked common property and the summary property on Sighting objects are the only examples I found of the spec listing a default value for any property, and both are optional properties.
@chisholm's suggestion is simple, but will it confuse users if the property shows up when they didn't specify it? A round-trip of parsing some JSON into python-stix2 and then printing it back out to JSON won't result in the original input. They will be semantically the same though.
Maybe we need to decouple our assumption that having a default = required. We could modify this line to also check if the property is required. Then the filter code would check if the object type has any non-required properties with defaults. This would keep us from maintaining a separate list of "optional-with-defaults" properties.

Boy, there's definitely terminology confusion here :)  At the conceptual level, a defaulted property is a required property.  I think you meant in your first sentence to say that defaulted in the current API design implied usage of the property in the API would be required (when constructing an SDO).  And you didn't want usage of revoked to be required, so you didn't default it either.  This is really mixed up thinking, to me.
I actually wrote about this before; I just dug up the email, which is dated 3/27/2017, almost exactly one year ago.  But was only addressed to Greg at the time.  It is about stix2 API design, specifically about the Property constructor.  Here's a paste:

to my mind, fixed implies defaulted and required, and default implies required.  So they're all dependent.  So instead of making three independent choices which may not make sense together, just choose one of the three.

This is a statement about the fixed/defaulted/required concepts, which I hoped to use to drive API design (I didn't like the Property constructor having those three separate kwargs).  Yes, defaulted implies required, but it doesn't imply usage of the property is required, when constructing an SDO.  The whole point of having a default is so that you don't have to specify the property: when omitted, its value is set to the default.  You default a Python function argument, for example, specifically so that callers don't have to specify it, yet you still maintain the invariant that the argument always has a value.  The function requires a value for the argument (therefore it is effectively required), but you don't want callers to always have to specify one.  You get the nice invariant, without burdening users with overly verbose function calls.  Defaulting is a convenience.
In the STIX spec, when a property is defaulted, that means it is conceptually required.  I know the spec has "(optional)" after the revoked property name, but that's only about usage.  When you default a property, it becomes impossible for it to not have a value.  If you were to implement a "delete" method which could operate on a defaulted property, you'd have to implement it with behavior like "reinstate the default".  You can't really remove the property, since by definition (of "default"), if not otherwise specified, the property has its default value.  (Which means it must exist.)
You wouldn't default a property unless you were thinking in your mind that it always had to be present with a value.  That it wouldn't make any sense for the property to not exist.  I.e. that it is conceptually required.  You only want usage to be optional.  So if the current API design is that giving a default value means that the property must always be given an explicit value when the SDO is constructed, then the API is designed wrong.  I would think that runs counter to most programmers' intuitions and experience with defaulting.
The design I wanted was for a Property creator to make a single choice, and for the API to be clearer about this:

optional: the property is optional.  If not given, it will not exist on the SDO.  This could be the... default :)
required: the property is required, and has no default.  This implies that usage is required.  It is the only way the property can obtain a value.  (Note, this is a slightly stricter definition from what I've been talking about conceptually, in that there's the additional "and has no default" part.  But I think users will get it.  Can you think of a better name?)
defaulted: the property is required, but has a default.  This implies that usage is optional.  If not explicitly given, the property's value will be the default.
fixed: the property is defaulted to a given value, and additionally can't be overridden by giving an alternative value explicitly during SDO construction.  You may explicitly give the same value as the default, but that would have exactly the same effect as if the property were omitted.

The way the API looked to me, with the three keywords, is that you can pick any combination of the three.  That's the way keyword args usually work.  It didn't seem to fit the conceptual requirements of the property.  That was my take on it, anyway.
As far as "remembering" whether a defaulted/fixed parameter were explicitly given or not, you wouldn't have to worry about properties mysteriously showing up.  You'd have to worry about them disappearing.  This could happen if a defaulted/fixed property were explicitly assigned the default/fixed value.  During serialization, the library could notice that and omit it, knowing the semantics would be the same.  If you didn't want that, extra bookkeeping would be required.  You'd have to keep track of which defaulted/fixed properties were explicitly assigned their default/fixed values, with the interpretation that "now the user wants these to be explicit in their JSON serializations".  I wouldn't assume that to be true though, I would prefer a user configurable setting.

We originally used "default" in the sense of "this field is required, but this is how you can come up with a sensible value if one isn't provided". As @clenk  pointed out, the only place we've used this is for created/modified timestamps. Perhaps we can rename that to something like "auto_now" (taking inspiration from Django's DateTimeFields. I like the idea of separating this out from a "default" value (from the spec), which semantically exists even if not present in the JSON.
It would be a lot of bookkeeping if we want to track specific default fields on specific instances of objects to know whether to export a value of "revoked": false, but I agree we can compromise on using either a global setting or add it to the serialize() call.

I like the idea of separating this out from a "default" value (from the spec), which semantically exists even if not present in the JSON.

I think you can use the same mechanism.  In fact, two different mechanisms that both do "defaults" in slightly different ways might be too confusing.  If the spec mandates a default and the user didn't supply a value, the library should automatically supply the spec's default.  Otherwise, to my mind, the library isn't being compliant.
Your additional defaulting behavior sounds just like what the higher convenience-layer factories were envisioned to do, I think.  Do we need it in both places?

It would be a lot of bookkeeping if we want to track specific default fields on specific instances of objects to know whether to export a value of "revoked": false, but I agree we can compromise on using either a global setting or add it to the serialize() call.

I didn't mean to advocate it, I was just addressing @clenk 's concern regarding unexpected property behavior.  Ideally, we could have a simple, natural implementation, and not have to worry about users being surprised by serialization details.

FTR: after dev meeting (2018 March 28) there was general consensus about:

modifying the creation of properties to specific mutually exclusive options (i.e. optional, required, defaulted etc..)  for a more clearer, expressive creation pf properties(long-term, especially before 1.0 release)
Not doing bookkeeping for tracking of properties that will/will not be serialized/exported but rather allowing a user to specify at some level whether to export "semantically default" properties
Further exploration of how many types of STIX properties fit into these corner cases of being optional (from a STIX specification perspective) but semantically defaulted from an API perspective. As Chris noted, he found "revoked" and "Sighting.summary" to be the only instances of optional STIX properties that also had defaults.

(Note Im paraphrasing here and enumerating from memory. So @gtback , @clenk please correct any incorrect statements)

I looked and didn't find any other default properties. I also noticed that both are required properties, so maybe we can handle this by making it an attribute of the BooleanProperty class? The only other required boolean property is EmailMessage.is_multipart, which doesn't have a default value, so it is required in the sense that @chisholm describes above (user must provide a value).

I think what @mbastian1135 said above (primarily what @chisholm suggested) makes the most sense:

Remove the 'fixed', 'required', and 'default' kwargs for Property (sub-)classes.
Create a new kwarg occurrence (I don't love the name, but it's the best I can think of right now) that has one of four values:

optional (the default). Properties of this type don't require the user to provide a value, and if they don't, nothing will show up in the serialized output. For now, there's no way to filter on objects where these values are not set (but maybe we can extend the filter syntax later).
required. Properties of this type are required by the spec, and have no value that can be inferred by the library. Users MUST provide a valid value when constructing the object
fixed. Properties of this type are required by the spec to have a specific value. Users MAY provide this fixed value when constructing the object, but regardless of whether they do or not, it will appear in the serialized output.
defaulted. Properties of this type are required (semantically) by the spec, but the library can help users fill them in. I think there are only four of these: created and modified time (which can be set to the current time), and revoked and Sighting.summary (Boolean properties that default to False). These will appear in the serialized output (even in the default False case).  No need to do bookkeeping on whether these were actually provided.

Add a value kwarg that is used for fixed and defaulted Properties. A special sentinel value (NOW) can be used for the default timestamp properties.

Actually, now that I think about it, maybe "Fixed" and "Defaulted" should be property classes rather than special occurrence values. I haven't thought through this yet, but it's late on a Friday, so I'll take the weekend to consider it more.

I'm okay with invocations looking like:
SomeProp(required=True)
SomeProp(default="foo")
SomeProp(fixed="foo")

I think it's at least as readable as:
SomeProp(occurrence="required")
SomeProp(occurrence="defaulted", value="foo")
SomeProp(occurrence="fixed", value="foo")

I assume you intend to enforce legal values on the occurrence parameter.  It's just as easy to enforce legal keys in a keyword arg, and you can get something a little more streamlined.  But either way, you should do that.  (Hopefully this doesn't seem like some kind of backpedaling, since that's kinda how the current API already is.  I don't know if this is seeming unclear or going around in circles.  I don't think so, but maybe I'm making people hopelessly confused :-P)

@chisholm, are you saying you're OK with having different kwargs for required, default, and fixed as long as the library throws an error if you try to use more than one of them, and that this is properly documented? It sounded like you thought there should only be one kwarg for the "occurrence type" of the property, but maybe I misunderstood.

Yeah, that's what I was afraid of.  My (probably too long) comment was really about the concepts, since I felt there was confusion.  All the code and design flows from that, so I wanted to clarify the ideas.  And it was the second time it had come up (for me, anyway), so it seemed like a recurring problem.  Also, I felt like library was not being spec-compliant (regarding defaults), which is a more serious issue.  I think we agree about the concepts; this remaining confusion is about API design.  Apologies if I seemed to nitpick over abstract concepts. That original email was written much earlier in the API development, so I think it was more appropriate to critique the design then.  Maybe that ship has sailed.
But in case it matters or would still help, here are some concrete ideas about the API design.  So, here's the current Property constructor:
def __init__(self, required=False, fixed=None, default=None, type=None):
    # etc ...

All parameters are defaulted.  From our above discussion, that means they're all required.  But Property conceptually needs a single choice.  All required... yet you must choose exactly one.  Can you see the conflict?  Design-wise, that was the main issue I had.  You might think "yeah, but they default to None", but to me, it doesn't change much.  They're always all there with a value, though it may sometimes be None.  And yeah, there is no error checking and not enough documentation.  What's basically been set up is a function with a set of defaulted parameters with a bunch of co-constraints among them (e.g. if arg X is this, then arg Y must be that).  In general, I think that makes it harder to understand, and more apt to be used incorrectly.
So here how I designed it:
def __init__(self, type_, **kwargs):
    if len(kwargs) > 1:
        raise AttributeError("Too many usage args for property "
                             "({} > 1)".format(len(kwargs)))

    for kw in kwargs:
        if kw not in ("fixed", "default", "required"):
            raise AttributeError("Unrecognized keyword arg: {}".format(kw))

    # etc...

Here, there are no defaults.  It's generic **kwargs.  That in itself gives no guidance as to what to pass, but I wrote a big docstring (omitted), and the very first bits of code tell you exactly what's expected: there can be no more than one keyword arg, and if a keyword arg is given, it must be one of those three values.  The language can't exactly express the requirements in the formal parameter list, but at least it doesn't mislead.
Clear as mud now?? :)  These kinds of discussions are great during design time, but perhaps a moot point now.  Sorry for any heartburn!

But checking the values in a **kwargs parameter against a fixed list of acceptable values smells like an anti-pattern to me.

I try to achieve a design which is closest to the model in my head.  No language allows you to express every idea perfectly.  In this case, the ideal is to express that at most one keyword arg is required, where the keyword is one of a fixed set.  To me, listing all three as defaulted keyword args is expressing the wrong thing.  I don't know if it's considered some over-arching language anti-pattern, but in this situation, it feels like the right thing to do.  Well, the best of the available options, anyway.
How would you express the at-most-one constraint with three None-defaulted parameters?
if (fixed and required) or (fixed and defaulted) or ...
    # raise error

Yuck.  That doesn't scale well (with the number of keyword args).  Maybe counting the Nones?
if sum(1 if a is None else 0 for a in (required, fixed, default)) < 2:
    # raise error

Scales better, but still awkward.  Or maybe you'd prefer:
if fixed:
    if default or required:
        # error
    # handle fixed
elif default:
    if fixed or required:
        # error
    # handle default
# etc...

That's pretty verbose.  You can probably think of other ways.  Can you think of any good understandable ones?  Maybe this is why the check was never done.  There didn't seem to be a simple natural way to do it.  Maybe it's because that function signature just doesn't really fit the concept very well :)  Or maybe I'm just missing the obvious.
If you smell an anti-pattern, maybe the usage/value split parameters would be less smelly to you?  And bypass the need for an at-most-one-usage check.

I see the benefits of moving type_ up to the first argument.

I should clarify that was pasted from code whose design diverged in more ways than just the Property constructor.  My type_ arg is a completely different animal.  It is more like the various property subclasses.  I wanted to experiment with splitting the typing from the properties.  So my design only needed one Property class, but there are many types (subclasses of a _STIXType class).  Anyway... not important for this.  The main point was the **kwargs style, with the error checking.  You can ignore the type_ arg.  Obviously I had to move it up to the front since I made it positional.

When I'm talking about implicit semantic default values of properties, I mean values of Propertys in STIXBase objects, not the value of keyword arguments to Property.__init__.

Of course.  One rarely thinks of functions as having "properties".  But I don't think there's one definition of "default" which applies to SDO properties, and another to Python functions.  I was applying the same general concept to both.  I thought it fit in both contexts.

The way that Propertys are defined in python-stix2 is almost an internal implementation detail, except that's also how users can define Custom Objects.

Sure, but one can still have aesthetics and care about design.  This conversation probably should have happened a year ago... :)

FTR - Dev Meeting 11 April 2018:

Proposed simple solution of having the two properties (revoked, sightings.summary) have default values of "False". This solves the usage bug that this thread was originally started on. But need to think through the effects of doing this for serialize() and python-stix2 output in general.
The above solution is to address the issue in the short term before 1.0 release, the deeper issue of the design of the Property object is still open.

(@clenk, @gtback - correct if I misinterpreted)

This was fixed for 1.0. I'll open a separate issue to consider refactoring how Properties are designed.


Fix for no element selected.

I believe this has been superceded and fixed in master - closing as addressed.


Fix to support mount fuse do not report error on macosx

What changes are proposed in this pull request?
Fix  mount fuse do not report error on macosx

@maobaolong  What is your macosx version? And why the sleep command stops fuse from reporting error?

@ssz1997 Thanks for your reply.

➜  ~ sleep 1
➜  ~ sleep 2s
usage: sleep seconds

@ssz1997 Could you take a look? Thanks！

alluxio-bot, merge this please

alluxio-bot, merge this please

@maobaolong do you think this is applicable to the main branch? I see the alluxio-fuse command looks quite different now. Thanks!


Broken Whorl and max Column Count in Guest Clipboard (tag: @ for people verifying if issue exists)

Product and Version [VS/VSCode]:
VS 2017
OS Version [macOS/Windows]:
Windows 10
Live Share Extension Version:
0.2.306.12878
Target Platform or Language [e.g. Node.js]:
asp.net 4.6.1 WebAPI
Steps to Reproduce / Scenario:

Have some string with Whorls in it
Have Guest copy string
Paste string outside of string quotes
See that string is not the same as when it went in.

Context: I use NPoco, so we are executing a stored procedure that includes:
@@addressLine2 = @addressLine2,
@@city = @city,
@@regionName = @regionName
Guest wanted to copy this into object parameters declaration so I wouldn't have to type each dynamically created property
(new {
addressLine2 = address.Line2,
city = address.city,
regionName = address.StateName
})
When Guest pasted, this was the results of their clipboard:
@addressLine2 = @
@city = @city,
@regionName = @re
This looks to me like 2 problems:

double Whorl turns into Single Whorl. Perhaps it's because they are at the beginning of the line.
Perhaps effect of Whorl at beginning of line causes a max character count of 16 in a line, but both top and bottom got cut off at 16 characters.

@EdLichtman Thanks for reporting this.  Right now we do not have universal language support in so it's possible there's an issue with SQL. That said, I've been unable to repro this with the latest VSIX.  Are you still seeing it with the latest VSIX? If so, is there any way for you to provide the file you encountered the issue?
@lostintangent  FYI re: language services.

Hi Chuxel,
We just tested it again and looks to be resolved!


Develop branch ain't working

Can't install the pod.
Analyzing dependencies
Pre-downloading: GeoTrackKit from git@github.com:intere/GeoTrackKit.git, branch develop
[!] Error installing GeoTrackKit
[!] Failed to download 'GeoTrackKit': [!] /usr/bin/git clone git@github.com:intere/GeoTrackKit.git /var/folders/xy/0whx_ft91kdbg_1sx16ddc0w0000gp/T/d20200816-3431-h2v9wi --template= --single-branch --depth 1 --branch develop
Cloning into '/var/folders/xy/0whx_ft91kdbg_1sx16ddc0w0000gp/T/d20200816-3431-h2v9wi'...
<EMAIL_ADDRESS>Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

@intere

You don't have SSH set up for github.  Try using https instead:
git clone https://github.com/intere/GeoTrackKit.git

And how should I add it like a pod to my swift project?

@Ralle001 - do you not know how cocoapods works?  I'd recommend starting here: https://guides.cocoapods.org/using/using-cocoapods.html
I'm not available to teach you how to use cocoapods.  There are lots of resources for this available.  If you have specific issues you're having with this library with respect to cocoapods, please feel free to open an issue.

I know but I used the one in the ReadMe file and it wasn't working. When I imported through the develop branch it worked but now it shows the error what I linked. Also when I import like the 'pod GeoTrackKit' then he code is not working.

You don't have SSH set up for github. Try using https instead:
git clone https://github.com/intere/GeoTrackKit.git

☝ You don't have SSH configured for github, you need to use an https url, not ssh.  You need to read up on cocoapods.


Please explain

In README.md, it says SuperForth can be both interpreted and compiled.
Well, where do I interpret it?

The interpreter is located in the current repository.
The compiler is relatively new, and is located here
Strictly speaking the only difference between the two is that the compiler lacks static linking with ffi c code.


composebox: Warn when linked to private streams.

Fix issue #6860

@showell can you review this? Should I add anything else in the flow?

@showell I have updated the changes.

@showell any updates about this?

Hi @rheaparekh I haven't been tracking this.  @timabbott Do you want me to review this?

@showell yeah, it'd be great if you can take this review.

@showell any updates about this?

@rheaparekh Merged, thanks!  Sorry about the late review.  The code quality here is really nice, and I particularly appreciate you digging into the compose node tests, which have some fairly complex idioms.
I'm gonna make a minor follow-up PR to add a line to the node tests and use the early-exit idiom.
Also pinging @brockwhittaker that this has some CSS changes that I didn't give a ton of scrutiny, but they seem to look fine.

See #7532 for my follow up commits, @rheaparekh

@showell Thankyou for the review! I'll keep the changes in mind. :)


typo

should be
platformio platforms install https://github.com/platformio/platform-espressif/archive/develop.zip

not
platformio platform install https://github.com/platformio/platform-espressif/archive/develop.zip

even then the url doesn't work.

Where did you find it? platformio platforms will be deprecated in PlatformIO 3.0. Need to use platformio platform instead. This repo is intended for PlatformIO 3.0

https://github.com/platformio/platform-espressif on the readme

Thanks. This is a valid command for PlatformIO 3.0. If you would like to try PlatformIO 3.0, please follow to https://github.com/platformio/platformio/issues/423

I'm trying to get platformio to build with the latest staging on travis... not having much luck though.
can't get it to build locally either but different reason.

PlatformIO 3.0 is located in separate branch (not in develop). See https://github.com/platformio/platformio/tree/feature/platformio-30
To install it use:
pip uninstall platformio
pip install -U https://github.com/platformio/platformio/archive/feature/platformio-30.zip

Don't forget to report about issues if you will find them.

I'll definitely try this... but I'm in the middle of an epic trying to get auto build deployment working with travis..


Indices are not created in elasticsearch

Describe the bug
When I run quick start script, only one index is created in elasticSearch.
To Reproduce
Steps to reproduce the behavior:

clone repository
Follow quickstart guid and run ./docker/quickstart.sh
Follow debugging guid and run curl http://localhost:9200/_cat/indices
only one index is present.
 yellow open .kibana ef5OZHAxTYGkuOQCgpJq6w 1 1 1 0 3.2kb 3.2kb

Expected behavior
quick start script should create all required indices in elasticSearch.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: windows 10 pro

Below are the logs form elastic continer
[2021-01-01T14:17:08,730][INFO ][o.e.n.Node               ] [] initializing ...
[2021-01-01T14:17:09,368][INFO ][o.e.e.NodeEnvironment    ] [2hkB708] using [1] data paths, mounts [[/usr/share/elasticsearch/data (/dev/sdc)]], net usable_space [230.4gb], net total_space [250.9gb], spins? [possibly], types [ext4]
[2021-01-01T14:17:09,370][INFO ][o.e.e.NodeEnvironment    ] [2hkB708] heap size [989.8mb], compressed ordinary object pointers [true]
[2021-01-01T14:17:09,402][INFO ][o.e.n.Node               ] node name [2hkB708] derived from node ID [2hkB708sS9yJcQqi-TbTnA]; set [node.name] to override
[2021-01-01T14:17:09,403][INFO ][o.e.n.Node               ] version[5.6.8], pid[1], build[688ecce/2018-02-16T16:46:30.010Z], OS[Linux/4.19.128-microsoft-standard/amd64], JVM[Oracle Corporation/OpenJDK 64-Bit Server VM/1.8.0_162/25.162-b12]
[2021-01-01T14:17:09,404][INFO ][o.e.n.Node               ] JVM arguments [-Xms2g, -Xmx2g, -XX:+UseConcMarkSweepGC, -XX:CMSInitiatingOccupancyFraction=75, -XX:+UseCMSInitiatingOccupancyOnly, -XX:+AlwaysPreTouch, -Xss1m, -Djava.awt.headless=true, -Dfile.encoding=UTF-8, -Djna.nosys=true, -Djdk.io.permissionsUseCanonicalPath=true, -Dio.netty.noUnsafe=true, -Dio.netty.noKeySetOptimization=true, -Dio.netty.recycler.maxCapacityPerThread=0, -Dlog4j.shutdownHookEnabled=false, -Dlog4j2.disable.jmx=true, -Dlog4j.skipJansi=true, -XX:+HeapDumpOnOutOfMemoryError, -Xms1g, -Xmx1g, -Des.path.home=/usr/share/elasticsearch]
[2021-01-01T14:17:16,840][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [aggs-matrix-stats]
[2021-01-01T14:17:16,846][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [ingest-common]
[2021-01-01T14:17:16,847][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [lang-expression]
[2021-01-01T14:17:16,847][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [lang-groovy]
[2021-01-01T14:17:16,847][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [lang-mustache]
[2021-01-01T14:17:16,848][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [lang-painless]
[2021-01-01T14:17:16,848][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [parent-join]
[2021-01-01T14:17:16,848][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [percolator]
[2021-01-01T14:17:16,849][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [reindex]
[2021-01-01T14:17:16,849][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [transport-netty3]
[2021-01-01T14:17:16,849][INFO ][o.e.p.PluginsService     ] [2hkB708] loaded module [transport-netty4]
[2021-01-01T14:17:16,850][INFO ][o.e.p.PluginsService     ] [2hkB708] no plugins loaded
[2021-01-01T14:17:28,925][INFO ][o.e.d.DiscoveryModule    ] [2hkB708] using discovery type [zen]
[2021-01-01T14:17:31,824][INFO ][o.e.n.Node               ] initialized
[2021-01-01T14:17:31,825][INFO ][o.e.n.Node               ] [2hkB708] starting ...
[2021-01-01T14:17:32,843][INFO ][o.e.m.j.JvmGcMonitorService] [2hkB708] [gc][1] overhead, spent [283ms] collecting in the last [1s]
[2021-01-01T14:17:33,236][INFO ][o.e.t.TransportService   ] [2hkB708] publish_address {<IP_ADDRESS>:9300}, bound_addresses {<IP_ADDRESS>:9300}
[2021-01-01T14:17:33,286][WARN ][o.e.b.BootstrapChecks    ] [2hkB708] max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
[2021-01-01T14:17:36,556][INFO ][o.e.c.s.ClusterService   ] [2hkB708] new_master {2hkB708}{2hkB708sS9yJcQqi-TbTnA}{qWrsmfGEQxy5alSS6QfVCw}{<IP_ADDRESS>}{<IP_ADDRESS>:9300}, reason: zen-disco-elected-as-master ([0] nodes joined)
[2021-01-01T14:17:36,710][INFO ][o.e.h.n.Netty4HttpServerTransport] [2hkB708] publish_address {<IP_ADDRESS>:9200}, bound_addresses {<IP_ADDRESS>:9200}
[2021-01-01T14:17:36,712][INFO ][o.e.n.Node               ] [2hkB708] started
[2021-01-01T14:17:37,881][INFO ][o.e.g.GatewayService     ] [2hkB708] recovered [1] indices into cluster_state
[2021-01-01T14:17:42,482][INFO ][o.e.c.r.a.AllocationService] [2hkB708] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[.kibana][0]] ...]).
[2021-01-01T14:18:34,582][WARN ][o.e.m.j.JvmGcMonitorService] [2hkB708] [gc][young][58][3] duration [4.1s], collections [1]/[4.2s], total [4.1s]/[4.6s], memory [313.8mb]->[131.4mb]/[989.8mb], all_pools {[young] [273mb]->[1.5mb]/[273mb]}{[survivor] [32.5mb]->[34.1mb]/[34.1mb]}{[old] [8.1mb]->[96.4mb]/[682.6mb]}
[2021-01-01T14:18:34,583][WARN ][o.e.m.j.JvmGcMonitorService] [2hkB708] [gc][58] overhead, spent [4.1s] collecting in the last [4.2s]
[2021-01-01T14:26:57,113][WARN ][o.e.m.j.JvmGcMonitorService] [2hkB708] [gc][young][557][4] duration [1.1s], collections [1]/[1.4s], total [1.1s]/[5.8s], memory [403.6mb]->[141.4mb]/[989.8mb], all_pools {[young] [273mb]->[1mb]/[273mb]}{[survivor] [34.1mb]->[20.9mb]/[34.1mb]}{[old] [96.4mb]->[119.7mb]/[682.6mb]}
[2021-01-01T14:26:57,116][WARN ][o.e.m.j.JvmGcMonitorService] [2hkB708] [gc][557] overhead, spent [1.1s] collecting in the last [1.4s]

Is DataHub quickstart supported on Windows ?
I know that the build of DataHub fails on windows and its a known issue  https://github.com/linkedin/datahub/blob/master/docs/developers.md

Is DataHub quickstart supported on Windows ?
I know that the build of DataHub fails on windows and its a known issue  https://github.com/linkedin/datahub/blob/master/docs/developers.md

It's very easy to miss. I switched to Linux environment and everything works fine now. closing this issue

It's very easy to miss. I switched to Linux environment and everything works fine now. closing this issue


MINOR: Update gradlew.bat as per latest gradle release

When invoking gradle on a recent version, it updates gradlew.bat to fix a typo. It's an annoyance at development time as it causes a diff on whatever branch one is working on.

Review by @ewencp

LGTM

LGTM


drivers: display: otm8009a: import 3rd-party source

Origin
STM32Cube_FW_H7_V1.9.1/Drivers/BSP/Components/otm8009a/
or https://github.com/STMicroelectronics/stm32-otm8009a
Purpose
Initializes the OTM8009A display over MIPI DSI.
Mode of integration
Integrate to the main tree as a driver.
Maintainership
Should be maintainable by the Zephyr display driver (or mipi_dsi) maintainer.
Pull Request
https://github.com/zephyrproject-rtos/zephyr/pull/53044
Discussion: https://github.com/zephyrproject-rtos/zephyr/discussions/52860#discussioncomment-4502450
Description
Basically only used the MIPI DSI init sequence from the original source.
Driver is necessary for the ST B-LCD40-DSI1 shield.
Dependencies
Zephyr MIPI DSI API.
Revision
not applicable.
License
Verbatim import as BSD-3-Clause license and then changed to Apache-2.0

I think it should just be implemented as a native display driver, using the MIPI-DSI API. What is the value of adding more vendor modules that bring poor quality code, not aligned with upstream?
FYI, this is an outdated (and probably needs fixes) native implementation: https://github.com/teslabs/zephyr/commits/feature/stm32-dsi.

As proposed by @gmarull, let's do a native implementation.


Error when trying to download from paperback

-Paperback V0.7-r46. Iphone x with IOS 15.6.1
-Komga v0.157.1-master From Docker for windows
[ERROR] [2022-09-06T04:33:57.245Z] [DownloadManager:downloadNextPage(for:):475] Download operation was not finished. State: failed [PaperbackError(401)] DownloadError: Server responded with errorCode: 401

Also hitting this, LMK if any logs help


Rename auto_scaling.md to auto-scaling.md

Fixes #1364
the auto scaling in content/bn/ folder markdown file has an '_' as a separator.  adding a '-' as a separator

@mitul3737  please check sir

@asem-hamid  Your PR has been merged!


Code review - comment dialog - suggestion overlap issue

Hello
A suggestion window lays under comment dialog when you add comments in code review process. See screenshot below...

@uwolfer - in IntelliJ IDEA 14.1.2 this issue is gone...

@ihorpts: Thanks for the update.


Mobile modals

this is really important for the mobile UX

currently they overflow and are placed in the middle of screen

Changes

from breakpoint 425px width (modals are currently 400px)
make the modals stick to the bottom and stretch.
like this:

I have removed the dropdown from minting fees in this issue #8132

this should prevent the modal excessively rescale.

Make sure there is no stroke/border on the sides. Only horizontal lines are visible in this case

👋

@Jarsen136 Do you mind if I take this one?

@Jarsen136 Do you mind if I take this one?

Hey @shashkovdanil This issue has been solved in https://github.com/kodadot/nft-gallery/pull/8136
So feel free to grab another issue.


After upgrading from flutter 3.3.4 to 3.7.1, the country flags unicode stopped working

Steps to Reproduce
Create an application with a Text widget and use different countries flags as unicode and test the different results using flutter 3.3.4 and 3.7.1.
Examples:

🇬🇧
🇺🇾

Execute flutter run on the code sample
App show the unicode separate instead of showing the flag.

Expected results: Show the unicode flag 🇬🇧
Actual results: Show the separate unicodes without converting to the flag

Hi @murilodag, thanks for the report!
This is a known issue being tracked at #119536. Closing this issue as a duplicate, so please follow up on it for further updates. You can leave there your comment and react an upvote to the original comment will help to raise the issue.
Thank you!

Thanks @huycozy. I missed that ticket.