Support for Controlling the Brightness of the Flashlight

Some Samsung and Pixel phones are able to adjust the flashlight brightness using getTorchStrengthLevel and turnOnTorchWithStrengthLevel. I came along this by @esper-io and this blog post.
Would this be a good idea for Flashy?

It would be a handy feature, seems good. I'd like work on it

It would be a handy feature, seems good. I'd like to work on it

Awesome! 😎

FWIW: https://github.com/polodarb/Flashlight-Tiramisu

There's a tiny problem...
I can develop it, but I cannot test it because I don't have a compatible physical Android 13 device.

I don't have a device running Android 13 too. Maybe we can ship it and let the users test. 😅

I don't have a device running Android 13 too. Maybe we can ship it and let the users test. 😅

b r u h.
Anyway, if we're forced to go that route, maybe you can stick a huge disclaimer for this feature in the release notes for next version?
Something like

DISCLAIMER: Controlling flashlight brightness is an EXPERIMENTAL feature that is only available in a few devices. If something goes wrong when using this feature, please open an issue. We need detailed explanations, as well as your willingness to test multiple times to properly fix the issue.

I can test if you give me an apk or some build instructions more detailed than
https://github.com/Crazy-Marvin/Flashy/blob/33a067938c756c3110aa7e57d3995d483dab6177/.github/CONTRIBUTING.md#L1

I can test if you give me an apk or some build instructions more detailed than
https://github.com/Crazy-Marvin/Flashy/blob/33a067938c756c3110aa7e57d3995d483dab6177/.github/CONTRIBUTING.md#L1

Alright, here's a apk. You can adjust flashlight brightness with the seekbar.
Please test every action you can think of, ie. screen rotation, switching modes, etc. and report any weird behavior along with reproduction steps.
app-debug.zip
Also @CrazyMarvin please update your guidelines lol.

The default brightness (after app (re)start) is 1 (i.e. darkest). I think max brightness would be a better default.

This also affects the tile. If flashy is open, the value from the seekbar is used. However if Flashy is closed, the default (i.e. darkest) value is used by the tile. So maybe change the default to 100% and remember the last value.

~Screen light goes "off" when you dimm it to zero, flashlight not. On the one hand this is a bit inconsistent, on the other hand it makes it easier to use the darkest value. And the screen light has wired on/off behaviour if you adjust it.~ I think it's fine the way it is.

Everything else seem to work fine.

Other things I noted while playing around and thinking about app functionality:

darktheme + material you needs some polishing. can be expanded in a new issue.
is this actually used somewhere? Flashy works fine for me w/o it.
https://github.com/Crazy-Marvin/Flashy/blob/ac47968a84225c1762aae502322e90156755f570/app/src/main/AndroidManifest.xml#L5-L7

The default brightness (after app (re)start) is 1 (i.e. darkest). I think max brightness would be a better default.
This also affects the tile. If flashy is open, the value from the seekbar is used. However if Flashy is closed, the default (i.e. darkest) value is used by the tile. So maybe change the default to 100% and remember the last value.

Please test this apk. It should have these behaviors:

If the seekbar is not touched, it should be at max value. The flashlight should be at max brightness as well, in both the app, the qs tile and the widgets.
If it is adjusted, a setting for the current flash brightness is saved when you release your finger. You can test it by closing and opening the app again (the seekbar should be set at the saved value), as well as measuring the brightness in the app, the tile and the widgets to see if it is correctly set according to the setting.
app-debug.zip

darktheme + material you needs some polishing. can be expanded in a new issue.

Please do.

is this actually used somewhere? Flashy works fine for me w/o it.

There is a widget called "Maximize screen brightness". It works by setting the system's brightness to max (as opposed to the app's brightness in the screen light mode, you can verify this by checking the system brightness bar in quick settings). To do so, the app needs this permission (you'll be prompted for it when adding this widget).
As you can already see, the permission is not used anywhere other than that.

Seems to work fine now.

I can test if you give me an apk or some build instructions more detailed than
https://github.com/Crazy-Marvin/Flashy/blob/33a067938c756c3110aa7e57d3995d483dab6177/.github/CONTRIBUTING.md#L1

I added a little bit more details. 😅
Please let me know if you miss something.


Scalaz snuck in another release before I cut ours

Codecov Report

Merging #1124 into release-0.15.x will increase coverage by 0.09%.
The diff coverage is n/a.

@@                Coverage Diff                 @@
##           release-0.15.x    #1124      +/-   ##
==================================================
+ Coverage           68.92%   69.01%   +0.09%
==================================================
  Files                 211      211
  Lines                4428     4428
  Branches              444      444
==================================================
+ Hits                 3052     3056       +4
+ Misses               1376     1372       -4

Impacted Files
Coverage Δ

core/src/main/scala/org/http4s/HttpVersion.scala
87.5% <0%> (-12.5%)
:arrow_down:

core/src/main/scala/org/http4s/Uri.scala
87.27% <0%> (+3.63%)
:arrow_up:

.../scala/org/http4s/testing/ArbitraryInstances.scala
82.35% <0%> (+23.52%)
:arrow_up:

Continue to review full report at Codecov.

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


Extracting fastq basecalled with Guppy with nanopolish

Hello,
It seems that nanopolish extract command is broken (v0.11.2) when fast5 are basecalled with Guppy (v3.2.4).
nanopolish extract -v -r -q /path/to/read.fast5 -o read.fastq
= extract.2 nanopolish_extract.cpp:386 parse_extract_options paths: /path/to/read.fast5
= extract.2 nanopolish_extract.cpp:387 parse_extract_options recurse: yes
= extract.2 nanopolish_extract.cpp:388 parse_extract_options read_type: 2d-or-template
= extract.2 nanopolish_extract.cpp:389 parse_extract_options basecaller_name:
= extract.2 nanopolish_extract.cpp:390 parse_extract_options basecaller_version:
= extract.2 nanopolish_extract.cpp:245 process_path /path/to/read.fast5
= extract.2 nanopolish_extract.cpp:185 process_file file [/path/to/read.fast5]: no basecalling data suitable for nanoplish
[extract] found 1 files, extracted 0 reads

Did I misused the command? If not, do you plan to update the code?
Thanks for your help.

Extract is only used for very old data (before 2017). For recent data you should just use the guppy basecalls and nanopolish index.
Jared

On Nov 25, 2019, at 8:15 PM, touala<EMAIL_ADDRESS>wrote:

Hello,
It seems that nanopolish extract command is broken (v0.11.2) when fast5 are basecalled with Guppy (v3.2.4).
nanopolish extract -v -r -q /path/to/read.fast5 -o read.fastq
= extract.2 nanopolish_extract.cpp:386 parse_extract_options paths: /path/to/read.fast5
= extract.2 nanopolish_extract.cpp:387 parse_extract_options recurse: yes
= extract.2 nanopolish_extract.cpp:388 parse_extract_options read_type: 2d-or-template
= extract.2 nanopolish_extract.cpp:389 parse_extract_options basecaller_name:
= extract.2 nanopolish_extract.cpp:390 parse_extract_options basecaller_version:
= extract.2 nanopolish_extract.cpp:245 process_path /path/to/read.fast5
= extract.2 nanopolish_extract.cpp:185 process_file file [/path/to/read.fast5]: no basecalling data suitable for nanoplish
[extract] found 1 files, extracted 0 reads
Did I misused the command? If not, do you plan to update the code?
Thanks for your help.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thank you for the quick answer. I was using nanopolish to extract reads after subsetting my datasets as it was more convenient (because already loaded in my pipeline). I will swap it with another solution.
Thanks again Jared.


Check if attributes have changed before index

Note that the Algolia equivalent of this gem indexes documents only if attribute(s) have changed. This is described here. Does meilisearch-rails have the same feature?

Yes, meilisearch-rails has the same feature. However, it only uses the newer will_save_change_to_#{attr} syntax. It is referenced in passing in the README of this repo: https://github.com/meilisearch/meilisearch-rails/#custom-attribute-definition.
See the implementation:
https://github.com/meilisearch/meilisearch-rails/blob/e7a12569f18ee40684c3c643a3cf573f3465c62e/lib/meilisearch-rails.rb#L853C1-L853C1


change PotassiumNitrate to Salpeter

KNO3 =  KNO3
(cherry picked from commit e4e904dc876229eb8174fce4bc33900f02bc8e66)

but they have differnent oredict ingame, so they are different items

yes but they are the same item chemstry wise so not sure why we add it in the first place. I change al recipes and let the material in for compatibility reasons. Maybe we set id to -1 some day. (Gt code)

Saltpeter is supposed to be an "ore", while potassium nitrate is a pure chemical compount. Saltpeter could have impurities, but that isn't used at all in the recipes so it's a good idea to merge them together.

So far i understand Glod right I need to work on this pr. He said I can remove this recipes because the saltpeter recipes already in the code. Need to check later.


Support PReLU Layer

Tested with the SeqFace model from here: https://github.com/huangyangyu/SeqFace. Accuracy on the tested Dataset is unchanged when using the TF model

@paulbauriegel thank you for contributing.
Why isn't it merged?

@VyBui There is no reason I'm aware of, whowever has write write access to this repository is most welcome to merge it. The code comes with no strings attached @ethereon

@paulbauriegel thank you for the quick reply man. I have cherry-picked some comments from yours to convert Openpose CMU to TensorFlow but no success. Would you mind looking over the error?

@VyBui Sure, I will take a look at it, but I cannot promise anything.


Amount of RAM required for consolidating OPT-175B?

Hi, does anyone know much RAM is needed to run the consolidate_fsdp_shards.py script for the OPT-175B model, to consolidate into one single file (without model/tensor parallelism)? Specifically the
python metaseq.scripts.consolidate_fsdp_shards ${FOLDER_PATH}/checkpoint_last --new-arch-name transformer_lm_gpt --save-prefix ${FOLDER_PATH}/consolidated
command from https://github.com/facebookresearch/metaseq/blob/main/projects/OPT/download_opt175b.md#reshard-the-shards.
I'm getting out-of-memory with a RAM limit (set via SLURM) of 500GB. I'm guessing at least 175B * 4 bytes = 700GB will be needed, but I'm figuring how large of an EC2 instance we should provision :)

@dpfried We load all sharded checkpoints into RAM before doing any merging, so I think requires about 2x model size of memory to hold both the input and output state dicts. Please see this script and this PR for some memory optimization during the MP resharding step.
In particular, I would suggest running metaseq/scripts/reshard_fsdp.py to merge FSDP shards (you can skip optimizer states to save RAM if they are not needed) and then metaseq/scripts/reshard_mp.py to merge model parallel parts.

Thank you! This is helpful.


Better logging for processing.py

Current:
INFO	preprocess.py	2018:
INFO	preprocess.py	transformed_laps is up-to-date
INFO	preprocess.py	2019:
INFO	preprocess.py	transformed_laps is up-to-date

Change function signatures so each season is on one line

done in #939d7c9


Fix #504

Fix #504

AssertionError: The Audio metadata is incomplete (5 entry)! Expected 3 (one for each entry of 'file_paths').

During handling of the above exception, another exception occurred:

self = <test_audio_interface.TestAudioInterface testMethod=test_not_all_metadata_are_unique>

    def test_not_all_metadata_are_unique(self):
        metadata = deepcopy(self.metadata)
        metadata["Behavior"].update(
            Audio=[
                dict(name="Audio", description="Acoustic waveform series."),
                dict(name="Audio", description="Acoustic waveform series."),
                dict(name="Audio2", description="Acoustic waveform series."),
            ],
        )
        expected_error_message = "Some of the names for Audio metadata are not unique."
        with self.assertRaisesWith(exc_type=AssertionError, exc_msg=expected_error_message):
>           self.interface.run_conversion(nwbfile_path=self.nwbfile_path, metadata=metadata)
E           AssertionError: "^Some\ of\ the\ names\ for\ Audio\ metadata\ are\ not\ unique\.$" does not match "The Audio metadata is incomplete (5 entry)! Expected 3 (one for each entry of 'file_paths')."

tests/test_behavior/test_audio_interface.py:159: AssertionError

I'm surprised the deep update didn't handle the duplication. Any idea why this might be, @luiztauffer ?

With the current proposed change under self.run_conversion(), the list of audios from self.get_metadata() (3 items) will append the list of unique audios passed by the metadata argument (3 items, 2 with repeated name, so 2 items at the end). The final metadata before conversion becomes this:
{
    'NWBFile': {
        'session_description': 'Auto-generated by neuroconv',
        'identifier': '091babae-f732-43ab-9c22-62e9a758afd5',
        'session_start_time': datetime.datetime(2023, 7, 4, 0, 13, 5, 499798, tzinfo=tzfile('/usr/share/zoneinfo/US/Pacific'))
    },
    'Behavior': {
        'Audio': [
            {'name': 'AcousticWaveformSeries', 'description': 'Acoustic waveform series.'},
            {'name': 'AcousticWaveformSeries1', 'description': 'Acoustic waveform series.'},
            {'name': 'AcousticWaveformSeries2', 'description': 'Acoustic waveform series.'},
            {'name': 'Audio', 'description': 'Acoustic waveform series.'},
            {'name': 'Audio2', 'description': 'Acoustic waveform series.'}
        ]
    }
}

So the conversion is operating as expected, the correct error was raised (number of items in list different from number of audio files), it’s just not the error expected by the test. Btw, dict_deep_update () will handle duplicates, so the error expected by the test can only happen with we don't pass the new metadata through dict_deep_update ().
The question is, if self.run_conversion() receives metadata!=None, what do we want to do?

append passed metadata to base datainterface metadata, as it comes form self.get_metadata(). This is the current behavior.
accept the passed metadata as the final metadata, in which case we should change our code to this:

if metadata is None:
    metadata = self.get_metadata()

The test seems to expect the result from number 2.
What do you think @bendichter ?

I think that, if the user/script is explicitly passing a metadata object to run_conversion(), then they should be responsible for passing a working version of it and, if no metadata is explicitly passed, the datainterface should use its default metadata from get_metadata().
I changed the code to follow this behavior now, and the tests are passing again.

Yeah, that seems reasonable to me


testing travis script

Evaluating travis script.
Related to issue #193.

/lgtm
/approve

/lgtm
/approve

Hi @zacharysarah .
Do you if it is possible to swap out travis for another build tool?

Hi @zacharysarah .
Do you if it is possible to swap out travis for another build tool?

@kbhawkey

Do you if it is possible to swap out travis for another build tool?

It should be possible, yes. I can't think of any dependencies that require Travis specifically.
Are you thinking of a specific replacement yet, or just curious in general?

@kbhawkey

Do you if it is possible to swap out travis for another build tool?

It should be possible, yes. I can't think of any dependencies that require Travis specifically.
Are you thinking of a specific replacement yet, or just curious in general?

I am looking into updating the build tool (prow).

I am looking into updating the build tool (prow).

I updated the travis script to build the component tool pages, kubectl command reference, gen-resourcesdocs.
The script depends on the correct release version.
I need to add more commands to build the api target. Ideally, each reference would build in a separate container/job
as there are library conflicts (note some libraries are removed from vendor directory).
The build takes a long time (currently just under 10 minutes?)!
My intention is to move this build/pull request job to prow. Other recommendations welcome.

I updated the travis script to build the component tool pages, kubectl command reference, gen-resourcesdocs.
The script depends on the correct release version.
I need to add more commands to build the api target. Ideally, each reference would build in a separate container/job
as there are library conflicts (note some libraries are removed from vendor directory).
The build takes a long time (currently just under 10 minutes?)!
My intention is to move this build/pull request job to prow. Other recommendations welcome.

Thanks for this change, @kbhawkey
I also spent some time yesterday debugging the build issue. The root cause is that GoLang is transiting from the old GOPATH based dependency to GO MOD based dependency. We have been hacking the k/k repo for its vendor directories.
I'm wondering if we are eventually going to use go mod as well.

Thanks for this change, @kbhawkey
I also spent some time yesterday debugging the build issue. The root cause is that GoLang is transiting from the old GOPATH based dependency to GO MOD based dependency. We have been hacking the k/k repo for its vendor directories.
I'm wondering if we are eventually going to use go mod as well.

Closing as PR #197 updated the component source and Makefile targets.

Closing as PR #197 updated the component source and Makefile targets.

/close

/close


Fix clusterpolicy.nvidia.com -> clusterpolicies.nvidia.com typo that caused CI failures

b510172de7d22ec83994d2b5dfc5286651205ccd - Fix clusterpolicy.nvidia.com -> clusterpolicies.nvidia.com typo that caused CI failures
25c1df404007437e37e1ce7f561cb093deab2412 - Fix broken waiting for CSV controller operator deployment image stanza update.  It was racey so it wasn't noticed until now

this one is another stupid mistake, however it might explain why I never get this PR https://github.com/openshift-psap/ci-artifacts/pull/203/files to work as expected (not wasn't waiting for the image to be properly deployed). I'll have to test again the short path of the master branch testing!
thanks again :)


