working very weird in doom emacs

so the issue is if put the
(defalias 'org-remove-inline-images #'org-sliced-images-remove-inline-images)
(defalias 'org-toggle-inline-images #'org-sliced-images-toggle-inline-images)
(defalias 'org-display-inline-images #'org-sliced-images-display-inline-images)

the first of all it donot respect the  #+HTML_HEAD_EXTRA: <style> img { width: 50%;  } </style>
secondly the image looks with artifacts on startup like

and on some file the many of minor modes like svg tag mode and superstar mode donot load if i have the alises set up on startup and the file  look like this

insted of looking like this

and if i remove those aliases then open the org file with images and then do org-sliced-images-toggle-inline-images then two things happen

the size of image get bigger , ie discarding the header #+HTML_HEAD_EXTRA: <style> img { width: 50%;  } </style>
there is still a black link at the bottom of the image

Thank you for your feedback. If I understand properly, you are using doom with org-indent-mode, and your issues are as follows:

#+HTML_HEAD_EXTRA: <style> img { width: 50%;  } </style> is not respected.

With the aliases, additionally:

There are gaps between slices.
svg-tag-mode and org-superstar-mode don't work.

Without the aliases, additionally:

There is a gap above the last line.

My comments:

Do you mean that the size of the images is larger in the exported webpage or in the buffer? I am not aware that HTML_HEAD_EXTRA has any in-buffer display effects. Could you please inform me what behavior you expect?
This should have been fixed with commit db64e31.
What happens if you call org-superstar-mode or svg-tag-mode in the buffer? If it works, then I would think this is a startup issue. Could you paste the relevant sections of your doom config?
I'm working on this one.


Update the approach of testing multiple rendered instances

Depends on https://github.com/softlayer/sl-ember-test-helpers/issues/156

Will possibly be addressed by https://github.com/softlayer/sl-ember-components/pull/912 but then needs to be captured for follow up work to replace the test case with the https://github.com/softlayer/sl-ember-test-helpers/issues/156 helper once it's developed.


Data load Step 1

Tasks

[ ] Form for adding files

Note the input options:

[ ] Always an empty input, which is actual two inputs - so the user can upload or paste link
[ ] Note state change when file is URL
[ ] Note state change when file is upload (change file)

[ ] As soon as file field is populated, we run a background check on file via GoodTables API

[ ] Simple indicator of success/fail onside the form field
[ ] If fail, div appended to field that prompts user to see the issues

[ ] on click, opens a modal, showing GoodTables report for this file (same as DataPackagist)

[ ] Note the button that indicates files are being checked

[ ] Default state "Waiting for files"
[ ] files added but not checked state "Checking files"
[ ] files added & checked state, where all files are valid "Next" (ie: proceed to step 2)
[ ] files added & checked state, where one or more are invalid "Fixes Required" (ie: user needs to go off and fix her source files, and cannot proceed to step 2)

[ ] All this data is mapped into a datapackage (eg: files are resources, name is the title field)

[ ] We will have a OSDP schema in our registry (see here), but until that is ready, can can use the Tabular Data Package schema

@pwalsh what is the difference between Replace file button in the left of file field and cross button in the right of it?

cross button remove field (and file)
replace leaves field, but adds a different file to field (ie: user chooses a new file from local machine)

[ ] upload progress — percents in the right of submit button

Can't show progress as most time spent on CSV parsing and there is no API for requesting progress state.
Instead of progress percents show file processing stages — Uploading, which is instantly replaced with Parsing and finally Validating.

@gvidon just noticed you added this. Please don't spend time on new tasks like this, until the existing task list is finished :).

@pwalsh probably I did uploading different from what we need. What I did is

upload-parse-validate file in background
and when done append to the list.

Do we need

append file to the list
show its spinner (not global one) while it is in progress
upload-parse-validate file in background
turn off loading state?

[ ] only one file for upload


emitting enums in stubs_inverted

It looks like that the enum generation is broken (or I'm missing something). The interface is:
val enum : (string * int64) list -> 'a Ctypes.typ -> unit

Where the role of the type parameter is not quite obvious. In any case, the enum elts typ is rendered as

<typ> {
   <elts>
};

That is not valid C (there is no enum keyword, and there is no such type that is rendered with the enum prefix).
So, am I missing something? If not, then a naive solution would to change the interface to:
val enum : (string * int64) list -> string -> unit

and just render enum elts name it as:
enum <name> {
    <elts>
};

If this solution is acceptable I can send the PR right now.

As a follow up, can we also add things like define (to generate #define'ed constants), and (global to generate global values), or that would be too much for the ctypes_inverted?

From what I can remember the enum definition is that way simply for symmetry with Cstubs.  Besides that I don't think there are any advantages over using a string in place of the typ argument.

there is no such type that is rendered with the enum prefix

There are at least two ways to build such a type: either via Cstubs.Types.Type.enum, or via typedef:
# typedef int64_t "enum foo";;
- : int64 typ = enum foo

can we also add a define declaration

Would there be any advantages to using define over simply writing the definitions to the output stream (i.e. to the first argument of write_c) directly?  The second argument to #define is not necessarily a constant; in fact, it can be almost arbitrary text.


Fix LICENSE and NOTICE

move legal information about subcomponents from NOTICE to LICENSE
include verbatim copy of subcomponent licenses in LICENSE
add disclaimer regarding third party APIs

do not yet merge this PR


[BUG]  System.Security.SecurityException: Requested registry access is not allowed.

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
2024-02-03T10:40:08Z [App::OnStartup] Starting Bloxstrap v2.5.4
2024-02-03T10:40:08Z [App::OnStartup] Compiled Friday, 3 November 2023 at 10:46:02 PM from commit 880c076fcd875fc10b5f6bef770033074d79a7a8 (tag/v2.5.4)
2024-02-03T10:40:08Z [App::OnStartup] Loaded from %UserProfile%\Favorites\Länkar\Bloxstrap-v2.5.4.exe
2024-02-03T10:40:08Z [App::GlobalExceptionHandler] An exception occurred
2024-02-03T10:40:08Z [App::FinalizeExceptionHandling] System.Security.SecurityException: Requested registry access is not allowed.
at Microsoft.Win32.RegistryKey.InternalOpenSubKeyCore(String name, Boolean writable)
at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)
at Bloxstrap.InstallChecker..ctor()
at Bloxstrap.App.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1_0(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

How/what did you use to download Bloxstrap?

Issue has been awaiting clarification for over a month, closing as stale. If you have anything further to add, just respond and I'll reopen.


Update ca-on-west_parry_sound REST endpoint to new address layer

If you add a conform this should be complete. Try this? (Hope it works…)
"conform": {
  "type": "geojson",
  "number": "CivicNumber",
  "street": "CivicAddress",
  "city": "Municipality"
}

I added a conform, let's see what the CI says....

Sorry it’s taking a while, there’s a Polish Voivodship in line first.

@slibby Thanks for getting this in!

@ingalls @migurski I noticed in looking at the latest run of failed datasets on data.oa.org that many of the Esri services have "type" : "csv"' in the conform. This one seemed to work after I changed it to "type" : "geojson" -- is this the right way of referencing these Esri layers? I see more that still have "csv" included, including one that you "fixed" here which I believe is failing now: https://github.com/openaddresses/openaddresses/blob/master/sources/us-ca-orange.json

@slibby I've been putting them as type csv as technically that is what they are when they reach the conform step of machine. The next iteration I do on this will be to abstract this away. At the moment there are several sources where you can put anything you want as the value as it is ignored.

The type really shouldn’t be necessary inside the conform, it’s a bit of a mess until we get that out of the spec.


Audit only when necessary

Checklist

[x] I left no linting errors in my changes.
[x] I tested my changes.
[x] I updated the documentation according to my changes.
[x] I added my change to the Changelog.

Description
Update the audit.yml workflow to only trigger for Pull Requests when there is a chance for a new finding as a result of the change. The motivation for this is to reduce unexpected CI failures.
Relates to #729

As is, this change is incorrect (it would also reduce invocations of the secrets job, which is not desired) so, given the project state, I don't plan to adjust this to get to a correct state at the risk of getting it wrong and sinking more time into it.


Cannot build APK

Pulling latest code it contains error which prevent the project build. Is the code fully updated ?

I need to create some build instructions, but you'll need to replace the default API 29 android.jar with the one from here: https://github.com/aeab13/android-jar-with-hidden-api/.


[performance] nnvm.compiler.build hasn't brought enough improvements

Below is my network's structure (input shape is (1,1,512,640)), mainly composing of separable depthwise convolution layer BN and relu, which is very similar to mobilenet. however , somehow after nnvm.compiler.build being called ,time consumption is 130 ms, whereas before nnvm.compiler.build 's optimization , the time needed for inference is 140ms. by the way , my GPU is 1050 GTX.. here: http://tvmlang.org/2017/08/22/Optimize-Deep-Learning-GPU-Operators-with-TVM-A-Depthwise-Convolution-Example.html , in this blog the improvement for depthwise convolution is remarkable. can nnvm.compiler.build method achieve similar result ?
def conv_block(data, name, depthwise_channels, pointwise_channels, layout, kernel_size=(3,3), strides=(1,1), padding=[1,1]):
"""This building block is composed of separable convolutional layer and activation layer."""
depthconv = sym.conv2d(data=data, channels=depthwise_channels,groups=depthwise_channels,
kernel_size=kernel_size,strides=strides,
padding=padding,use_bias=False,layout=layout,name=name+"1_depthwise_conv")
pointconv = sym.conv2d(data=depthconv, channels=pointwise_channels,
kernel_size=(1,1), strides=strides,
padding=[0,0], use_bias=True, layout=layout, name=name+"1_pointwise_conv")
relu = sym.relu(data = pointconv, name=name+"_relu")
return relu
def separable_conv_block(data, name, depthwise_channels, pointwise_channels, layout, strides = (1,1),kernel_size=(3,3), padding=[1,1],epsilon=1e-5):
"""This building block is composed of separable convolutional layer, batch normalization layer and activation layer."""
depthconv = sym.conv2d(data=data, channels=depthwise_channels,groups=depthwise_channels,
kernel_size=kernel_size,strides=strides,padding=padding,use_bias=False,
layout=layout,name=name+"_depthwise_conv")
pointconv = sym.conv2d(data=depthconv, channels=pointwise_channels, kernel_size=(1,1),
strides=strides, padding=[0,0],use_bias=True,
layout=layout, name=name+"_pointwise_conv")
bn = sym.batch_norm(data=pointconv,epsilon=epsilon,name=name+"_batchnorm",center=True,scale=True,axis=1)
relu = sym.relu(data=bn, name=name+"_relu")
return relu
def dncnn_net(num_separable_conv_block=5,layout='nchw'):
"""Defining what the topology is for CNN."""
data = sym.Variable("data")
body = conv_block(data, "separable_conv_block_", 1,64,layout)
for n in range(num_separable_conv_block):
body = separable_conv_block(body, "separable_conv_block_"+str(n+2), 64,64,layout)
body = sym.conv2d(data=body, channels=1, groups=1, kernel_size=(3,3),strides=(1,1),
padding=[1,1],use_bias=True,layout=layout, name="last_conv")
return body

That blog is operator level optimization. nnvm.compiler.build's optimization is graph level, and you can set the opt_level: https://github.com/dmlc/nnvm/blob/master/python/nnvm/compiler/build_module.py#L11
In your case, the acceleration from 140ms to 130ms is brought by graph level optimization.

@Huyuwei do you mean operator level optimization has to be done on user's side ,following tvm's tutorial or the instructions in your blog?

@BigJerry  nnvm compiler calls into computing kernels in TOPI. The operators in TOPI are already optimized and expected to be reused. Of course, you can further optimize it, tune it for specific workloads, or add new operators.

@Huyuwei thanks a lot! I'll try it .

@Huyuwei still have a question for you . I used nnvm.compiler.build method to obtain graph level optimization. Did you mean that if I want operator level optimization , I have to struct my network via tvm.topi instead of nnvm.symbol ?

nnvm.compiler.build performs graph optimization and then calles into TOPI to do the real computing. They work together.
I assume that by saying operator level optimization, you mean improving the performance of a single operator, e.g. depthwise conv and conv. This should be done in TOPI, by modifying the operators' schedules.

@BigJerry You should build the network using nnvm.symbol, since it's on the graph symbol level. It will call into topi to do the real computing part.

@Huyuwei as you can see , I've already constructed a network  with building blocks composing of  depthwise convolution , but it didn't perform well like the depthwise convolution in your blog . What should I do to reach the remarkable speed you'd achieved as my network already has been built via nnvm.symbol system?

The net is composed of depthwise conv and also 1x1 conv. Since conv is much more time consuming than depthwise conv, it's probable that the bottleneck is 1x1 conv. You can use nvprof to do a profiling and measure the time cost of each operator kernel.

Got it . I'll do some tests. by the way , we share same age(from your home page). you and TianQi Chen are my models. @Huyuwei

here is my WeChat Id ZZW971749411 , it will be very appreciated if you could add me into your list. @Huyuwei

haha, Ok @BigJerry


rearrange fio loop order

After running some tests, it is clear to me that the order of the nested workload loops is inverted from what it should be for best analysis of the data. This change re-orders the loops and updates the related documentation.


Helper for creating new Isolate and Context.

Any helper available for creating new Isolate and Context ?
Ex: Some versions use Isolate::New(create_params) signature to create new Isolate where as some versions use Isolate::New().
For now I am using my own helper like below:
#if NODE_MODULE_VERSION >= NODE_4_0_MODULE_VERSION
 ArrayBufferAllocator allocator;
 Isolate::CreateParams create_params;
 create_params.array_buffer_allocator = &allocator;
 thread->isolate= Isolate::New(create_params);
#else
 thread->isolate= Isolate::New();
#endif

Thanks

New<Context> creates a new Context. Isolates are not and can not be supported.

Okay thanks :)


added few sorting algorithms

I have changed the cocktail_sort.py as suggested. And thanks for the advice. Eventually, these small tips help to write better code. If there is still any scope for improvement, please let me know.

Thank you for the changes! Could you rename the functions to be snake_case? (i.e. timSort -> tim_sort)
Looking at the sorting unit tests they aren't the best right now, otherwise I would suggest adding those. However, I can refactor the sorting unit tests to be more comprehensive and less boilerplate first

@OmkarPathak Thanks for the advice. I have changed the function names as suggested. If there are any changes possible, please let me know.

@OmkarPathak Sorry for that. I forgot to do that and Sorry for so many mistakes. I have checked all files and I guess, now this should be okay but still if there is any changes, please let me know. Thanks.


Animation: Fixes an issue where setFrame would skip a frame if the an…

Important: Pull Requests should only be issued against the dev branch. PRs against the master branch will always be closed.

Nothing, it's a bug fix

Describe the changes below:
Fixes https://github.com/photonstorm/phaser/issues/2822

Thank you for your PR! Today I released Phaser CE (Community Edition). This is my way of opening up Phaser 2 to the community, allowing you to control features and updates directly. Please see the README in the v2-community folder of the repo for more details about this change.
If you could please re-submit your PR against the new Phaser CE version then I will merge it immediately :) Note that PRs now go against the master branch, and don't forget to add your change to the README too!


