Initial setup error

Operating System: OSX Sierra (10.12.2)
Vagrant Version: 1.9.1
Virtual Box Version: 4.3.38 r106717
When I follow the install instructions on your website, I get the following error on vagrant up:
~/Code/web/my-project on master▲ $ vagrant up
Bringing machine 'lo.dev' up with 'virtualbox' provider...
==> lo.dev: Box 'vccw-team/xenial64' could not be found. Attempting to find and install...
    lo.dev: Box Provider: virtualbox
    lo.dev: Box Version: <= 20161209
==> lo.dev: Loading metadata for box 'vccw-team/xenial64'
    lo.dev: URL: https://atlas.hashicorp.com/vccw-team/xenial64
==> lo.dev: Adding box 'vccw-team/xenial64' (v20161209) for provider: virtualbox
    lo.dev: Downloading: https://atlas.hashicorp.com/vccw-team/boxes/xenial64/versions/20161209/providers/virtualbox.box
==> lo.dev: Successfully added box 'vccw-team/xenial64' (v20161209) for 'virtualbox'!
==> lo.dev: Importing base box 'vccw-team/xenial64'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "/Users/my-username/.vagrant.d/boxes/vccw-team-VAGRANTSLASH-xenial64/20161209/virtualbox/box.ovf", "--vsys", "0", "--vmname", "vccw-xenial64_default_1481252133975_59103_1482532508518_75571", "--vsys", "0", "--unit", "10", "--disk", "/Users/my-project/VirtualBox VMs/vccw-xenial64_default_1481252133975_59103_1482532508518_75571/box-disk1.vmdk"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /Users/my-username/.vagrant.d/boxes/vccw-team-VAGRANTSLASH-xenial64/20161209/virtualbox/box.ovf...
OK.
0%...
Progress state: VBOX_E_IPRT_ERROR
VBoxManage: error: Appliance import failed
VBoxManage: error: Could not create the directory '/Users/my-username/VirtualBox VMs/vccw-xenial64_default_1481252133975_59103_1482532508518_75571' (VERR_ACCESS_DENIED)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component Appliance, interface IAppliance
VBoxManage: error: Context: "int handleImportAppliance(HandlerArg*)" at line 779 of file VBoxManageAppliance.cpp

Any idea how I can fix this?

Seeing that the issue had to do with permissions, I tried running vagrant up with sudo. Running with sudo gives this error:
~/Code/web/my-project on master▲ $ sudo vagrant up
Password:
Bringing machine 'lo.dev' up with 'virtualbox' provider...
==> lo.dev: Importing base box 'vccw-team/xenial64'...
==> lo.dev: Matching MAC address for NAT networking...
==> lo.dev: Checking if box 'vccw-team/xenial64' is up to date...
==> lo.dev: Setting the name of the VM: lo.dev
==> lo.dev: Clearing any previously set network interfaces...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["hostonlyif", "create"]

Stderr: 0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to create the host-only adapter
VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterface, interface IHostNetworkInterface
VBoxManage: error: Context: "int handleCreate(HandlerArg*, int, int*)" at line 66 of file VBoxManageHostonly.cpp

@selbekk
Plase try
$ /Library/StartupItems/VirtualBox/VirtualBox restart

or Re-install VirtualBox.

@torounit - tries that, including uninstalling and reinstalling both virtualbox and vagrant. Made no difference :-(

Ah, you must not use sudo for vagrant command.
If you don't need existing virtual machines.
Please run following.
$ sudo rm -fr ~/VirtualBox\ VMs
$ sudo rm -fr ~/.vagrant.d

Did that, then uninstalled virtualbox and vagrant, then installed the newest versions of virtualbox and vagrant. Then unzipped a new version of vccw, and finally ran all the commands on the website.
When running vagrant up, I get the following error:
$ vagrant up
Bringing machine 'vccw.dev' up with 'virtualbox' provider...
==> vccw.dev: Importing base box 'vccw-team/xenial64'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "/Users/kristoferselbekk/.vagrant.d/boxes/vccw-team-VAGRANTSLASH-xenial64/20161209/virtualbox/box.ovf", "--vsys", "0", "--vmname", "vccw-xenial64_default_1481252133975_59103_1482664712511_5580", "--vsys", "0", "--unit", "10", "--disk", "/Users/kristoferselb/VirtualBox VMs/vccw-xenial64_default_1481252133975_59103_1482664712511_5580/box-disk1.vmdk"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting /Users/kristoferselbekk/.vagrant.d/boxes/vccw-team-VAGRANTSLASH-xenial64/20161209/virtualbox/box.ovf...
OK.
0%...
Progress state: VBOX_E_IPRT_ERROR
VBoxManage: error: Appliance import failed
VBoxManage: error: Could not create the directory '/Users/kristoferselb/VirtualBox VMs/vccw-xenial64_default_1481252133975_59103_1482664712511_5580' (VERR_ACCESS_DENIED)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component ApplianceWrap, interface IAppliance
VBoxManage: error: Context: "RTEXITCODE handleImportAppliance(HandlerArg *)" at line 886 of file VBoxManageAppliance.cpp

Ah, it was - of course - my own fault. I've previously changed my username from kristoferselb to kristoferselbekk, because reasons, and I guess it wasn't updated in virtualbox :)
Either way, closing this. Thanks for helping out!

You can remove the ~/.config/VirtualBox folder.


Escape Nodelet/tag names for Dot as well.

This escaping requirement was previously leaking into the implementation
of graph.go, by writing \n directly instead of "\n". This meant that
if it was displayed in a different program besides dot, it would have
been potentially incorrectly escaped.
Now, this commit moves all the escaping directly into dotgraph, which is
more encapsulated, and also allows us to escape other characters in the
name which need escaping.
This required adding a justify option to escapeForDot to preserve old behavior.
This allows tag newlines to stay center justified, and legend label
newlines to stay left justified, as they were before we started escaping
them for Dot.

This PR is a follow-up to https://github.com/google/pprof/pull/564, opened here instead of https://github.com/google/pprof/pull/568.

Codecov Report

Merging #1 into nhd-dotgraph-escape-labels will decrease coverage by 0.40%.
The diff coverage is 94.44%.

@@                      Coverage Diff                       @@
##           nhd-dotgraph-escape-labels       #1      +/-   ##
==============================================================
- Coverage                       67.12%   66.72%   -0.41%
==============================================================
  Files                              39       39
  Lines                            7033     7041       +8
==============================================================
- Hits                             4721     4698      -23
- Misses                           1899     1928      +29
- Partials                          413      415       +2

Impacted Files
Coverage Δ

internal/graph/graph.go
27.87% <0.00%> (ø)

internal/graph/dotgraph.go
90.62% <100.00%> (+0.34%)
:arrow_up:

internal/binutils/binutils.go
47.11% <0.00%> (-12.00%)
:arrow_down:

internal/driver/commands.go
25.83% <0.00%> (-1.67%)
:arrow_down:

internal/report/source.go
80.76% <0.00%> (-0.65%)
:arrow_down:

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 dff1afc...8c597aa. Read the comment docs.

closing this stale PR


Fix services stopping logic

Goal

Testing

Release Notes

WHAT:
WHY:
WHO:

#873  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bidetofevil and the rest of your teammates on  Graphite


Tile buffer overlay with -b 0

Firstly thanks for making this wonderful tool, really love it!
I'm having some issues configuring Tippecanoe correctly. I'm experiencing buffer overlays in the tiles when exporting, even though I've set -b 0
Please see attached screenhot.
I use the following command:
sudo nohup tippecanoe -o transport-z12.mbtiles -t /mnt/volume_ams3_02/tmp/ -Z7 -z12 -f -F -ps -pf -pk -pt -Bg -d12 -b 0 transportation-layer-z12.geojson &
Can any one spot what I'm doing wrong?

The only thing that stands out as weird is the use of -F, which would allow you to write new data into an existing tileset, but I don't see how that would affect the buffer size.