Fixes bug where vim new line creates a permanent thick cursor

Thanks for your contribution! I can reproduce the issue and your changes indeed fix it. I wonder what the root cause for this issue is and if there's a better way to fix it, though.

I agree that this looks like it's fixing the issue on the wrong level. Could you say a bit more about how you diagnosed this and why making the mode change asynchronous helps?

@marijnh honestly I don't remember what it was.  I think it had to do with the way operations (src/display/operations.js) were getting batched, events were happening out of order and the  that is the thick curser wasn't getting removed properly.
It was 6 weeks ago, but I think another issue of using the operations module was the operation functionality wasn't exported.
Setting the timeout is just a hack for putting off the new line command to the next pass of the run loop so it happens after the current reconciliation of the render steps (and, yea, does another pass through the render steps).
The


Allow parsing of function types in expr position

What's in this pull request?
This pull request resolves SR-502 by adding the ability to parse expressions that contain function types, such as [Int -> Int](). It does so by adding a new Expr type, ArrowExpr.
Resolved bug number: (SR-502)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Previously it was not possible to parse expressions of the form
[Int -> Int]()

because no Expr could represent the '->' token and be converted later
into a FunctionTypeRepr. This commit introduces ArrowExpr which exists
solely to be converted to FunctionTypeRepr later by simplifyTypeExpr.
https://bugs.swift.org/browse/SR-502

@swift-ci please test

Looks like [() -> Int]() doesn't parse correctly; simplifyTypeExpr doesn't convert an empty TupleExpr to an empty TupleTypeRepr.

@swift-ci please test

@DougGregor, would you mind sanity-checking this change?

Clever! Can you add an ASTVerifier check that no ArrowExprs survive past successful type-checking, and some tests for ArrowExprs that won't get turned into types?

@jrose-apple The ArrowExpr AST node is declared in ExprNodes.def with UNCHECKED_EXPR, so ASTVerifier will complain if an ArrowExpr makes it past type-checking.
What sort of tests did you have in mind? I've got it checking cases where either side of -> cannot be interpreted as a type, e.g. 1 -> Int…

I'm more thinking about cases where the syntax is valid, but it's not in a TypeExpr position.
let a = Int -> Int
2 + () -> Int
() -> (Int, Int).2

(And, whoops, of course.)


[BUG] New AllocationStatus during Allocator timeout

Describe the bug
With this https://github.com/opensearch-project/OpenSearch/pull/14848 we added timeout mechanism to time bound large shard allocations. And currently, we are marking the unassigned shards THROTTLED which fails to be allocated to during a reroute round. We would want to add new AllocationStatus which would convey the decision of an unassigned shard better.
Related PR Comments -

https://github.com/opensearch-project/OpenSearch/pull/14848#discussion_r1687421542

Related component
Other
To Reproduce

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
New Allocation Status for allocator timeout
Additional Details
Plugins
Please list all plugins currently enabled.
Screenshots
If applicable, add screenshots to help explain your problem.
Host/Environment (please complete the following information):

OS: [e.g. iOS]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

[Triage - attendees 1 2]
@imRishN Thanks for creating this issue, could you make a pull request to address this or update the description to remove to make it clearer what should be done for another community member?


Problems when changing ItemRightBehavior in VisualState Trigger

Hi
In my UWP project I try to change the value of the SwipeListView.ItemRightBehavior in a VisualState Trigger. Doing it in designtime in Blend gives me an "The property value is not valid" error, and running the app gives the following error message.
Error: Converter failed to convert value of type 'Windows.Foundation.Int32' to type 'SwipeListBehavior'; BindingExpression: Path='ItemRightBehavior' DataItem='Universal.UI.Xaml.Controls.SwipeListView'; target element is 'Universal.UI.Xaml.Controls.SwipeListViewItem' (Name='null'); target property is 'RightBehavior' (type 'SwipeListBehavior').
Any suggestions on how to fix it?

What value do you set with trigger to ItemRightBehavior?

I want to be able to switch between all the states: Disabled, Expand and Collapse. But for this project I was trying to switch between Disabled and Collapse in the VisualState trigger.

Ok, doing some tests right now!