Fixes #1587 - Added connection string example

Fixes #1587 - Added connection string example

Docs Build status updates of commit c44b57b:
:clock10: Pending: waiting for processors (11 builds ahead of you)
:warning: Docs Build is busy, currently there are 11 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit c44b57b:
:warning: Validation status: warnings

File
Status
Preview URL
Details

azps-4.7.0/Az.Websites/Set-AzWebApp.md
:warning:Warning
View (azps-4.7.0)
Details

azps-4.6.0/Az.Websites/Set-AzWebApp.md
:white_check_mark:Succeeded
View (azps-4.6.0)

azps-4.6.1/Az.Websites/Set-AzWebApp.md
:white_check_mark:Succeeded
View (azps-4.6.1)

azps-4.7.0/Az.Websites/Set-AzWebApp.md

Line 0, Column 0: [Warning-file-not-found] Invalid file link: './New-AzResource.md'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Charging State Specific Icons

I would like to be able to have different icons depending on the value in state, my devices report state as "Full","Charging","Discharged" and I would like to present different icons depending on which value is returned.
Current Code
type: custom:battery-state-card
title: Battery levels
tap_action:
  action: more-info
charging_state:
  state: Charging
  icon: mdi:flash
  color: '#007a0c'
color_gradient:
  - '#a30000'
  - '#ffe100'
  - '#007a0c'
entities:
  - sensor.ups_battery_charge
  - sensor.fsdfsd_battery_state
  - sensor.dsffsdfsd_battery_state
  - sensor.dfgfgd_battery_state

So these three are the states of the device battery? Or is the battery level a separate value available somewhere (as a separate entity or attribute)?
If it's the former then you can use the state_map to convert "Full" to 100, "Discharged" to 0 and you can set charging_state as you have listed above.

Closing due to lack of reply. Feel free to reopen if needed


Browser Redirects too much

Domain
linkvertise.com
Link
https://linkvertise.com/152666/fluxus-windows-check-1/1
Version
37fd375
What browsers are you seeing the problem on?
Microsoft Edge
What OS are you seeing the problem on?
Windows
Anything else?
I'm pretty sure its getting detected because its redirecting to your browser site(with the timer before it redirects you to the target site) before it bypasses the site(as in remove the downloads off linkvertise) I think a fix would be to add a switch to turn off redirecting to the browser site.
PS: krnl is doing the same thing aswell

Wontfix: The FastForward developers do not condone cheating in games.


Chat - Threads don't work with concierge

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Send a message to concierge and wait for their reply
Hover over the reply from concierge or long press on the message and click reply in thread
Send a message in the thread

Expected Result:
Concierge will reply appropriately in the thread based on your message.
Actual Result:
Concierge replies automatically with "Oops! This email was received by the Expensify team at<EMAIL_ADDRESS>but it doesn't look like that's what you intended.
Let me know if you have any questions about your Expensify account!"
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: 1.3.34-1
Reproducible in staging?: n/a
Reproducible in production?: n/a
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:
Issue reported by: Neil Marcellini
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688017119435549
View all open jobs on GitHub

QA team is not testing Concierge, adding Need Reproduction label. Thank you


[COMMONSSITE-145]upgrade checkstyle

https://issues.apache.org/jira/browse/COMMONSSITE-145

Checkstyle upgraded in #188


redis disable snapshots

Disable AOF by setting the appendonly configuration directive to no (it is the default value)
Disable RDB snapshotting by disabling (commenting out) all of the save configuration directives (there are 3 that are defined by default)

I have changed for Redis 5.5 this template redis.conf.erb to have uncommented this string save ""
# Save the DB on disk:
# ...
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

<% if @save_db_to_disk %>
    <%- @save_db_to_disk_interval.sort_by{|k,v|k}.each do |seconds, key_change| -%>
    save <%= seconds -%> <%= key_change -%> <%= "\n" -%>
<%- end -%>
    <% else %>save ""
<% end %>

Hi,
Any update on this ? Will it be implemented ?
Thanks,

There is a lot more options/etc in redis than this module provides. I have worked around this in my local work by:

setting up my own redis.conf.puppet-ish file (not the same one by this module)
inserting exec between Exec['cp -p /etc/redis/redis.conf.puppet /etc/redis/redis.conf'] and Service['redis'] where above file is appended to redis.conf

example of the insertion logic (however you add to the redis.conf is up to reader):
        notify      => Service['redis'],
        refreshonly => true,
        subscribe   => Exec['cp -p /etc/redis/redis.conf.puppet /etc/redis/redis.conf'],

paths might be different for your configs, and above could use vars defining those of course.

I'll use my own template. But seriously, this issue is open for nearly 4 years now. Can't something as trivial as this be impelemented?!

I'll use my own template. But seriously, this issue is open for nearly 4 years now. Can't something as trivial as this be implemented?!

Not if nobody creates a pull request.


[Bug] angleAxis.axisLabel.align & angleAxis.axisLabel.verticalAlign not working

Version
5.5.0
Link to Minimal Reproduction
无
Steps to Reproduce
option = {
    "polar": [
        {
            "radius": [
                0,
                186.25
            ]
        },
        {
            "radius": [
                216.25,
                "80%"
            ],
            "tooltip": {
                "trigger": "axis"
            }
        }
    ],
    "radiusAxis": [
        {
            "axisLine": {
                "show": false
            },
            "axisTick": {
                "show": false
            },
            "splitLine": {
                "show": false
            },

        },
        {
            "polarIndex": 1,
            "axisLine": {
                "show": false
            },
            "axisTick": {
                "show": false
            },
            "splitLine": {
                "show": false
            },
            "axisLabel": {
                "show": false,

            }
        }
    ],
    "angleAxis": [
        {
            "type": "category",
            "axisLabel": {
                "show": false,

            },
            "axisLine": {
                "show": false
            },
            "splitLine": {
                "show": false
            }
        },
        {
            "polarIndex": 1,
            "type": "category",
            "axisLine": {
                "show": false
            },
            "boundaryGap": false,
            "splitLine": {
                "show": true,
                "lineStyle": {
                    "type": "dotted"
                }
            },
            "startAngle": 88.2,
            "triggerEvent": true,
            "data": Array.from({
                    length: 100
            },(_,i)=>({
                value: i.toString(),
                textStyle: {
                    fontSize: 12,
                    padding: 0,
                    fontWeight: "normal",
                    backgroundColor: "pink",

                }
            })),
            "axisLabel": {
                "interval": 0,
                verticalAlign: 'middle',
                align: 'center'
            }
        }
    ],
    "tooltip": {

    },
    "series": [

    ],
    "animation": false
}