KeyError(select('not(mod(n,9))')

Hello, I'm trying to run a select filter to extract frames but I'm getting a KeyError. The code looks like this:
stream = ffmpeg.input(mov_file)
filter_str = r"not(mod(n\," + str(int(mod_n)) + "))"
stream = stream.filter('select', filter_str)
out_str = out_folder + '/' + mov_file[:-4] + "-%03d.png"
stream.output(out_str)
ffmpeg.run(stream)

mod_n is a float. I printed the filter_str and got filter_str: not(mod(n\,9))
The error is: KeyError(select('not(mod(n\\,9))') <1b654db963fc>)
The select filter works okay from the command line. Any ideas what I'm doing wrong?

Looks like it has something to do with splitting the stream over multiple lines. If the filter is run like this
ffmpeg.input(..).filter(...).output(...).run()
then it works


[performance test] Fetch image size of spiffe related service

🚀 Feature Request
Relevant Package [REQUIRED]

 This feature request is for...
edgex-go #3968
Description [REQUIRED]
 A clear and concise description of the problem or missing capability...
Describe the solution you'd like
 If you have a solution in mind, please describe it.
Fetch image size for new services.
Describe alternatives you've considered
 Have you considered any alternative solutions or workarounds?

Fixed by #704


Change reference to latest nanogui

The new version of nanogui works as a simple drop-in after updating the gitmodule reference.

@meshula I’m closing this PR for now, but feel free to reopen when your latest work is ready to test!


v2.0.0 breaks async: false

Current behavior
If I have async: false, our webpack build (webpack-dev-serverwill not finish and just stuck atwait until bundle finished`
Expected behavior
In v1.6.0, this does not happen.
Steps to reproduce the issue
I am using this plugin with eslint, typescript-eslint, webpack and ts-pnp (similar to the setup of create-react-app).
I have async: false in webpack config and that's when I see problem with 2.0.0. async:false is kind of important to me because I want to fail the webpack build when there are type issues (warning or error), also I want webpack to be the reporter of error because I have a decent error format reporter there :). As such I want to block webpack build to finish until this plugin's done with checking type, but somehow after upgrading to 2.0.0 that nolonger happens.
Issue reproduction repository
Really sorry the project I'm working on doesn't have a public repo so it would take me time to create a repo for this
Environment

fork-ts-checker-webpack-plugin: 2.0.0
typescript: 3.6.4
webpack: 4.41.2
os: Windows 10

P/S: Honestly though the more I think about this the more I want to ask you guys what's your view on this? Do you want to fail a build when there are typescript/linting errors?
I don't know of a way to have async:true and still fail webpack compilation build using this plugin` :(, let me know if I miss some config. Thanks!

This is related to @fatme PR here: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/337
cc @piotr-oles

If I have async: false, our webpack build (webpack-dev-serverwill not finish and just stuck atwait until bundle finished`

I'm guessing you're running in watch mode rather than doing a production build?

Do you want to fail a build when there are typescript/linting errors?

Most definitely. But speaking for myself (and create-react-app does the same) I only run with async: false for the production build.
I'm not totally clear what the issue is here; we won't be able to do much without a repro repo I'm afraid.

Hello,
I can confirm that this is indeed an issue. I will try to create a repro.

@johnnyreilly Sorry it will take me time to build a repro repo. In the meantime I did a little bit of digging. I just needed to change this line back to use emit.
Also another thing, when I'm building production (i.e. not in watch mode and async=false), I notice emit is called multiple times if afterCompile hook is used
but only called one when emit hook is used.

Hello,
I did some testing and was able to create a repro. You can find it here
https://github.com/swashata/fork-ts-checker-issue
The thing is

If there is a style.scss or style.less import, then the plugin fails in async:false mode.
If there are more than one style.scss or style.less import, then the plugin hangs in async:false mode.

Kindly read the README of the repository for more information. If I comment out both the style file imports, then the plugin works just fine.

Also

Also another thing, when I'm building production (i.e. not in watch mode and async=false), I notice emit is called multiple times if afterCompile hook is used  but only called one when emit hook is used.

You are correct about this. I was working on my tooling wpackio and I notice this behavior. The afterCompile I believe is called for every files compiled? (entrypoint, chunk files etc).

Thanks all - let's use this issue as a place to discuss this. @fatme can you be part of this if possible?
We want to land on a solution that suits all parties; it sounds at present that 2.0.0 works well for @fatme use cases but not for @blacksteed232 and @swashata.
Let's see if we can work towards a future which serves all cases.
I'm wondering if the (now default) behaviour introduced in 2.0.0 should actually be opt in as described here: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/337#issuecomment-545594920  (Though I'm not generally keen on a multitude of behaviours in the same plugin. Let's see.)

Yeah,
But I am most interested in the part that why in async:false mode, the plugin fiddles with what comes from style files. And if there is more than one style file it completely hangs.
I must say I am relieved though. Have been banging my head over wall to figure out why the build was failing. At first I thought, it was something to do with mini-css-extract-plugin, but it turns out to be this.
One thing I would like to add more is that, if I use style-loader instead of MiniCssExtractPlugin.loader, the issue just goes away.

Thanks for the repro repo @swashata - that's super helpful. Given that 2.0.0 clearly has a number of issues I think it's wise if we revert the changes of
https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/337/files
And release that as 3.0.0. This will ensure that people installing the plugin don't get broken. That's super important.
Would someone be up for raising that PR please? Please note this will be a breaking changes release as it's changing behaviour of the plugin. (Just as the change that took us from 1.6.0 to 2.0.0 was)
Thanks!

Very strangely, this issue affected me with one entry point, but not another of the multi-compiler entries in the same build; both use typescript and the same tsconfig.json. But yes, can confirm that rolling back to <2.0.0 avoids the breakage.

3.0.0 should be out later today which will resolve this issue.

:tada: This issue has been resolved in version 3.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

@johnnyreilly am I missing something, I thought this line is supposed to be reverted to emit right? (based on this commit)
Just tried 3.0.0 and I still see the problem.

@piotr-oles @blacksteed232 same here, still just hangs after modules are handled.

Indeed, 3.0.0 still freezes.

Okay - let me take a look

Okay just force merged https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/pull/353/files
A new release should appear with the fix in the next couple of hours.  v3.0.1.  Serves me right for merging in the middle of a sleepless night.   Ah well.

:tada: This issue has been resolved in version 3.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


#877 breaks runtime build

#877 changed the git branch setup used for testing under Jenkins. The problem is it breaks the runtime build:
16:48:06      CHECK   check-go-static
16:48:06      TEST    check-go-test
16:48:06 INFO: Running 'go test' as current user on packages '.' with flags '-v -race -timeout 10s'
16:48:15 # github.com/clearcontainers/runtime
16:48:15 /tmp/go-build333502155/github.com/clearcontainers/runtime/_test/_obj_test/cc-env.go:370:8: undefined: envCmd
16:48:15 /tmp/go-build333502155/github.com/clearcontainers/runtime/_test/_obj_test/delete.go:37:46: undefined: name

The problem I think is this:

.ci/jenkins_job_build.sh now creates a PR branch.
It then runs https://github.com/clearcontainers/runtime/blob/master/.ci/setup.sh
The runtimes setup.sh script then runs checkcommits.
Next, setup.sh calls back into the tests repo by running https://github.com/clearcontainers/tests/blob/master/.ci/setup.sh.
The tests setup.sh script then calls install_runtime.sh to build the runtime.
Control returns to .ci/jenkins_job_build.sh when then merges the commits from the PR branch into master.
The git reset deletes the runtime's auto-generated config-generated.go file.
.ci/jenkins_job_build.sh then calls https://github.com/clearcontainers/runtime/blob/master/.ci/run.sh which calls make check in the runtimes repo.
This invokes https://github.com/clearcontainers/runtime/blob/master/.ci/go-test.sh which calls go test.
go test fails because it cannot find all the source since config-generated.go was deleted above.

Digging further, the problem seems to be caused by the runtime's post-checkout git hook:

https://github.com/clearcontainers/runtime/blob/master/Makefile#L584..L598

I guess the simplest solution is to only install those if the CI envvar is not set.


Include -rtsopts in all builds

I'm not aware of any downside to doing this, and it'd be helpful for testing for me (I'd like to add some tests which verify a thing runs in constant memory by running it with a tiny heap).
/cc @ambiata/engineers

@olorin Why not in the cabal file? feels a bit funny having the default build options tied to mafia rather than the cabal file. As an alternative is it enough to say the default in our cabal files is to have this set. Or am I understating the importance of this, as in is it never valid to not have it set and is valid for mafia to be more opinionated than ghc in this case?

@markhibberd you're right, there's no reason to put this in mafia rather than in cabal files, not sure what I was thinking.


Can't use ThumbnailMixin when customising the ModelAdmin on a model with the example method "main_image" from tutorial

Issue Summary
My model has many related children which each contain an image. Using the "main_image" method from the wagtail tutorial, I believe I should be able to use this as the 'admin_thumb' field.
AttributeError at /admin/gallery/galleryitem/
Unable to lookup 'admin_thumb' on GalleryItem or GalleryItemAdmin

wagtail_hooks.py
class GalleryItemAdmin(ModelAdmin):
    model = GalleryItem
    menu_label = 'All Gallery Items'  # ditch this to use verbose_name_plural from model
    menu_icon = 'pick'  # change as required
    menu_order = 000  # will put in 3rd place (000 being 1st, 100 2nd)
    add_to_settings_menu = False  # or True to add your model to the Settings sub-menu
    exclude_from_explorer = False # or True to exclude pages of this type from Wagtail's explorer view
    list_display = ('title', 'description', 'admin_thumb')
    thumb_image_field_name = 'main_image'

models.py
class GalleryItem(Page):
    description = models.CharField(blank=True, max_length=250)

    # @property  >>> this didn't make any difference
    def main_image(self):
        img = self.gallery_images.first()
        if img:
            return img.image
        else:
            return None

class GalleryImage(Orderable):
    item = ParentalKey(GalleryItem, on_delete=models.CASCADE, related_name='gallery_images')
    image = models.ForeignKey(
        'wagtailimages.Image', on_delete=models.CASCADE, related_name='+'
    )

Steps to Reproduce
As explained in the documentation.
https://docs.wagtail.io/en/v2.10.1/reference/contrib/modeladmin/indexview.html#wagtail-contrib-modeladmin-mixins-thumbnailmixin

@jeffykle you need to actually apply the mixin to your ModelAdmin class in order to be able to use admin_thumb.


subkey build error on macos 12.4(M1)

Is there an existing issue?

[X] I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

[X] This is not a support question.

Description of bug
env info
macos 12.4 M1
rust:

stable-aarch64-apple-darwin (default)
nightly-aarch64-apple-darwin
rustc 1.61.0 (fe5b13d68 2022-05-18)

substrate: v2.0.1
exec
cargo install --force --git https://github.com/paritytech/substrate subkey

error info
error[E0308]: mismatched types
   --> client/executor/wasmi/src/lib.rs:718:35
    |
718 |         Module::from_parity_wasm_module(blob.into_inner()).map_err(|_| WasmError::InvalidModule)?;
    |         ------------------------------- ^^^^^^^^^^^^^^^^^ expected struct `parity_wasm::elements::module::Module`, found a different struct `parity_wasm::elements::module::Module`
    |         |
    |         arguments to this function are incorrect
    |
    = note: perhaps two different versions of crate `parity_wasm` are being used?
note: associated function defined here
   --> /Users/renshiwei/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/wasmi-0.9.1/src/lib.rs:494:12
    |
494 |     pub fn from_parity_wasm_module(module: parity_wasm::elements::Module) -> Result<Module, Error> {
    |            ^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `sc-executor-wasmi` due to previous error
warning: build failed, waiting for other jobs to finish...
warning: `sp-runtime` (lib) generated 1 warning
error: failed to compile `subkey v2.0.1 (https://github.com/paritytech/substrate#a0a40adb)`, intermediate artifacts can be found at `/var/folders/by/x5x4lkyj0291vnkh4__x4g6m0000gn/T/cargo-install9KxI71`

Steps to reproduce
No response

Execute the following command to solve the problem:
cargo install --force subkey --git https://github.com/paritytech/substrate --version 2.0.1 --locked

Should be fixed now, I yanked the problematic crate: https://github.com/paritytech/wasm-instrument/issues/20


Allow changing of Titlebar colour on Windows

This will allow apps to have title bar match the theme.

This would require client decorators as far as I know. I'm not sure that's possible on Linux or OSX so it would need to be a windows-specific functionality.

Windows-specific would be good. Can title bar be hidden on the other platforms?

Linux

X11 uses external decorations rendered by window manager. You can mark window as a borderless one, but it will break some nice stuff like titlebar merging with global menu when window is maximized

I'm closing this as we can now ShowSystemDecorations = false


Cluster assignments learning for Graph classification

Hi @RexYing ,
Thank you for your work and for the code.
I have a question related to cluster assignments in the context of graph classification.
How do you initialize the number C of clusters  and how to get  the assignments cluster for each node.
Given x of dimension (30,256) where 30 is the number of nodes and  256  the dimension of features. Where x is the output of my convolutional layer. A is an adjacency matrix of dimension (30,30).
How can l get S the assignments matrix of dimension (30,C) given x and A.
Thank you

C is chosen to be, e.g. assign-ratio * num nodes, where assign-ratio could be 0.1, 0.25 etc.
In practice, since graph sizes vary, it might not be the best number of clusters for a particular graph data in the dataset. However, we observe that by encouraging sparsity, only a few clusters out of C maximum number of clusters are used. Depending the the objective, the assignment network can find suitable number of clusters/hyper-node for each different input graph.
The weight matrix in your example should be of dimension (30, C) for the assignment network, so that the output matches the number of clusters.

@RexYing
Could you maybe elaborate on how you encourage the sparsity in your network?


New Device - wipro B22D 12.5W Wi-Fi Smart LED Bulb

Link: wipro B22D 12.5W Wi-Fi Smart LED Bulb
Dump: dump.zip

Added as Wipro NS1220 B22D 12.5W Smart Bulb


Feature/spade duration

Change of the calculation of the duration as part of signature, plus some typos

@p-bouss are you making any progress on this? kick me if you need help (with tests, whatsoever)

@p-bouss are you making any progress on this? kick me if you need help (with tests, whatsoever)

Effectively, I think, I'm done. I only did small changes. The thing of the Code factor would be a much bigger issue of the structure of SPADE.
And the test works on my local system and environment. There I don't know, why the Travis CI does not do it.
Output of test:
test_fpgrowth_fca (main.SpadeTestCase) ... fim.so is found.
ok
test_parameters (main.SpadeTestCase) ... Time for data mining: 0.022835969924926758
Time for stability computation: 0.001313924789428711
Time for pvalue spectrum computation: 0.58880615234375
Time for data mining: 0.01697087287902832
Time for stability computation: 0.002855062484741211
Time for pvalue spectrum computation: 0.6112940311431885
Time for data mining: 0.01685190200805664
Time for stability computation: 0.0027272701263427734
Time for pvalue spectrum computation: 0.6162209510803223
Time for data mining: 0.0161740779876709
Time for stability computation: 7.867813110351562e-06
ok
test_parameters_3d (main.SpadeTestCase) ... Time for pvalue spectrum computation: 0.5960729122161865
Time for data mining: 0.01649308204650879
Time for stability computation: 0.0011250972747802734
Time for pvalue spectrum computation: 0.592825174331665
Time for data mining: 0.017222881317138672
Time for stability computation: 0.0028259754180908203
ok
test_pattern_set_reduction (main.SpadeTestCase) ... Time for pvalue spectrum computation: 0.42499399185180664
Time for data mining: 0.01402902603149414
Time for stability computation: 0.0018770694732666016
ok
test_spade_cpp (main.SpadeTestCase) ... Time for pvalue spectrum computation: 11.59470796585083
Time for data mining: 0.17986702919006348
Time for stability computation: 0.007178783416748047
ok
test_spade_msip (main.SpadeTestCase) ... Time for pvalue spectrum computation: 0.6200377941131592
Time for data mining: 0.01690220832824707
Time for stability computation: 0.0027899742126464844
ok
test_spade_msip_3d (main.SpadeTestCase) ... Time for pvalue spectrum computation: 0.6264221668243408
Time for data mining: 0.017107248306274414
Time for stability computation: 0.0027158260345458984
ok
test_spade_raise_error (main.SpadeTestCase) ... ok
test_spade_spectrum_cpp (main.SpadeTestCase) ... ok
test_spectrum (main.SpadeTestCase) ... ok

Ran 10 tests in 17.437s
OK

Coverage increased (+0.04%) to 83.033% when pulling 84244ce355173652a8445286aa129d4d212d48d7 on INM-6:feature/spade_duration into 5b5a02324d8770a8bd4962509ab435a6cc4b3c01 on NeuralEnsemble:master.


Configuration to ignore dotfiles.

This allows ratelimit to run on Kubernetes with configuration from a configmap.

Any changes required? Should I rebase?


cannot save scripts

System information:

Operating system (distribution) and version.  Mac Big Sur 11.5.2
DBeaver version. Version <IP_ADDRESS>109181446
Additional extensions

Connection specification:

Database name and version
Driver name
Do you use tunnels or proxies (SSH, SOCKS, etc)?

Describe the problem you're observing:
when I try to save a file, either by keys combination or file > Save, nothing happens. The File tab keeps with the asterisk.
Steps to reproduce, if exist:
Include any warning/errors/backtraces from the logs

thanks for the report.
closed as a duplicate of #9097


Fixing #1722

This PR fixes the problem described in #1722.
In order to be able to send parcels in batches, we need to serialize them right before sending them. This serialization can't block the current sending thread as we unnecessarily hold back parcels which are to be send in this batch. This eventually leads to deadlocks in some situations.
As such a third serialization pass has been added which is able to wait on futures that aren't ready yet when put_parcel(s) is called. This might be futures that are to be serialized or when a GID exceeds its credits and a incref is needed.

The review comments have been addressed.

LGTM! Thanks!


onEnd event is fired when navigating away from the page

I noticed that even if I do not do tour.start() or tour.restart(), and at the same time - try to navigate away from the page - the onEnd event is fired.

I can't seem to replicate. This is the code I was running:

    <title>Test Page</title>

    A slow page

Is there any more information or an example you can provide?

Closing due to lack of response.


ISPN-7989 Fixed Spring remote test

https://issues.jboss.org/browse/ISPN-7989

Apparently this issue has been already fixed by https://github.com/infinispan/infinispan/commit/1a3d653efe9c8f9cdac058d263f752a6d57282ab#diff-5af2436e9ce44e0c2a8f7d448537bb96L50. Thanks @tristantarrant!


Bump jenkins version as 2.235 is 9 months old

Proposition
Bump jenkins to a more recent version as the one packaged which is 2.235 is 9 months old.
See package included within the image: https://catalog.redhat.com/software/containers/openshift3/jenkins-2-rhel7/581d2f4500e5d05639b6517b?container-tabs=packages -> jenkins-<IP_ADDRESS>0415953-1.el7.noarch
Latest release of jenkins is : https://github.com/jenkinsci/jenkins/releases/tag/jenkins-2.277

Hi @cmoulliard
we are in the process of upgrading to 2.263.3 LTS.

Super :-) When is it planned to release a new image as this one still uses 2.235 - https://catalog.redhat.com/software/containers/openshift3/jenkins-2-rhel7/ ? @akram

we are now on 2.277.x
/close


sofa_env/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py     It didn't work

1.I encountered the following error while running the ”gras_lift_toucheenv.py” script, but I was successful when running the controllable-env.py script：
sofa::simulation::ResetVisitor::processNodeTopDown(sofa::simulation::Node*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*, std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::doExecuteVisitor(sofa::simulation::Visitor*, bool)
sofa::simulation::node::reset(sofa::simulation::Node*)
_PyObject_MakeTpCall
_PyEval_EvalFrameDefault
_PyEval_EvalFrameDefault
_PyFunction_Vectorcall
_PyEval_EvalFrameDefault
PyEval_EvalCode
_PyRun_SimpleFileObject
_PyRun_AnyFileObject
Py_RunMain
Py_BytesMain
__libc_start_main
段错误 (核心已转储)

Meanwhile, I followed the sofa_godot tutorial, but encountered the following error while loading and compiling in the plugin:
[INFO]    [GUIManager] Registered qt as a GUI.
[INFO]    [PluginManager] Loaded plugin: /home/grize/sofa/build/install/lib/libSofa.GUI.Qt.so
[INFO]    [PluginManager] Loaded plugin: /home/grize/sofa/build/install/plugins/MultiThreading/lib/libMultiThreading.so
[INFO]    [PluginManager] Loaded plugin: /home/grize/sofa/build/install/plugins/Sofa.Metis/lib/libSofa.Metis.so
[INFO]    [PluginManager] 70 plugins have been loaded from /home/grize/sofa/build/install/lib/plugin_list.conf
[INFO]    [GUIManager] lastUsedGUI.ini not found; using default GUI.
[WARNING] [Qt] Could not find the Qt platform plugin "xcb" in ""

But in my environment, it is possible to find xcb:
(sofa)  grize@grize-MS-7D90 :~/PycharmProjects/lap_gym-main$ find / -name "libqxcb.so" 2>/dev/null
/opt/nvidia/nsight-systems/2023.4.4/host-linux-x64/Plugins/platforms/libqxcb.so
/opt/nvidia/nsight-compute/2024.1.0/host/linux-desktop-glibc_2_11_3-x64/Plugins/platforms/libqxcb.so
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
/home/grize/PycharmProjects/sofa_env/SOFA/bin/platforms/libqxcb.so
/home/grize/PycharmProjects/sofa_env1/1/sofa_env/SOFA/bin/platforms/libqxcb.so
/home/grize/PycharmProjects/lap_gym-main/sofa_env/SOFA/bin/platforms/libqxcb.so
/home/grize/sofa/build/install_yuan/bin/platforms/libqxcb.so
/home/grize/sofa/build/install/bin/libqxcb.so
/home/grize/sofa/build/install/bin/platforms/libqxcb.so
/home/grize/anaconda3/plugins/platforms/libqxcb.so
/home/grize/anaconda3/envs/surrol/lib/python3.7/site-packages/cv2/qt/plugins/platforms/libqxcb.so
/home/grize/anaconda3/envs/sofa/lib/libqxcb.so
/home/grize/anaconda3/envs/sofa/lib/python3.10/site-packages/cv2/qt/plugins/platforms/libqxcb.so
/home/grize/anaconda3/pkgs/qt-main-5.15.2-h53bd1ea_10/plugins/platforms/libqxcb.so
/home/grize/.local/share/Trash/files/SOFA_v<IP_ADDRESS>_Linux/bin/platforms/libqxcb.so

Hi @Grizemc ,
indeed, there a recent update of SOFA seems to have broken my code for ArticulatedSystemMapping. I will have to look into that.
For SofaGodot, I am currently not maintaining it actively.

Thank you very much! May I ask if I need to lower the version of SOFA to recompile it so that Gras_lift_touchenv.py can function.

你好@Grizemc确实 ，SOFA 的最近一次更新似乎破坏了我的 ArticulatedSystemMapping 代码。我必须调查一下。
对于 SofaGodot，我目前没有积极维护它。

Thank you very much! May I ask if I need to lower the version of SOFA to recompile it so that Gras_lift_touchenv.py can function.

That would probably do as a workaround. :)
You could try going back through the major releases (23.12, 23.06, 22.12, ...).
I think 23.12 should work.

Sorry to bother you again, but as a reference, I tried compiling versions 23.12, 23.06, and 22.12 of the sofa, but Gras_limit_touchenv.py always reported an error:
sofa::simulation::ResetVisitor::processNodeTopDown(sofa::simulation::Node*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*,  std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*,  std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*,  std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*,  std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*,  std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::executeVisitorTopDown(sofa::simulation::Visitor*,  std::__cxx11::list<sofa::simulation::graph::DAGNode*, std::allocatorsofa::simulation::graph::DAGNode* >&, std::map<sofa::simulation::graph::DAGNode*, sofa::simulation::graph::DAGNode::StatusStruct, std::lesssofa::simulation::graph::DAGNode*, std::allocator<std::pair<sofa::simulation::graph::DAGNode* const, sofa::simulation::graph::DAGNode::StatusStruct> > >&, sofa::simulation::graph::DAGNode*)
sofa::simulation::graph::DAGNode::doExecuteVisitor(sofa::simulation::Visitor*, bool)
sofa::simulation::node::reset(sofa::simulation::Node*)
_PyObject_MakeTpCall
_PyEval_EvalFrameDefault
_PyEval_EvalFrameDefault
_PyFunction_Vectorcall
_PyEval_EvalFrameDefault
PyEval_EvalCode
_PyRun_SimpleFileObject
_PyRun_AnyFileObject
Py_RunMain
Py_BytesMain
__libc_start_main
Duan error (core has been dumped)

That would probably do as a workaround. :)
You could try going back through the major releases (23.12, 23.06, 22.12, ...). I think 23.12 should work.

Hello, may I ask how to solve the problem of some scene scripts not running due to Sofa updates?

Hey! @Grizemc I am having the same issue, well to me most scenes are kinda broken. are you compiling sofa in linux or ubuntu? also how are you sure its due to the sofa version. is there an error log that shows this?

Hi @Zoniaku,
yeah, sorry. The update to downloading a precompiled SOFA version was a bit hasty.
A workaround would be rolling back to an earlier version of sofa_env together with manually compiling sofa.
For example this one: https://github.com/ScheiklP/sofa_env/commit/d58030a3f54bf9cdd15cdb8cdf61d5a83cb6c802

嘿！@Grizemc 我遇到了同样的问题，对我来说大多数场景都有点不完整。你是在 Linux 还是 ubuntu 中编译 sofa？另外你怎么确定这是由于 sofa 版本造成的？有没有显示此问题的错误日志？

Hello, have you implemented it according to the author's statement? Has it been successful？

Hi @Zoniaku, yeah, sorry. The update to downloading a precompiled SOFA version was a bit hasty. A workaround would be rolling back to an earlier version of sofa_env together with manually compiling sofa. For example this one: d58030a

May I ask again, which versions of Sofa_env, Sofa, and Sofa_Python 3 can successfully run most of the scripts in Sofa_env, and what are the specific commits for these three versions.
Because I used your https://github.com/ScheiklP/sofa_env/blob/d0d197d4bda74338e8b6aa1e5a72a9c715f7f73e/docs/source/setting_up_sofa.rst All the explanations,
Multiple versions of sofa_env were used separately,
And the e74b94848af09536873d1c7eb291a5e742fc6077 and e41f341feb82351c00a0b9b7b94e9035a389e346 versions of sofa were used,
Sofapython version 15bc9725e85b282ce97738266e9849ca1b9c1602, but ultimately running: cmake Wno dev
-S $FOLDER_SRC -B $FOLDER_TARGET
-DCMAKE_BUILD_TYPE=Release
-DSOFA_FETCH_SOFAPYTHON3=OFF
-DPLUGIN_SOFAPYTHON3=ON
-DPython_EXECUTABLE=$PYTHON_EXE
-DPython_ROOT_DIR=$PYTHON_ROOT_DIR
-DSP3_LINK_TO_USER_SITE=ON
-DSP3_PYTHON_PACKAGES_LINK_DIRECTORY=$PYTHON_PKG_PATH
-DPLUGIN_SOFACARVING=ON
-DSP3_BUILD_TEST=OFF
-DSOFA_BUILD_TEST=OFF all display:
-- Adding plugin ArticulatedSystemPlugin
-- Adding plugin SofaCarving
-- Adding plugin SofaMatrix
-- Adding application SceneChecking
-- Adding application runSofa
Write Plugin list at /home/grize/sofa/build/lib/plugin_list.conf.default
-- Configuring done
CMake Warning at applications/plugins/SofaMatrix/CMakeLists.txt:79 (add_library):
Cannot generate a safe runtime search path for target SofaMatrix because
files in some directories may conflict with libraries in implicit
directories:
runtime library [libtiff.so.5] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
runtime library [libpng16.so.16] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
Some of these libraries may not be found correctly.
CMake Warning at applications/projects/runSofa/CMakeLists.txt:58 (add_executable):
Cannot generate a safe runtime search path for target runSofa because files
in some directories may conflict with libraries in implicit directories:
runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
Some of these libraries may not be found correctly.
-- Generating done
-- Build files have been written to: /home/grize/sofa/build
II Sometimes it may also display:
-DSP3_LINK_TO_USER_SITE=ON
-DSP3_PYTHON_PACKAGES_LINK_DIRECTORY=$PYTHON_PKG_PATH
-DPLUGIN_SOFACARVING=ON \ Some modules are useless
And sometimes when I use compiled binary files, such as versions 23.06, 22.12, etc., I get an error saying: sofa. helper
can't find.
So can you provide specific requirements for solving the scenario script running problem, including the three versions of Sofa, and whether to compile directly from source code or use pre compiled binary files. Can Windows be solved with WSL

Hi @Zoniaku, yeah, sorry. The update to downloading a precompiled SOFA version was a bit hasty. A workaround would be rolling back to an earlier version of sofa_env together with manually compiling sofa. For example this one: d58030a

May I ask again, which versions of Sofa_env, Sofa, and Sofa_Python 3 can successfully run most of the scripts in Sofa_env, and what are the specific commits for these three versions.
Because I used your https://github.com/ScheiklP/sofa_env/blob/d0d197d4bda74338e8b6aa1e5a72a9c715f7f73e/docs/source/setting_up_sofa.rst All the explanations,
Multiple versions of sofa_env were used separately,
And the e74b94848af09536873d1c7eb291a5e742fc6077 and e41f341feb82351c00a0b9b7b94e9035a389e346 versions of sofa were used,
Sofapython version 15bc9725e85b282ce97738266e9849ca1b9c1602, but ultimately running: cmake Wno dev
-S $FOLDER_SRC -B $FOLDER_TARGET
-DCMAKE_BUILD_TYPE=Release
-DSOFA_FETCH_SOFAPYTHON3=OFF
-DPLUGIN_SOFAPYTHON3=ON
-DPython_EXECUTABLE=$PYTHON_EXE
-DPython_ROOT_DIR=$PYTHON_ROOT_DIR
-DSP3_LINK_TO_USER_SITE=ON
-DSP3_PYTHON_PACKAGES_LINK_DIRECTORY=$PYTHON_PKG_PATH
-DPLUGIN_SOFACARVING=ON
-DSP3_BUILD_TEST=OFF
-DSOFA_BUILD_TEST=OFF all display:
-- Adding plugin ArticulatedSystemPlugin
-- Adding plugin SofaCarving
-- Adding plugin SofaMatrix
-- Adding application SceneChecking
-- Adding application runSofa
Write Plugin list at /home/grize/sofa/build/lib/plugin_list.conf.default
-- Configuring done
CMake Warning at applications/plugins/SofaMatrix/CMakeLists.txt:79 (add_library):
Cannot generate a safe runtime search path for target SofaMatrix because
files in some directories may conflict with libraries in implicit
directories:
runtime library [libtiff.so.5] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
runtime library [libpng16.so.16] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
Some of these libraries may not be found correctly.
CMake Warning at applications/projects/runSofa/CMakeLists.txt:58 (add_executable):
Cannot generate a safe runtime search path for target runSofa because files
in some directories may conflict with libraries in implicit directories:
runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
Some of these libraries may not be found correctly.
-- Generating done
-- Build files have been written to: /home/grize/sofa/build
II Sometimes it may also display:
-DSP3_LINK_TO_USER_SITE=ON
-DSP3_PYTHON_PACKAGES_LINK_DIRECTORY=$PYTHON_PKG_PATH
-DPLUGIN_SOFACARVING=ON \ Some modules are useless
And sometimes when I use compiled binary files, such as versions 23.06, 22.12, etc., I get an error saying: sofa. helper
can't find.
So can you provide specific requirements for solving the scenario script running problem, including the three versions of Sofa, and whether to compile directly from source code or use pre compiled binary files. Can Windows be solved with WSL?
esteem it  a favor! The stars have already been lit up hahaha

May I ask again, which versions of Sofa_env, Sofa, and Sofa_Python 3 can successfully run most of the scripts in Sofa_env, and what are the specific commits for these three versions.
Because I used your https://github.com/ScheiklP/sofa_env/blob/d0d197d4bda74338e8b6aa1e5a72a9c715f7f73e/docs/source/setting_up_sofa.rst All the explanations,
Multiple versions of sofa_env were used separately,
And the e74b94848af09536873d1c7eb291a5e742fc6077 and e41f341feb82351c00a0b9b7b94e9035a389e346 versions of sofa were used,
Sofapython version 15bc9725e85b282ce97738266e9849ca1b9c1602, but ultimately running: cmake Wno dev
-S $FOLDER_SRC -B $FOLDER_TARGET
-DCMAKE_BUILD_TYPE=Release
-DSOFA_FETCH_SOFAPYTHON3=OFF
-DPLUGIN_SOFAPYTHON3=ON
-DPython_EXECUTABLE=$PYTHON_EXE
-DPython_ROOT_DIR=$PYTHON_ROOT_DIR
-DSP3_LINK_TO_USER_SITE=ON
-DSP3_PYTHON_PACKAGES_LINK_DIRECTORY=$PYTHON_PKG_PATH
-DPLUGIN_SOFACARVING=ON
-DSP3_BUILD_TEST=OFF
-DSOFA_BUILD_TEST=OFF all display:
-- Adding plugin ArticulatedSystemPlugin
-- Adding plugin SofaCarving
-- Adding plugin SofaMatrix
-- Adding application SceneChecking
-- Adding application runSofa
Write Plugin list at /home/grize/sofa/build/lib/plugin_list.conf.default
-- Configuring done
CMake Warning at applications/plugins/SofaMatrix/CMakeLists.txt:79 (add_library):
Cannot generate a safe runtime search path for target SofaMatrix because
files in some directories may conflict with libraries in implicit
directories:
runtime library [libtiff.so.5] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
runtime library [libpng16.so.16] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
Some of these libraries may not be found correctly.
CMake Warning at applications/projects/runSofa/CMakeLists.txt:58 (add_executable):
Cannot generate a safe runtime search path for target runSofa because files
in some directories may conflict with libraries in implicit directories:
runtime library [libz.so.1] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
/home/grize/anaconda3/lib
Some of these libraries may not be found correctly.
-- Generating done
-- Build files have been written to: /home/grize/sofa/build
II Sometimes it may also display:
-DSP3_LINK_TO_USER_SITE=ON
-DSP3_PYTHON_PACKAGES_LINK_DIRECTORY=$PYTHON_PKG_PATH
-DPLUGIN_SOFACARVING=ON \ Some modules are useless
And sometimes when I use compiled binary files, such as versions 23.06, 22.12, etc., I get an error saying: sofa. helper
can't find.
So can you provide specific requirements for solving the scenario script running problem, including the three versions of Sofa, and whether to compile directly from source code or use pre compiled binary files. Can Windows be solved with WSL?
esteem it  a favor! The stars have already been lit up hahaha

Hi @Grizemc ,
could you check out the most recent commit? I think I fixed all scenes except for TissueManipulation.

Thank you very much, you are truly an outstanding author!
However, every time I compile Sofa and Sofapython3 using cmake, the result is that there is no SP3 in the path/home/drivewz/Sofa/build/install/plugins. This means that my cmake did not compile sp3, right?, Therefore, when I used your newly submitted commit script, I separately used pre compiled files (including the total pre compilation of Sofa and Sofapython3), as well as my own compiled Sofa+pre compiled sp3 (because I did not compile sp3 when I compiled it myself), and I switched from dual system to WSL under Windows, using the same process as instructions. Sofa source code used v23.12, sp3 used f1ac0f03efd6f6e7c30df8b18259e16da523f0b2.
But the script, for example: gras_lift_touch_cenv.py, always outputs:
[WARNING] [InteractiveCamera(camera)] Too many missing parameters ;  taking default ...
[WARNING] [MechanicalObject(unnamed)] Could not read value for data field showColor: 255 0 255
[WARNING] [MechanicalObject(unnamed)] Could not read value for data field showColor: 255 0 255
[ERROR]   [SofaRuntime] ValueError: Object type StopperLagrangianConstraint<> was not created
The object 'StopperLagrangianConstraint' is not in the factory.
But the following exits:
: StopperConstraint (77% match)
: BilateralInteractionConstraint (63% match)
: UnilateralInteractionConstraint (62% match)
: ParabolicConstraint (60% match)
: FixedTranslationConstraint (60% match)
Traceback (most recent call last):
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 820, in
env.reset()
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 480, in reset
super().reset(seed)
File "/home/grizewz/sofa_env/sofa_env/base.py", line 207, in reset
self._init_sim()
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 418, in _init_sim
super()._init_sim()
File "/home/grizewz/sofa_env/sofa_env/base.py", line 286, in _init_sim
self.scene_creation_result = getattr(self._scene_description_module, "createScene")(self._sofa_root_node, **self.create_scene_kwargs)
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/scene_description.py", line 165, in createScene
gripper = Gripper(
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/sofa_objects/gripper.py", line 95, in init
PivotizedArticulatedInstrument.init(
File "/home/grizewz/sofa_env/sofa_env/sofa_templates/rigid.py", line 1122, in init
super().init(
File "/home/grizewz/sofa_env/sofa_env/sofa_templates/rigid.py", line 773, in init
self.articulation_description_node.addObject(
Then, I observed your newly updated script and found that you did indeed include StopperLagrangian Constraint in the updated script.
Therefore, I believe that the versions of Sofa and SP3 are incorrect.
At the same time, may I ask if you use pre compiled files or manually compiled sofa and sp3 when running most of the scripts successfully? If you compiled it manually, could you give me some advice as my SP3 was not compiled in the build file.

Hi@ScheiklP
Thank you very much, you are truly an outstanding author!
However, every time I compile Sofa and Sofapython3 using cmake, the result is that there is no SP3 in the path/home/drivewz/Sofa/build/install/plugins. This means that my cmake did not compile sp3, right?, Therefore, when I used your newly submitted commit script, I separately used pre compiled files (including the total pre compilation of Sofa and Sofapython3), as well as my own compiled Sofa+pre compiled sp3 (because I did not compile sp3 when I compiled it myself), and I switched from dual system to WSL under Windows, using the same process as instructions. Sofa source code used v23.12, sp3 used f1ac0f03efd6f6e7c30df8b18259e16da523f0b2.
But the script, for example: gras_lift_touch_cenv.py, always outputs:
[WARNING] [InteractiveCamera(camera)] Too many missing parameters ; taking default ...
[WARNING] [MechanicalObject(unnamed)] Could not read value for data field showColor: 255 0 255
[WARNING] [MechanicalObject(unnamed)] Could not read value for data field showColor: 255 0 255
[ERROR] [SofaRuntime] ValueError: Object type StopperLagrangianConstraint<> was not created
The object 'StopperLagrangianConstraint' is not in the factory.
But the following exits:
: StopperConstraint (77% match)
: BilateralInteractionConstraint (63% match)
: UnilateralInteractionConstraint (62% match)
: ParabolicConstraint (60% match)
: FixedTranslationConstraint (60% match)
Traceback (most recent call last):
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 820, in
env.reset()
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 480, in reset
super().reset(seed)
File "/home/grizewz/sofa_env/sofa_env/base.py", line 207, in reset
self._init_sim()
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 418, in _init_sim
super()._init_sim()
File "/home/grizewz/sofa_env/sofa_env/base.py", line 286, in _init_sim
self.scene_creation_result = getattr(self._scene_description_module, "createScene")(self._sofa_root_node, **self.create_scene_kwargs)
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/scene_description.py", line 165, in createScene
gripper = Gripper(
File "/home/grizewz/sofa_env/sofa_env/scenes/grasp_lift_touch/sofa_objects/gripper.py", line 95, in init
PivotizedArticulatedInstrument.init(
File "/home/grizewz/sofa_env/sofa_env/sofa_templates/rigid.py", line 1122, in init
super().init(
File "/home/grizewz/sofa_env/sofa_env/sofa_templates/rigid.py", line 773, in init
self.articulation_description_node.addObject(
Then, I observed your newly updated script and found that you did indeed include StopperLagrangian Constraint in the updated script.
Therefore, I believe that the versions of Sofa and SP3 are incorrect.
At the same time, may I ask if you use pre compiled files or manually compiled sofa and sp3 when running most of the scripts successfully? If you compiled it manually, could you give me some advice as my SP3 was not compiled in the build file.

@ScheiklP I apologize for bothering you again. I successfully ran your newly submitted project using the pre compiled 24.06 sofa file, but the only question that puzzled me was:

I ran it directly in the PyCharm window and successfully reproduced the expected window!

I executed it with the command line and received an error message:
[INFO]    [PluginManager] Loaded plugin: /home/grize/sofa/build/install/lib/libSofa. Component.ODESolver.Forward.so
[DEPRECATED] [SofaGeneralRigid] SofaGeneralRigid is being deprecated.  It will be removed at v23.06. You may use Sofa.Component.Mapping instead.
[INFO]    [PluginManager] Loaded plugin: /home/grize/sofa/build/install/lib/libSofa. Component.Mapping.so
[INFO]    [PluginManager] Loaded plugin: /home/grize/sofa/build/install/collections/SofaGeneralRigid/lib/libSofaGeneralRigid.so
[WARNING] [InteractiveCamera(camera)] Too many missing parameters ;  taking default ...
[WARNING] [MechanicalObject(unnamed)] Could not read value for data field showColor: 255 0 255
[WARNING] [MechanicalObject(unnamed)] Could not read value for data field showColor: 255 0 255
[ERROR]   [SofaRuntime] TypeError: Gripper.__ init__() got an unexpected keyword argument 'ptsd_reset_noise'
Traceback (most recent call last):
File "/home/grize/PycharmProjects/sofa_env-main/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 820, in
env.reset()
File "/home/grize/PycharmProjects/sofa_env-main/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 480, in reset
super().reset(seed)
File "/home/grize/PycharmProjects/sofa_env/sofa_env/base.py", line 206, in reset
self._init_sim()
File "/home/grize/PycharmProjects/sofa_env-main/sofa_env/scenes/grasp_lift_touch/grasp_lift_touch_env.py", line 418, in _init_sim
super()._init_sim()
File "/home/grize/PycharmProjects/sofa_env/sofa_env/base.py", line 280, in _init_sim
self.scene_creation_result = getattr(self._scene_description_module, "createScene")(self._sofa_root_node, **self.create_scene_kwargs)
File "/home/grize/PycharmProjects/sofa_env-main/sofa_env/scenes/grasp_lift_touch/scene_description.py", line 165, in createScene
gripper = Gripper(

I am very curious about this situation; do you have any suggestions if possible? However, I have successfully reproduced the result, and I'm just puzzled by this situation.
Lastly, based on your information, I guess you might be from Germany. The last person who made me feel such a profound sense of rigor and sincerity in science was also a German scholar, which further deepened my admiration for your country's academic atmosphere, full of scientific rigor. Your dedication to scholarship has profoundly inspired me as someone who has just entered graduate school.
Once again, thank you for demonstrating your sincere and rigorous sense of responsibility!

Hi @Grizemc ,
my best guess for the second one is that SOFA tries to guess where it can find the binaries for SOFA, and comes up with the wrong guess.
You could
export SOFA_ROOT=<path-to-sofa-env>/SOFA
export SOFAPYTHON3_ROOT=<path-to-sofa-env>/SOFA/plugins/SofaPython3

in your command line, before running an env. This will tell SOFA, where to look for the correct binaries.
Cheers,
Paul

Due to my multiple attempts, I overlooked this. Thank you again!


command line dendron functionality

It would be great to have the ability to create/edit (with the note opening in VSCODE)/ delete / move / copy / attach an external file to / dendron notes from the command line - either a terminal inside of vscode or outside.    The workflow instances are huge for those of us who spend a lot of time at the command line.  A quick note:
$dendron add notename -title 'Syntax' -content 'Use this syntax to do blah'
Thanks!!
RH

Thanks for the suggestion. Was thinking about this. Will add this to the November milestone list


Create specific exceptions for API calls

Currently each service class has a couple TODOs for creating a specific exception for API calls.

Despite this being briefly mentioned on Slack a couple of days ago, I think it's worth elaborating a bit on this and re-thinking it one laste time.
So I'd like to point out the code duplication that currently exists in Service classes, which makes methods quite longer, hides the business logic behind error-handling of API calls and, ultimately, requires us tracking every Service class to make the above change.
I think a generic wrapper would be the best option if it's something easy to implement.
This is what the Kotlin-SDK devs are currently trying out.

I have been waiting for other developers to jump in for a few days now to see how it will work out once things start to grow a bit. I honestly feel like we could probably make this codebase smaller and easier to maintain with a different structure/layout. I also believe that there needs to be a focus on the single-responsibility principle since a lot of our service methods are serializing to JSON, Making an API call, receiving a response, and deserializing. That is a pretty large surface area if a bug arises.

Let's use this issue as a way to discuss possible implementations and usage examples. I like the Kotlin example. Do you guys have any suggestions?

I must say that architecting solutions is way way way out of my league, however I made an initial attempt (not complete though) in case this leads us somewhere, or gives you guys any better ideas. (Not sure if I'm following C# best practices either :grin:).
So I create a new class, NetworkClient.cs,  to hold the repeating code. This results in the Service classes becoming a simple forwarder, for example the ConnectedBanksService becomes:
public class ConnectedBanksService : IConnectedBanksService
    {
        private readonly INetworkClient _networkClient;

        public ConnectedBanksService(INetworkClient networkClient)
        {
            _networkClient = networkClient;
        }

        public async Task<ResponseModel> GetBanksAsync()
        {
            return await _networkClient.makeApiFetchCall<ResponseModel>("/banks");
        }

        public async Task<BankResponseModel> UpdateBankAsync(string nodeIdentifier, RequestModel payload)
        {
            return await _networkClient.makeApiPatchCall<BankResponseModel>(nodeIdentifier, payload);
        }
    }

I have also created an HTTP Message response converter that will accept any type. It will need a bit more polish also, and maybe a different name, but I think it may work to replace quite a bit of code in our service classes.

    internal sealed class HttpResponseConverter<T>
    {
        private readonly HttpResponseMessage m_Message;

        public HttpResponseConverter(HttpResponseMessage message)
        {
            if(message == null)
            {
                // TODO: Some type of exception
                throw new Exception();
            }

            m_Message = message;
        }

        public async T GetResult()
        {
            if (!m_Message.IsSuccessStatusCode)
            {
                // TODO: Some type of exception
                throw new Exception();
            }

            var stringResult = await m_Message.Content.ReadAsStringAsync();

            if(string.IsNullOrEmpty(stringResult))
            {
                // TODO: Some type of exception
                throw new Exception();
            }

            return JsonConvert.DeserializeObject<T>(stringResult);
        }
    }

Used in the BankService class

        public async Task<BankAccount> UpdateAccountAsync(string accountNumber, AccountRequestModel account)
        {
            var jsonAccount = JsonConvert.SerializeObject(account);
            var httpContent = new StringContent(jsonAccount, Encoding.UTF8, "application/json");

            var response = await _requestSender.PatchAsync($"/accounts/{accountNumber}", httpContent);

            var result = new HttpResponseConverter<BankAccount>(response);
            return result.GetResult();
        }

Oh I just realized I used my own naming conventions here... again it is a sample, but m_Name is my convention for private members. That way I can always find my members with IntelliSense with "m_". Public members are always "M_Name".   I also follow all async methods with _ASYNC so that they are more identifiable. Sooo if you ever see those just know I'm a creature of habit lol.

Thanks for the input and sorry for being late on this :) I'll put together something regarding the requests and be back with a PR for review. Afterwards, we can talk more about exceptions.


Add .display-inline class

Right now there is no display-inline class to apply display: inline; CSS style:
https://github.com/nenkan/css/blob/master/helper.scss#L35-L49
Add that to the file above (helper.scss). Follow alphabetic order in the definition of class names.

I want help


Unicode person

Describe the issue
https://datatracker.ietf.org/person/Unicode is a fascinating page.  I'd be interested in learning whether this is a bug or something intentional.
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

I'm gonna go with "🐛"

This is a consequence of the very low bar we set for people creating accounts/establishing data (like names).
>>> Person.objects.filter(name__icontains='unicode')
<QuerySet [<Person: [Unicode]>, <Person: Unicode>, <Person: Unicode>, <Person: Unicode>, <Person: UNICODE>, <Person: RFC 6778>, <Person: (Unicode)>, <Person: Jerarxoaguinigacervantesunicode.com>, <Person: UnicodeAnimus>, <Person: Unicode>, <Person: unicode>]>

Most (probably all) of these are junk accounts.
Note that on the form that allows editing that name:


Refactor XY Grid cell mixins

Description

This pull request add new options, functions and mixins to the XY Grid and deprecate some others with the following objective:

Reduce the number of entry points to use the XY Grid and harmonize the interface between the XY Grid mixins.
Give a finer control on the CSS output
Add clarity about different usages of gutters generations

Changes
Update XY Grid static classes generation

Use new XY cell base/gutters/size mixins to generate classes instead of the xy-cell-static() mixin
Deprecate xy-cell-static() mixin (See migration notes below)

Update XY Grid mixins:

Add support for fractions in xy-cell-size() mixin
Support values representing a fraction (6, 50%, 1 of 2 or 1/2...), treating them like shrink.

Use the contextual breakpoint in xy-cell-offset() and xy-cell-layout()
Support for the current breakpoint context set by the breakpoint() mixin.

Add support for none value for $gutter-type in all XY Grid mixins
Generate a gutters-less cell, instead of a gutter "without gutters generated" or "with 0-width gutters".

Add $output option to xy-cell() and xy-grid-layout() mixins
Cell parts to output. You will need to generate others parts of the cell seperately, it may not work properly otherwise.

Deprecate $gutter-output option in favor of $output (See migration notes below)
Note: Breaking change introduced in #11081 has been replaced with a warning notice.

Add XY Grid functions:

xy-cell-base($size)
Returns the appropriate CSS flex value for a cell base.

xy-cell-gutters($gutters, $breakpoint)
Calculate the size of a cell gutters.

xy-cell-size-css($size, $gutters, $gutter-type, $breakpoint)
Returns the appropriate CSS value for a cell size. Gutters-related arguments are required for cells with margin gutters (by default) as the gutter is included in the width.

xy-cell-offset($n, $gutters, $gutter-type, $breakpoint)
Returns the appropriate CSS value to offset a cell.

Add XY Grid mixins:

xy-cell-size($size, $gutters, $gutter-type, $breakpoint, $vertical)
Sets sizing properties for cells. Gutters-related arguments are required for cells with margin gutters (by default) as the gutter is included in the width.

xy-cell-gutters($size, $gutter-type, $gutter-position, $breakpoint, $vertical)
Sets gutters properties for cells.

Add utility functions:

-zf-bool($val)
Convert the given $val to a Boolean. Empty values are considered as false.

zf-is-fraction($value, $allow-no-denominator)
Returns whether the given $value represents a fraction. Supports formats like 50%, 1 of 2, 1 per 2 or 1/2.

zf-parse-fraction($fraction)
Parse the given $fraction to numerators and denumerators.

fraction-to-percentage($fraction, $denominator)
Calculate a percentage from a given fraction.

Add utility mixins:

-zf-each-breakpoint-in($breakpoints, $zero-breakpoint, $media-queries)
Iterates with @content through the given list of breakpoints $breakpoints.

Others changes:

Fix reversed $vertical option in xy-cell-reset() mixin.
Fix description for $gutter-type in xy-cell() mixin
Add missing semicolon in xy-grid() mixin
Add info about the cell parts and related mixins in the XY Grid documentation

Impact
🚚 CSS
With the disctinction it provide about different gutters generation usages, this PR remove useless gutters added in #11081 and let us saving some KB.
You can see the diff between this PR and develop at https://www.diffchecker.com/lMRwqPWa
:warning: Deprecations

All XY cell mixins/functions: deprecate the $gutter-output option
We now recommand the usage of the following options according to the needs:

Use $gutter-type: none for cells without gutters.
Use $gutters: 0 for cells with a 0-width gutters.
Use $output: (...) without the gutters keyword for cells with gutters that must be generated seperately.

    // Before
    @include xy-cell($gutter-output: false);

    // After
    @include xy-cell($output: (base size));

Deprecate the xy-cell-static() mixin
Use the xy-cell() mixin instead. As xy-cell-static() do not generate the cell base, you may need to use the $output option, like the following.
  // Before
  @include xy-cell-static();

  // After
  @include xy-cell($output: (size gutters));

:boom: Breaking changes:

All XY cell mixins/functions: a valid gutter config and breakpoint is now required.
When no gutter can be found to generate a cell, an error is now thrown.

The xy-cell-offset() mixin does not support raw values for $breakpoint anymore
To add an offset to a XY cell with custom gutters, use the $gutters option instead.
  // Before
  @include xy-cell-offset(6, $breakpoint: 16px);

  // After
  @include xy-cell-offset(6, $gutters: 16px);

The xy-cell() and xy-cell-base() mixins now generate the XY cell base CSS when $size represents a fraction.
If you call xy-cell() with a fraction but do not want to generate the full cell, use the $output option.
  // Before
  @include xy-cell-base(shrink);
  (...)
  @include xy-cell(12);

  // After
  @include xy-cell-base(shrink);
  // or @include xy-cell(shrink, $output: (base));
  (...)
  @include xy-cell(12, $output: (size gutters));

If you call xy-cell-base() dynamically and do not want to generate the base for each keyword/fraction you pass it, check $size before calling the mixin or generate the base seperately.

    // Before
    @each $size in $my-array-of-sizes {
      .my-cell.my-cell-#{$size} {
        @include xy-cell($size);
      }
    }

    // After.
    .my-cell {
      @include xy-cell-base();
    }
    @each $size in $my-array-of-sizes {
      .my-cell-#{$size} {
        @include xy-cell($size, $output: (size gutters));
      }
    }

TODO ⚠

[x] Provide a cell-oriented mixin for each part generated by xy-cell()
[x] Make some tests to make sure that everything works as before
[x] Update documentation

Types of changes

[x] Documentation
[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing
functionality to change)

Checklist (all required):

[x] I have read and follow the CONTRIBUTING document.
[x] There are no other pull request similar to this one.
[x] The pull request title is descriptive.
[x] The template is fully and correctly filled.
[x] The pull request targets the right branch (develop or develop-v...).
[x] My commits are correctly titled and contain all relevant information.
[x] My code follows the code style of this project.
[x] I have updated the documentation accordingly to my changes (if relevant).
[ ] I have added tests to cover my changes (if relevant).
[x] All new and existing tests passed.

I updated the documentation and checked that everything works.
👋 @DanielRuf @brettsmason Could you take a look at this ? Thanks!

Poke @DanielRuf @SassNinja Could you review this ?

Poke @DanielRuf @SassNinja 👋 Hi! Could you help me with this and review it ? Thanks :)

Not sure how I can test the changes or what has changed in comparison to before.
Can you explain further @ncoden?

@DanielRuf hmm, the description of this pull request should describe everything. All changes in the API. New features, deprecations, breaking changes and new recommended usages are listed.
But to make you a quick resume:

Split the xy-cell mixin into multiple mixins: xy-cell-base, xy-cell-size-css, xy-cell-gutters. They take gutter-oriented arguments.
Replace the $gutter-output option by much safer options. See Deprecations for more infos.
Change some arguments defaults and behaiors in various XY mixins and functions so their all behave the same way across mixins/functions.
Some refactor and optimizations
Various bug fixes (already merged in v6.5)

@SassNinja @DanielRuf Will you have some time to review this?

@SassNinja Let me know when you reviwed everything :)

@SassNinja Let me know when you finished your review 😉

Let me know when you finished your review

I'm no grid power user (quite happy with the basic features 😉) but so far it looks good to me and makes sense.
So good to merge imo.

I'm no grid power user (quite happy with the basic features 😉) but so far it looks good to me and makes sense.
So good to merge imo.

Same here. We do not use these mixins in most projects so I can not test this thoroughly.

Perfect. Thank you folks! 👍

This pull request has been mentioned on Foundation Open Source Community. There might be relevant details there:
https://foundation.discourse.group/t/foundation-for-sites-v6-6-0-is-here-farout/30/1

Love the update :) Maybe this is a bit unrelated, but is there any documentation on the reworked XY Grid? The docs are not updated yet, the migration files showing most of the changes, not all of them. Haven't tried the local docs.
Anyone who could point me in the right the direction? Would love to dive into the mixins and see what i can do there :)

In general I can see them in the docs: https://get.foundation/sites/docs/xy-grid.html#xy-cell-base

Must have missed, cause now i see.
Thanks! (y)

can someone please give me an example of xy-cell-layout with the new changes to gutters, I don't really understand what needs to be done, for example a current block grid I'm using is:
@include xy-grid-layout(2, '.flexible-item', true, $grid-margin-gutters, margin, left right, small, false);

谢谢


Feature request: Clarify color

This issue has been migrated from :
https://github.com/mike-goodwin/owasp-threat-dragon-core/issues/75
and was opened by @adamshostack :
The sample diagram has some elements (background worker, worker config, etc) which show in red. It's not clear what red means. (dashed lines seem to be used for both trust boundaries and Out of scope).
I suggest adding a key, but possibly alternately reducing use of color to address the threat of black & white printing.

For v2, there will be a help section added to the diagram page itself that will show the indicators.  I agree with the OP that using colors isn't the best choice due to printers as well as people with color-blindness (green vs red can be very hard to differentiate).
Do we want to just include the key for v2, or should we discuss alternatives for UI indicators?

Agreed, we want to move away from green and red.
My take on this is that  colour should not be used (solely) to indicate the status of any element, just as a further aid to what is already being indicated.
I guess we should fit in with what the generally generally expects, and I think it is only Threat  Dragon that provides dashed line borders to components that are out of scope - shame to lose that though

I wouldn't want to lose the out of scope indicator.  Maybe we can standardize some icons that can be displayed along a line or within a box/circle that indicate different things?  The only downside of that is that it can quickly become cluttered looking.  We definitely want to balance the ability to quickly understand the threat model as well as keeping it readable.
Just spitballing, and this is off the top of my head so I may be missing some other important pieces of information.

Icon/UI
Meaning

Triangle Exclamation
Has Threats

Open Padlock
Not encrypted (data flows)

Globe
Public Network

Small dashes
Out of Scope

Large Dashes
Trust Boundary

These icons could even become part of the label?  This is related to #135 as well.
As mentioned elsewhere, I'm by no means a UI/UX expert. If anyone has suggestions, please do leave a comment!  I'm willing to try out as many different things as needed with the new Diagraming framework until we find a great solution. :smile: With that said, I'll try to put together a few different ideas and post the results here.  Sometimes it can be difficult to express thoughts on UI through words as opposed to pictures.

and for comparison here is an output from TMT 2017:

and just to recap on what all the components mean :

Building off of the material provided, how do you feel about having an icon be present as part of the data flow label, and the protocol in parenthesis after the label?  For example, an encrypted data flow using HTTPS without threats might look something like this (padding is off, just the general idea):

"Custom Edge" is just the label for the data flow.  I know that boxes are reserved for actors, however, I can see things getting very unruly in the UI should we not have the labels and indicators in some sort of container.  We'd still need to figure out what icons we'd want for what information as far as data flows (public network, (un)encrypted, etc). I think this approach would keep things clear and relatively clutter free.  The only downside I see is that with the icons, they take up a bit of space so we may have a few cases where the labels for dataflows overlap when migrating to v2.

@lreading this does look very good to me, I really like the way the data flow is represented
The box around the icon + label + protocol certainly fits in with what other tools do, so this looks a great way forward from my point of view. Secure communications has becomes so important that an icon will be a good use of space.
Are communication paths that are not secure going to have an open padlock? And there are also cases where the security of the communications is provided by something other than the protocol, for example HTTP can be secure if the data link is in itself secure, so will the padlock follow the "Is encrypted" checkbox rather than being determined by  the protocol?
Thinking about that again, the use of "Is encrypted" should probably read "Is secured"

A couple of thoughts:

I'd stay away from marking up each data flow for security/not, and only mark one or the other (probably insecure, since it's needs attention)
Boxes around labels make them harder to distinguish from other things.
(deeper) What toggles the secure label? Is it only TLS? What about the difference between message security (S/mime or DKIM) vs channels security (start-tls, or only with MTS-STS?)

Thanks for the feedback, this is great!
I'll try a few other ways of displaying the labels in the data flow and see if there's something that will be less busy and easier to distinguish.  Maybe no border whatsoever is the way to go?  I'll post screenshots back here after playing with a few things.  I think the rounded border helps a bit, but it is pretty subtle.
Regarding point 3 as far as what toggles the secure label: There's currently a checkbox for "is encrypted" that you can apply to data flows.  @jgadsden suggested changing that to "is secure".  At that point, it would be the user determining what constitutes "secure" for the communication channel / data flow in question.  There's also a user-defined field for protocol that would allow the user to expand on what is securing that data flow.

After more discussion surrounding this, it's imperative we keep the UI relatively clutter free and easy to use/understand.  I think that appending the protocol to the data flow label in parenthesis would address the need for showing encryption/secure, while  avoiding further use of colors.  I believe this would also mostly satisfy the want from #135
The original question involved the use of color.  I think for the initial launch of v2 we should keep the existing colors, but introduce a new UI element to distinguish elements that have threats.  My initial thought would be to make it bolder, but this also may be a bit too subtle.  I am very open to suggestions for a new UI element that indicates that something has threats associated with it!  I still plan to add a key/legend to the diagram to make it relatively clear, at least when viewing on a screen.
A visual example with bolded lines for having threats and including the protocol in the labels:

These are good ideas @lreading , the bold can work - also possible is using italics for the threat status?
A suggestion may be that we do not need a different colour for the boundaries (trust or otherwise) because green/black does not add any information

version 2.0 is coming sometime end of 2020, so in the meantime I have created a pull request that  makes the trust boundaries for version 1.x black rather than green.
This is going some way to reducing colour, and also making the boundaries a different colour did not add to the information content

I'll be updating the 2.0 branch to remove the color from trust boundaries as well.  Thanks, Jon!

Closing, as this is completed in the v2-development branch.


ctlptl: 0.8.6 -> 0.8.7

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/tilt-dev/ctlptl/releases.
meta.description for ctlptl is: "CLI for declaratively setting up local Kubernetes clusters"
meta.homepage for ctlptl is: "https://github.com/tilt-dev/ctlptl"
meta.changelog for ctlptl is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.8.7 with grep in /nix/store/g89nkqhq5mxiv79mf82mkfyzl73f4ykz-ctlptl-0.8.7
found 0.8.7 in filename of file in /nix/store/g89nkqhq5mxiv79mf82mkfyzl73f4ykz-ctlptl-0.8.7

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
ctlptl

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/g89nkqhq5mxiv79mf82mkfyzl73f4ykz-ctlptl-0.8.7 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A ctlptl https://github.com/r-ryantm/nixpkgs/archive/dc2d82a38225265dfb7f09bc02fd9b23aa59ba93.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/g89nkqhq5mxiv79mf82mkfyzl73f4ykz-ctlptl-0.8.7
ls -la /nix/store/g89nkqhq5mxiv79mf82mkfyzl73f4ykz-ctlptl-0.8.7/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

ctlptl

Maintainer pings
cc @svrana for testing.

Tested creation/deletion of clusters, works fine.


CodeGeeX for Visual Studio 2022?

Is there a plugin version of CodeGeeX for visual studio 2022?

Not yet, but we added it to our schedule. We highly welcome developers to join us to accelerate the development of plugins on different platforms. And we plan to open source these plugins in the future.


Support bicepconfig.json and send out didChangeWatchedFiles notification in visual studio

Changes to support below in visual studio:

bicepconfig.json in visual studio
'workspace/didChangeWatchedFiles' events

Microsoft Reviewers: Open in CodeFlow

@majastrz, I'll go ahead and merge this change. Please feel free to leave comments. I'll address them in follow up PR. Thanks!


duplicate json tag field for enum/struct tags

Now we can define tags on structs (which is a great thing), but in the cases you need tags both on enums and structs, there is a duplicate type tag in JSON now:
#[serde(tag = "type", rename = "s1tag")]
#[derive(Debug,Clone,Serialize,Deserialize)]
struct S1 {
    text : String
}

#[serde(tag = "type", rename = "s2tag")]
#[derive(Debug,Clone,Serialize,Deserialize)]
struct S2 {
    text : String
}

#[serde(tag = "type")]
#[derive(Debug,Clone,Serialize,Deserialize)]
enum E {
    #[serde(rename = "s1tag")]
    S1V(S1),
    #[serde(rename = "s2tag")]
    S2V(S2)
}

fn main() {

    let s1 = S1 {
        text : String::from("test str")
    };

    let s2 = S2 {
        text : String::from("test str")
    };

    let e1 = E::S1V(s1.clone());
    let e2 = E::S2V(s2.clone());

    let s1_ser = serde_json::to_string(&s1).unwrap();
    let s2_ser = serde_json::to_string(&s2).unwrap();
    let e1_ser = serde_json::to_string(&e1).unwrap();
    let e2_ser = serde_json::to_string(&e2).unwrap();

    println!("serialized = {} from {:?}", s1_ser, s1);
    println!("serialized = {} from {:?}", s2_ser, s2);
    println!("serialized = {} from {:?}", e1_ser, e1);
    println!("serialized = {} from {:?}", e2_ser, e2);

}

resulted in
serialized = {"type":"s1tag","text":"test str"} from S1 { text: "test str" }
serialized = {"type":"s2tag","text":"test str"} from S2 { text: "test str" }
serialized = {"type":"s1tag","type":"s1tag","text":"test str"} from S1V(S1 { text: "test str" })
serialized = {"type":"s2tag","type":"s2tag","text":"test str"} from S2V(S2 { text: "test str" })

I've tried to find a workaround with untagged enums like:
#[serde(untagged)]
#[derive(Debug,Clone,Serialize,Deserialize)]
enum EU {
    S1V(S1),
    S2V(S2)
}

but it won't help because you can't decode enums properly anymore (tags on structs won't be used for enum variations).
Looks like a bug, isn't?

I've never seen tag being used on structs, and it's not a well-documented feature. From what I can tell it just outputs a tag during serialization that doesn't get checked during deserialization. I added this to your main and it still runs fine, even though the tag is incorrect:
    let s1_de: S1 = serde_json::from_str(r#"{"type":"s2tag","text":"test str"}"#).unwrap();
    println!("{:?}", s1_de);

Putting that aside though, it's not the main focus of this issue.

in the cases you need tags both on enums and structs, there is a duplicate type tag in JSON now

I wouldn't expect serde/serde_json to deduplicate anything you give it. That creates unnecessary overhead that is not needed for the majority of use cases. They simply guarantee that they will produce valid JSON if the Serialize logic gives it data that is compatible with JSON.
In this case, you specify that you will use the key "type" in two different places. That's like using the same key for different fields, what is it supposed to do there? Determining that they're always compatible with each other is non-trivial.

Aside: Ideally, we'd catch these kinds of things at compile time for derived impls, but the logic for that could get complicated, given that it has to account for things like flattening and enum representations, as you've demonstrated. Plus, there may be some use case where duplicate keys are allowed and possibly even required, so it's not reasonable to implement this kind of check globally.

If you're trying to tag your S1 and S2 serializations, you can always wrap them in the relevant enum variant before serializing. That's the approach I would take if I were writing this.

You can always wrap them in the relevant enum variant before serializing

I know about this workaround and, well, I was exactly trying to remove those intermediate wrapping enums for these scenarios :) They exist only to encode tags for structs and don't look good for me, but it is only one option to produce correct json at the moment.

Maybe you could factor that into a function? I'm using serde_json::to_string here, but it should work with whatever method you're using to output the JSON.
impl From<S1> for E { /* ... */ }
impl From<S2> for E { /* ... */ }

fn to_string<T>(val: T) -> Result<String, serde_json::Error>
where
    T: Into<E>,
{
    serde_json::to_string(val.into())
}

This could work, you're right. And it seems better than wrapping enums. I'll look into this, thanks!


PLT-8113: Fixes missing values on OAuth2 setup success page.

Summary
Expected keys in JS object were nested within JSON payload's data key.
Ticket Link
PLT-8113
Checklist

[x] Ran make check-style to check for style errors

Marked as WIP for now because there are two bugs listed in the ticket and I'm awaiting confirmation that the second one still exists.

Setup Test Server label detected. Spinmint test server created if build succeeds (checks pass and no conflicts with base branch).

Spinmint test server created at: http://i-0b45b2cd464962388.spinmint.com
Test Account 1: Email<EMAIL_ADDRESS>| Password: passwd
Test Account 2: Email<EMAIL_ADDRESS>| Password: passwd
Instance ID: i-0b45b2cd464962388

@mkraft @jasonblais This looks good to me! I was able to successfully set up the Zapier integration with no issues. First issue with values not displaying = fixed, and second issue did not reproduce for me.

Spinmint test server destroyed

This needs to be based off the release-4.4 branch if it's meant for 4.4. You can change the base branch by clicking the edit button in the top right

@jwilander Fixed base branch.


Gaps in the RC1->RC2 migration guide

https://docs.asp.net/en/latest/migration/rc1-to-rc2.html
Missing steps:

[ ] TFMs: dnx451 -> net451, dnxcore50 -> netcoreapp1.0, Microsoft.NETCore.App dependency
[x] buildOptions emitEntryPoint
[ ] Migrating xunit test projects

References:
https://github.com/aspnet/Docs/commit/090db3acb8e5ef92901f9c740876f6011f55a0b5
https://github.com/aspnet/Docs/commit/c9fcad4fdba0e18f680ea8140aa2264b5dfae826

What about dotnet-publish-iis

I've identified a bunch of other stuff last night too, I'll update it today.

[ ] Add section on "exclude" (now "buildOptions -> compile -> exclude")
[ ] Add section on "publishExclude" -> "publishOptions"
[ ] Removal of runtime information stuff
[ ] ILoggerFactory.MinimumLevel removed?
[ ] Call .SetBasePath(env.ContentRootPath) on WebHostBuilder
[ ] sql cache tool
[ ] user secrets tool
[ ] dnx-watch -> dotnet-watch

cc @JunTaoLuo

@Tratcher note that there is also the dotnet migration doc (there's a link to it from the aspnet migration doc). For example, the TFM updates are noted there.

In fact some of the gaps listed here should be addressed in the dotnet migration docs if they are missing since it is not specific to aspnet https://dotnet.github.io/docs/core-concepts/dnx-migration.html. Or, we can duplicate the information in both places if it's very important (like the global.json changes).

cc @Rick-Anderson

Let's just point to dotnet and not duplicate.

fixed via #1485


KYLIN-4855 kylin.metrics.prefix bug fix

Proposed changes
After executed "system-cube.sh cron", the system cube will be added to the crontab, but the cube name is wrong, and it does not match the actual situation. After testing, it is found that the system-cube is
There is a bug in the handling of kylin metrics prefix
In system-cube.sh, the prefix is "KYLIN". The logic is wrong. You should get "kylin.metrics.prefix" from kylin.properties. If this item is set, take the value set by the user, if not set, go to the default value. "KYLIN"
In bin/build-incremental-cube.sh The username and password default value ADMIN:KYLIN, if the password has been changed, it will not work
Types of changes
What types of changes does your code introduce to Kylin?
Put an x in the boxes that apply

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation Update (if none of the other choices apply)

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I have create an issue on Kylin's jira, and have described the bug/feature there in detail
[ ] Commit messages in my PR start with the related jira ID, like "KYLIN-0000 Make Kylin project open-source"
[ ] Compiling and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] If this change need a document change, I will prepare another pr against the document branch
[ ] Any dependent changes have been merged

Further comments
If this is a relatively large or complex change, kick off the discussion at user@kylin or dev@kylin by explaining why you chose the solution you did and what alternatives you considered, etc...

Codecov Report

Merging #1536 (be98fd8) into master (47f8e54) will decrease coverage by 0.09%.
The diff coverage is 1.23%.

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

Codecov Report

Merging #1536 (be98fd8) into master (47f8e54) will decrease coverage by 0.09%.
The diff coverage is 1.23%.

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

Good job @wolfboys , I will check it later!

Good job @wolfboys , I will check it later!

LGTM and test passed.

Thanks @wolfboys for contributions, thanks @zhangayqian for verification.