Hi, I don't want to give full swipe options like delete and flag available in Outlook mail. I want to give 2 options on both when user swipes and when he clicks on any of them some action should take place. Is it possible with this control?


Updating Laravel 9->10 and error states that backpack CRUD is not supported by L10

My composer.json:
{
"name": "laravel/laravel",
"type": "project",
"description": "The Laravel Framework.",
"keywords": [
"framework",
"laravel"
],
"license": "MIT",
"require": {
"php": "^7.3|^8.0|^8.1",
"backpack/crud": "^5.6.0",
"backpack/generators": "^3.3.16",
"backpack/logmanager": "^4.0.10",
"doctrine/dbal": "^3.6.2",
"fideloper/proxy": "^4.4.2",
"guzzlehttp/guzzle": "^7.5.1",
"jamesmills/laravel-timezone": "^1.13.0",
"lab404/laravel-impersonate": "^1.7.4",
"laravel/framework": "^9.52.7",
"laravel/sanctum": "^3.2.5",
"laravel/tinker": "^2.8.1",
"mckenziearts/laravel-notify": "^2.4",
"phpoffice/phpword": "^0.18.3",
"venturecraft/revisionable": "1.*"
},
"require-dev": {
"spatie/laravel-ignition": "^1.6.4",
"fakerphp/faker": "^1.21.0",
"laracasts/generators": "^2.0.2",
"laravel/breeze": "^1.19.2",
"laravel/sail": "^1.22.0",
"mockery/mockery": "^1.5.1",
"nunomaduro/collision": "^6.4.0",
"phpunit/phpunit": "^9.6.7"
},
"config": {
"cache-dir": "/home/initxcso/proactiveadvisor.danfs.co/cache",
"optimize-autoloader": true,
"preferred-install": "dist",
"sort-packages": true
},
"extra": {
"laravel": {
"dont-discover": []
}
},
"autoload": {
"psr-4": {
"App\": "app/",
"Database\Factories\": "database/factories/",
"Database\Seeders\": "database/seeders/"
},
"files" : [
"app/helpers.php"
]
},
"autoload-dev": {
"psr-4": {
"Tests\": "tests/"
}
},
"scripts": {
"post-autoload-dump": [
"Illuminate\Foundation\ComposerScripts::postAutoloadDump",
"@php artisan package:discover --ansi"
],
"post-root-package-install": [
"@php -r "file_exists('.env') || copy('.env.example', '.env');""
],
"post-create-project-cmd": [
"@php artisan key:generate --ansi"
]
},
"minimum-stability": "dev",
"prefer-stable": true
}
If I change :
"laravel/framework": "^9.0",
"spatie/laravel-ignition": "^1.0",
to
"laravel/framework": "^10.0",
"spatie/laravel-ignition": "^2.0",
I got all error coming from  backpack/crud
Problem 1
- backpack/crud[5.0.0, ..., 5.3.13] require laravel/framework ^9.0|^8.26 -> found laravel/framework[v8.26.0, ..., 8.x-dev, v9.0.0-beta.1, ..., 9.x-dev] but it conflicts with your root composer.json require (^10.0).
- backpack/crud[5.4.0, ..., 5.4.16] require laravel/framework ^9.0|^8.69 -> found laravel/framework[v8.69.0, ..., 8.x-dev, v9.0.0-beta.1, ..., 9.x-dev] but it conflicts with your root composer.json require (^10.0).
- illuminate/contracts[v5.6.0, ..., 5.8.x-dev] require php ^7.1.3 -> your php version (8.1.10) does not satisfy that requirement.
- illuminate/contracts[v6.0.0, ..., v6.19.1] require php ^7.2 -> your php version (8.1.10) does not satisfy that requirement.
- illuminate/contracts[v7.0.0, ..., v7.28.4] require php ^7.2.5 -> your php version (8.1.10) does not satisfy that requirement.
- illuminate/contracts[v8.0.0, ..., v8.11.2] require php ^7.3 -> your php version (8.1.10) does not satisfy that requirement.
- Conclusion: don't install fideloper/proxy 4.4.2 (conflict analysis result)
- Root composer.json requires backpack/crud ^5.0 -> satisfiable by backpack/crud[5.0.0, ..., 5.6.0].
- Conclusion: don't install laravel/framework v10.0.1 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.0.2 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.0.3 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.1.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.1.1 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.1.2 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.1.3 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.1.4 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.1.5 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.2.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.3.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.3.1 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.3.2 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.3.3 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.4.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.4.1 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.5.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.5.1 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.6.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.6.1 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.6.2 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.7.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.7.1 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.8.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.9.0 (conflict analysis result)
- Conclusion: don't install laravel/framework v10.10.0 (conflict analysis result)
- Root composer.json requires fideloper/proxy ^4.4 -> satisfiable by fideloper/proxy[4.4.0, 4.4.1, 4.4.2].
- fideloper/proxy 4.4.0 requires illuminate/contracts ^5.0|^6.0|^7.0|^8.0 -> satisfiable by illuminate/contracts[v5.0.0, ..., 5.8.x-dev, v6.0.0, ..., 6.x-dev, v7.0.0, ..., 7.x-dev, v8.0.0, ..., 8.x-dev].
- Only one of these can be installed: illuminate/contracts[v5.0.0, ..., 5.8.x-dev, v6.0.0, ..., 6.x-dev, v7.0.0, ..., 7.x-dev, v8.0.0, ..., 8.x-dev, v9.0.0-beta.1, ..., 9.x-dev, v10.0.0, ..., 10.x-dev], laravel/framework[v10.0.0, ..., 10.x-dev]. laravel/framework replaces illuminate/contracts and thus cannot coexist with it.
- backpack/crud[5.5.0, ..., 5.6.0] require laravel/framework ^10.0|^9.0|^8.69 -> satisfiable by laravel/framework[v10.0.0, ..., 10.x-dev].
- Conclusion: don't install laravel/framework v10.0.0 (conflict analysis result)
I would appreciate any advice or what I'm doing wrong. Can't figure it out. I have tried deleting my vendor and composer.lock unfortunately haven't succeed in neither way, this might be a bug

Hi @eberteogam
Im using Laravel 10, with Backpack 5 and PHP 8.1 (is mandatory for Laravel 10 have php 8.1)
Here is my composer versions:
"require": {
"php": "^8.1",
"laravel/framework": "^10.0",
"backpack/crud": "^5.5",
"backpack/logmanager": "^4.0",
"backpack/settings": "^3.0",
"backpack/permissionmanager": "^6.0",
"spatie/laravel-translatable": "^6.0",
"laravel/tinker": "^2.1",
"spatie/laravel-ignition": "^2.0",
"intervention/image": "^2.3",
"consoletvs/charts": "6.*",
"laravel/legacy-factories": "^1.0",
"backpack/filemanager": "^2.0",
"backpack/backupmanager": "^3.0",
"backpack/editable-columns": "^2.0",
"backpack/pro": "^1.6",
"backpack/newscrud": "^4.0",
"backpack/menucrud": "^3.0",
"backpack/revise-operation": "^1.0",
"mews/purifier": "dev-master"
},
"require-dev": {
    "fakerphp/faker": "~1.4",
    "mockery/mockery": "1.5.*",
    "phpunit/phpunit" : "^10.0",
    "symfony/css-selector": "2.8.*|3.0.*",
    "symfony/dom-crawler": "^5.0.2|3.0.*|2.8.*",
    "backpack/generators": "^3.1",
    "barryvdh/laravel-debugbar": "^3.2"
},

Let me know if you try a composer install or composer update, but first try to change your composer versions with the one i show you.

Cheers.

@jorgetwgroup I realized the main issue was coming from "fideloper/proxy" since L8->L9. Composer remove fideloper/proxy is mandatory. Attaching doc if anyone encounters same issue:
https://laravel.com/docs/9.x/upgrade#the-assert-deleted-method
Your json helped me a lot to get a better idea, appreciate the help.


Add accessibility to Pagination items

Hi,
I am part of a team that is developing applications for the swiss post. As we were integrating accessibility we encountered an issue with the pagination item that you provide:

In normal mode it looks legit but having users who need the high contrast mode, they are not able to see on which page they are currently at:

As you can see, it is not represented in any color... Also the left- and right-chevrons are not really visible.
It is for the following Post-Design Element:
https://swisspost-web-frontend.netlify.app/#/ng-bootstrap-samples/pagination
Here is an example for a possible approach and how we used to solve it in our part of the system:

If there are any further questons, please feel free to reach out to me.
Many Thanks and kind regards
Daniel

Thanks for taking the time to submit the issue and also providing a fix, that's awesome. We'll have a look at it.


ciao-cli node list -compute returns error

After install ciao in a 4 nucs cluster from the configuration created at "(pwd)/clear-config-management/examples/ciao" (not using the container), ansible reply success, but after source the generated files "admin-ciaorc" and "openrc" when trying to list he nodes, got this error
`
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # source admin-ciaorc
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # source openrc
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # ciao-cli node list -compute
E1109 23:38:13.002075   30742 authenticate.go:43] ciao-cli ERROR: Could not get AuthenticatedClient Post https://controller.example.com:35357/v3/auth/tokens: dial tcp <IP_ADDRESS>:35357: getsockopt: connection refused
E1109 23:38:13.002345   30742 identity.go:126] ciao-cli ERROR: Failed to create an AuthenticatedClient
E1109 23:38:13.154504   30742 main.go:220] ciao-cli ERROR: Could not send HTTP request Get https://controller.example.com:8774/v2.1/nodes: dial tcp <IP_ADDRESS>:8774: getsockopt: connection refused
F1109 23:38:13.154541   30742 node.go:123] ciao-cli FATAL: Get https://controller.example.com:8774/v2.1/nodes: dial tcp <IP_ADDRESS>:8774: getsockopt: connection refused
goroutine 1 [running]:
github.com/01org/ciao/vendor/github.com/golang/glog.stacks(0x8feb00, 0xc400000000, 0xa6, 0x124)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:769 +0xa5
github.com/01org/ciao/vendor/github.com/golang/glog.(*loggingT).output(0x8e2820, 0xc400000003, 0xc4200d20c0, 0x8bd491, 0x7, 0x7b, 0x0)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:720 +0x357
github.com/01org/ciao/vendor/github.com/golang/glog.(*loggingT).printDepth(0x8e2820, 0xc400000003, 0x1, 0xc4200e9b68, 0x1, 0x1)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:646 +0x126
github.com/01org/ciao/vendor/github.com/golang/glog.FatalDepth(0x1, 0xc4200e9b68, 0x1, 0x1)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:1134 +0x5d
main.fatalf(0xc420056ee0, 0x6a, 0x0, 0x0, 0x0)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/ciao-cli/main.go:127 +0x126
main.listComputeNodes(0x0, 0x9, 0x0)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/ciao-cli/node.go:123 +0x9dc
main.(*nodeListCommand).run(0xc420018600, 0xc42000c2b0, 0x0, 0x0, 0xc42000c2b0, 0x0)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/ciao-cli/node.go:107 +0xdb
main.(*command).run(0x8e0de8, 0xc42000c2b0, 0x0, 0x0, 0xc42008d868, 0x0)
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/ciao-cli/main.go:55 +0x15b
main.main()
/builddir/build/BUILD/ciao-62/src/github.com/01org/ciao/ciao-cli/main.go:401 +0xf7
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao #
`
here is the "admin-ciaorc" file
`
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # cat admin-ciaorc
export CIAO_CONTROLLER=controller.example.com
export CIAO_IDENTITY=https://controller.example.com:35357
export CIAO_USERNAME=admin
export CIAO_PASSWORD=adminUserPassword
export CIAO_TENANT_NAME=admin
`
here is the "openrc" file
`
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # cat openrc
export OS_PROJECT_DOMAIN_ID=default
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_NAME=admin
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=adminUserPassword
export OS_AUTH_URL=https://controller.example.com:35357/v3
export OS_CACERT=certificates/keystone/keystone_cert.pem
export OS_IDENTITY_API_VERSION=3
export OS_IMAGE_API_VERSION=2
`