Current Behavior
The following configuration items are not working:

angleAxis.axisLabel. align
angleAxis.axisLabel. verticalAlign

Expected Behavior
Code links:

https://github.com/apache/echarts/blob/master/src/component/axis/AngleAxisView.ts#L281
https://github.com/apache/echarts/blob/master/src/component/axis/AngleAxisView.ts#L282

After checking the source code, I found that these configuration items are hardcoded in the source, making the option configuration ineffective. If these configuration items are needed, how can they be implemented?
Environment
- OS:
- Browser:
- Framework:

Any additional comments?
No response

I'd like to clearify that when align is set to be 'right', do you expect the label 25 to be displayed at the green position? I can't imagine the real-world case when this is necessary. Can you provide a case when setting it to be left or right to be necessary?

I also think this scenario should not occur in real situations. my requirement is to set both align and verticalAlign to center
I set align and verticalAlign to center mainly to solve the issue of gaps caused by inconsistent calculation rules for positions in different ranges, like this:

If I set them all to center & middle, the gaps will disappear, like this:

If this is the case, maybe it's more important to figure out why the inconsistent happens.

I think the following code is key:
https://github.com/apache/echarts/blob/master/src/component/axis/AngleAxisView.ts#L259
https://github.com/apache/echarts/blob/master/src/component/axis/AngleAxisView.ts#L261
However, if the configuration items work as documented, this issue can be resolved through configuration.


Update Storage Blob SDK to T2

SDK Updated List:
Azure Storage Blob

@ljian3377, @EmmaZhu, Can one of you review this PR please?

Thanks for updating @zzhxiaofeng !
@ljian3377, Can you take another look?

@zzhxiaofeng On second thoughts, we should probably not update this sample at all.
The readme already has a warning saying that this sample uses the older package and points the reader to https://github.com/Azure-Samples/storage-blobs-node-quickstart which has both v10 and v12 package samples.

WARNING You are viewing a tutorial for the legacy version of the Azure Storage Node.js SDK. Please go here to view the latest JavaScript SDK (v10).

We should close this PR and open a new one to update the warning to include v12

@ramya-rao-a  Ok, We don't close the PR and use the PR to update warning as you said.

I don't have permission to merge PR to this repo.
@georgewallace can you help take a look?

@jongio can help with merging PRs


Missing dependency: URI

Looks like there is a missing require.
[1] pry(main)> require 'neo4j/core/cypher_session/adaptors/bolt'
NoMethodError: undefined method `URI' for Neo4j::Core::CypherSession::Adaptors::Bolt:Class

              @uri = url.nil? ? @default_uri : URI(url)
                                               ^^^
from /home/tom/.rbenv/versions/3.1.0/lib/ruby/gems/3.1.0/gems/neo4j-core-9.0.0/lib/neo4j/core/cypher_session/adaptors/has_uri.rb:25:in `uri_from_url!'
Caused by LoadError: cannot load such file -- neo4j/core/cypher_session/adaptors/bolt
from <internal:/home/tom/.rbenv/versions/3.1.0/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'

wow, that's an old code. It has never been tested on ruby 3.1. This version is not maintained anymore. We recommend upgrading to activegraph.


Add a deeper check for DB URL to enforce running against a test DB

📖 Description
Following the change from @alarochelle in #92, I propose to push the check a little deeper.
While the initial proposal in #92 protects us against erasing production data, the latter protect our local data.
This way, if, by mistake, you do the classic nv .env.dev.local make test instead of nv .env.test.local make test, it will raise the following:
** (RuntimeError) Expected database URL to ends with '_test', got: postgres://localhost/elixir_boilerplate_dev
    config/test.exs:14: TestEnvironment.enforce_test_database_name/1
    (stdlib 3.12) erl_eval.erl:680: :erl_eval.do_apply/6
    (stdlib 3.12) erl_eval.erl:888: :erl_eval.expr_list/6
    (stdlib 3.12) erl_eval.erl:240: :erl_eval.expr/5
    (stdlib 3.12) erl_eval.erl:232: :erl_eval.expr/5
    (stdlib 3.12) erl_eval.erl:233: :erl_eval.expr/5
    (stdlib 3.12) erl_eval.erl:888: :erl_eval.expr_list/6
    (stdlib 3.12) erl_eval.erl:411: :erl_eval.expr/5
make: *** [test] Error 1

🦀 Dispatch

#dispatch/elixir

🦀 Requesting reviewers for this pull request:

@remi (contributor with 5 commits in the last 90 days and 156 commits overall)
@gcauchon (expert reviewer for the elixir stack)

I’m not sure we need both approaches.
I think if we enforce the _test suffix, the “local hostname” check is redundant since if you happen to use a *_test database in a non-local hostname, you pretty much know what you’re doing.

I’m not sure we need both approaches.
I think if we enforce the _test suffix, the “local hostname” check is redundant since if you happen to use a *_test database in a non-local hostname, you pretty much know what you’re doing.

I was actually asking myself the same question!
I not a big fan of over protection against hypothetical user mistakes… A production database should never be locally writable! Is dropping your local database really an issue? It sucks, but we should have all the tools in place to put you back on your feet in a matter of seconds…

The way I saw it when I proposed this protection is:
We are exposing a boilerplate for all to use, which means that not all setups will be the same and not all ways of building the infrastructure will be the same (i.e.: production DB not accessible locally).
As for the cost of rebuilding your local DB, the same applies, often dummy seeds aren't maintained, your data might have a lot of value over time, etc...
Also, if we accept this change, I think both checks should be kept because #92 is built in a re-usable way for any environment keys, therefore has a lot of value for the future.

Kind of feel like both checks should be kept. The way I see it, the checks should enforce the fact that tests are run using a DB that's both local AND disposable (*_test name).
To re-iterate over Mat's point, we all had it happen to us: wiping our local DB by mistake. Restoring our local DB is possible, but makes us waste precious time. It's not uncommon to work on a project whose seed script is no longer up to date or simply does not work anymore. Even with working seeds, restoring them does not necessarily bring you back to the state you were working from before wiping your data.

Kind of feel like both checks should be kept. The way I see it, the checks should enforce the fact that tests are run using a DB that's both local AND disposable (*_test name).

I still don’t get why we would need both checks. If we enforce running tests against a _test database, why do we also need to enforce running tests in a local database? The _test check is much more powerful.
Let’s see how it would work when running tests with various DATABASE_URL values:
# Would get caught with `_test` check
<EMAIL_ADDRESS>
# Would get caught with `_test` check
DATABASE_URL=postgres://localhost/project_development

# Would get caught with local host check
<EMAIL_ADDRESS>
# All good!
DATABASE_URL=postgres://localhost/project_test

The way I see it, we should not have something in place for the third use case — it doesn’t exist. If you’re running the test suite and providing a non-local URL with a database name that ends with _test, you know what you’re doing.
Is there something I’m missing?

@remi gotcha. I'd misunderstood the point of your earlier comments. I guess keeping only this check would indeed make sense since it would catch all critical mistakes

I think @remi proposition covers it all 👍

Well my proposition is to kinda revert #92 and use only this check.

Well my proposition is to kinda revert #92 and use only this check.

Is not there some value to keep both as the way #92 was implemented, it is "re-usable" for other URL based environment key.

I don’t think so. #92 was made to address the same problem #98 fixes. #98 is just a lot simpler 😄

Ready boys!


github-runner: Build fails if overriding

Steps To Reproduce
Steps to reproduce the behavior:

build github-runner.overrideAttrs ({ buildInputs ? [], ... }: { buildInputs = buildInputs ++ [ bashInteractive ]; }) in nix repl

Build log
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/0yazg03l5pyfxv521zjp4pnayw3kb4pr-source
source root is source
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
applying patch /nix/store/j7gzfpc8py1zygprfkkmy6wjpczlpr29-dir-proj.patch
patching file src/dir.proj
Hunk #2 succeeded at 38 (offset 2 lines).
Hunk #3 succeeded at 82 (offset 2 lines).
applying patch /nix/store/jqyjzp0d0wpk4v2mshbxw2pzba9j97jc-host-context-dirs.patch
patching file src/Runner.Common/HostContext.cs
Hunk #1 succeeded at 238 (offset 18 lines).
applying patch /nix/store/6xgrk4bycx0llp4y8p8lk03cpnl3kxa6-use-get-directory-for-diag.patch
patching file src/Runner.Common/HostContext.cs
Hunk #1 succeeded at 112 (offset 3 lines).
Hunk #2 succeeded at 291 (offset 19 lines).
applying patch /nix/store/fxb9j8shn0ivscalfzr2hxjyy4rbc054-dont-install-systemd-service.patch
patching file src/Runner.Listener/Configuration/ConfigurationManager.cs
Hunk #1 succeeded at 347 (offset 27 lines).
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
Package source with Name: nuget.org disabled successfully.
=  Determining projects to restore...
/nix/store/h9ngq6ww8vaxsfnvnphwaiyabykw0ykz-dotnet-sdk-6.0.401/sdk/6.0.401/NuGet.targets(132,5): error : Central Directory corrupt. [/tmp/nix-build-github-runner-2.296.2.drv-0/source/src/ActionsRunner.sln]
/nix/store/h9ngq6ww8vaxsfnvnphwaiyabykw0ykz-dotnet-sdk-6.0.401/sdk/6.0.401/NuGet.targets(132,5): error :   Invalid argument : '/nix/store/qzdjv76281ai9f6v3zzm4w6jhh3s6dfa-nuget-packages/runtime.debian.8-x64.runtime.native.System.Security.Cryptography.OpenSsl.4.3.0.nupkg' [/tmp/nix-build-github-runner-2.296.2.drv-0/source/src/ActionsRunner.sln]