It looks like keystone is not running.  Could you ssh onto the controller.example.com node and do a sudo docker ps -a
Are you running ceph on your cluster as well?  We did encounter an issue before in which there was a port conflict between ceph and keystone.

Hi @markdryan , answering your questions, here is the output of the docker command
`
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # sudo docker ps -a
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS              PORTS                                                        NAMES
6a76371d2c45        clearlinux/ciao-webui   "/bin/sh -c '/usr/bin"   15 hours ago        Up 15 hours         <IP_ADDRESS>:443->443/tcp                                         ciao-webui
aed4a2a3fbd0        clearlinux/keystone     "/bin/sh -c '/usr/bin"   15 hours ago        Up 15 hours         <IP_ADDRESS>:5000->5000/tcp, 3306/tcp, <IP_ADDRESS>:35357->35357/tcp   ciao-keystone
`
Next, yes, I have a ceph running in the cluster too
`
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # ceph -s
cluster d1582c6e-d866-403f-8453-43620eba4702
 health HEALTH_OK
 monmap e1: 1 mons at {controller=<IP_ADDRESS>:6789/0}
        election epoch 4, quorum 0 controller
  fsmap e5: 1/1/1 up {0=controller=up:active}
 osdmap e10: 6 osds: 6 up, 6 in
        flags sortbitwise
  pgmap v23: 320 pgs, 3 pools, 2068 bytes data, 20 objects
        30924 MB used, 149 GB / 179 GB avail
             320 active+clean

`
and keystone seems to be up, since I can list the users after source the "openrc" file
`
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # source openrc
<EMAIL_ADDRESS>~/cloud/clear-config-management/examples/ciao # openstack user list
+----------------------------------+-------+
| ID                               | Name  |
+----------------------------------+-------+
| 6ae299a2fbc741d8b2d94f40b9a3782b | demo  |
| bffc418a676e4817b3eaf95158656be4 | ciao  |
| edcfc59f646c4727bb51638548555e7d | admin |
+----------------------------------+-------+
`

Also the playbooks from clear-config-management are not being used and will be removed shortly. you should use those from ciao/_DeploymentAndDistroPackaging/ansible

HI @albertomurillo
I try install using ciao/_DeploymentAndDistroPackaging/ansible and still receiving the same error
<EMAIL_ADDRESS>~/BAT/cloud # ciao-cli node status
E1130 18:41:37.926971   11417 authenticate.go:43] ciao-cli ERROR: Could not get AuthenticatedClient Post https://controller.example.com:35357/v3/auth/tokens: dial tcp <IP_ADDRESS>:35357: getsockopt: connection refused
E1130 18:41:37.927267   11417 identity.go:126] ciao-cli ERROR: Failed to create an AuthenticatedClient
E1130 18:41:38.036786   11417 main.go:220] ciao-cli ERROR: Could not send HTTP request Get https://controller.example.com:8774/v2.1/nodes/summary: dial tcp <IP_ADDRESS>:8774: getsockopt: connection refused
F1130 18:41:38.036816   11417 node.go:228] ciao-cli FATAL: Get https://controller.example.com:8774/v2.1/nodes/summary: dial tcp <IP_ADDRESS>:8774: getsockopt: connection refused
goroutine 1 [running]:
github.com/01org/ciao/vendor/github.com/golang/glog.stacks(0x901c00, 0xc400000000, 0xae, 0x124)
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:769 +0xa5
github.com/01org/ciao/vendor/github.com/golang/glog.(*loggingT).output(0x8e5860, 0xc400000003, 0xc4200f20c0, 0x8c02f9, 0x7, 0xe4, 0x0)
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:720 +0x357
github.com/01org/ciao/vendor/github.com/golang/glog.(*loggingT).printDepth(0x8e5860, 0xc400000003, 0x1, 0xc42010bd40, 0x1, 0x1)
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:646 +0x126
github.com/01org/ciao/vendor/github.com/golang/glog.FatalDepth(0x1, 0xc42010bd40, 0x1, 0x1)
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/vendor/github.com/golang/glog/glog.go:1134 +0x5d
main.fatalf(0xc420076c80, 0x72, 0x0, 0x0, 0x0)
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/ciao-cli/main.go:127 +0x126
main.(*nodeStatusCommand).run(0xc4200f82a0, 0xc4200781c0, 0x0, 0x0, 0xc4200781c0, 0x0)
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/ciao-cli/node.go:228 +0x532
main.(*command).run(0x8e3e30, 0xc4200781c0, 0x0, 0x0, 0xc4200a9bc8, 0x0)
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/ciao-cli/main.go:55 +0x15b
main.main()
	/builddir/build/BUILD/ciao-75/src/github.com/01org/ciao/ciao-cli/main.go:401 +0xf7

After some research with @albertomurillo , it come up that this was a DHCP issue, after update on configuration  to properly resolve the names, ciao-cli is working again, closing this issue


JGRAPHX ANALYSIS FUNCTION IS MISSING

Hello
I have read the JGraphx User manual and I found something interesting:

This image shows the result of a function that determines and shows all the possible routes between two cells and also shows another function that returns the shortest path between those cells.
I already found the ShortestPath Function, but I am still looking for the function that allows me to get all possible routes between two cells, despite checking out the analysis package of JGraphx, I haven´t been able to identify this function; so I ask: Does this function exist?
If the function exists, it would be good to know its name and how to find it in JGraphx API.
Thank you.

This is mxGraph, not JGraphX.


Dev

Proposal of text for README.md
I will work on the dev branch, so the PRs are easier to identify. As the team is small, I think there should be no problem. Let me know if you want to change the workflow.

I believe each PR must go on its own branch.
Merging...


Decide and implement a versioning scheme

Is your feature request related to a problem? Please describe.
Create a more through versioning scheme with auto incremental version numbers for deployment.

Finally it's done. 😄


Normal map is incorrectly compressed when using Basis Universal compression mode

Godot version
4.0.alpha (992317957)
System information
Fedora 36, GeForce GTX 1080 (NVIDIA 510.68.02)
Issue description
Normal map is incorrectly compressed when using Basis Universal compression mode:

This does not occur when using VRAM compression (which is S3TC on desktop platforms).
Steps to reproduce

Add a normal map to a material.
Change its compression mode to Basis Universal in the Import dock, then click Reimport.
Notice how the 3D rendering looks all wrong, and the normal map in the inspector preview is too green (the thumbnail may be outdated).

Minimal reproduction project
https://github.com/Calinou/godot-test-basis-universal
(.godot/ is included to avoid crashes due to Basis Universal importing)
The texture included in the MRP is https://polyhaven.com/a/mud_cracked_dry_03.

Changing this code works around the problem:
modules/basis_universal/register_types.cpp
                        case Image::USED_CHANNELS_RG: {
 #ifdef USE_RG_AS_RGBA
-                               image->convert_rg_to_ra_rgba8();
-                               decompress_format = BASIS_DECOMPRESS_RG_AS_RA;
+                               //image->convert_rg_to_ra_rgba8();
+                               //decompress_format = BASIS_DECOMPRESS_RG_AS_RA;
+                               decompress_format = BASIS_DECOMPRESS_RGB;

It's disabling a major optimization to how normal maps are compressed, so I don't think this is a good fix, but it confirms that the issue is caused by the RG_AS_RA case.
I don't know quite enough about what's going on here to suggest a good fix yet, but we could apply the above to disable the RG_AS_RA workaround for 4.1 or 4.0.x until we learn more.


Show Login/Signup form when user clicks on Events/Programs

Is your feature request related to a problem? Please describe.
Right now, if the user clicks on Tune In/Participate, nothing happens if the user is not logged in because the cursor-event is set to none.

Describe the solution you'd like
Instead of setting cursor-event: none, login/signup form can be displayed when the user clicks on Tune In/Participate.
Describe alternatives you've considered
N/A

ለተወሰነ ጊዜ አጥፊ ሕይወት ለሰው ልጅ አስደሳች ግን አድካሚ ሁኔታን ያስከትላል። ሁሉም ነገር አሰልቺ ከሆነ ወይም ብዙ መጥፎ ነገሮች ሲከሰቱ አበረታች ንጥረ ነገሮችን እንጠቀማለን ወዘተ.

Would you like to take it?

I would like to work on this

I have added this feature please review it

#129


[epic] Elemental CAPI Implementation

This epic tracks the progress of the Elemental CAPI Implementation.
The scope is to implement the Cluster and Machine infrastructure provider contracts.
To keep aligned with CAPI conventions and to keep implementation simpler, this will be handled as a separate project: cluster-api-provider-elemental
Experimental CAPI features are out of the scope of the epic.
The first goal is to have a working prototype that can be used with the Kubeadm Bootstrap and Control-Plane providers.
A test Elemental image containing kubeadm and all needed dependencies can be provided initially for a proof of concept.
Since Kubeadm is the reference implementation for these providers, it would be best to have automated testing using it, so that we can compare differences and troubleshoot issues when using the RKE2 or K3s providers.

Linking sub-issues:

#989
#990


git version of 0bin not starting

Just reporting, git version of 0bin is not working out of the box, I mean;
$ python zerobin.py
Traceback (most recent call last):
  File "zerobin.py", line 4, in <module>
    from zerobin.routes import main
ImportError: cannot import name main

The PR #91 fix this. But thank you for reporting anyway ! ;)

Oh, you got me. It's not pulled and I didn't noticed it : )


Project Page - Work done - should be allowed to all users

Problem -

Work Done button is currently visible to only members
@vinpahilwani suggested to open it for all users. so all user with or without project manager rights can use this
Multiple Project Manager can use this button to exit project, when other manger is handling project

Solution-

Allow all end user to see this button
don't hide from anyone, show it to everybody
Don't allow last Manager to exit project, anybody can exit project until last project manager
Project requires at least one project manager

Technical Rule-

Allow any one to exit project, only check if there is other project manger exist in project

Initially reported by @vinpahilwani
Verified by @mitulpanch

#1504  this issue change functionality of Leave Project  Work done initially commited

"suggested to open it for all users. so all user with or without project manager rights can use this". I guess this button will not be available to owner who is not on project
Allow any one to exit project, only check if there is other project manger exist in project - yeh samajh nahi aaya

Rest all things are ok we can proceed

Allow any one to exit project, only check if there is other project manger exist in project

validation to exit project is , if any other project manger is exist then user can exit project, removing himself from project.

"suggested to open it for all users. so all user with or without project manager rights can use this"

now "Work Done" button available to all member who are manager or member to project. at time of save , backend check for if any other project manager is present in project.

https://www.berrycast.com/conversations/cb03495c-9a82-53d9-8fac-4de151e0180f


Update README.md

This is real good news!
I'd say it's much better than a potential improvement... Just upgrade your bullet point under a ## header above What can be improved, such as Use it straight from your umbrel and maybe explain in more details how this works.

I may end up refactoring the whole README later, but I'll let you create that commit if you like.

Sure, you can refactor as you wish. Just wanted to leave a note. I think it's quite an improvement, but it depends on everybody's case. For now, Lightning Shell is only on Umbrel and Citadel, so for those using other platforms, the "lncli must be in the path" would still apply.
BTW, under "Prerequisites", it seems that the points about editing the script are still there. When in fact it's about the config file now ...

Ok thanks @ibz, I will merge this tomorrow and then make the fixes on top of them.


Current Date and Time

I want the current date and time to be displayed at the top of the page.

Displays but doesn't run. Is it supposed to run?

time refreshes on page refresh


Can't use this in react native

I can't use this lib in react native. Above images is the error I got and my code.
Please give me tip.

Hi @danijel2017, thanks for the issue. I do not have a quick answer for you, but I will take a closer look at this issue at the weekend.

how can i use this, ?....

I alwayas error when use it, can you give an example for your repository, this make me confused about how i do?.

The support for react native is unfortunately not yet implemented. Feel free to create a PR.

Use this https://github.com/rtgstudio/rtg-react-native-social-buttons

@danijel2017 could you try the latest version - 3.0.0?

@MichalSzorad i get the same error, also on 3.0.0

There is no support for react-native at the moment, please feel free to submit a PR. Thank you!

@danijel2017 @zidniryi @styrken The errors shown are due to the library using components that do no exist in react-native (specifically div). I would recommend using  a react-native social button library instead. I cam across https://github.com/rnsb-community/react-native-social-buttons and added typescript to it. It is not as robust as @michaeljscript's but it does work in react-native.
I think this issue should be closed.


Revise/revisit all SI-units listed in Modelica.SIunits

Reported by dietmarw on 12 Mar 2012 12:10 UTC
The current version of Modelica.SIunits is based on quote

Library of type and unit definitions based on SI units according to ISO 31-1992

The problem is that this ISO norm is deprecated by  ISO 80000-1:2009.
In addition to that has the current Modelica.SIunts been steadily "enhanced" by other library officers with unit names that are not defined in the ISO norm but where just convenient to use. There should be a proper rule on what can be added and what not.
Related tickets: #545 (Molar units missing), #688 (Add Complex Units (Magnetic))
I'm scheduling this already for [milestone:MSL3.2.1] so that we can evaluate the new units that have been added recently. The main overhaul should probably be done in connection with [milestone:MSL4.0]
Related tickets: #545 (Molar units missing), #688 (Add Complex Units (Magnetic))

Migrated-From: https://trac.modelica.org/Modelica/ticket/712

Comment by hansolsson on 17 Apr 2012 13:24 UTC
To me it seems that if Modelica.SIunits is not based on the SI standard we should consider using another name.
I know that one can argue that the other units are based on the SI-base units, but the same should be true for all models in the entire MSL, except for:
Modelica.SIunits.Conversions.NonSIunits

which does not seem like the most intuitive name.
The new standard is possibly not that important, I would assume it is just a slight revision with possibly some changed names etc; i.e. not a change with major impact.

Comment by wischhusen on 17 Apr 2012 14:19 UTC
Perhaps one could stay with Modelica.SIunits but open another subpackage Modelica.SIunits.Derived to account for units that were derived from the standard unit system with multipliers. I think, it is useful to add somewhere in the Modelica Standard Library really commonly used units for many reasons (e. g. there is still no length unit in feet ... ). I know that this can (and is) already be done with local settings on each single machine but is that reasonable?
So what about that proposal:
Create a new subpackage Modelica.SIunits.Derived and put all those types inside which are really used by scientist and engineers :-).

Comment by mtiller on 17 Apr 2012 15:26 UTC
The biggest issue I see here is with the number of potential imports that users are going to have to deal with here.  Consider for the moment that users are going to need to know, for a given unit, whether it is formally in the ISO specification or not.  Is this really practical?
Also, keep in mind that "SI" is not universally synonymous with the ISO specification.  In fact, the Wikipedia page (in English) doesn't even mention the ISO specification until half way through the article and it lists it under "Related systems".
It seems to me that the real requirement here is that we give users a way to determine whether a given type is part of the ISO standard or not.  As I said, my feeling is that most will not care.  But for those who do, it should be possible.
One could imagine including a descriptive string on each unit indicating "ISO" or "derived".  You could further add an annotation (which could even specify what version of an ISO standard it was pulled from and the name in that standard if it was different).  Frankly, it might be sufficient to just indicate derived units only.
Frankly, I'm not sure it is worth it to go through all this.  However, I do agree that we should have a process for determine what types go into the SIunits package and making sure that any additional units are properly documented.

Comment by wischhusen on 17 Apr 2012 15:54 UTC
Replying to [comment:3 mtiller]:

The biggest issue I see here is with the number of potential imports that users are going to have to deal with here.  Consider for the moment that users are going to need to know, for a given unit, whether it is formally in the ISO specification or not.  Is this really practical?

Right, this is not a good solution from that point of view.

Also, keep in mind that "SI" is not universally synonymous with the ISO specification.  In fact, the Wikipedia page (in English) doesn't even mention the ISO specification until half way through the article and it lists it under "Related systems".

Okay, so that means derived units could stay inside the Modelica.SIunits package. This would be fine for me.

It seems to me that the real requirement here is that we give users a way to determine whether a given type is part of the ISO standard or not.  As I said, my feeling is that most will not care.  But for those who do, it should be possible.
One could imagine including a descriptive string on each unit indicating "ISO" or "derived".  You could further add an annotation (which could even specify what version of an ISO standard it was pulled from and the name in that standard if it was different).  Frankly, it might be sufficient to just indicate derived units only.
Frankly, I'm not sure it is worth it to go through all this.  However, I do agree that we should have a process for determine what types go into the SIunits package and making sure that any additional units are properly documented.

I think units are the base of every model, parameter dialog and result plot. It's important to offer those units which are really accepted in Modelica using (and perhaps also future!) technical domains. The Modelcia Standard Library could improve here in my opinion. I agree absolutely that there should be a process to integrate new units. How should that be done? Potentially on the Design Meetings, right?

Comment by pharman on 18 Apr 2012 09:11 UTC
Rather than have another package for derived units it would perhaps be neater to have a Units package in each subpackage (such as Modelica.Mechanics.Translational.Units) containing units that are useful in that particular domain.
A related issue that this would help with is that of nominal values. It is useful to use nominal values for scaling, but the default values are always 1, units in a domain-specific library can extend the base units and supply a nominal value that is closer to typical values (such as type HydraulicPressure = SI.Pressure(nominal=1e5);).

Comment by mtiller on 18 Apr 2012 09:43 UTC
This idea of per-library Units packages is interesting.  But I don't think it is very practical.  We will end up importing lots of package contents from different places and we'll still have a lot of left over units that have to go somewhere (since I think we should include at least the ISO standard units, esoteric as they may be).
However, you raise an interesting point about the nominal values.  I think perhaps a good compromise might be to put everything in Modelica.SIunits but then create per library units packages for that library to use where domain specific attributes (min, max, start, nominal) could all be associated with it.  Then the library could extend from that type.
This would achieve the objective of having domain specific units used within the library while still preserving the aggregated units package.

Comment by pharman on 18 Apr 2012 10:06 UTC
Replying to [comment:6 mtiller]:

I think perhaps a good compromise might be to put everything in Modelica.SIunits but then create per library units packages for that library to use where domain specific attributes (min, max, start, nominal) could all be associated with it.  Then the library could extend from that type.

Yes I meant the base units would remain in SIunits, maybe it should be renamed Modelica.Units at some point (though the resulting update script might be quite big!).

Comment by fcasella on 18 Apr 2012 13:40 UTC
Replying to [comment:6 mtiller]:

This idea of per-library Units packages is interesting.  But I don't think it is very practical.  We will end up importing lots of package contents from different places and we'll still have a lot of left over units that have to go somewhere (since I think we should include at least the ISO standard units, esoteric as they may be).
However, you raise an interesting point about the nominal values.  I think perhaps a good compromise might be to put everything in Modelica.SIunits but then create per library units packages for that library to use where domain specific attributes (min, max, start, nominal) could all be associated with it.  Then the library could extend from that type.

Note that a similar concept has already been implemented long time ago in Modelica.Media: each fluid model is described by a package, which has local unit definitions with appropriate min, max, start, and nominal attributes. These can also be modified locally when using the medium package in a specific modelling context.

Comment by hansolsson on 18 Apr 2012 14:27 UTC
Having per library types with specific min, max, start and nominal in non-Media parts in MSL does not seem ideal to me, since the nominal values are more application-specific than domain specific.
E.g. the translational library is used for 1d-motion; it could be an entire vehicle or it could the parts of the hydraulic system of a vehicle - the equations are the same, but the nominal values differ by several orders of magnitude.
Having the possibility to modify it locally as for the media-library does work; but it requires modifying packages which seems excessive for the other parts of MSL.
--
Oh, and renaming "Modelica.SIunits" to "Modelica.Units" is just one line a conversion script.