Additional context
I'm testing a workaround to the bug that nodejs is searched in 1.12 instead of 1.16 folder.
The expression I'm aiming for is nix-repl> :u pkgs.github-runner.overrideAttrs ({ postInstall ? "", buildInputs ? [], ... }: { postInstall = postInstall + "ln -s ${nodejs-16_x} $out/externals/node12"; buildInputs = buildInputs ++ [ bashInteractive ]; }).
Notify maintainers

Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux <IP_ADDRESS>-microsoft-standard-WSL2, NixOS, 22.05 (Quokka), 22.05.20220913.d86a461`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.9.1`
 - channels(root): `"home-manager, nixos"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

#193033 seems to fix this


Override path in sources/source in XML Report

Our CI System needs the path in sources/source to match the Repo structure.
We run out tests in a different location. So we need to change the path in the generated coverage.xml file
Our current solution is to run sed --in-place 's,<source>/a/b</source>,<source>/x/y/</source>,' coverage.xml to replace it after generation.
Describe the solution you'd like
There is a parameter or config value to hard code the path in sources/source.
Describe alternatives you've considered
I can continue to run after the generation.
sed --in-place 's,<source>/a/b</source>,<source>/x/y/</source>,' coverage.xml

The [paths] setting can be used to remap data measured in one location to another location.  Typically this is because a test suite is run in a few different environments, then all the data files are collected together and combined.  The combine step uses the [paths] setting to remap the measured data so that it conforms to the layout of the combining environment.
If you are not using coverage combine, you can add it as a step to get this remapping.
Does that help? It might be that I still don't understand your situation.  Why do you have different layouts?


TestCatalogImageUpdate e2e test does not work locally on kind clusters

Bug Report

What did you do?
A clear and concise description of the steps you took (or insert a code snippet).
The TestCatalogImageUpdate test does not work on KIND clusters locally (it does work on minikube however). This seems due to the port-forwarding that is required to talk to the local docker registry that is deployed during the course of this test.
Test Here
Fixing this quickly would require a check to see if we are in a kind cluster and then a t.Skip() if so. Fixing this properly would require some thought and more diagnosis.
What did you expect to see?
A clear and concise description of what you expected to happen (or insert a code snippet).
Test passes on KIND clusters
What did you see instead? Under which circumstances?
A clear and concise description of what you expected to happen (or insert a code snippet).
Test fails on KIND clusters
Environment

operator-lifecycle-manager version:

Kubernetes version information:

Kubernetes cluster kind:

Possible Solution

Additional context
Add any other context about the problem here.

The test is still skipped - not sure we should close this until it can be enabled

I did a quick github/local search and wasn't immediately able to find the test name in question - it looks like it was renamed to It("delete gRPC registry pod triggers recreation") in https://github.com/operator-framework/operator-lifecycle-manager/commit/06e84d94d38a63b770b43930d6daf4343e8f9b61 if I'm following everything correctly. Am I missing anything, or is this a problem on another already released, yet still supported branch?


Add support fot those cheap chinese cameras

Hi!
Couldn't get to the RSTP stream that looks like this:
rtsp://<IP_ADDRESS>:554/user=admin&password=TheStrongestPassword&channel=1&stream=0.sdp?
Please consider adding support for this.
Thank you!

This link looks broken. GET parameters must be passed like this: /?user=admin&password=... Didn't you forget the question character "?"?

Nope, everything is correct. There are a lot of different ones though. And what exactly I am talking about is "720, dome, GENERAL AREA, H264DVR, IPCAM P2P, ONVIF, Other, P2P IP CAMERA" string.

Okay. The Cams app uses the libvlc engine from the VLC app. If VLC can play something, Cams can do the same. So please check your URL in VLC first.


With on_error = :stop, web connector stops on warnings

Warns happen when you do a query and what you searched for wasn't found.
We consider warns OK - even if you have on_error = :stop, we'll keep going. Web Connector, however, will stop on a warn if you have on_error = :stop.
We can't change what Web Connector does, but maybe we can add another mode where we tell Web Connector :continue but we act as :stop, so that we can continue after warns.

Possibly related to an earlier concern about handling warnings?


fix: qdrant.rb

Thank you for creating this Gem. I encountered a couple of bugs when trying to use Qdrant with VectorDatabase.
my code
require 'langchainrb'
require 'qdrant'
require 'pry'

client = Langchain::Vectorsearch::Qdrant.new(
  url: '*********************',
  api_key: '*********************',
  index_name: 'test',
  llm: Langchain::LLM::OpenAI.new(api_key: '*********************')
)

client.create_default_schema

company_info = Langchain::Processors::JSON.new.parse(Langchain.root.join('/user/dev/embedding_sample/company_info.json'))

client.add_texts(
  texts: company_info.to_s
)

puts client.ask(
  question: "#{ARGV}"
)

The first bug is related to the absence of default arguments in the 'add_texts' method, which caused an error.

/Users/satoru/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/langchainrb-0.6.3/lib/langchain/vectorsearch/qdrant.rb:35:in `add_texts': missing keyword: :ids (ArgumentError)
        from test_company_info.rb:19:in `<main>'

The second bug was found in the 'ask' method while mapping the 'search_results' object. It was unnecessary to include the 'result' parameter, so I removed it.

/Users/satoru/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/langchainrb-0.6.3/lib/langchain/vectorsearch/qdrant.rb:113:in `dig': no implicit conversion of String into Integer (TypeError)
        from /Users/satoru/.rbenv/versions/3.0.3/lib/ruby/gems/3.0.0/gems/langchainrb-0.6.3/lib/langchain/vectorsearch/qdrant.rb:113:in `ask'
        from test_company_info.rb:24:in `<main>'

@satoru02 This is excellent! Thank you for contribution and fixes! Lmk if you have any other feedback on this gem!


PromQL emits unsorted data

I would expect PromQL to return sorted data since log cache can sort data.
curl -s -G "http://log-cache.<system-domain>.com/v1/promql" --data-urlencode 'query=http{source_id="<sourceID>"}[2m]' -H"Authorization: $(cf oauth-token)" | jq . | grep time
            "time": "1525881083000000000",
            "time": "1525881084000000000",
            "time": "1525881084000000000",
            "time": "1525881085000000000",
            "time": "1525881085000000000",
            "time": "1525881067000000000",
            "time": "1525881082000000000",
            "time": "1525881083000000000",

/cc @johannasmith

@toddboom This looks like an old issue that has since been resolved. Closing.


Gas and Storage Cost Report

Run tool from https://github.com/Cardinal-Cryptography/aleph-node/tree/obrok/price-contracts/scripts/pricing to measure gas and storage costs for contracts operations. The report will be sent to Aleph Zero to adjust parameters so that prices of various operations are at least reasonable.

completed


profile page

*Issue:*https://github.com/bcgov/entity/issues/17710
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

/gcbrun

Temporary Url for review: https://bcregistry-btr-dev--pr-55-90en7z63.web.app

/gcbrun

Temporary Url for review: https://bcregistry-btr-dev--pr-55-90en7z63.web.app


@superset-ui/switchboard v2.1.0 has been published empty

Latest stable version of @superset-ui/switchboard is an empty package (version 2.1.0).
How to reproduce the bug
https://www.npmjs.com/package/@superset-ui/switchboard/v/2.1.0?activeTab=code
Screenshots

Environment
NA
Checklist

[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Some issues are mentioning the emptiness of version 0.18.26 but none of them relates to 2.1.0
Additional context
None
Comment
We are using the corrected version 0.18.26-2 but we would appreciate the latest stable version to be released with its content! Thanks :)

That is odd... I'll give this a 4.0 label, since I believe we'll be re-publishing the monorepo packages under that versioning number, and will want to make sure that things look right with that release.

From https://github.com/apache/superset/blob/master/superset-frontend/packages/superset-ui-switchboard/package.json it seems like 0.18.26 might in fact be the current version - in which case it is indeed strange that there is a 2.x version published there.


WslRegisterDistribution failed with error: 0x80370114

Windows Version
Microsoft Windows [Version 10.0.22631.3880]
WSL Version
<IP_ADDRESS>
Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version
<IP_ADDRESS>-2
Distro Version
Debian 12.5
Other Software
Docker Desktop (Windows) 4.18.0
Repro Steps
Started up my PC as usual
opened Docker -> not working (see actual Behavior)
used wsl --shutdown
rebooted pc
still not working
uninstalled WSL
reinstalled WSL using wsl --install -d Debian
Expected Behavior
In the first place I expected Docker to work.
In the second place I expected the re-installation of WSL to finish successfully.
Actual Behavior
starting Docker, got this:

reinstalled WSL using wsl --install -d Debian (I also tried installing with --web-download), got this:

The error message tells me that one feature is missing, but it doesn't tell me which one.
I checked troubleshooting but I couldn't find the exact error, but one with the same message
I set CPU Virtualization from 'auto' to 'on' in the BIOS
I checked bcdedit /enum | findstr -i hypervisorlaunchtype and got this:
hypervisorlaunchtype  auto
Diagnostic Logs
WslLogs-2024-07-30_08-18-35.zip
"Virtual Machine Platform" and "Windows Subsystem For Linux" are enabled on the Windows:

Using wsl -l -v, gets me this:
NAME                   STATE           VERSION
docker-desktop-data    Stopped         2

/dumps

The error message has changed to 0x8000000d, the only change I made are new drivers for my graphics card and the windows update KB5040527.
The new logs are too big to upload here.
Therefore I have uploaded it to my google drive:
https://drive.google.com/file/d/1NzWbMWI8SBTs9rt-_CuV5XP2nMor0Fxs/view?usp=sharing

The error message has changed to 0x8000000d, the only change I made are new drivers for my graphics card and the windows update KB5040527. The new logs are too big to upload here. Therefore I have uploaded it to my google drive: https://drive.google.com/file/d/1NzWbMWI8SBTs9rt-_CuV5XP2nMor0Fxs/view?usp=sharing

Thank you. Looking at the logs it looks like debian might be in a bad state. You can delete it and start over by running: `wsl --unregister debian```


KinematicBody get_slide_collision() crashes.

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Kubuntu 17.04, Godot git MASTER
Issue description:
the new changes to KinematicBody api brings crashes when colliding. I do this:
if get_slide_count() > 0:
  print("slide count: ", get_slide_count())
  print(get_slide_collision(0))
and I get this on console:
slide count: 1
ERROR: operator[]: FATAL: Index p_index out of size (size()).
   At: core/vector.h:137.
or am I doing something wrong?  the get_slide_count is the new get_collision_count, right? atleast it will return 0 count when my character is still on air dropping to ground.