Comment by dietmarw on 17 Dec 2012 13:50 UTC
Find a proper rule for units for MSL3.3 (decided at the MAP-LIB phone meeting 2012-12-17)

Changelog removed by dietmarw on 17 Dec 2012 13:50 UTC

Comment by beutlich on 29 Apr 2014 06:34 UTC
@dietmarw: Should Milestone be set to MSL_withConversionScript?

Comment by dietmarw on 29 Apr 2014 06:45 UTC
Well the decision was to include it in MSL3.3 which means there will have to be a conversion script for that version. I'd like to leave this at MSL3.3 as an explicit decided statement.

Comment by beutlich on 29 Apr 2014 06:48 UTC
But there is no Milestone MSL3.3.

Comment by otter on 13 Dec 2015 17:14 UTC
Replying to [ticket:712 dietmarw]:

The current version of Modelica.SIunits is based on quote

Library of type and unit definitions based on SI units according to ISO 31-1992

The problem is that this ISO norm is deprecated by  ISO 80000-1:2009.

I agree that this should be clarified. However, I have no time to inspect and compare the newest SI unit ISO norm with the older one. I therefore re-schedule to the next milestone.

In addition to that has the current Modelica.SIunts been steadily "enhanced" by other library officers with unit names that are not defined in the ISO norm but where just convenient to use. There should be a proper rule on what can be added and what not.

I made this clearer in the documentation with 95ba212c5798c588ffb0884b627abc082f247e21:
Some of the types are derived SI units that are utilized in package Modelica (such as ComplexCurrent, which is a complex number where both the real and imaginary part have the SI unit Ampere).
I quickly checked and did not found type definitions that are neither directly defined in the ISO norm nor are derived from it. Please, can you give concrete type definitions where you see an issue (the solution is then to either move this type to Non-SIunits or improve the description of the package). I do not really understand why the name of the package should be changed (e.g. this package does not contain non-SIunits like "foot" or "rev/min" and it contains only units that can be expressed, without conversion factors, by the seven SI base units).

Modified by otter on 13 Dec 2015 17:15 UTC

Comment by hansolsson on 13 Dec 2015 18:43 UTC
Note that this ticket is about 4 years old, and in the coming 3 years we are likely to get a revised SI-system. Even if it primarily is about the basic definition of the units (like kilogram) - they are also planning awareness campaigns about the new SI-system.
An unrelated major change of Modelica.SIunits close in time to that seems confusing.

Since we are now at a point where we can do proper clean-ups I like to bring the idea of reorganising the SIUnits package  to the surface again.

Name: I'm still pretty much in favour to make a rename from SIunits to simply Units. Reason being that:

having the nonSI unit conversions as part of the SIunits package looks strange
it always bothered me that the camel-case convention in SIunits is kind of broken. Naturally I would write SIUnits.
when domain/3rd-party libraries specify their own units I've only seen the package name Units for that. So this seems to be the more natural thing to call things.

Structure: Finding the right unit without knowing the exact name in MSL beforehand makes it hard to find. Browsing is cumbersome because of the pure quantity. So having the units split up into sub-packages by chapters might help. What I don't like about that is that you then can not do a simple

import U=Modelica.Units;

and access all units with just short syntax like U.xxx but rather have to type then U.yyy.xxx. Doing this via a special description string could help if the tool would allow filtering the component browser based on that. Which neither OMEdit nor Dymola (only ones I have access to) do currently.

Type of unit: By this I mean is it a derived or an SI unit. For this the use of a description string was mentioned which I think would be sufficient.

Difference SI and non-SI is fuzzy: When looking at Modelica.SIunits.Conversions.NonSIunits it is not clear to me why these are not SI units but rather just scaled versions of SI. But then again all units are likely to be obtained by scaling. We even have already things like Modelica.SIunits.Temp_C (which in turn links down to non-SI). So all this really points to 1. and just calling it Units and marking the ones we are certain about being SI as SI or ISO or ... and others not.

Two additional comments:

The Modelica.SIunits.* names do actually not seem to be clearly defined by the SI-standard as far as I know, and it is fact more complicated. The names correspond to the names of "Derived quantities" - but I can only see the SI-standard listing examples for that - and not a complete list; so we don't know if many of the units should be there or not.
Regarding NonSI: the derived quantity list in the SI-standard includes "Celsius temperature" (for temperature difference); "cm" is a prefixed SI-unit (part of the SI-standard), "deg" (for degree) and "h" (for hour) are non-SI-units accepted for use with the SI-standard according to the SI-standard - so even if the name is counterintuitive it makes sense for them.
It is still unclear how to use the SI-types for connector-variables.

So having the units split up into sub-packages by chapters might help.

It might - or it might just cause confusion since many units are common for several domains; and thus the chapters might not be logical; and thus making it harder. I guess tool vendors could experiment with some advanced support for finding appropriate units - but assumedly after the conference.

Nothing in this ticket is meant to be fixed by the conference ;-)

Name: I'm still pretty much in favour to make a rename from SIunits to simply Units.

Not sure if  Units is sufficiently clear. BIMP develops a system of units of measurement.

@dietmarw @HansOlsson @tobolar Shall we call a web-meeting how to go on here?

Since @christiankral and @MartinOtter are the library officers of Modelica.SIunits they should be included here.
For MSL4.0.0 maybe we can address the main points:

Update the name from SIunits to Units since the current class name structure includes strange constructs (see above https://github.com/modelica/ModelicaStandardLibrary/issues/712#issuecomment-272611734 ) which basically means the units are simply a collection of, well units. Some are SI some are not, and some are derived.
Decided if an update to ISO 80000-1:2009 is relevant. If not at least update the documentation to state why MSL is still fine with using the deprecated ISO 31 norm.
Resolve the related ticket: #545 (Molar units missing) at the same time.

There are several main unit systems:

SI (International System of Units) (meter-kilogram-second-ampere-kelvin-mole-candela)
FPS (foot-pound-second)
MKS (meter-kilogram-second)
CGS (centimeter-gram-second)
EMU (Electromagnetic) (centimeter-gram-second-abampere)
ESU (Electrostatic) (centimeter-gram-second-abcoulomb)

The purpose of Modelica.SIunits are units based on  (meter-kilogram-second-ampere-kelvin-mole-candela), not on one of the other unit systems. Using "Units" as package name would indicate that also units of the other unit systems could be used, but this is not the intention and should not be done.
Nearly every sub-library in package Modelica has transformers to another domain, e.g., Translational.Components.IdealGearR2T transforms rotational into translational motion. Although, such mixed-domain components are present, the library is called Translational and not TranslationalWithSomeRotationalParts. Why should SIunits be an exception? SIunits.Conversions contains conversions into non SI units and in order to do this, non SI units are defined here.
To conclude, the name SIunits should not be changed.

I agree, SIunits shall not be changed.

Is it really that much of a change to add a single . compared to right now if Units.SI was used instead? I see import SI = Modelica.SIunits a lot anyway, so it seems to be what people want:
$ grep -R "import *SI *= *Modelica" ~/MODELICAPATH/ | wc -l
1137

To conclude, the name SIunits should not be changed.
Noted.
So what about 2 and 3?

Is it really that much of a change to add a single . compared to right now if Units.SI was used instead? I see import SI = Modelica.SIunits a lot anyway, so it seems to be what people want:
$ grep -R "import *SI *= *Modelica" ~/MODELICAPATH/ | wc -l
1137

https://github.com/modelica/ModelicaStandardLibrary/issues/2960#issuecomment-501223526

Indeed. So if it was renamed to Modelica.Units.SI, you could do the recommended style import Modelica.Units.SI and use SI.Voltage like many people seem to prefer.

Is it really that much of a change to add a single . compared to right now if Units.SI was used instead? I see import SI = Modelica.SIunits a lot anyway, so it seems to be what people want:
$ grep -R "import *SI *= *Modelica" ~/MODELICAPATH/ | wc -l
1137

#2960 (comment)

Which perfectly fits to having import Modelica.Units.SI.

Decided if an update to ISO 80000-1:2009 is relevant. If not at least update the documentation to state why MSL is still fine with using the deprecated ISO 31 norm.

I quickly inverstigated. There are about 14 chapters of ISO80000 (e.g. Part 4: Mechanics). Every part costs about 120 CHF, so the whole standard > 1000 Euro. I have no access to it. Even if someone has access, one would have to inspect > 500 definitions in Modelica.SIunits and ISO80000 and update correspondingly. This is a lot of work. Could be probably made by paid work (MA backoffice?). In my opinion, it is not worth it. The simplest approach is to change the documentation and just state that Modelica.SIunits is based on ISO80000 (assuming that the parts of ISO80000 that are relevant for Modelica.SIunits did not change, but that just new stuff was added that is missing in Modelica.SIunits).

Update the name from SIunits to Units since the current class name structure includes strange constructs (see above #712 (comment) ) which basically means the units are simply a collection of, well units. Some are SI some are not, and some are derived.

Rethinking about various options:

Modelica.Units and in the description state that these are SI units and contains conversions to non-SI units.

Modelica.Units.SI: Drawbacks: We should not support other unit systems and therefore only one sub-package under Units, which seems to be over-structured. The Modelica package avoids abbreviations in package names and this would be an abbreviated package name (yes, SIunits also contains an abbrevation, which is not nice).

Modelica.SI: Would avoid one drawback of 2, but would be not so descriptive.

So to summarize: I changed my mind. For me it is also o.k. to just use Modelica.Units, if in the documentation it is stated that the units are based on SI-units of ISO 80000 (with some conversions to non SI-units).
Since this is a change that influences nearly every model, we could make a polly (Modelica.SIunits, Modelica.Units (but only SI units), Modelica.Units.SI, Modelica.SI).

I'd like to discuss option 2 a bit further as I think that would actually allow us to solve issues like the ambiguity of the current characterisation of SI and nonSI and also of having nonSI units inside the current SIunits. OK let me explain how I think this can be solved rather elegantly and also "fixing" the import issue that came up.
Currently (as of 3.2.3) the strurcture looks as follows:

Modelica

SIunits

UsersGuide
Icons
Conversions

NonSIunits

Taking option 2 as a starting point and doing some structual clean up at the same time I propose (let's call it option 2a):

Modelica

Units

UsersGuide
Icons
SI (toplevel content of old  Modelica.SIunits but non of the sub-packages)
NonSI (old Modelica.SIunits.Conversions.NonSIunits)
Conversions (same as before but with the NonSIunits removed)

The benefit of 2a is:

We can use the recommended import:

import Modelica.Units.SI;

Modelica.Units.SI can continue to strictly follow is ISO standard
Greater freedom of adding useful (and practically used) units under Modelica.Units.NonSI though it might be an idea to put those (and the ones inside the existing NonSI) simply under Modelica.Units.Other

Option 2a makes sense to me and I am in favor of it. I do, however, not understand what

Modelica.Units.SI can continue to strictly follow is ISO standard

means. As I have also no access to the ISO 80000 standard, I am not sure how I exactly stick to the standard. Or does that mean that we strictly keep only SI units in this package?

That is of course a problem. In practice it probably means unless somebody with access to the ISO standard can document that a unit is SI then it can be added there otherwise it simply is added to Modelica.Units.Other. This probably means that the content of Modelica.Unitis.SI will stay as it is as per today.

Option 2a looks good and is fine for me.
However, since this influences practically every existing model, other people of the MAP lib group and the tool vendors should give their opinion (especially regarding issues with automatic conversion).

That is of course a problem. In practice it probably means unless somebody with access to the ISO standard can document that a unit is SI then it can be added there otherwise it simply is added to Modelica.Units.Other. This probably means that the content of Modelica.Units.SI will stay as it is as per today.

I understand the general direction, but the concrete details seem doubly problematic:

The existing Modelica.Units.SI likely contains some units that shouldn't be there (or with wrong name); having some special preference for them seems odd.
Even if someone has access to the ISO 80000 standard I doubt that they are allowed to just copy every definition of the standard.

I'm also unsure if ISO 80000 really standard really defines the units in such an unambiguous way (the SI-standard itself doesn't really).
TL;DR: To me it doesn't make sense that we base something on something we haven't read.
The SI-standard itself is freely accessible.

The SI-standard itself is freely accessible.

@HansOlsson So you suggest to check the content of SIUnits against the freely accessible SI-Standard (do you have a link?) or what is it you are suggesting should be done?

@dietmarw Do you mean https://www.bipm.org/en/measurement-units/ ?

I'm just trying to find a solution as to what our claim should be. Just the 7 Base SI units can not be the answer.

There are also some derived and non-SI units to be found in the SI broschure. But I understand. We need more.

There are also some derived and non-SI units to be found in the SI broschure. But I understand. We need more.

True, one possibility is that we allow other derived units as long as they are derived SI-units (without prefixes). That seems to be what we already do - but it is clearly ad-hoc.

Option 2a+"Other" is fine with Wolfram (SystemModeler).

So I started working on the ticket and finished already the structure of Modelica.Units itself. When then updating the references in MSL itself it became clear that I really need to wait with this until all currently outstanding PRs for 4.0.0 are merged. Otherwise the references need to be updated twice. So I hope we can get the open PRs done by Jan 2020 and then announce a kind of "week(s) of PR silence".

Some more thoughts on how I'm going to proceed. Currently we have a mixture of absolute class name use (i.e., Modelica.SUunits.) and making use of named imports (i.e., SI.). Now thanks to the new structure the later usage will no longer depend on named imports but can use the simple import:
import Modelica.Units.SI

So in order to keep the changes due to the restructure of the SIunits package within the MSL to a minimum (least classes being touched) I'll do it in these steps (after SIunits has been changed to Units.):

Rename/update all non-SI references
Rename all "SI"-Modelica.SIunits. to SI.
In order that those class references can work I will add one top-level import:

import Modelica.Units.SI

and at the same time getting rid of all (now unnecessary) lower level SI imports.
So for the future when inside the MSL the developers can always be able to use SI. types without having to worry about adding another import statement.

In order that those class references can work I will add one top-level import:
import Modelica.Units.SI
and at the same time getting rid of all (now unnecessary) lower level SI imports.
So for the future when inside the MSL the developers can always be able to use SI. types without having to worry about adding another import statement.

Three notes:

Remember that this procedure will not work in encapsulated classes, as the import isn't found.
Stylistically I'm not too keen on relying on such imports.
Remember: if you want to copy an example for use outside of MSL use "New>Duplicate class" in Dymola (and something corresponding in other tools); don't just copy the text.

* Remember that this procedure will not work in encapsulated classes, as the import isn't found.

Yes I'll look out for those.

* Stylistically I'm not too keen on relying on such imports.

I understand but since these kinds are already in place it makes more sense to keep those (i.e., no change) and just update the others to have one consistent way within the MSL.

* Remember: if you want to copy an example for use outside of MSL use "New>Duplicate class" in Dymola (and something corresponding in other tools); don't just copy the text.

I know but I think this is something that we can live with.

Remember: if you want to copy an example for use outside of MSL use "New>Duplicate class" in Dymola (and something corresponding in other tools); don't just copy the text.

I know but I think this is something that we can live with.

Alternatively we could use
import Modelica.Units.SI

in each model where SI units are used. I know this implementation requires a lot more changes, but it is then more obvious to new Modelica users, what, e.g.,  SI.Voltage means. It also solves the problem of the missing import Modelica.Units.SI when duplicating a model.

That would be the exact opposite than what I would consider a clean implementation. Having unnecessary code duplication goes against the whole idea of Modelica with its object oriented features. Taking care of the class rename is basically a tool issue.

The problem is that there are currently no tool features (recommended by the Modelica Specification) which allow the user to understand what imports are used in a specific model. This is the reason why I somehow dislike package specific imports, which I can never understand without knowing where the import is implemented in the code.
However, I yet agree with your point of view, that it makes sense to use object oriented features and to avoid redundant code. So using one import in the top package makes sense to me -- even though it will the be difficult to new Modelica users to understand the code.

I perfectly get your point but need to decide to either:

make the change of the unit structure as least invasive (least changes) as possible. This would mean leave all SI. type references as they are and only change the current SIunits references.
use absolute class references everywhere. This would basically change almost every single model.

What I don't want is a mixture of both inside the MSL.

I discussed this with @beutlich and will wait to create the PR until after feature freeze. Since this is not a new feature but a reorganisation and would otherwise disturb the current surge in feature PRs.


Replace constant stat polling with server-sent events

At the moment webui is constantly polling following HTTP API endpoints:

/api/v0/stats/bw
/api/v0/swarm/peers
/api/v0/repo/stat
/api/v0/config/show

This is has few unfortunate consequences:

Increases pressure on network IO limits that browsers have.
Inceases overhead on the HTTP API of IPFS node (draining battery).
Harms dev experience due to noise in the network panel.

Describe the solution you'd like
EventSource is a standard web API that provides interface to  server-sent-events as replacement for ong-polling pattern (that browsers can optimize to discard consumed input).
Describe alternatives you've considered
Alternatively we could use fetch body to read updates from ReadableStream, but that is less widely supported than EventSource API. Also unlike EventSource that is push based, ReadableStreams are push & pull which could lead to buffering on the client if not actively consumed, which would not be the case with EventSource.
Additional context
I am realizing this conversation reaches beyond webui into IPFS HTTP API, but I'm going to fill relevant issues there as well and interlink those.

Another solution would be to have websockets handle these kinds of updates.
I know that involves a higher number of changes, but I believe it's the most efficient approach to this.

@rafaelramalho19 the problem with Websockets is that when used from a Secure Context they require the other end to also be a Secure Context, making it impossible to use API over LAN IP without  setting up TLS. EventSource does not have that limitation and may be easier to add, as it does not require opening any new ports or creating new APIs.
@Gozala I agree its worth exploring. This would not only benefit WebUI, but also Desktop and Companion. I converted existing https://github.com/ipfs/in-web-browsers/issues/140 to an epic – feel free to opdate its description and link relevant issues to it.


RuntimeBinderException coming from write async

I'm not really sure how I got this exception but I think its happening when an empty object is passed into the enhancer at the end of configure store like this:
export default function configureStore(initialState, history) {
    const state = {};

    const enhancer = compose(
      applyMiddleware(thunk),
      applyMiddleware(routerMiddleware(history)),
      devTools
    )(createStore);

    return enhancer(reducers, state);
}

Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: The call is ambiguous between the following methods or properties: 'System.IO.TextWriter.WriteAsync(string)' and 'System.IO.TextWriter.WriteAsync(char[])'
   at CallSite.Target(Closure , CallSite , TextWriter , Object )
   at CallSite.Target(Closure , CallSite , TextWriter , Object )
   at JavaScriptViewEngine.JsViewEngine.JsView.<RenderAsync>d__8.MoveNext()

It appears to be coming from one of these two lines:
https://github.com/pauldotknopf/JavaScriptViewEngine/blob/75c0027f004e5af17f41a438bc9fadf239683e8a/src/JavaScriptViewEngine/JsViewEngine.cs#L156
https://github.com/pauldotknopf/JavaScriptViewEngine/blob/75c0027f004e5af17f41a438bc9fadf239683e8a/src/JavaScriptViewEngine/JsViewEngine.cs#L160
I'll try to set up a project tonight that makes this reproducible for you since I can't share the project the error is happening in.

Thanks for reporting this.
Are you running from source, or from NuGet? If from NuGet, what package are you using?

from nuget, version 1.2.2

Ah, that is out dated.
Use this NuGet package.
https://www.nuget.org/packages/JavaScriptViewEngine.MvcCore1/
The version you are using is using embedded V8. We moved away from that to a nodejs implementation.

my apologies that new package didn't even come up when I searched JavaScriptViewEngine. I'll install it and try it tomorrow.

@pauldotknopf Its working now. Thanks!


Support IPv6 in local_settings.py get_pod_ip()

OSPRH-6238

So, this is wrong - we want the POD IP - not resolving horizon-openstack.apps ...

So, this is wrong - we want the POD IP - not resolving horizon-openstack.apps ...

Done.


Use pipelinerun with scan status for commits & integration tests tabs

Fixes
https://issues.redhat.com/browse/RHTAPBUGS-255

Description
The pipelinerun scan status row was recently updated to use pipelinerun object with augmented scan status, but the commits & integration tests tabs were not updated along with it.

Type of change

[ ] Feature
[x] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

Screen shots / Gifs for design review

Browser conformance:

[ ] Chrome
[x] Firefox
[ ] Safari
[ ] Edge

/cc @jeff-phillips-18 @rohitkrai03

/lgtm
/approve

Can we do conditional label filtering using the API? I wasn't able to find a way for this
      pipelineRunsWithStatus?.filter(
        (plr) =>
          plr?.metadata?.labels[PipelineRunLabel.COMMIT_LABEL] === commitName ||
          plr?.metadata?.labels[PipelineRunLabel.TEST_SERVICE_COMMIT] === commitName,
      ) || [],

/retest

@rottencandy yes you can use matchExpressions with operators in selectors.
I'm going to log a separate bug to capture improvements in our queries

/lgtm


Updated to Node 4.2.2. Unable to install module.

After updating to Node.js 4.2.2 on Mac 10.11.1 and Xcode 7.1. I get the following error. Any idea what might be causing it?

><EMAIL_ADDRESS>install /Users/rayhwang/Projects/xxxxxxxx/Web/node_modules/sharp
> node-gyp rebuild

  CXX(target) Release/obj.target/sharp/src/common.o
  CXX(target) Release/obj.target/sharp/src/utilities.o
In file included from ../src/utilities.cc:4:
../node_modules/nan/nan.h:324:27: error: redefinition of 'NanEnsureHandleOrPersistent'
  NAN_INLINE v8::Local<T> NanEnsureHandleOrPersistent(const v8::Local<T> &val) {
                          ^
../node_modules/nan/nan.h:319:17: note: previous definition is here
  v8::Handle<T> NanEnsureHandleOrPersistent(const v8::Handle<T> &val) {
                ^
../node_modules/nan/nan.h:344:27: error: redefinition of 'NanEnsureLocal'
  NAN_INLINE v8::Local<T> NanEnsureLocal(const v8::Handle<T> &val) {
                          ^
../node_modules/nan/nan.h:334:27: note: previous definition is here
  NAN_INLINE v8::Local<T> NanEnsureLocal(const v8::Local<T> &val) {
                          ^
../node_modules/nan/nan.h:757:13: error: no member named 'smalloc' in namespace 'node'
    , node::smalloc::FreeCallback callback
      ~~~~~~^
../node_modules/nan/nan.h:768:12: error: no matching function for call to 'New'
    return node::Buffer::New(v8::Isolate::GetCurrent(), data, size);
           ^~~~~~~~~~~~~~~~~
/Users/rayhwang/.node-gyp/4.2.2/include/node/node_buffer.h:31:40: note: candidate function not viable: no known conversion from
      'uint32_t' (aka 'unsigned int') to 'enum encoding' for 3rd argument
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
/Users/rayhwang/.node-gyp/4.2.2/include/node/node_buffer.h:43:40: note: candidate function not viable: 2nd argument ('const char *')
      would lose const qualifier
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
/Users/rayhwang/.node-gyp/4.2.2/include/node/node_buffer.h:28:40: note: candidate function not viable: requires 2 arguments, but 3 were
      provided
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate, size_t length);
                                       ^
/Users/rayhwang/.node-gyp/4.2.2/include/node/node_buffer.h:36:40: note: candidate function not viable: requires 5 arguments, but 3 were
      provided
NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                       ^
In file included from ../src/utilities.cc:4:
../node_modules/nan/nan.h:772:12: error: no viable conversion from 'v8::MaybeLocal<v8::Object>' to 'v8::Local<v8::Object>'
    return node::Buffer::New(v8::Isolate::GetCurrent(), size);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:210:7: note: candidate constructor (the implicit copy constructor) not viable: no
      known conversion from 'v8::MaybeLocal<v8::Object>' to 'const v8::Local<v8::Object> &' for 1st argument
class Local {
      ^
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:210:7: note: candidate constructor (the implicit move constructor) not viable: no
      known conversion from 'v8::MaybeLocal<v8::Object>' to 'v8::Local<v8::Object> &&' for 1st argument
class Local {
      ^
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:214:13: note: candidate template ignored: could not match 'Local' against
      'MaybeLocal'
  V8_INLINE Local(Local<S> that)
            ^
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:326:13: note: candidate template ignored: could not match 'S *' against
      'v8::MaybeLocal<v8::Object>'
  V8_INLINE Local(S* that)
            ^
In file included from ../src/utilities.cc:4:
../node_modules/nan/nan.h:779:26: error: no member named 'Use' in namespace 'node::Buffer'
    return node::Buffer::Use(v8::Isolate::GetCurrent(), data, size);
           ~~~~~~~~~~~~~~^
In file included from ../src/utilities.cc:1:
In file included from /Users/rayhwang/.node-gyp/4.2.2/include/node/node.h:42:
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:221:5: error: assigning to 'v8::Primitive *volatile' from incompatible type
      'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:501:12: note: in instantiation of function template specialization
      'v8::Local<v8::Primitive>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(v8::Undefined(v8::Isolate::GetCurrent())));
           ^
../node_modules/nan/nan.h:483:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(Nan::imp::NanEnsureLocal(val))
                             ^
In file included from ../src/utilities.cc:1:
In file included from /Users/rayhwang/.node-gyp/4.2.2/include/node/node.h:42:
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:221:5: error: assigning to 'v8::Boolean *volatile' from incompatible type
      'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:511:12: note: in instantiation of function template specialization 'v8::Local<v8::Boolean>::Local<v8::Value>'
      requested here
    return NanEscapeScope(NanNew(v8::True(v8::Isolate::GetCurrent())));
           ^
../node_modules/nan/nan.h:483:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(Nan::imp::NanEnsureLocal(val))
                             ^
In file included from ../src/utilities.cc:1:
In file included from /Users/rayhwang/.node-gyp/4.2.2/include/node/node.h:42:
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:221:5: error: assigning to 'v8::Function *volatile' from incompatible type
      'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:1645:12: note: in instantiation of function template specialization
      'v8::Local<v8::Function>::Local<v8::Value>' requested here
    return NanEscapeScope(NanNew(handle)->Get(kCallbackIndex)
           ^
../node_modules/nan/nan.h:483:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(Nan::imp::NanEnsureLocal(val))
                             ^
In file included from ../src/utilities.cc:1:
In file included from /Users/rayhwang/.node-gyp/4.2.2/include/node/node.h:42:
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:221:5: error: assigning to 'v8::Object *volatile' from incompatible type
      'v8::Value *'
    TYPE_CHECK(T, S);
    ^~~~~~~~~~~~~~~~
/Users/rayhwang/.node-gyp/4.2.2/include/node/v8.h:180:37: note: expanded from macro 'TYPE_CHECK'
    *(static_cast<T* volatile*>(0)) = static_cast<S*>(0);      \
                                    ^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:1776:12: note: in instantiation of function template specialization 'v8::Local<v8::Object>::Local<v8::Value>'
      requested here
    return NanEscapeScope(
           ^
../node_modules/nan/nan.h:483:30: note: expanded from macro 'NanEscapeScope'
# define NanEscapeScope(val) scope.Escape(Nan::imp::NanEnsureLocal(val))
                             ^
10 errors generated.
make: *** [Release/obj.target/sharp/src/utilities.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:270:23)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 15.0.0
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /Users/rayhwang/Projects/xxxxxxx/Web/node_modules/sharp
gyp ERR! node -v v4.2.2
gyp ERR! node-gyp -v v3.0.3
gyp ERR! not ok
npm ERR! Darwin 15.0.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "sharp"
npm ERR! node v4.2.2
npm ERR! npm  v2.14.7
npm ERR! code ELIFECYCLE

npm ERR<EMAIL_ADDRESS>install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the sharp package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls sharp
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/rayhwang/Projects/xxxxxxx/Web/npm-debug.log

Hi Ray, support for Node v4 was added in sharp v0.11.2.


Add Modern Chinese

Adding the Modern Chinese Parser using hanlp (The English version document seems not good. 😞) which I think the parsed result is very nice.
It requires Pytorch, Tensorflow, so by default the is_supported() return False, until user installed the hanlp by pip.
It needs to download model, and the path is configurable . About model path configuration: https://hanlp.hankcs.com/docs/configure.html

Local branch rebased, this pr can not sync the new changes, will create a new PR


Update example syntax

Was trying out the plugin and in the midst of copy-pasting when I got a syntax error. Sorry that the PR is so small. This would make my first public PR by the way, hope it helps!

Hey, thank you for spotting this and thanks for the contribution!
That's my bad, this is just something I quickly wrote down without testing because I don't use this exact logic in my setup!
I hope you find the plugin useful!


Nested Model update using REST

Hello,
I've encountered some issues while trying to update a model with nested entities using REST. It works fine when the model doesn't have nested entities. Could you please review the following details and let me know if I'm doing something wrong here?
http://localhost:1337/product/d170b9f5-fac3-11e4-80f2-e93099b668ba
HTTP Put Request - Update nested entity field
{
    "inventory": {
        "id": "d16fa884-fac3-11e4-a761-aac656ffae25",
        "availableQty": 4
    }
}

HTTP Put Request - Update first level field
{
    "description": "updated description"
}

Error Response for both the requests above
{
"error": "E_UNKNOWN",
"status": 500,
"summary": "Encountered an unexpected error",
"raw": {
"query": "SELECT id,price,createdat,updatedat FROM productprice WHERE id = ?;"
}
}

Models
api/models/Product.js
module.exports = {

  attributes: {
    id: {type: 'string', primaryKey: true, autoIncrement: true},
    name: {type: 'string', required: true},
    price: {model: 'productPrice'},
    inventory: {model: 'productInventory'}
  }
};

api/models/ProductPrice.js
module.exports = {

  attributes: {
    id: {type: 'string', primaryKey: true, autoIncrement: true},
    price: {type: 'float', required: true, defaultsTo: 0.0, index: true}
  }
};

api/models/ProductInventory.js
module.exports = {

  attributes: {
    id: {type: 'string', primaryKey: true, autoIncrement: true},
    availableQty: {type: 'integer', required: true, defaultsTo: 0, index: true}
  }
};

Thanks for the excellent bug report. I will look into it asap.

For the first request try to spell "availableQty" all lower case "availableqty". I have suspicion that something funny is going on with name conversion. If this works then we found the problem.
For the second case, you do not have "description" attribute in your model. I think you meant "name". Could you please re-test and confirm?

I think for your firts case you need to do something like this:

I get a 404 when I try POST or PUT on '/product/d170b9f5-fac3-11e4-80f2-e93099b668ba/inventory/d16fa884-fac3-11e4-a761-aac656ffae25'.

I tried the lower case 'availableqty' and I still get the same error. Also, retested by changing the field name to 'name' and the error repeats.

The sails-cassandra module is actually a waterline module, so I'm not using sails for testing it at all. I've added a unit test to the master based on your feedback and test to update name passes. The test to update inventory is still work in progress. You can have a look for your reference. I will investigate it little bit further, but at this point it seems that problem you are having is not related to the adapter. BTW, does it work if you use say sails-memory or sails-disk? If you could test and confirm that would be great.