got this from gdb, if it helps.
#0  0x00005555567c19d2 in KinematicBody::_get_slide_collision(int) ()
#1  0x00005555567ce1df in MethodBind1R<Ref, int>::call(Object*, Variant const**, int, Variant::CallError&) ()
#2  0x0000555556f581fb in Object::call(StringName const&, Variant const**, int, Variant::CallError&) ()
#3  0x0000555556f0bbc4 in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) ()
#4  0x0000555555c25cf6 in GDFunction::call(GDInstance*, Variant const**, int, Variant::CallError&, GDFunction::CallState*) ()
#5  0x0000555555c0cd78 in GDInstance::call_multilevel(StringName const&, Variant const**, int) ()
#6  0x00005555565abd57 in Node::_notification(int) ()
#7  0x00005555567c32e8 in KinematicBody::_notificationv(int, bool) ()
#8  0x0000555556f50d24 in Object::notification(int, bool) ()
#9  0x0000555556566ddd in SceneTree::_notify_group_pause(StringName const&, int) ()
#10 0x00005555565679da in SceneTree::iteration(float) ()
#11 0x0000555555b7d8c3 in Main::iteration() ()
#12 0x0000555555b76bd1 in OS_X11::run() ()
#13 0x0000555555b6fd1b in main ()

is this just me? should I put up a sample project?
thanks.
.b

A sample is always welcome for quick tests :D

kinbug.tar.gz
here you go.
.b

I can't reproduce the crash with the sample project on 18e453baf (current master).
Are you sure there is not an invalid access to the collision list somewhere else in your code?
It should not crash, though.
KB have changed a lot and those slide_count and slide_collision do not have the best names for a method :dizzy_face:
These, if related to collisions, should be "collision count" and "collision data" :upside_down_face:

thanks for looking into it.. I am not sure what happened, but I decided to wipe the whole source dir and clone the git repo again for totally clean build.. now it really seems to work. I close this issue.


Vulnerability roundup 85: axel-2.17.7: 1 advisory [5.9]

search, files

[ ] CVE-2020-13614 CVSSv3=5.9 (nixos-20.03)

Scanned versions: nixos-20.03: a84b797b28e. May contain false positives.

Merged.


Fix Issue #95, Introduce a rule for a layer to express that it requires some user selected add-ons

Issue: https://github.com/wildfly/wildfly-glow/issues/95

We will not follow this approach.


🐛 Bug Report: Techdocs Flashing on Navigation

📜 Description
Whenever you navigate around on a techdocs page (I.e clicking a navigation item, or pressing "Next/Previous" in the bottom, it "flashes" 1-2 times before it renders the next page.
👍 Expected behavior
As you click a navigation item, the content that you were previously viewing should remain visible (and stable) until the new content is loaded. At that time, the content should change to the new content.
👎 Actual Behavior with Screenshots
It flashes whenever you navigate before it goes to the next page.
👟 Reproduction steps

Navigate to a doc set like https://demo.backstage.io/docs/default/component/backstage/getting-started/create-an-app/.
Click the next link down in the left hand nav
Notice the blinking page.
Sometimes it's a bar then blinking. Sometimes just blinking.

📃 Provide the context for the Bug.
This is incredibly distracting, and destroys the user experience for our users. As techdocs is one of our most visited features, we fear that this would potentially keep people away.
🖥 Your Environment
OS:   Darwin 22.4.0 - darwin/arm64
node: v16.16.0
yarn: 1.22.19
cli:  0.22.6 (installed)
backstage:  1.13.2
Dependencies:
@backstage/app-defaults                          1.3.0
@backstage/backend-app-api                       0.4.2
@backstage/backend-common                        0.15.2, 0.18.4
@backstage/backend-dev-utils                     0.1.1
@backstage/backend-plugin-api                    0.5.1
@backstage/backend-tasks                         0.4.3, 0.5.1
@backstage/backend-test-utils                    0.1.36
@backstage/catalog-client                        1.4.1
@backstage/catalog-model                         1.3.0
@backstage/cli-common                            0.1.12
@backstage/cli-node                              0.1.0
@backstage/cli                                   0.22.6
@backstage/config-loader                         1.2.0
@backstage/config                                1.0.7
@backstage/core-app-api                          1.7.0
@backstage/core-components                       0.11.2, 0.12.4, 0.13.0
@backstage/core-plugin-api                       1.5.1
@backstage/dev-utils                             1.0.14
@backstage/errors                                1.1.5
@backstage/eslint-plugin                         0.1.3
@backstage/integration-aws-node                  0.1.2
@backstage/integration-react                     1.1.12
@backstage/integration                           1.4.4
@backstage/plugin-api-docs                       0.9.2
@backstage/plugin-auth-backend                   0.18.2
@backstage/plugin-auth-node                      0.2.13
@backstage/plugin-catalog-backend-module-github  0.2.7
@backstage/plugin-catalog-backend                1.9.0
@backstage/plugin-catalog-common                 1.0.13
@backstage/plugin-catalog-graph                  0.2.29
@backstage/plugin-catalog-import                 0.9.7
@backstage/plugin-catalog-node                   1.3.5
@backstage/plugin-catalog-react                  1.3.0, 1.5.0
@backstage/plugin-catalog                        1.10.0
@backstage/plugin-events-backend-module-aws-sqs  0.1.6
@backstage/plugin-events-backend-module-github   0.1.6
@backstage/plugin-events-backend                 0.2.5
@backstage/plugin-events-node                    0.2.5
@backstage/plugin-explore-backend                0.0.6
@backstage/plugin-explore-common                 0.0.1
@backstage/plugin-explore-react                  0.0.28
@backstage/plugin-explore                        0.4.2
@backstage/plugin-github-actions                 0.5.17
@backstage/plugin-github-deployments             0.1.48
@backstage/plugin-home                           0.4.31, 0.5.1
@backstage/plugin-org                            0.6.7
@backstage/plugin-permission-backend             0.5.19
@backstage/plugin-permission-common              0.7.5
@backstage/plugin-permission-node                0.7.7
@backstage/plugin-permission-react               0.4.12
@backstage/plugin-proxy-backend                  0.2.38
@backstage/plugin-scaffolder-backend             1.13.1
@backstage/plugin-scaffolder-common              1.2.7
@backstage/plugin-scaffolder-node                0.1.2
@backstage/plugin-scaffolder-react               1.3.0
@backstage/plugin-scaffolder                     1.13.0
@backstage/plugin-search-backend-module-catalog  0.1.0
@backstage/plugin-search-backend-module-explore  0.1.0
@backstage/plugin-search-backend-module-pg       0.5.5
@backstage/plugin-search-backend-module-techdocs 0.1.0
@backstage/plugin-search-backend-node            1.2.0
@backstage/plugin-search-backend                 1.3.0
@backstage/plugin-search-common                  1.2.3
@backstage/plugin-search-react                   1.5.2
@backstage/plugin-search                         1.2.0
@backstage/plugin-tech-radar                     0.6.3
@backstage/plugin-techdocs-addons-test-utils     1.0.12
@backstage/plugin-techdocs-backend               1.6.1
@backstage/plugin-techdocs-module-addons-contrib 1.0.12
@backstage/plugin-techdocs-node                  1.7.0
@backstage/plugin-techdocs-react                 1.1.5
@backstage/plugin-techdocs                       1.6.1
@backstage/plugin-user-settings                  0.7.2
@backstage/release-manifests                     0.0.9
@backstage/test-utils                            1.3.0
@backstage/theme                                 0.2.19
@backstage/types                                 1.0.2
@backstage/version-bridge                        1.0.4
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
None

I will link to an issue i found that explains it as well, but as its closed i figured i would open this one hoping it would get noticed.
https://github.com/backstage/backstage/issues/13696

@alper98 I will close this issue as a duplicate and re-open the other one as it looks like theres more information in the other one.


Debug menu doesn't position properly with different app.width/height

The debug menu (the current position and the info about the shape) that is supposed to render in the corner of the screen does not do so when the width and height are not the default values. It appears that the position of the menu is hardcoded instead of relative to the size of the screen.

I have opened a pull request here #86 which should fix this problem

Thank you for your bug report! We will work to get this fix merged soon.


feat: update internal templates for kusion init

What type of PR is this?

/kind feature
What this PR does / why we need it:
This PR updates the internal templates for kusion init.
Which issue(s) this PR fixes:

Fixes #781
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., design docs, usage docs, etc.:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 5 (100.0%)  changed or added relevant lines in 1 file are covered.
7 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.05%) to 76.853%

Files with Coverage Reduction
New Missed Lines
%

pkg/cmd/destroy/options.go
7
81.86%

Totals

Change from base Build<PHONE_NUMBER>:
-0.05%

Covered Lines:
9074

Relevant Lines:
11807

💛  - Coveralls


if you catch a pokemon in battle that it also counts as a KO

Closing this for now as I'm unable to replicate

Loading up multiple worlds in a single game launch causes multiple event registrations?


[ENIGMA] implement new features like ticker, order book, etc.

Hi @timmolter,  I've got error from travis-ci:
"Error installing ‘oraclejdk8’: “Expected feature release number in range of 9 to 14, but got: 8”
Can you please take a look at this if you have a time?
Thanks

yeah I saw that. I'll look into it.

can you update your PR with my latest commit please?

nevermind. It passed with Java 11.


Online signer Prototype

Closes #316
This is my API design for OnlineSigner and a default version that wraps OfflineSigner. Discussed with @willclarktech and @webmaster128 and generally agreed as a decent design for an OnlineSigner that presents a UI.
TODO:

[ ] Add SignedTx to the return value of OnlineSigner.signAndBroadcast
[ ] Move fee lookup into InProcessOnlineSigner and not in SigningClient.

So as I understand it, there are two advantages of using an online signer over the offline signer we've already implemented:

It allows the signer to override/set properties of a transaction which were set/left blank by the application requesting a signature (in particular fees/gas).
It allows the signer itself to control the broadcasting of the transaction, which prevents a potential class of mischievous app behaviour involving asking for signatures and then using the signed in a way the user wasn't expecting. E.g. telling the user the transaction failed somehow, waiting for a user action reflecting that fact, and then successfully broadcasting the transaction later.

Are we clear on how realistic these advantages are? E.g. is it plausible to support a decent UX for point 1?

It allows the signer to override/set properties of a transaction which were set/left blank by the application requesting a signature (in particular fees/gas).

Good point.
So far I thought the desired feature is the ability to override the fields as a human. Do we even want to allow leaving them empty? Is an online signer able to determine the gas limit for all message types on all chains it connects to?

This is a good start and nice way to combine the two interfaces. Here is some initial feedback on this PR:

signAndSubmit sould be renamed to signAndBroadcast (see also https://github.com/CosmWasm/cosmjs/issues/317)
Decide who sets sequence, account number and fee (gas+amount). Right now it is everybody's and nobody's responsibility and the concept is unclear. If gas simulation works good enough, fine. Then the extension/signer should do it.
signAndBroadcast should return the transaction that was actually signed including all the adjustments the signer did to the app. This is basically what I suggested here: https://github.com/CosmWasm/cosmjs/issues/264#issuecomment-655927403 (no matter if encoded as bytes or as an object)
Restore SigningCosmosClient.signAndBroadcast, which is a working public API – even if it just passes everything to the OnlineSigner. If needed we can ignore the fee argument if it turns out in 2. that the signer does that.

https://github.com/chainapsis/keplr-extension/blob/cosmjs/src/content-scripts/inject/cosmjs-provder.ts
https://github.com/chainapsis/keplr-example/blob/online-signer-demo/src/main.js
I made an initial prototype of online signer support for Keplr and basic example usage based on your PR.
For 2 of @webmaster128's opinion, I think that it is better to set sequence, account number field in the SigningCosmWasmClient. If sequence, account number is null, we have to fetch these values from the node in the online signer anyways, and this seems to be a duplicating the same logic.
And, it would be better if values like apiUrl, broadcastMode are passed from SigningCosmWasmClient to the online signer
since these values are duplicated in SigningCosmWasmClient and online singer, it is better to set them in one place.

I think that it is better to set sequence, account number field in the SigningCosmWasmClient. If sequence, account number is null, we have to fetch these values from the node in the online signer anyways, and this seems to be a duplicating the same logic.

I think Simon's concern was that we do it maybe here, maybe there, rather than just leaving one place to do it, and I agree. In general, an app doesn't need to think about that stuff and I consider those values part of the signing process, so I moved that to 100% responsibility of the OnlineSigner. I think you do that already in Kepler, no? If this is an issue, we can move them 100% to the app and not allow nulls.
The only fields I think should be maybe signer, maybe app is fees. And in this case, I would propose the app can optionally set a gasWanted as it may have a good estimate of how much gas a complex tx will need. But leave the feesPerGas and final fees calculation to the signer.

And, it would be better if values like apiUrl, broadcastMode are passed from SigningCosmWasmClient to the online signer
since these values are duplicated in SigningCosmWasmClient and online singer, it is better to set them in one place.

Yeah, I was thinking about the apiUrl in particular, and this actually ties with dynamically registering chains. I figured there would be some chainId -> apiUrl lookup in kepler, as it needs to have the chainId already registered to know the proper bech32 prefix and (maybe) hd derivation path. I am fine passing it through as well, but let's discuss this with a "dyamic chain registration" functionality. I think the better idea would have a registerChain(chainId, apiUrl, bech32prefix, hdPath, ...) method on the OnlineSigner that can add a new chain support, then we only need the chainId when calling signing. I know you have an issue about the dynamic registration, so maybe we can discuss more there and I think the required registration info is something more than I have above and less than what you have in your issue.

Re: broadcast mode, does async (no confirmation) make any sense in a UI? I only see it for automated testing bots aiming for max volume.
That leaves us with sync and block as valid modes. I know that there have been issues with timeouts with the block choice, but it does make debugging a lot easier. I do see this as a good option to pass in.

https://github.com/chainapsis/keplr-extension/blob/cosmjs/src/content-scripts/inject/cosmjs-provder.ts
https://github.com/chainapsis/keplr-example/blob/online-signer-demo/src/main.js
I made an initial prototype of online signer support for Keplr and basic example usage based on your PR.

Looking at these prototypes. Thank you.
My take-aways:

The app definitely must set gas.
I'm guessing that Keplr can set the fee amount if the gas is given
Your extension never gets the accountNumber/sequence, but rather that is expected from the client. We can move the responsibility to the caller
The extension doesn't post directly, but rather that is in the injected code.

I am a bit confused by the last two points, as it seems the extension doesn't go online to get info. But when looking at your ChainInfo proposal the extension needs both rpc and rest endpoints. The difference between the Online and Offline versions seems to be RequestTxBuilderConfigMsg vs. RequestSignMsg. And the tx builder just seems to be able to set fee price and take json -> sign bytes. But I don't see much difference there. Are there any docs (or code links) for the various request messages that the extension supports?
I guess my main question is what are the possible functionality modes that Keplr offers. And maybe the Online/Offline distinction doesn't make much sense. Rather we could have JSONTxSigner vs RawSignBytesSigner. Please let me know the functionality you would prefer to inject and I can make the CosmJS interfaces match.

Just saw how you import branches from monorepos. Very cool!

After looking more at the sample, I see all the critical work is done in the OfflineSigner:

GetKeyMsg to get the address and public key
RequestSignMsg to sign the SignBytes

The only addition seems to be the RequestTxBuilderConfigMsg which can set the fee before signing. It cannot set the gas needed, just the fee token. I assume this pops up some UI in the extension to control how much you pay.
This is actually quite nice, as we currently hard-code some price in the app and no way to adjust or predict it. However, if this is the only change we really need to make to the API, I have a much simpler solution than Online Signer. We just add another method to OfflineSigner to calculate fee for example.
interface OfflineFeeSigner extends OfflineSigner {
    readonly calculateFee: (chainId: string, gasLimit: number, suggestedFee?: Coin[]) => Promise<Coin[]>
}

It seems this is the heart of the current implementation. I could do something like:
export class CosmJSOfflineFeeSigner extends CosmJSOfflineSigner {
    async calculateFee(chainId: string, gasLimit: number, memo?: string, suggestedFee?: Coin[]): Promise<Coin[]> {

      const random = new Uint8Array(4);
      crypto.getRandomValues(random);
      const id = Buffer.from(random).toString("hex");

      const msg = new RequestTxBuilderConfigMsg(
        {
          chainId,
          accountNumber: 0,
          sequence: 0,
          memo,
          gas: gasLimit,
          fee: suggestedFee
        },
        id,
        true,
        window.location.origin
      );

      const txBuilderConfig = await sendMessage(BACKGROUND_PORT, msg);

      let fee = txBuilderConfig.config.fee
        .split(",")
        .map(str => CosmosJsCoin.parse(str))
        .map(coin => {
          return {
            denom: coin.denom,
            amount: coin.amount.toString()
          };
        });

      return fee;
      // or we also take the memo
      // return { fee, memo: txBuilderConfig.config.memo);
    }
}

This will just call the actual APIs you expose (and not require you to import a bunch of cosmjs code to get this to work). It simplifies the interfaces you need. And it makes it clear where the actual logic goes.
I am happy for any amount of logic and processing happening in the extension. And any amount in the app. I would like to keep the injected code as simple as possible. Especially as a version mismatch between the injected cosmjs and the app's cosmjs would not be so great and the less logic injected the better.
What do you think of this proposal?

Initially, I thought that the tx type can be not stdTx, so I designed that the setting the tx config and requesting the signature are separate. But, for now, I agree that the case of that the chain uses their custom transaction type doesn't exist and probably such case will not exist for a while. So, I also have plan to deal with the transaction by one step that just sets tx config and signing at once. Then, the difference between offlineSigner and onlineSigner would be small. IMHO, I think that the current onlineSigner is enough and it can replace the offlineSigner.
In current Keplr's onlineSigner implementation, I prohibited the null gas field because the gas simulation is not implemented yet, so we can't calculate the gas automatically. Users can change the gas on extension's UI if the tx config is requested.
The extension doesn't post directly, but rather that is in the injected code. The answer to this line can be slightly complex. As you said, in the current implementation, the transaction is not broadcasted by the extension. But, if you have used the Keplr, you can see the transaction's status is notified by the browser's notification system and it works even in the wallet.keplr.app webpage. This feature is not described yet, Keplr extension can be delegated to broadcast the transaction on behalf of the webpage with using the browser's notification system. So, I think I can provide the option that the transaction is broadcasted by the webpage or delegate the broadcasting to the extension. If the transaction broadcasting is delegated to the extension, this transaction will be broadcasted to the node that Keplr knows.

The only fields I think should be maybe signer, maybe app is fees. And in this case, I would propose the app can optionally set a gasWanted as it may have a good estimate of how much gas a complex tx will need. But leave the feesPerGas and final fees calculation to the signer.

@ethanfrey I'm not sure that I understood this part 100%. Could you clarify this part?

Thank you for clarifying. From looking at the UI, it is hard to see what is done where exactly.

So, I think I can provide the option that the transaction is broadcasted by the webpage or delegate the broadcasting to the extension. If the transaction broadcasting is delegated to the extension, this transaction will be broadcasted to the node that Keplr knows.

Okay, if you will be adding the broadcast by the extension in the future (to the node Keplr knows), I would stick with this interface. And when implemented make cosmjs just use that part. I feel rather hesitant to have so much code compiled into the injected code (as imports). Maybe we can trim that down later, but I was wondering if it made sense the functionality.

The only fields I think should be maybe signer, maybe app is fees. And in this case, I would propose the app can optionally set a gasWanted as it may have a good estimate of how much gas a complex tx will need. But leave the feesPerGas and final fees calculation to the signer.

@ethanfrey I'm not sure that I understood this part 100%. Could you clarify this part?

Sorry, re-reading that is confusing. I wanted to make sure either the app or the signer is responsible for all fields. Does this make sense:
The app provides:

messages
chain_id
gasLimit
memo?
fees?

The signer provides:

account_number
sequence
fees

The signer may override:

memo
gasLimit

Given your feedback, I would just polish off these types a bit

@webmaster128 is on vacation and I would like his input for the final types. I see two main options. The first one is to just make the relatively minor adjustments to the current OnlineSigner interface as described above: https://github.com/CosmWasm/cosmjs/pull/403#issuecomment-682110991
This would give us:
// move more fields to the caller
export interface SignRequest {
  // required fields
  readonly msgs: readonly Msg[];
  readonly chainId: string;
  readonly gas: string;
  readonly account_number: string | number;
  readonly sequence: string | number;
  // optionally set by caller, can be overriden by signer
  readonly fee_amount?: readonly Coin[];
  readonly memo?: string;
}

export interface SignAndBroadcastResult {
  // we add this field as well (return the signed tx that was broadcast)
  tx: SignedTx;
  result: BroadcastTxResult;
}

export interface OnlineSigner {
  readonly enable: () => Promise<boolean>;
  readonly getAccounts: () => Promise<readonly AccountData[]>;
  // pass in broadcast mode when calling
  readonly signAndBroadcast: (address: string, request: SignRequest, broadcastMode = BroadcastMode.Block) => Promise<SignAndBroadcastResult>;
}

Option 2
When looking at the implementation in keplr, I notice they have to pull in a lot of @cosmjs/launchpad code into the injected script to make this work. As the extension does not directly submit the transaction. I would make a new interface tailored to just what the extension actually does. If it starts broadcasting in a later version, we can revive the OnlineSigner interface.
Here is an alternate design (freezing this PR and replacing it with a new design). It should be easy to update the current Keplr injected script to this new API (just trim down a bit), as I describe above: https://github.com/CosmWasm/cosmjs/pull/403#issuecomment-681983426
We would have a slightly higher-level interface (chain-aware) that can make some tx modifications before signing.
// minimal
export interface OfflineSigner {
  readonly getAccounts: () => Promise<readonly AccountData[]>;
  readonly sign: (address: string, message: Uint8Array, prehashType?: PrehashType) => Promise<StdSignature>;
}

// this can modify data and returns a complete StdTx with a valid Signature
export interface BuildingSigner {
  readonly getAccounts: () => Promise<readonly AccountData[]>;
  readonly enable: () => Promise<boolean>;
  readonly buildAndSign: (address: string, request: SignRequest) => Promise<StdTx>;
}

export interface StdTx {
  readonly msg: readonly Msg[];
  readonly fee: StdFee;
  readonly signatures: readonly StdSignature[];
  readonly memo: string | undefined;
}
export interface StdSignature {
  readonly pub_key: PubKey;
  readonly signature: string;
}

export interface PubKey {
  // type is one of the strings defined in pubkeyType
  readonly type: string;
  // Value field is base64-encoded in all cases
  // Note: if type is Secp256k1, this must contain a COMPRESSED pubkey
  readonly value: string;
}

We could use the exact same SignRequest as in Option 1, except a different return value. Most of the imported code and this broadcastMode argument are doing stuff in the injected script that is not done in the extension and could better be done in an app. The cosmJSprovider (and extension) will return the exact signed tx that will be broadcast, so it can also precompute the txHash and monitor the transaction (it seems this is the current flow in cosmosJSprovider).

Given that the only clear use-case we have for the OnlineSigner or BuildingSigner interface is Keplr, I think it makes sense to tailor it to Keplr's interface and exposed capabilities, which would be quite close to BuildingSigner. It's more powerful and generic than the "calculateFeeSigner", as it lets the extension make any desired transformations and sign the final transaction.
The app retains the responsibility of broadcasting and error handling there, which is much simpler than trying to feed the entire error handling from broadcasting a tx from the extension into the app. Option 2 is my preference, and I would be happy to code it when I am back (in one week), but I would like to hear the opinions of @Thunnini and @webmaster128 first. I think this would be an easy adjustment to what you have already built on the cosmjs integration branch.

Wouldn't it be better if the sequence was optional so it can also be set by the signer?
// move more fields to the caller
export interface SignRequest {
  // required fields
  readonly msgs: readonly Msg[];
  readonly chainId: string;
  readonly gas: string;
  readonly account_number: string | number;
  readonly sequence: string | number;
  // optionally set by caller, can be overriden by signer
  readonly fee_amount?: readonly Coin[];
  readonly memo?: string;
}

I do think option 2 is good but personally prefer option 1.
While we’re not committed to a specific design, I do think option 1 allows more flexibility. For example, the wallet can provide the features that account for cases where the transaction failed due to lack of gas and the wallet may be able to try again with higher gas. Another case I could think of is the frontend wanting to send multiple transactions at the same time, and the transactions can be stored as a queue to be sequentially sent to ensure that the transaction succeeds. I think option 1 allows more options for more creative wallet designs so I do like option 1 better.

I scanned most of the discussion now and a core question seems to be still open: which component is responsible for broadcasting a transaction? As long is there is no consensus on this one, all the rest cannot efficiently be worked on.
The two basic ways are:

A: (OnlineSigner) The signer signs the transaction and broadcasts it, informing the frontend what it did (this is shown in this PR)
B: (OfflineSigner) The signer signs the transaction, potentially adjusting some values and the frontend broadcasts it (this is what a Ledger signer does and what Keplr does so far)

If we want A, then Keplr should do the broadcasting. If we want B, then we can close here and improve the existing OfflineSigner interface.

When looking at the implementation in keplr, I notice they have to pull in a lot of @cosmjs/launchpad code into the injected script to make this work. As the extension does not directly submit the transaction. I would make a new interface tailored to just what the extension actually does. If it starts broadcasting in a later version, we can revive the OnlineSigner interface.

+1 for this. The OfflineSigner is simpler, exists already and works for Ledger. As long as we don't have a good, specific reason to move broadcasting from the frontend to the extension, I would not do it.

While we’re not committed to a specific design, I do think option 1 allows more flexibility. For example, the wallet can provide the features that account for cases where the transaction failed due to lack of gas and the wallet may be able to try again with higher gas. Another case I could think of is the frontend wanting to send multiple transactions at the same time, and the transactions can be stored as a queue to be set the sequence in order that the transaction succeeds. I think option 1 allows more options for more creative wallet designs so I do like option 1 better.

Option A (~ Option 1) creates more flexibility for the signer while Option B (~ Option 2) creates more flexibility in the frontend. So far I did not hear a convincing argument for A/1 over B/2 other than the fact that a frontend can easily trick the user into signing multiple transactions by presenting fake error messages and then broadcasting all of them to perform a payment multiple times.

Thank you Ethan for proposing this and @Thunnini for all the input. The way of wrapping an OfflineSigner in an OnlineSigner implementation is very neat and will not be forgotten.
For now we decided to allow signers to override parts of the sign doc without implementing an OnlineSigner (#432). Thus #316 remains open until we have a very good reason to implement it. Closing here.


L-cysteine desulfurase complex & children

We currently have this arrangement:
L-cysteine desulfurase complex (GO:1990221)
	|__IscS-IscU complex (GO:1990329)
	|__IscS-TusA complex (GO:1990330)

L-cysteine desulfurase complex (GO:1990221) is defined as:
"A protein complex capable of cysteine desulfurase activity decomposing L-cysteine to L-alanine and sulfur. It belongs to a ubiquitous family of pyridoxal 5-phosphate (PLP)-dependent enzymes. In E. coli it consists of a SufS dimer." [GOC:bhm, PMID:11827487]
Whereas the two children terms are defined as:
name: IscS-TusA complex
def: "A heterotetrameric protein complex involved in the sulfur-relay system required for 2-thiolation of 5-methylaminomethyl-2-thiouridine (mnm5s2U) at tRNA wobble positions. In E. coli it consists of a central IscS dimer with the two TusA protomers bound to one of the IscS units each via persulfide (-SSH) groups." [GOC:bhm, PMID:20404999]
name: IscS-IscU complex
def: "A heterotetrameric protein complex involved in the sulfur transfer during iron-sulfur cluster assembly and in the modification of tRNA wobble positions. In E. coli it consisting of a central IscS dimer with the IscU protomers attached to one of the IscS units each via a disulfide (-SSH) group." [GOC:bhm, PMID:20404999]
(Note that IscS is a Cysteine desulfurase - https://www.uniprot.org/uniprotkb/P0A6B7/entry)
The definitions of the two IscS complexes don't really fit with the current def of the parent term. This could be fixed by broadening the def of GO:1990221, perhaps just by removing the last two sentences.
Alternatively, maybe the 2 IscS complex terms shouldn't be children of L-cysteine desulfurase complex?
Maybe @dsiegele can help here?
Also, I think we should add a 'is capable of' 'GO:0031071 cysteine desulfurase activity' relation to 'L-cysteine desulfurase complex (GO:1990221)'
Also, "it consisting" should be changed to "it consists" in def of ' IscS-IscU complex'

I think IscS-IscU complex (GO:1990329) should also be a child of:
id: GO:1990229
name: iron-sulfur cluster assembly complex
def: "A protein complex capable of assembling an iron-sulfur (Fe-S) cluster." [GOC:bhm, PMID:17350958]
synonym: "Fe-S cluster assembly complex" NARROW [GOC:bhm]
synonym: "SufBCD complex" NARROW [GOC:bhm]
intersection_of: GO:0032991 ! protein-containing complex
intersection_of: capable_of_part_of GO:0016226 ! iron-sulfur cluster assembly
relationship: part_of GO:0005829 ! cytosol
created_by: bhm
creation_date: 2013-11-12T09:15:03Z

I also removed the 'sulfurtransferase complex' parent on 'IscS-IscU complex' and 'IscS-TusA complex' and added it to the parent term 'L-cysteine desulfurase complex' instead.


[MXNET-908] Enable minimal OSX Travis build (v1.3.x)

Description
Port of https://github.com/apache/incubator-mxnet/pull/12462 to the v1.3.x release branch.
Includes following PR's as well:
[MXNET-908] Enable python tests in Travis
https://github.com/apache/incubator-mxnet/pull/12550
[MXNET-968] Fix MacOS python tests
https://github.com/apache/incubator-mxnet/pull/12590
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

@KellenSunderland @nswamy @szha

There are a few more Travis related PRs. Please add these commits as well as they ensure high stability of Travis.

I agree with @marcoabreu lets not add it to the branch

@marcoabreu @nswamy I think the timeout is not happening on the branch. Let's merge and observe, this will not harm, but in case it will work has the benefit to cover MacOS with testing.

@lebeg I am not seeing a need for the OS X builds since the tests are disabled and also this did not exist for 1.3.0

@nswamy Ok, for clarity I understand this as: Strongly opposed to have it in the release branch. I'm not seeing that much risk as you do, but I commit to this decision and close this PR.


split Snakefile

We decided it would be a good idea to split the Snakefile into multiple parts, so that it could be used more flexibly. That's why I thought it might be a good idea to split them up according to the FASTQ inputs. Here are the different sections:

Variant Calling
WASP
Allelic Imbalance Detection

However, I could also split them up according to the BAM outputs:

DNA BAM pre-processing
Variant Calling + WASP
Allelic Imbalance Detection

Which one should I do?

I've decided to go with the first split, mostly because the output of the DNA BAM pre-processing section wouldn't actually be used directly in the Allelic Imbalance Detection section, anyway.


Feature: require GitHub Actions to be present

Would be great if allstar could verify whether certain GitHub Actions exist and a minimum version.
Often GitHub Actions contain a set of security screenings to block the PR.

Yes, this is needed. Being able to generically configure an expected action/workflow to be present seems very useful. I believe defining how the config would work and the behavior of the policy will be tricky, help is needed here. For example, you can have multiple workflows in a repo, based on different triggers, and they may block/allow different things. I assume we would want to ensure a specific action is a part of a workflow that blocks something specific (PR merge, etc.).


Update rg name

Describe your changes
Updated rg scaffold name, deleted actions
Issue number
#000
Checklist before requesting a review

[X] The pr title can be used to describe what this pr did in CHANGELOG.md file
[X] I have executed pre-commit on my machine
[X] I have passed pr-check on my machine

Thanks for your cooperation!

Reviewed directly with @jrspinella. Updates look good.


Forti-Analyzer issues on template

Hi Team,
The provided Fortigate AutoScale templates are going to create a new Forti-Analyzer while deploying for every deployment

Instead of creating a new Forti-Analyzer for repeated usage of the Autoscale Fortigate Template we need to map the existing Forti-analyzer.

Auto-Scaled Fortigate Firewalls dynamically should get authenticate automatically from the Forti-Analyzer as well as FortiGate Firewall, instead of authenticating manually.

Once the authenticated FortiGate firewalls move to the respective ADOM in Forti-Analyzer.

Hi Team,
The provided Fortigate AutoScale templates are going to create a new Forti-Analyzer while deploying for every deployment

Instead of creating a new Forti-Analyzer for repeated usage of the Autoscale Fortigate Template we need to map the existing Forti-analyzer.
Auto-Scaled Fortigate Firewalls dynamically should get authenticate automatically from the Forti-Analyzer as well as FortiGate Firewall, instead of authenticating manually.
Once the authenticated FortiGate firewalls move to the respective ADOM in Forti-Analyzer.

We will add support for point 1. I'll create a separate issue for it and please monitor it then.
Please clarify point 2 and 3.

If you go through the image.

Newly Scaled Fortigate Firewalls in the Autoscale cluster should get authenticate automatically from the Forti-Analyzer & vice versa i.e Fortigate Firewall.

After authenticating the newly scaled FW to the Forti-Analyzer, by default, it will move the root ADOM in the Forti-Analyzer but the requirement is to move the authenticated Firewalls to respective ADOM in Forti-Analyzer based on the tag or CIDR range of the FW AutoScale Cluster VPC.

Example:- Refer to the image above.
FW Cluster-1 AutoScale VPC CIDR Range is <IP_ADDRESS>/24 should be mapped with Forti-Analyzer ADOM FW Cluster-1 Adom

@JaydenLiang  We are expecting the default script/template for this use case from fortinet, based on our requirements we will amend the changes to interact directly with the FAZ & FMG.

This script is an add-on to the Autoscale project. @ManikantaNandyala , we are following up with your expected solution in another communication channel.
We are not going to make this add-on a built-in feature for the project but I'll leave this issue open for any possible solution in this way (aka: as an add-on).


Live examples stopped working (muts-needle-plot)

There is suddenly a problem with the live examples of muts-needle-plot and I am not quite sure what it is. There seems to be a problem with the encoding of some special characters within the d3-code.
See here: http://biojs.io/d/muts-needle-plot
Is this a server problem?
The console output:
Uncaught SyntaxError: Unexpected token ILLEGAL
d3-svg-legend.js:1 Uncaught ReferenceError: d3 is not defined
muts-needle-plot@0.8.0:655 Uncaught ReferenceError: d3 is not defined
(program):1 Uncaught SecurityError: Blocked a frame with origin "http://workmen.biojs.net" from accessing a frame with origin "http://biojs.io". Protocols, domains, and ports must match.
d3.js:3389 Uncaught SyntaxError: Unexpected token ILLEGAL
d3-svg-legend.js:1 Uncaught ReferenceError: d3 is not defined
muts-needle-plot@0.8.0:655 Uncaught ReferenceError: d3 is not defined
http://biojs.io/d/muts-needle-plot Failed to load resource: the server responded with a status of 404 (Not Found)

D3 contains UTF-8 symbols (like π) invalids in non-UTF8 documents. Try to adding the following element to your HTML:
<meta http-equiv="content-type" content="text/html; charset=UTF8">

Is this a server problem?

Yes indeed. Thanks for reporting!
We use "node-request-caching" to cache the github sources temporary in memory. It turns out that they don't use utf8 buffers, I fixed that and made pull request to the lib.
BTW here is the source for the registry github proxy.

Try adding the following element to your HTML:

@jmvillaveces: The registry and sniper add the meta charset header automatically and actually one shouldn't need to write HTML at all.
@mpschr: you can also require dependencies - you don't need to add everything to the sniper section, e.g. var _ = require('underscore').
Moreover if you really don't want to use require, you could use the buildJS section which will be used instead of js at the registry, so e.g.
 "buildJS": [
      "https://cdnjs.cloudflare.com/ajax/libs/d3/3.5.5/d3.min.js"
    ],

Great, thanks for the solution and explanation!


Remove the old mangler and remangler

And some other old stuff

@swift-ci Please smoke test and merge

Wow, that's more than 1% of the codebase


Android: Google Play Asset Delivery initial support

When  android.usesExpansionFile = true all assets would be placed into the preloaded asset pack. This will expand game size to 1GB.
Fixes #233

Hello, if I need to use this function, do I need to add code into my project manually? Or does corona already have this function?

@xbcross Solar2D handles everything. You only need to add the setting

Excuse me, I've seen your example of solar2d. The Android project does not include this modification. The user needs to configure it himself, right? Please let me know!

@Shchvova Excuse me, I've seen your example of solar2d. The Android project does not include this modification. The user needs to configure it himself, right? Please let me know! thank you

@xbcross https://docs.coronalabs.com/guide/distribution/buildSettings/index.html#expansion-files

@Shchvova Excuse me, after I configured according to your document and generated "AAB", I tried to use Google's bundletools tool for local testing, but unfortunately it failed. I don't know what the problem is. Can you put a demo for my reference? Because I don't see any trace of this modification in the example of "corona-3648 / national / samples / simpleluaextension / Android". So I don't know where my problem is. Hope to get your help, thank you!

@xbcross sorry. All setup you have to do is to set the value in your build.settings file:
{
    android = {
        usesExpansionFile = true
        ...
    }
}

That's that. No other setup is required (or possible).
Then make sure to select Google as target store when building the app.
To test the packaging you can unzip the produced aab file. In the output you will get additional preloadedAssets directory. You can unzip with 7z on windows or The Unarchiver on macOS.
(also, instead just APK you will get apk and oob files)
There are no samples for it yet. All what changes is literally the single line in build.settings. You can not influence it with any other code in your app.
I tested it only with Google Play uploading the AAB to use in closed alpha.

@Shchvova OK, thank you very much. I misunderstood it. Thank you again for your help. Thank you

@Shchvova Hello, I have encountered a problem again. I try to build my project with "Android studio". The generated "aab" has no "preloadedassets" folder after it is unwrapped. Did you build it directly with solar2d? If I need to build it with "Android studio", what should I do? Thank you very much for your

Is there a reason you're not using the Simulator? This flag only works when packaging with the Sim. With Android Studio you would have to make your own asset packs. It isn't complicated but I can help you with that if you really need to use Android Studio.

@Shchvova Yes, I need Android studio to build my project. Thank you for your help

@Shchvova How do I need to make my asset package to build with Android studio? I'm still confused. I hope you can help me. I made a similar production according to your source code, but I didn't find the "preloadedassets" file after unpacking the constructed "aab". If you can help me, I'm really happy

@Shchvova Excuse me, I also encounter the same problem. My project also needs to be built with ‘Androidstudio’. What can I do to build with ’Androidstudio‘? I have the same question. Can you directly provide a ‘demo project ’for your reference! Thank you here!


update macaroons/README.md

Provide sample of command to create macaroon with similar rights as admin.macaroon to be used with 3rd party applications.
Change Description
Description of change / link to associated issue.
Steps to Test
Steps for reviewers to follow to test the change.
Pull Request Checklist
Testing

[ ] Your PR passes all CI checks.
[ ] Tests covering the positive and negative (error paths) are included.
[ ] Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

[X ] The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
[ ] Commits follow the Ideal Git Commit Structure.
[ ] Any new logging statements use an appropriate subsystem and logging level.
[ ] Any new lncli commands have appropriate tags in the comments for the rpc in the proto file.
[ ] There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our Contribution Guidelines for further guidance.

@coderabbitai review

https://github.com/coderabbitai review

@coderabbitai review

Improved grammar.

Shortened lines under 80 cols.


All properties are always optional

Hi,
I am wondering why from this schema:
Manufacturer: {
  type: "object",
  properties: {
    id: {
      type: "string",
      format: "uuid"
    },
    created: {
      type: "string",
      format: "date-time"
    },
    modified: {
      type: "string",
      format: "date-time"
    },
    name: {
      type: "string",
      nullable: true
    },
    identificationNumber: {
      type: "string",
      nullable: true
    }
  },
  additionalProperties: false
},

I am getting this:
export interface Manufacturer {
  id?: string;
  created?: string;
  modified?: string;
  name?: string | null;
  identificationNumber?: string | null;
}

instead of this:
export interface Manufacturer {
  id: string;
  created: string;
  modified: string;
  name: string | null; //or name?: string;
  identificationNumber: string | null;  //or identificationNumber?: string;
}

Am I doing something wrong?

Hello @alesdvorakcz ! Can you say the version of usage schema ?  (3.0, 3.1, 2.0)
If you are using 2.0 version then you should add the list of required properties like in this schema:
https://github.com/acacode/swagger-typescript-api/blob/master/tests/schemas/v2.0/authentiq.json#L870

Same thing you should do with 3.0+ versions:
(example with Open API 3.0)
https://github.com/acacode/swagger-typescript-api/blob/master/tests/schemas/v3.0/personal-api-example.json#L134

You are right, its what I am missing in my schema (3.0)
Thank you for fast response and amazing project!


Messaging application feedback

Users are currently sent a message when their application is accepted or rejected.
The same should be possible with FAPP:

Approval: $flair granted!
Rejection: free text

Pulling this up the queue.
We are going to put sendmeyourflairapp's oauth key into the app (well, not hardcoded, it'll be a config thing) in #248 so we may as well implement this.
I will make it use sendmeyourflairapp and if we need to do a captcha (will be unlikely) I will show it to the mod who is clicking the button. Agreed?

I will make it use sendmeyourflairapp and if we need to do a captcha (will be unlikely) I will show it to the mod who is clicking the button. Agreed?

Sounds good. Try contacting Deimorz to see if he can give us a captcha bypass on that account, he is usually around on snoonet IRC.

I think this has been fixed by @not-an-aardvark 's changes, yes?

/u/FlairHQ hasn't needed any captchas for some reason. It has picked up a bit of karma, so maybe that's why.

The issue was for sending mails on approval and denial of applications. I believe you did that, yes?

It currently sends mail on approval, but not denial.

I think we decided that we weren't going to do denials because people can do that manually. Happy for me to close?

Fine by me. I was thinking denials could be a future goal once we get the notification center working -- they could get sent with a custom message from /u/FlairHQ, and then any mod would be able to see the response through the notification center.

Ok, I've reopened and renamed. We can get to this at some point.