.NET 4.7 problem with WCF service reference.

I have asp.net mvc project targeting .NET 4.5
I tried to update to .NET 4.7 but there is problem with web service that my mvc project is consuming. The service is WCF defined with http://xxx.svc endpoint. You can see on screenshot 1 that with .NET 4.5 it is fine, I can consume this service:

However after updating my project to .NET 4.7 the service reference no loger works, the parts of my code referencing it can't see it. I tried to "UpdateServiceReference" - no change. I tried to delete the service and add it again from the .svc endpoint, doesnt work either.

@dagood @StephenBonikowsky can you help?
/cc @preetikr

@zhenlan

I tried to delete the service and add it again from the .svc endpoint, doesnt work either.

@urza sorry for running into this. By "doesn't work", did you mean the tool fail to generate service reference or the generated service reference does not compile? Just to isolate the issue - did you try to create a new MVC app from VS template and add service reference again to see if works? By any chance can you share a repo project with us? That will be very helpful for our investigation.

@urza we tried to upgrade an MVC project with service reference from 4.5 to 4.7 but cannot reproduce the issue you saw, so it might be related to something more specific to your project or the service. BTW, if you change your project back to 4.5, will the issue go away?

I have same issue, upgraded from 4.6.1 to 4.7 and now I can't regenerate my web service.

@cblaze22 sorry for running into this. Do you have any information regarding the questions I asked on Jul 3 and Jul 5 above? It will be very helpful if you can can share any further information.

I had to uncheck "Reuse types in all reference assemblies" and check "mscorlib" to make it work.

Is that the intended solution? It works, but why? Seems like it should be re-opened.


Refactor guidelines 3.0 button style

Related to https://github.com/db-ui/core/issues/11

Closed in favour of https://github.com/db-ui/mono/issues/745


Handle HTTP/2 client timeout based on the stream state

$subject. In current implementation, regardless of the state the stream is in, return error always says "Timeout occurs before inbound response received"

Fixed in https://github.com/wso2/transport-http/pull/341


Decide on Styling

CSS Styling
Instead of using a CSS library like Bootstrap, consider one of the following suggestions:
Explore the concept of CSS-in-JS, which abstracts CSS to the component level, using JavaScript to describe styles in a declarative and maintainable way. Some popular libraries include styled-componentsLinks to an external site. and EmotionLinks to an external site..
Try using a component library, such as Semantic UILinks to an external site., Chakra UILinks to an external site., or Ant DesignLinks to an external site..
Create all the CSS for your application just using CSS.

Tailwinds and Vite for CSS framework/React Front End package


fix(rtc_interface): use clock created by node to judge expired cooperate status

Description
Some issues were caused by rclcpp::Clock{RCL_ROS_TIME} when we used --use-sim-time option. In this PR, I fixed and used clock created by node to judge expired cooperate status.

Tests performed

Psim
Effects on system behavior

Nothing.
Interface changes

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

I imported this PR and was able to run Autoware on AWSIM successfully.
Thank you very much!


Calendar | Month-Year navigation

Hi Gleb,
The support of scroll over the time elements is so useful!
Could you please consider supporting scroll for the Month as well? This will be useful if the date needs to be moved for long period of time, something like (1-3-2015 to 30-3-2016). It helps avoiding clicking too many times.
It's also worth to mention that scrolling over the month is expected to moves through the calendar (months) but not looping through the (12 months).
Hopeful this can be added on the road-map of improvements.
thanks a lot!

Good suggestion, I've added it to the latest release(v0.2.7) 👍
With respect to looping, scroll behavior is exactly the same as clicking on the left/right arrows which is consistent with scroll behavior with hours/minutes/seconds.

Thanks Gleb for implementing scrolling over Month.
During scrolling it's difficult to know "where I'm" especially if the date needs to move to another year.
Do you see that displaying the year next to month like MONTH YYYY helps overcoming that issue?
(year can be shown only if it's not the current one, or simply always visible)
Thanks!

Good idea! :) I've added that to the latest version (v0.2.9)

thanks 👍


Procedure to generate files for JRL website

@aescande, thank you for these scripts. Could you add the following information to README, so that we can continue to update JRL web pages?
How do you install the scripts in this repo, and how exactly do you call the functions in websitePubli.py to reproduce the auto-generated files in https://github.com/jrl-umi3218/jrl-umi3218.github.com (maybe you call websitePubli.generateYamlJRL, but what arguments do you pass)?

@aescande, maybe you don't have time to do it but is there someone else who knows this procedure?

I tried the following procedure locally and it seemed to work.

create gen.py in script directory

import websitePubli

websitePubli.generateYamlJRL(<jrl-publi>, <jrl-umi3218.github.com>, True)

in src directory, execute python3 ../script/gen.py
mv <jrl-publi>/tmp/*.bib <jrl-umi3218.github.com>/en/assets/bib
mv <jrl-publi>/tmp/publications.yml <jrl-umi3218.github.com>/_data

@fkanehiro Did you do some installation procedure beforehand?

Sorry, just after doing the following in bibmanagement directory, I succeeded the all steps.
pip3 install -r ./requirements.txt

The procedure in https://github.com/jrl-umi3218/bibmanagement/issues/1#issuecomment-1237884191 is working, so I close this.


Fix inferring complex builtin for complex dtypes in get_scalar_type

Remove use of _UndefinedStub in dtype_helpers.py

This is mighty useful as currently we have two classes of the dtype helpers—those that consume stubs and those who don't, which is hard to keep track. This unifies the approach of the helpers so they are only constructed with available dtypes.

Resolves #179

There's also this error.  Every other test failure seems to be either an issue with torch or an unrelated test suite problem which I've reported elsewhere.

Not that it's that important, but can we address https://github.com/data-apis/array-api-tests/pull/181#issuecomment-1528045938 here?

full uses the default complex dtype by default, which is complex64 for torch, so it shouldn't generate fill values outside of that dtype unless dtype=complex128 explicitly.

There's also this error. I can't tell if it's caused by this or something else:

Fixed and fixed—thanks for catching these. I folded in #182 as it addresses the former issue. Whilst its nice to keep PRs atomic I think we're not keeping track of multiple PRs at once, so mono PRs with at least a general cohesion is probably better.

Not that it's that important, but can we address #181 (comment) here?

Already addressed!

(I'll merge this soon if no review)


add ames data from confidence intervals lab to package

https://github.com/andrewpbray/oilabs/pull/16


Can't save

Error: Service Unavailable
Error: Service Unavailable
    at Request.<anonymous> (https://homebrewery.naturalcrit.com/homebrew/bundle.js:71831:19)
    at Request.Emitter.emit (https://homebrewery.naturalcrit.com/homebrew/bundle.js:1764:20)
    at XMLHttpRequest.xhr.onreadystatechange (https://homebrewery.naturalcrit.com/homebrew/bundle.js:72140:10)
{
  "status": 503,
  "method": "POST",
  "url": "/api/newGoogle/"
}

See discussion #1580 for a solution

Thank you
On Tue, Aug 24, 2021 at 7:12 PM Gazook89 @.***> wrote:

See discussion #1580
https://github.com/naturalcrit/homebrewery/discussions/1580 for a
solution
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/naturalcrit/homebrewery/issues/1601#issuecomment-905036210,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFHREZSZSAPSH43GYWJTJFDT6QRPJANCNFSM5CX2GAGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.


[KeyVault] API inconsistencies

Purpose
-keys
-secrets
-certificates
Needs update

Create
createKey
setSecret
createCertificate
???

Create parameters
name: string, keyType: JsonWebKeyType, options?: CreateKeyOptions
secretName: string, value: string, options?: SetSecretOptions
name: string, options?: KeyVaultClientCreateCertificateOptionalParams
???

Get parameters
name: string, options?: GetKeyOptions
secretName: string, options?: GetSecretOptions
name: string, version: string, options?: RequestOptions
???

Lines with ??? need confirmation. Replace the question marks with the resolution once we have an agreement.

I would suggest the following.

Purpose
-keys
-secrets
-certificates
Needs update

Create
createKey
setSecret
createCertificate
I would suggest no change.  If we absolutely believe they have to be consistant, then I would change setSecret to createSecret, but setSecret is consistent with all the service documentation.

Create parameters
name: string, keyType: JsonWebKeyType, options?: CreateKeyOptions
secretName: string, value: string, options?: SetSecretOptions
name: string, options?: KeyVaultClientCreateCertificateOptionalParams
KeyVaultClientCreateCertificateOptionalParams -> CreateCertificateOptions

Get parameters
name: string, options?: GetKeyOptions
secretName: string, options?: GetSecretOptions
name: string, version: string, options?: RequestOptions
version should be optional and go into a new options bag type GetCertificateOptions.

@schaabs Based on that, is it ok if I only use the last suggestion? I think that's the one that will be most impactful. The first two don't seem to really affect the user, but I believe it was great to discuss this, for the record.

Ooh we already had GetCertificateOptions! Interesting.


[Actors] Java example for actor reentrancy

What content needs to be created or modified?
Java code snippet for actor reentrancy
Where should the new material be placed?
https://docs.dapr.io/developing-applications/building-blocks/actors/actor-reentrancy/#enable-actor-reentrancy-with-actor-configuration
The associated pull request from dapr/dapr, dapr/components-contrib, or other Dapr code repos
Actors refresh issue: #3257
Additional context
Docs refresh pt 1 PR: #3300

not supported in Java right now - closing and will open new docs issue when available.


⚠ Samsung has degraded performance

In f54e700, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2523 ms

Resolved: Samsung performance has improved in 2c45dbd.


Tweak tab bar style to make the selected tab easier to see.

This is a small cosmetic customization that makes it easier to see which tab is selected.
Here is a view without the change:

Here is a view with the change (note that in both, the leftmost tab is selected):

@giteshk I've been unsuccessful at fixing the container build, so I've reverted back to my original change and will follow your suggestion to disable the workflow. If you have time to look at the container build (no rush), I think we should update the Dockerfile to use the same tool versions that we use in .github/workflows/flutter.yml. I was also looking at updating the Dart dependencies with flutter pub upgrade. I also realized that this would probably be easier to debug locally in docker instead of pushing and waiting for CI. Thanks for your advice/help on this.


How to describe target species?

In GitLab by @peterdesmet on Sep 8, 2020, 14:04
This issue pivoted to a discussion on how to indicate target species
The current definition of taxonomic coverage is:

Taxonomic coverage for this data package. It is based on a set of unique values from scientific_name field in observations.csv table.

Could this be broadened to allow the inclusion of species that were available for determination (e.g. in a project defined species list) or were considered target species, but did not result in observations? Or should we consider another way to allow the inclusion of target species?

In GitLab by @kbubnicki on Nov 30, 2020, 11:09
If I understand you correctly you would like to preserve the information about "real zeros" i.e. not recorded species confirmed before to be present in the study area, right? Very good point I would say, but I am not convinced that this should be mixed with the idea of taxonomic coverage. Mainly because this can be confusing for people searching for datasets containing images/videos of particular species or for algorithms doing an automatic data aggregation/harmonization etc For this reason I would not mix these two things. I think this needs more thinking and probably community:feedback?

In GitLab by @peterdesmet on Nov 30, 2020, 16:30
Ok to keep taxonomic coverage to only those taxa that are included in dataset. :+1: Target species can be mentioned in dataset description anyway. Fine to close this issue.

In GitLab by @kbubnicki on Nov 30, 2020, 17:48
What about not closing this but leaving marked as community:feedback? I see this as an interesting topic in general.

In GitLab by @peterdesmet on Nov 30, 2020, 17:51
Ok, but best to update the title of this issue then

In GitLab by @peterdesmet on Dec 1, 2020, 12:55
changed the description

In GitLab by @peterdesmet on Dec 1, 2020, 12:55
changed title from {-Broaden scope of taxonomic coverage to include target species-} to {+How to describe target species?+}

In GitLab by @kbubnicki on Dec 1, 2020, 15:09
Perfect!

Picking this one up again. Taxonomic scope is intended to list all species in the observations, but that doesn't really tell us much regarding:

What species were targeted (if any) and which ones were by catch
To what level classifications were made (only target species, sex, life stages, etc.).

I think the latter one is quite difficult to standardize and for publishers to assess at project level. The target species however could be indicated by adding an optional property target=TRUE to taxa in taxonomic coverage. The R package camtraptor could then e.g. include a target column to the observations based on the taxonomic coverage, just like it already does for vernacular names (ping @damianooldoni).
{
      "taxonID": "RQPW",
      "taxonIDReference": "https://www.checklistbank.org/dataset/3LR",
      "scientificName": "Castor fiber",
      "taxonRank": "species",
      "target": true, <--
      "vernacularNames": {
        "en": "Eurasian beaver",
        "nl": "bever"
      }
    },
    {
      "taxonID": "6MB3T",
      "taxonIDReference": "https://www.checklistbank.org/dataset/3LR",
      "scientificName": "Homo sapiens",
      "taxonRank": "species",
      "target": false, <--
      "vernacularNames": {
        "en": "human",
        "nl": "mens"
      }
    },

I agree with you @peterdesmet: it's something to be specified in the taxonomic coverage (metadata) and can be indeed picked up by a package like camtraptor while reading this information from the camtrap datapackage. Indeed, something we do already with some other fields like vernacular names.

Discussed with @kbubnicki. The problem with adding a target=TRUE is twofold:

It only addresses a small aspect of sampling intend. There's also the spatial and temporal intend and other things that are best described in separate terms borrowed from Humboldt Extension (see #276)
What do you do when a target=TRUE taxon was not observed. Do you add it to taxonomic scope? In that case, your taxonomic scope no longer describes the data (it's bigger than the data).

When there is a demand for it, it will likely be better to describe targetTaxa in a separate term, listing all target taxa (whether observed or not). That term will then align well with https://tdwg.github.io/hc/terms/#hc:targetTaxonomicScope. For now (1.0), we refer to the free text project description to indicate target taxa.


Alternative API with KStream on top of Processor

@jkreps @nehanarkhede @ymatsuda
This is a second attempt for KStream-on-top-of-Processor: I maintained generics on KafkaProcessor and make addProcessor accepting the parent object directly.

I like the separation of layers a lot. I left some minor comments.  Currently I think the interface is to define a class that builds a topology and then pass it in as a class. I think this is a bit weird.
I expect to do something like this:
Topology myTopology = new TopologyBuilder(defaultDeser)
.addProcessor("my-processor", MyProcessor.class, new Source("my-source"))
.addProcessor("my-other-processor", MyOtherProcessor.class, new Source("other-source", customDeser, customDeser), "my-processor");
KafkaStreaming streaming = new KafkaStreaming(config, myTopology);
streaming.run();
I think this is tied back to the question of whether I pass processor instances or classes. I think I may understand part of the confusion on this issue. One thing I am assuming is that the user will pass fully instantiated Objects to the processors that would be available in the init method.
So the implementation of KStream.filter currently looks like this:
public KStream<K, V> filter(Predicate<K, V> predicate) {
KStreamFilter<K, V> filter = new KStreamFilter<>(predicate);
topology.addProcessor(filter, processor);
return new KStreamImpl<>(topology, filter);
}
What I am proposing is that it look instead like this:
public KStream<K, V> filter(Predicate<K, V> predicate) {
KStreamFilter<K, V> filter = new KStreamFilter<>(predicate);
topology.addProcessor(KStreamFilter.class, new Configs("predicate", predicate));
return this;
}
The advantage is that the user code can now get rid of the whole Topology class with the builder. I think the order of execution for that API is quite unintuitive.

I am not convinced that we need this complexity.


[QUESTION] is possible to setup retry for lack of internet with this lib?

Hi,
Is this lib supporting retry for tmp lack of internet?
Right now when I use it  with conf from readme, SocketException is not handled with retry.
Is any way to configure this lib so if phone has no internet or server is down retry still  be performed?

Seems like it's a Dart related issue: https://github.com/cfug/dio/issues/1869


importfeeds: fix #1490 don't overwrite basename argument

cf #1490

Oops! The dangers of reusing variable names in an imperative language. :grimacing: Fix looks great; feel free to merge, and please do add a short changelog entry.


Command not loaded/parsed && TypeError: Class constructor Command cannot be invoked without 'new'

i tried the beginners guide just to be clear that im not forgotten something
the command is not even loaded even if theres no error with ES6 export/import
my npm run babel:

babel src/ --experimental --source-maps-inline -d build/ && node build/main.js

i've tried to invoke !help all, but the command is not listed

Vip Market
group1
Commands
groups: Lists all command groups.
enable: Enables a command or command group.
disable: Disables a command or command group.
reload: Reloads a command or command group.
load: Loads a new command.
unload: Unloads a command.
Utility
help: Displays a list of available commands, or detailed information for a specified command.
prefix: Shows or sets the command prefix.
ping: Checks the bot's ping to the Discord server.
eval: Executes JavaScript code.

import commando from 'discord.js-commando';
export class ReplyCommand extends client.Command {
	constructor(client) {
		super(client, {
			name: 'reply',
			group: 'group1',
			memberName: 'reply',
			description: 'Replies with a Message.',
			examples: ['reply']
		});
	}

	async run(msg) {
		return msg.say('Hi, I\'m awake!');
	}
}

TypeError: Class constructor Command cannot be invoked without 'new'

Perhaps try export default, though I don't know if not supporting is a concern.

i ended up not using transpiler instead.

This issue still isn't fixed.


Add a JEKYLL_ENV variable to my GitHub builds

I want to check this is being set as I expect, then I want to start using it to disable local analytics.
For https://github.com/alexwlchan/analytics.alexwlchan.net/issues/37

🚀 Deployed on https://663615af240d76dc72e97cb6--alexwlchan.netlify.app


Write decorator to ensure request origin is safe when communicating with application

So I think a security vulnerability would be if a malicious website sent a request to localhost:port, as flask-desktop is connected to python that has a higher amount of user access(such as modifying files) than web applications,  that desktop applications usually require.

Very possibly, you shouldn't use this to open websites that run untrusted code.

ANY website can send a request to localhost, since the app uses localhost:port, a developer might want to send and recieve data from their flask-desktop application to make file-system changes, and might open a malicious website in a browser-tab while doing so.
for example:
try the following flask code:

@app.route("/",methods=["GET","POST"])
def foo():
    print(request.data)

app.run(port=5000)

open the javascript console in any web browser from about:blank or any website with a weak CSP and type

fetch("http://localhost:5000/",{method:"POST",body:"whooooie"})

the request goes through,
b"whoooie" will get printed
but i can do something more vulnerable than print(request.data), like

with open(request.data.encode(), "w") as of:
of.write("this is a new file")

a malicious website could send like a 1000 requests of this action and fill the users computer with unnecessary files
tl;dr: "you can't open any website with malicious code while your flask-desktop app runs"

This issue is pretty old already, but i guess it probably won't hurt to give my opinion on this issue.
In my opinion, you should just use CSRF tokens to avoid this situation, here's example code:
import os
import secrets
from flask import Flask, request, session, abort

app = Flask(__name__)
# Set secret key in order to use session
app.config['SECRET_KEY'] = os.getenv('FLASK_SECRET')

@app.after_request
def after_request(response):
    token = session.get('token')
    # Generate CSRF token using secrets library if it does not already exist
    if not token:
        token = secrets.token_urlsafe(32)
        session['token'] = token
    # Save CSRF token to cookie so it's easily available on all requests
    response.set_cookie('token', token, httponly=True)
    return response

@app.before_request
def before_request():
    # If incoming request method is PUT, DELETE or POST
    if request.method in ('PUT', 'DELETE', 'POST'):
        # Get CSRF token from session
        token = session.pop('token')
        # Get CSRF token from cookie
        cookie_token = request.cookies.get('token')
        if not token or not cookie_token or token != cookie_token:
            # Abort the request with 403 access denied, if CSRF token does not exist or it is invalid
            abort(403)

The code above will save CSRF token to session and cookie on each request, when request method is PUT, DELETE or POST it'll check if the CSRF token is valid.


Laravel 5.6 and package:discover

laravel: 5.6.19
jenssegers/mongodb: 3.4.2
Hi,
I have a trouble with package when package:discover command is running. If I don't specify correct connection credentials, command will fail with something like this
In Client.php line 83:
Failed to parse MongoDB URI: 'mongodb:///admin'. Invalid host string in URI.

In my case I can't specify correct connection string because I use CI to build app and CI (obviously) doesn't have access to mongodb (access restrictions).
Is there a way to solve this problem?

solved by using dummy data


remove obsolete version: from docker-compose

Docker-compose deprecated version in compose documents, I removed them in this fork

Thanks!


Updated requirements (channels and asgi-redis).

@ostcar may check this ...

You should merge this. The problem is, that geiss want work with it, but I try to update geiss in the next month. If not, you should nevertheless use a current version of channels.
One proposal: Add all channel-packages explicit to our requirements-file. So problems like #3204 wont happen again. The additional packages we need is asgiref and daphne

You should merge this. The problem is, that geiss want work with it, but I try to update geiss in the next month. If not, you should nevertheless use a current version of channels.
One proposal: Add all channel-packages explicit to our requirements-file. So problems like #3204 wont happen again. The additional packages we need is asgiref and daphne


MORE Button should display the text more gracefully

Right now the box slides open. I suggest it slides open and then the text blends in (maybe line by line). This would look a bit cleaner. Maybe you don't need a slide anyway, just blend the text in it will push down the rest of the content - but I'm not an expert on css and DOM manipulation.

This issue was moved to consortium/hybrid-publishing-research#11


Omics Integrator 1 "No space left" error is back

Running Omics Integrator 1 on Singularity with a large network I'm getting the error:
Traceback (most recent call last):
  File "/OmicsIntegrator/scripts/forest.py", line 1464, in <module>
    main()
  File "/OmicsIntegrator/scripts/forest.py", line 1424, in main
    (edgeList, info) = inputObj.runPCSF(options.msgpath, options.seed)
  File "/OmicsIntegrator/scripts/forest.py", line 576, in runPCSF
    1-float(self.undirEdges[edgeNode1][edgeNode2])))
IOError: [Errno 28] No space left on device

This is in the same environment as the last time we saw this issue https://github.com/Reed-CompBio/spras/issues/37#issuecomment-892714685 but I'm not certain if it's the exact same problem (I don't yet have a full grasp over which volume is mapped where).
PS. this error is printed out but what actually halts the pipeline is failure to rename the consequently non-existent output file, maybe the reconstruct rule should explicitly fail if OI1 has a nonzero return code?

Thanks for the report.  Based on where the error occurs, it seems that the Singularity working directory can't support making this copy of the input network.  How large is the input network you're using?

maybe the reconstruct rule should explicitly fail if OI1 has a nonzero return code

Yes, I agree with this.  I'll need to look more closely at what type of errors we can throw based on the information we get back from the Singularity and Docker calls.

The network has 1053138 edges, it's a 48MB file.


Can't upgrade av via homebrew

Looks like you recently released a new version, and I keep getting this message every time I use an av command:
>> A new version of av is available: v0.0.43 => v0.0.46
>> https://docs.aviator.co/reference/aviator-cli/installation#upgrade

However, when I try to follow the Homebrew upgrade instructions, the new version isn't there:
% brew upgrade av
Warning: aviator-co/tap/av 0.0.43 already installed

You might want to run brew update first to update the list of packages?

Rookie mistake, that was it! Sorry for the trouble. You might want to update the docs though.

Good call out, I've updated the docs. Rolling out README update as part of some larger changes too.


docs: 更新删除 snap 相关内容,修正错误

本次更新的内容主要为...
欢迎前来学习

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Infinity Int

How do you say infinity integer in K? I need to find the least number in a certain bag, and I need to initially compare to infinity.

I don't remember having such a thing in K for Integers. Only for floats.
Another thing is, bags are supposed to be commutative, so no order on them.
Maybe you need a different structure to keep track of an order?

No, the number is in a cell inside a cell inside the bag, but that's not my problem. I already solved my problem though. I'm using an upper limit. But just for reference, how do you refer to infinity with floats?

https://github.com/kframework/k/blob/master/k-distribution/include/builtin/domains.k#L318


Issue tracker URL is invalid

Fix typo in URL for issue tracker

Sorry, i will archive the repository


FwPositionControl: don't do takeoff help for vtol

takeoff help is used for fixed wings, it increases the altitude setpoint
after a launch. A vtol does not need this as it's already sufficiently
high up in the air.

Signed-off-by: Roman<EMAIL_ADDRESS>

If anybody has been wondering why in the gazebo standard vtol simulation the vehicle climbed like crazy after a front transition just to descend again later...

This helper function is only used in altitude and position control modes, although I don't see why we aren't using it everywhere.

@dagar I think I'm already a step ahead. I was implementing front transition using TECS and discovered this behavior. With current master you don't see this  because I assume TECS is only activated after transition.
I currently put TECS into no-airspeed mode during the transition and give it a predefined throttle ramp up.
Like this we can have it control altitude during the front transition and it's states (except the throttle states) will be initialized after transition. In SITL I get smooth pitch and throttle setpoints and we can avoid having to hack altitude controllers for the transition into the vtol module. I'm not entirely sure how it will work in practice but it's worth a shot. I'm currently testing in SITL and will push a PR most likely today.

@dagar I think this should be fixed for the release because as is it's broken and it causes the plane to increase altitude after transition.
Since the FW position controller does not run during hover mode the ground reference altitude is not set correctly, it's actually set as soon as the vehicle goes into transition mode.
That means that currently for VTOL we always get an increase in altitude after transition no matter how far you are from the ground. I've confirmed that this does not happen if you set the climb-out diff parameter to 0. But that is not the solution as this parameter is used in other parts of the code, not just for the takeoff help.
Additionally, even if we fix the ground reference we still only allow takeoff help for a duration of 10 seconds after the vehicle goes in air. Practically this means that the takeoff help is anyway useless for VTOL as usually the transition to FW takes place after that.
Let me know what you think.

Alright, can we start by getting it rebased?

@dagar No, if we agree how to do it I will quickly do a PR. I just reopened this as a placeholder.

@dagar We will test this in the afternoon.

@PX4/testflights Please test on the deltaquad. The vehicle should not climb noticeably after the front transition (assuming you don't command it to climb).

I've given this a quick test in SITL to verify the behavior. @PX4/testflights please still test this.


Fix GitHub Case

Simply replaced Github with GitHub.

Codecov Report

Merging #240 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #240   +/-   ##
=======================================
  Coverage   51.66%   51.66%
=======================================
  Files          66       66
  Lines        3666     3666
  Branches      414      414
=======================================
  Hits         1894     1894
  Misses       1677     1677
  Partials       95       95

Continue to review full report at Codecov.

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


How to move the desktop application window using keyboard (Alt + Space + m) and then pressing keyboard Down Arrow

I have tried the following (in Java) to move one of my window, but I did not have a luck:
Actions builder = new Actions(MyDriver);
builder.keyDown(Keys.ALT).keyDown(Keys.SPACE).sendKeys("m").keyUp(Keys.ALT).keyUp(Keys.SPACE).perform();
and the pressing Down arrow.
builder.sendKeys(Keys.chord(Keys.ARROW_DOWN));
builder.perform();
builder.sendKeys(Keys.chord(Keys.ARROW_DOWN));
builder.perform();

Buw why do you want to move the desktop window

What's the use case

Because this child window goes out of the screen and some times it displays only half in the scree and rest out of the screen. so, only way is to use 'move' using keyboard (Alt + Space + m) and then use arrow keys or mouse drag and drop.

As a work around you can use autoit script check the below link
https://www.autoitscript.com/autoit3/docs/functions/WinMove.htm


bath method flips index

see lecture 6 from fall 23, types.plot(kind='barh', y='Radius');

Should be an easy fix, but look at #25 as well


Move carrenza env_sync push jobs from Carrenza Staging => Production

Rather than env_sync'ing the publishing apps in Carrenza staging, run these jobs from the Carrenza mysql-backup machine.
This will allow us to easily restore from the production Carrenza database at AWS migration time

@sengi

I'm assuming you plan on having the Integration sync come straight from Prod like it currently does, rather than the Prod->Staging->Integration waterfall that some of the other govuk_env_sync jobs do. (I think that's a fine choice provided there's no redaction needed for Integration.)

Yep, just checked over the backup-and-sync jobs for these, and there's no redaction happening. A card has been created to remove the previously used jobs. I've added govuk_env_sync jobs to pull from the backups created in b3e0e6e


change SubscriptAvatar mode prop to size

Details

This is a pending change from Workspace chats implementation, also includes Storybooks stories for SubscriptAvatar component cc @roryabraham

Fixed Issues

This is a follow-up PR of https://github.com/Expensify/App/pull/7852#discussion_r819174112
Tests / QA

Pre-requisites:

Create or use an existing account which will be the admin
Add the admin account to policyExpenseChat beta
Create a Workspace and invite a few workspace members.
As admin send a message to one of the members through the workspace chat

Steps:

From the workspace chat mark a few messages as unread
Enable #focus mode on Settings -> Preferences
The SubscriptAvatar should be displayed in small size

[ ] Verify that no errors appear in the JS console

PR Review Checklist

Contributor (PR Author) Checklist

[x] I verified the PR has a small number of commits behind main
[ ] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[ ] I clearly indicated the environment tests should be run in (Staging vs Production)

[x] I wrote testing steps that cover success & fail scenarios (if applicable)
[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests & veryfy they passed on:

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

[x] I verified there are no console errors related to changes in this PR
[x] I followed proper code patterns (see Reviewing the code)

[x] I added comments when the code was not self explanatory
[ ] I put all copy / text shown in the product in all src/languages/* files (if applicable)
[ ] I followed proper naming convention for platform-specific files (if applicable)
[x] I followed style guidelines (in Styling.md) for all style edits I made
[x] I followed the JSDocs style guidelines (in STYLE.md)

[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I corroborated the UI performance was not affected (the performance is the same than main branch)
[x] If I created a new component I verified that a similar component doesn't exist in the codebase

PR Reviewer Checklist

[ ] I verified the PR has a small number of commits behind main
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the testing environment is mentioned in the test steps

[ ] I verified testing steps cover success & fail scenarios (if applicable)
[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

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

[ ] I verified there are no console errors related to changes in this PR
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified comments were added when the code was not self explanatory
[ ] I verified any copy / text shown in the product was added in all src/languages/* files (if applicable)
[ ] I verified proper naming convention for platform-specific files was followed (if applicable)
[ ] I verified style guidelines were followed
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components are not impacted by changes in this PR (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[ ] I verified the UI performance was not affected (the performance is the same than main branch)
[ ] If a new component is created I verified that a similar component doesn't exist in the codebase

QA Steps

[ ] Verify that no errors appear in the JS console

Screenshots

Web

Mobile Web

Desktop

iOS

Android

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

Thanks for the follow-up @marcochavezf

🚀 Deployed to staging by @amyevans in version: 1.1.43-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Align buffer for inotify_events to avoid SIGTRAP

Additional description:
Found in internal testing.
Risk Level: Low
Testing: Unit tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A

/retest


200_Manage_Workload_Risks_with_OpsCenter lab changes:

Description of changes:

Added support for custom lenses.
Handling for 'None of these Option' and the absence of HTTP URL of improvement URL in custom lenses.
Added a sorting key and question_Id field to DynamoDB in the Cloudformation template to create uniqueness among choice_IDs within the lens.

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

Hello, is this ready for review? Do you need support with reviewing the change?

Hello, is this ready for review? Do you need support with reviewing the change?

The code was tested and is ready for review.


Broken bottom-right class in drop down

[x] bug
[ ] feature request
[ ] enhancement

Expected behavior
the class bottom-right should cause the drop down to align bottom right.
Actual behavior / reproduce
the class bottom-right does not cause the drop down to align bottom right. This is a bug can be viewed on the clarity website
Environment details

Angular version: 2.0.X

Clarity version:  0.8.14

OS and version: Win10

Browser: Chrome 57.0.2987.133 (64-bit)

Was just trying to track this down on my app.
bottom-left not working either.

This weekend I ran into the same thing but found the answer in the dropdowns docs (https://vmware.github.io/clarity/documentation/dropdowns)
Change your dropdown to use the Clarity angular dropdown component instead of the HTML ones and it will work properly.

@konsultaner @shadowkrusha thank you for bringing this to our attention.
Just investigated this and parts of our website doc is not up to date. We have had an input called clrMenuPosition in the angular dropdown component for a while, but it used to work just fine even if you put css classes directly on the the <clr-dropdown> element to position it (thought this wasn't the intended design).
This breaks for the angular dropdown component starting 0.8.13. Now our component relies on the clrMenuPosition input value to smartly position it, so the angular dropdown must provide this input value for positioning (it defaults to bottom-left if unspecified).
I've created a PR to update our documentation (https://github.com/vmware/clarity/pull/695) to show correct examples of using the dropdown component.
Let me know if using the clrMenuPosition input doesn't resolve your issue, and I'd be happy to take another look.

@jeeyun I used it like this and it worked as expected, thank you!
<clr-dropdown clrMenuPosition="bottom-right">
...
</clr-dropdown>


[SPARK-29725][SQL][TESTS] Add ThriftServerPageSuite

What changes were proposed in this pull request?
Added UT for the classes ThriftServerPage.scala and ThriftServerSessionPage.scala
Why are the changes needed?

Currently, there are no UTs for testing Thriftserver UI page
Does this PR introduce any user-facing change?

No
How was this patch tested?

UT

Test build #113280 has started for PR 26403 at commit e0407d6.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/18188/
Test PASSed.

Test build #113280 has finished for PR 26403 at commit e0407d6.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
      .doc(\"Comma-separated list of class names implementing \" +
sealed abstract class PluginContainer
  class PluginMetricsSource(
case class PluginMessage(pluginName: String, message: AnyRef)
public class GangliaReporter extends ScheduledReporter
   public static class Builder
abstract class IntervalNumOperation(
case class MultiplyInterval(interval: Expression, num: Expression)
case class DivideInterval(interval: Expression, num: Expression)
case class AlterTableAddPartitionStatement(
case class AlterTableSerDePropertiesStatement(
case class ShowCurrentNamespaceStatement() extends ParsedStatement
case class ShowCurrentNamespace(catalogManager: CatalogManager) extends Command
case class ShowCurrentNamespaceExec(

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/113280/
Test FAILed.

Test build #113281 has started for PR 26403 at commit e420857.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/18189/
Test PASSed.

Test build #113281 has finished for PR 26403 at commit e420857.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/113281/
Test FAILed.

retest this please

Test build #113285 has started for PR 26403 at commit e420857.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/18193/
Test PASSed.

cc @srowen Kindly review

Thanks @srowen for the review

Test build #113288 has started for PR 26403 at commit d085611.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/18196/
Test PASSed.

Test build #113285 has finished for PR 26403 at commit e420857.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/113285/
Test PASSed.

Test build #113288 has finished for PR 26403 at commit d085611.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/113288/
Test PASSed.

Merged to master.

Thanks @HyukjinKwon @srowen


11214 DEV update admiral to allow users to enable Gerrit basic auth

https://github.com/Shippable/pm/issues/11214

This is complete.
Closing.


feature: Cluster/Service CIDR

Summary
By default RKE2 sets:

<IP_ADDRESS>/16 - for cluster network
<IP_ADDRESS>/16 - for service netwotk

In manual installation, those values can be altered with rke2/config.yaml:
cluster-cidr: <IP_ADDRESS>/16
service-cidr: <IP_ADDRESS>/16

The goal is to add a support of cluster-cidr and service-cidr opinions in this role.
Issue Type
Feature Idea

Hi @marcinwisniowski, you can achieve that using the variable rke2_server_options.
Example:
rke2_server_options:
    - "cluster-cidr: <IP_ADDRESS>/16"
    - "service-cidr: <IP_ADDRESS>/16"

It looks like a solution to that.
Thanks @MonolithProjects


does this support SSR or nuxtjs?

I've not heard of those (what is SSR?).. and have no idea if text-mask will work with them.. have you tried? (maybe vue-text-mask package if its compatible... or perhaps the vanilla-text-mask may work...)

SSR: Server side rendering


Document how to start hacking on the Tact implementation

Issue #130 is essentially a duplicate of this one, but #130 elaborates more on this, so closing this one


WIP: Cloudformation based SQS broker implementation

What
WIP: cloudformation based sqs broker

closing so I can make it actually re viewable not 4K files :)


fetch metadata from DOI's which are not in DataCite

cordis can return a large number of DOI's, which are project deliverables, mostly reports and scientific articles, some datasets. For those deliverables that have a DOI, it is usually possible to fetch metadata for that DOI from Datacite API. While testing the combination Cordis and Datacite I noticed that many DOI's are not available in Datacite. These are mostly DOI's from scientific magazines, such as Elsivier, Springer, Nature.
Which made me wonder, what is the best way to retrieve metadata from these DOI's?

An obvious approach is to follow the DOI link to its actual target, and try to grab as much metadata as possible from this website. Unfortunately publishers do not have a common approach to advertise metadata on these pages. Some use open graph metadata, some dublin core, some a tailored citation syntax.
Metadata for all DOI's (as far as I know) is advertised in Bibtex format via the general DOI endpoint. Consider that bibtex is quite limited, it has the date, title, authors, publisher and publication details.

Maybe OpenAire is the answer here, query the openAire API for the specific DOI? Alternatively a library service such as Scopus?
Interesting is to see that most commercial library providers implement google tagmanager, which advertises the most elaborate metadata via the window.datalayer
Some questions:

What properties of metadata do we expect minimally from these approaches (title, year, authors, magazine, publisher, copyright/usage constraint/license, status).
We need at least a link to the actual resource (pdf/zip/...), usually the DOI brings you to the article, however in many cases it brings you to a metadata page about the resource,  the link to the resource is usually added as a link in the metadata,

OpenAire seems to not include some of the articles returned by cordis:

https://api.openaire.eu/search/researchProducts?doi=j.catena.2020.104511
https://api.openaire.eu/search/researchProducts?doi=2010.1002/hyp.11434

But others, which are not in Datacite, are actually in OpenAire

https://api.openaire.eu/search/researchProducts?doi=10.1051/e3sconf/20199809012


[Azure Monitor OpenTelemetry] Implement Web Snippet Injection

Packages impacted by this PR
@azure/monitor-opentelmetry
Describe the problem that is addressed by this PR
Adding the web snippet feature to the distro.
Are there test cases added in this PR? (If not, why?)
Yes, added in the webSnippet.test.ts file.
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[x] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[x] Added a changelog (if necessary)

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-monitor-opentelemetry


Neardrop disappearsl quickly

I have used Neardrop properly until two days ago. I have Ventura 13.6.4 (22G513)and now when I send a file the notification windows disappears quickly and I cannot select accept. I have tried several times but always have this problem. Could you help me? Thank you so much

Set NearDrop notifications to "alerts" in system settings.


[SPARK-16694] [CORE] Use for/foreach rather than map for Unit expressions whose side effects are required

What changes were proposed in this pull request?
Use foreach/for instead of map where operation requires execution of body, not actually defining a transformation
How was this patch tested?
Jenkins

Test build #62764 has started for PR 14332 at commit 6fabd16.

Test build #62764 has finished for PR 14332 at commit 6fabd16.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/62764/
Test FAILed.

Jenkins retest this please

Test build #62767 has started for PR 14332 at commit 6fabd16.

Test build #62767 has finished for PR 14332 at commit 6fabd16.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/62767/
Test PASSed.

The Scala API docs clearly specify that the most idiomatic usage of Option is to treat it as a collection or monad and use map, flatMap, filter, or foreach.  Those docs also clearly specify that using Option values via pattern matching is less idiomatic.  There is nothing fundamentally wrong with map applying a function that produces results of type Unit, nor is such an operation some kind of special not-a-transformation that must always be treated differently from operations that have been blessed as legitimate transformations.  Sure, when you eventually come to the boundaries of purely functional code and it is time to deal with side effects, then the distinctness of Unit comes into play.  But it is a basic FP principle or best practice to not treat types as specific instead of abstract until you logically must deal with the specifics -- and that is just not the general case with map functions that produce Unit, nor with folding an Option.
Usage of Unit consistent with usage of other types in things like map and fold can be confusing to the many Spark contributors who aren't completely at home with idiomatic FP, and that is why, e.g., we chose not to allow folding of Option within the Spark code.  That's not going to change based on any argument in this PR's comments.
But neither should we shy away from any and all usages of Unit producing functions within map -- especially not when that usage is the preferred, idiomatic usage of Option.  The issue that SPARK-16694 should be dealing with is not a fundamental problem with map and Unit, but rather with problems caused by the not completely sound implementation of view in Scala.  There are known problems and ugly corner cases associated with view, and that's why I think Scala programmers would be well advised to avoid it when they can, or to use it with great caution when they must.  Alternatively, you can more safely use something like Josh Sureth's Viewduction work: https://github.com/jsuereth/viewducers

Jenkins retest this please

Test build #63003 has started for PR 14332 at commit 6fabd16.

Test build #63003 has finished for PR 14332 at commit 6fabd16.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63003/
Test PASSed.

Merged build finished. Test PASSed.

Test build #63018 has started for PR 14332 at commit 3a5c5a6.

Test build #63018 has finished for PR 14332 at commit 3a5c5a6.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/63018/
Test PASSed.

Merged to master


Add DynamoDBContextConfig.DisableFetchingTableMetadata to skip the internal DescribeTable call if the index structure is provided statically

Description
This is a proposal to partially address https://github.com/aws/aws-sdk-net/issues/1476 if using the object persistence model with a fully annotated class.
Currently both of our higher-level DynamoDB programming models rely on knowledge of the table's index structure which is cached inside the SDK via a DescribeTable call.

For the object mapper, this is done lazily when the first DynamoDB operation is invoked on DynamoDBContext
For the document model, this is more explicit via Table.LoadTable

In versions of .NET that only have an async HTTP client, this DescribeTable is made via the sync-over-async antipattern becayse we've always carried forward the public sync APIs for the high-level programming models. This is leading to threadpool exhaustion and deadlocks in some scenarios.
As @normj discussed in https://github.com/aws/aws-sdk-net/issues/1476#issuecomment-567221982, one path is to go async-only, but we'd have to do that in a new major version since we currently expose public sync APIs.
Another idea is to remove the need for the DescribeTable call if the table structure is provided statically in advance. This PR explores this idea for the object-persistence model.

Adds a new option AWSConfigsDynamoDB.Context.DisableFetchingTableMetadata which defaults to false.
Adds a new option DynamoDBContextConfig.DisableFetchingTableMetadata, which defaults to false.
If this is set to true, when populating the internal SDK cache of table metadata for a given table we only rely on the information from:

The DynamoDBAttribute attributes applied to the .NET class that is mapped to to the table
The global AWSConfigsDynamoDB object.

The SDK fills the cache using that static data, then proceeds as if it has made the DescribeTable call.
Testing

Existing DynamoDB test cases pass
Added new automated tests that verify the following scenarios:

DynamoDB operations can be invoked successfully based on the table info supplied only via class attributes.
DynamoDB operations can be invoked successfully based on the table info supplied via a combination of class attributes and the app config.
DynamoDB operations can be invoked successfully based on the table info supplied via attributes on the parent class.
DynamoDB operations can be invoked successfully based on a Datetime attribute as the hash key that is stored as epoch.
The table info is cached using the actual table name and the key/index info is generated correctly based on DynamoDB attributes.
Setting the global AWSConfigsDynamoDB.Context.DisableFetchingTableMetadata to true propogates to the local DynamoDBContextConfig.

There is a separate backog item (DOTNET-7140) to investigate failure modes when the table info provided via class attributes does not match the actual table.
Types of changes

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

Checklist

[X] My code follows the code style of this project
[X] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
[X] I have read the README document
[X] I have added tests to cover my changes
[X] All new and existing tests passed

License

[X] I confirm that this pull request can be released under the Apache 2 license

I can't formally approve since I originally created this, but LGTM. Two small nits related to docs (one I forgot to publish last week), but neither are dealbreakers.

Squashed and merged into the feature branch feature/ddb-skip-describe-table


Add test case to demonstrate exception on pickling RethrownJobError

Here's your test case. Checked in Python 3.5.1 in a virtual environment that contained only ruffus.
At least one problem here is that because of the non-standard exception arguments, RethrownJobError cannot be de-pickled, because BaseException in CPython defines a custom __reduce__() that contains certain assumptions including that there is a tuple args and it will create the new exception by invoking CustomException.__init__(*args). After that all other variables are set.
I think error_task_construction and its subclasses will have similar problems too, but error_task is probably okay.
Exceptions have to be picklable to cross process boundaries. One demonstration of this is attempting to log the exception using the ruffus proxy_logger since it puts the logging in a separate process. This doesn't exactly replicate the error I was getting, although I did find a more complex way to do that. I will check for that if necessary, but I suspect getting RethrownJobError to unpickle properly will resolve the issue (and it should be resolved regardless).
See here for some details and a link to the relevant C code for BaseException.__reduce__
https://stackoverflow.com/questions/16244923/how-to-make-a-custom-exception-class-with-multiple-init-args-pickleable

Also this one
https://stackoverflow.com/questions/27993567/custom-exceptions-are-not-raised-properly-when-used-in-multiprocessing-pool

Storing the information in a variable other than args just seems to work. Thanks for sorting this out, and especially for writing the test case.
The only thing that puzzles me is the call to "log.join()".

I added log.join() because while creating the test case I was sometimes able to trigger a race condition where the logger process exited without posting its last message. But it might not be needed any more, and it's not a documented part of the API - so maybe it's better left out.
Relevant code:
https://github.com/python/cpython/blob/master/Lib/multiprocessing/managers.py


feat: build simple calculator in c

This can be used as a start (boilerplate) for the rest of the project.
I added a header file calc.h which contains the standard input and output Library.
I also wrote the calc.c file which house the main function and implements the basic calculator

more features coming soon

Hi Destiny.
Please move these files you wrote (they are awesome!!) into a new directory called Destined_Codes-C. Don't forget to add a README.
Thank you boss.

Sure, I'll do that

@dohoudaniel I have moved the Source code to the DestinedCodes-c directory

Thank you.
Reviewers will be assigned soon.
Thank you @DestinedCodes


Small changes, mock data for the new format

Nothing much here, some typing changes, made a mock file for the data that the render function takes

I think that the renderer should not worry about twitter api response format. I think there should be some transformation from the twitter response into the renderer specific format.
Also the puppeteer scraped response should return the same format.
Twitter API | Puppeteer --> Common format --> handlebars template

@johnjacobkenny The mock.json does contain the common format. For all the file formats.

I'm seeing a lot of fields that's why I asked. Doubtful whether that level of granularity will be possible from scraping

@johnjacobkenny
Those extra fields you're seeing are just in the user object. They need to be refined.
Part of my next work😉

@johnjacobkenny Can you merge it if its fine?


Unable to press

Preparation

[X] I tested the latest release
[X] I looked at other issues (even the closed ones)
[X] I read the Troubleshooting Guide

FGO server
NA
FGA build number
1577
Describe the bug
When I want to press "start" after pressing "start device", it does not work. But the cancel  button function

( i'am on bluestack )
Video
https://user-images.githubusercontent.com/90508205/146682762-9e7fc9e6-129f-4081-aeba-592b775338ce.mov
Device model
blustacks on ONEPLUS 3T
Android version
7
Screen size
1920X1080
RAM
4 GB

If you searched for "Bluestacks" in the closed issues, you would have found the solution.
Since more and more people can't find the solution, I've added it to the Bluestacks part of the troubleshooting guide: https://github.com/Fate-Grand-Automata/FGA/wiki/Running-on-Emulators#bluestacks
It's the part about rotating your screen before you start the FGA service.

I had watched and read this post, I just didn't understand that it was mandatory to be on bluestacks 5


A multi-stage docker build errors on this image (see related)

Errors with
hcsshim::ImportLayer failed in Win32: The configuration registry database is corrupt. (0x3f1)

Related: https://github.com/moby/moby/issues/44992

https://github.com/moby/moby/issues/44992#issuecomment-1428768253


feat: July 2024 email issues notification

TIS21-6252

There is an e2e test for this, but no component test unfortunately.


airflow CLI commands using docker exec -it ignore the config in compose files

I have pulled this repo and changed postgres details in docker-compose-LocalExecutor.yml to the following (nothing else changed). Note that load examples is set to False and executor is set to LocalExecutor
version: '2.1'
services:
    postgres:
        image: postgres:9.6
        environment:
            - POSTGRES_USER=w63kIwod7gae
            - POSTGRES_PASSWORD=OioE9068995S
            - POSTGRES_DB=airdb

    webserver:
        image: puckel/docker-airflow:1.9.0
        restart: always
        depends_on:
            - postgres
        environment:
            - LOAD_EX=n
            - EXECUTOR=Local
            - POSTGRES_USER=w63kIwod7gae
            - POSTGRES_PASSWORD=OioE9068995S
            - POSTGRES_DB=airdb
        volumes:
            - ./dags:/usr/local/airflow/dags
            # Uncomment to include custom plugins
            # - ./plugins:/usr/local/airflow/plugins
        ports:
            - "8080:8080"
        command: webserver
        healthcheck:
            test: ["CMD-SHELL", "[ -f /usr/local/airflow/airflow-webserver.pid ]"]
            interval: 30s
            timeout: 30s
            retries: 3

I then did:
docker-compose -f docker-compose-LocalExecutor.yml up --build

This starts the container correctly and I can see in the console that the configuration was picked up correctly:
webserver_1  | [2018-02-09 17:55:17,519] {{__init__.py:45}} INFO - Using executor LocalExecutor
webserver_1  | DB: postgresql+psycopg2://w63kIwod7gae:***@postgres:5432/airdb

I can access the admin ok and I can trigger tutorial dag ok.
Now, I then log into the container interactively:
docker exec -it $(docker-compose -f docker-compose-LocalExecutor.yml ps -q webserver) bash

If I do:
airflow connections
# brings up Using executor CeleryExecutor

airflow trigger_dag example_python_operator
# returns FATAL:  password authentication failed for user "airflow" (note that user defined in compose is w63kIwod7gae)

airflow list_dags
# lists all default examples (load examples is set to false in compose)

Location of airflow is:
airflow@b64d95a03a95:~$ which airflow
/usr/local/bin/airflow

**It seems that in interactive mode airflow uses the default configuration and completely ignores the contents of compose. **
I also tried assigning another name to the psql service i.e. changed postgres to scheduler-psql and aliased it appropriately
    webserver:
    links:
      - scheduler-psql:postgres

In this case running airflow trigger_dag tutorial from inside the container complains that postgres service is not running even though the DAGs trigger and register correctly through the UI (and if I expose port 5432 I can access the db with a sql client).
Any ideas? I'm not sure where to go next debugging this. It would be great to have the flexibility of using CLI commands inside of the container.
Thanks!

Hi don't know if you solved this but i ran into the same thing. If I use my own config file with sql_alchemy_conn set then it works as the cli is reading that file.

Same problem here. It seems that the airflow.cfg that you find inside the airflow container (located in the airflow home) is always the default one, no matter what you do in the yml file. I wonder why airflow starts with the correct configuration. From where does it read the config?

Airflow reads the environment variables...
echo $AIRFLOW__CORE__SQL_ALCHEMY_CONN
postgresql+psycopg2://airflow:airflow@postgres:5432/airflow

As stated here https://airflow.apache.org/configuration.html the environment variables take precedence over airflow.cfg

Now I understand what is happening.
Env variables are set by entrypoint.sh only for the current session, so airflow is started with the correct config.
However if you open a bash the env variables are not set.
`echo $AIRFLOW__CORE__SQL_ALCHEMY_CONN
`
(My previous comment was wrong, I forgot I did an export of the variable manually first ...)
You need to export the variables in .bashrc file in order to make them available in all bash sessions.
Se also this interesting post on Airflow configuration:
http://www.the-efficient-programmer.com/programming/an-effective-airflow-setup.html

@ena1106 I believe L#19 is doing this very thing: exporting environment variables. I even tried adding explicit export statements around L#60-61, to no avail.
Just a quick confirmation: when you say

..However if you open a bash the env variables are not set...

you mean opening bash session by docker exec -it into an already running container that was launched by docker-compose / Dockerfile, right? If not, could you please elaborate a bit?

@y2k-shubham @ena1106 Im facing the same issue and stumbled upon this post. When I ssh into the container I don't see AIRFLOW__CORE__SQL_ALCHEMY_CONN set but seems airflow initdb correctly created tables in postgres.
Can you please elaborate on You need to export the variables in .bashrc file in order to make them available in all bash sessions. ?

Since you are using using docker-compose to initialize your environment then you should use docker-compose to list your dags or execute any other airflow command.
docker-compose -f docker-compose-CeleryExecutor.yml run --rm webserver airflow list_dags
Running the above will allow to airflow cli to take the same environment variables that are used in your docker component.
If you need to use docker instead of docker-compose (remember that docker cli is used to manage individual containers and docker-compose cli is used to manage a multi-container application), then you can go through entypoint.sh
docker exec -ti airflow_webserver_1 sh -c "/entrypoint.sh airflow list_dags"

This is a little bit of a hack but it does enable me to open a bash session into a Docker container and run all of the Airflow subcommands.
Basically I have created a custom entrypoint script  (and a slightly modified Docker image) and added this little one liner.
if [ "$AIRFLOW__CORE__EXECUTOR" = "LocalExecutor" ]; then
    printenv | grep AIRFLOW | awk '{ print "export " $1 }' > ~/.bashrc
fi

So, when I start Airflow under Local Executor I output all of the environment variables into a .bashrc file.  This means I can then start a bash session into a running container using docker exec -it and then perform any airflow subcommand as normal.

Here's a slightly different hack: ask the entrypoint to run the shell for you, so the environment variables are present:
docker exec -it airflow sh -c "/entrypoint.sh /bin/bash"


Chore: Cleanup Code and prepare for v3

[x] Make sure that storage API is stable
[x] Remove dirty code only to prevent breaking changes
[x] Improve Code Quality

How about support defining jobs in Scheduler module, instead of config?
It will help maintaining config clean, and keep codes organized.

@jung-hunsoo This is already possible. I'm not sure though if this is properly documented.
You can define an init/1 function in the Scheduler where it is possible to alter the configuration in code.

@maennchen Thanks. Based on your comment, I successfully moved defining jobs from config to Scheduler module.
Here is my working codes:
  def init(config) do
    jobs = [
      # Everyday midnight in Seoul.
      {"5 15 * * *", {Nohogu.Tips, :clear_old_applied_editors, []}},
      # Monthly midnight in Seoul.
      {"10 15 1 * *", {Nohogu.Tips, :rerole_editors_by_role_all, []}}
    ]

    base = Quantum.Job.new(config)
    norm_jobs = Enum.map(jobs, &Quantum.Normalizer.normalize(base, &1))
    Keyword.put(config, :jobs, norm_jobs)
  end

Any improvements?

Fixed on master, will be released with #427


[RFC] 1 WIP: Docs as Code

RFC Name: Docs as Code
RFC ID: 1
Start Date: 2022-08-22
Contributors: @frankhinek, @ALRubinger, @saeedjabbar
Current Status: WIP

Summary
Proposal to adopt a docs-as-code approach for developing a technical documentation system that helps orient newcomers, helps contributors acquire and apply knowledge, and helps create an inclusive community.
Context and Scope
TBD's projects are developed in the public guided by an open source philosophy with three foundational pillars: inclusivity, transparency, and clarity.  This proposal is focused on making progress towards fulfilling these commitments:

Anyone with the capacity to contribute: can.
We are proactive in welcoming a diverse contributor base for our code, documentation, ...
Decision-making is open by default, ...
Projects need ... accessible, comprehensive documentation, a stellar Getting Started experience, and well-defined expectations.

"Incomplete or confusing documentation" has frequently been cited as one of the top problems in open-source software development.  Accurate, up-to-date, and well-organized documentation improves the first time contributor experience, creates a more inclusive environment, and can result in significant productivity boosts.
Given the target audience for developer.tbd.website and early stage of development for most TBD projects, it follows that the documentation should be optimized for the new contributor experience.  Using a docs-as-code approach combines the power of developer tools with techniques to encourage community engagement and improve documentation quality.
Treating docs-as-code means that document publishing follows a similar process to software development:

documentation is stored as plain text in a version control system
issues and pull requests track all documentation changes and decisions
additions and revisions are reviewed
approved documents are published without much human intervention

By taking an open approach that is accessible and familiar to developers, TBD can establish a virtuous cycle by encouraging more community enhancements and feedback to improve the contributor experience, which in turn leads to more engagement.
Goals

Anyone in the community can contribute enhancements, fixes, and ideas.
Documentation source files are stored in a publicly accessible repository.
Documentation and code/command examples in separate files.
Minimize the dependencies and onboarding steps for contributors.
The documentation repository is organized in a thoughtfully structured manner.
Changes to documents are reviewed and must be approved prior to publication.
All code and command examples are manually tested during review.
Once approved, document processing and artifact builds are automated.
Documentation is published to developer.tbd.website.

Non-goals
Several of these could reasonably be goals, but are explicitly chosen not to be goals in favor of releasing a minimum viable documentation system and receiving feedback from the community.

Definition of documentation templates
Automated code/command testing and linting
Multi-language support
Search
Support for JSX in Markdown documents (.mdx)

Proposal
Document Format

Documentation text is stored as plain text files.
Markdown formatting is used to add style to plain text.
CommonMark syntax specification for Markdown.
Code/command examples are stored separately from documentation text to minimize migration friction if/when automated testing is introduced.

Documentation Processing

Target output format for inclusion in developer.tbd.website is Markdown so that the Docusaurus-powered site can import post-processed Markdown files.
Use remark to parse, transform, and serialize Markdown content. Why remark?
A new command-line utility, tentatively tbdoc, automatically transforms documentation source files into artifacts ready to be imported to developer.tbd.website.  Why wrap with Docker?

Repository Structure

Developed and maintained by the community on GitHub in a single @TBD54566975 repository.

Documentation is organized by topic to improve discovery, authoring, and maintenance (e.g., SSI Service, DWN, third-party integrations, etc.).

Each topic consists of:

Sub-directories for tutorials and how-to guides.
If appropriate, one or more Dockerfiles which are shared by topic documentation.  Ideally, the Docker image definition maintained within the associated TBD project repo can be used to minimize maintenance.
A sub-directory is created for each tutorial or how-to guide and consists of:

Markdown files that contain the documentation text.
Images that support the content.
A workflows directory that contains an individual file for each command or code example.  During the documentation build process, these files will be parsed and inserted inline with the documentation text.

Contributor creates the directory structure scaffolding for a new tutorial.
Contributor authors the document, including any command/code and/or images.
Contributor opens a pull request (PR) in the TBD community docs repo.
TBD and community members review, manually test command/code examples, and provide feedback.
If approved, the PR is merged to the TBD community docs repo.
GitHub Actions automatically process the contributed docs and open a PR on the TBD Developer Site.

Suggesting a Fix or Improvement

Contributor opens an Issue or PR in the TBD GitHub repo.
TBD and community members review and provide feedback.
If approved, a PR is created (if starting as an Issue) and approved/merged.
Automated workflow publishes the revised content.

Definition of success

Community contributors author, submit, and have their content published to developer.tbd.website.
Positive feedback is received from the community.
The docs-as-code approach and design proposal can be adapted to automate publishing to developer.tbd.website.
This design can be enhanced and extended over time as a function of being modular and flexible.

Open Questions

After a community contribution is approved and merged into the community docs repo, a GitHub Action will automatically create a PR in the TBD Developer Site.  When this action is creating the PR, should it create a new branch and PR for each approved push to the community docs repo?  Or should any additional pushes to the community docs repo main branch be added to the open TBD Developer Site PR until it is approved or closed?

Appendix
Alternatives Considered

MarkdownPP
Pandoc 3
Antora
Gitdown
Markdoc
Postman API Platform
Gitbook
Mkdocs
ReadMe

Design Decision Rationale
Why Remark?

Can be easily extended with linting, grammar, and language use plugins to drive up the quality of the documentation and make it more accessible to groups that are underrepresented in open source software development.
Markdown parsing engine used by Docusaurus, MDX, Node.js docs, GitHub Docs, and many other projects.
The most downloaded Markdown parser.
100% compliant to CommonMark and 100% to GitHub Flavored Markdown (GFM) with a plugin.
Hundreds of available plugins to support a broad variety of use cases and workflows.

Why encapsulate utility tools/scripts with Docker?

One of the high priority goals for this proposal is that Anyone in the community can contribute..., and to that end, a secondary objective is to Minimize the dependencies and onboarding steps for contributors.  By encapsulating utility tools/scripts using a Docker container, the only dependency a contributor must satisfy is a local installation of a Docker engine.
For documentation contributors whose strengths are in technical writing or who aren't polyglot programmers, the major benefit to this approach is eliminating onboarding steps such as installing runtime environments (e.g., Node.js, JVM, etc.), modifying the PATH environment variable, or managing multiple runtime environment versions needed to satisfy different project requirements (e.g., Node 10 vs. 16).
Docker containers run applications in a consistent, isolated environment which helps to ensure that more contributors are successful when using the tools and less community time is spent troubleshooting.

Decision Log

Docusaurus is used for developer.tbd.website, which supports MDX.  Should we support including JSX in markdown content for community-contributed docs?
DECISION: MDX/JSX will not be supported in the initial release.
Additional Context: There may be complications related to how Docusaurus handles MDX and incorporates external Markdown. Long term we may want to offer docs authors greater flexibility in styling by exposing JSX directly. In service of MVP, we will limit the scope to exclude support for community contributors authoring MDX and release a system which lets us author in Markdown, embed code and images and publish content on the TBD Developer Site.

When new documentation is approved and PRs merged, GitHub Actions can be triggered to build the doc artifacts and potentially trigger publishing to developer.tbd.website.  Should this workflow run in the main Docusaurus site repo or the community-contributed docs repo?  What additional steps can we take to automate the publication process and minimize human intervention?
DECISION: The community-contributed docs repo will use GitHub Actions to build the output Markdown and trigger a Pull Request on the TBD Developer Site repo.
Additional Context: The community-contributed docs repo can run builds to compose the output Markdown, and then we trigger a PR into the Developer Site repo to update/add the newly-generated page? This would let us always revert the Developer Site if we needed, and makes clear when a new piece of content is to be published, while letting the docs repo handle its own build to generate the markdown.

This is a remarkable effort. Thank you, @frankhinek!
Overall, it's a path I'd love to continue exploring. I appreciate the Docker-based approach to lock the build environment and give devs consistency. Remark looks like it's working great so far for the code injection and templating. My run through the docs here got me a clean build with no issues and the sh snippits inlined into the output. Overall, I'm really curious to see how this works if we do automate this into a PR for the developer site - I think that'll be proof that we're on to something. As you call out, the workflow is super important to contribution and to our validating that we've really lowered the bar to docs submissions from folks. TL;DR from me is I think this makes a lot of sense to make progress, and I suspect we'll have plenty of room to fine-tune along the way.
Some more detailed feedback on items in the WIP:
Non-Goals
Is the intent here simply to keep scope small to deliver an MVP?

Automated code/command testing and linting

Automated testing, to me, is the piece that protects user experience by making sure that the docs as published will work against a specified version of the software. Are we leaving space for this to be solved later, or do you have opinions about the testing of docs that leave this out of scope longer-term?

Multi-language support

One of the best ways I've found to welcome new contributors is to give them an easy way to translate docs into their preferred language, in turn addressing a more global audience and welcoming them. Same question as above: we'll leave space for this to add easy internationalization so that docs can be prepared in N outputs, pulling in the same code snippits that you've externalized in this example?
Open Questions

Docusaurus is used for [developer.tbd.website](https://developer.tbd.website/), which supports [MDX](https://mdxjs.com/docs/what-is-mdx/). Should we support including JSX in markdown content for community-contributed docs?

This one may get murky as I believe it's tied into how Docusaurus handles MDX and pulling in external Markdown. Long term we may want to offer docs authors greater flexibility in styling by exposing JSX directly. In service of MVP I'd be thrilled to start by releasing a system which lets us author in Markdown, embed code and images as you've shown, and get things published on the Developer Site. WDYT?

When new documentation is approved and PRs merged, GitHub Actions can be triggered to build the doc artifacts and potentially trigger publishing to [developer.tbd.website](https://develop.tbd.website/). Should this workflow run in the main Docusaurus site repo or the community-contributed docs repo? What additional steps can we take to automate the publication process and minimize human intervention?

Hot takes: chained builds? The community-contributed docs repo can run builds to compose the output Markdown, and then we trigger a PR into the Developer Site repo to update/add the newly-generated page? This would let us always revert the Developer Site if we needed, and makes clear when a new piece of content is to be published, while letting the docs repo handle its own build to generate the markdown.
Will also comment on the forum post about this to address how we wanna keep the momentum up here. @frankhinek - thank you again!!

@frankhinek Excellent job. See my write up here: https://forums.tbd.website/t/tutorials-and-examples-system/89/25?u=saeedjabbar

Overall, I'm really curious to see how this works if we do automate this into a PR for the developer site - I think that'll be proof that we're on to something. As you call out, the workflow is super important to contribution and to our validating that we've really lowered the bar to docs submissions from folks.

Agreed -- wiring up the workflow end-to-end will help to validate the approach, and we can work out any minor issues along the way.  To accelerate the implementation and testing we could create a second repo to simulate the developer.tbd.website Docusaurus integration (GitHub Actions & PRs).  Once the approach is validated and the contributor experience is satisfactory, the workflow can be incorporated with the repo tied to the production deployment.

Is the intent here simply to keep scope small to deliver an MVP?
Automated code/command testing and linting

Yes, precisely.  The intent was in the spirit of getting an MVP going per the forum discussion thread.  As I started writing out the detailed design proposal, it became clear that getting the contributor experience right with automated tests was going to take some iteration.  There are a few ways to approach both in-lining the statements and authoring tests, which can be decoupled from the initial MVP deployment.
I do suggest that we tackle this in the near-term as it does have numerous benefits for the contributor experience.  "Broken" step-by-step documentation is all too common, particularly for fast moving projects.  Additionally, the longer we wait to introduce this feature, the more clean-up work will be needed to address previously published content.

Multi-language support
Same question as above: we'll leave space for this to add easy internationalization so that docs can be prepared in N outputs, pulling in the same code snippits that you've externalized in this example?

That is a great point and could be a good way to encourage more early contributors.  Based on a review of how Docusaurus handles i18n, it appears that this would be fairly easy to plan for in the initial design and incorporate in the short-to-medium term depending on the prioritization by the community and TBD.
Q: Does the current developer.tbd.website Docusaurus instance already have i18n configured, and if so, can you share a few details that can guide how to structure community contributed docs?
e.g., translation file structure, single-/multi-domain strategy, etc.

Should we support including JSX in markdown content for community-contributed docs?
In service of MVP I'd be thrilled to start by releasing a system which lets us author in Markdown, embed code and images as you've shown, and get things published on the Developer Site. WDYT?

Agreed -- progressing to an initial working MVP seems appropriate.

Should this workflow run in the main Docusaurus site repo or the community-contributed docs repo?
Hot takes: chained builds? The community-contributed docs repo can run builds to compose the output Markdown, and then we trigger a PR into the Developer Site repo to update/add the newly-generated page? This would let us always revert the Developer Site if we needed, and makes clear when a new piece of content is to be published, while letting the docs repo handle its own build to generate the markdown.

I like it for the reasons you highlighted, and it also allows the two to run in parallel at a different pace, if needed.

Updates:

Closed two Open Questions and updated the Decision Log based on the feedback from @ALRubinger and @saeedjabbar.
Added two NEW Open Questions.
Implemented the end-to-end community contributed docs workflow.
Implemented Live Preview for local doc editing.

End-to-end Worklow Notes
Two repos are used to mock the TBD Developer Site and the Community Docs repos:

TBD Developer Site: https://github.com/frankhinek/prototype-tbdocusaurus
TBD Community Docs: https://github.com/frankhinek/prototype-tbdocs

The steps for authoring new content are:

A contributor would start by forking the TBD Community Docs repo, cloning locally, and adding/editing content.
There's now a Live Preview utility so contributors can see how their content will look once its published: tbdoc Live Preview.
Once satisfied with their additions/changes, a contributor commits their changes to their fork and submits a PR to the TBD Community Docs repo.
TBD and community members review, and if needed, provide feedback or request changes.
Once the PR is approved and merged to the TBD Community Docs main branch, GitHub Actions automatically kicks off an Open Dev Site PR workflow to process the Markdown content and open a PR in the TBD Developer Site mockup.
The TBD Developer Site PR contains the committed files, a link to the original approved merge, and also a Netlify Deploy Preview for the team managing the TBD Developer Site to review the visual appearance of the contributions.
If the changes are accepted, the PR is approved/merged and then the typical publishing process for the TBD Dev Site would kick off.

Here's an example:

Commit to community docs mock repo: https://github.com/frankhinek/prototype-tbdocs/pull/13/commits/669877e53a3416fe0f81e23fa8742551dc31708a
GitHub Actions ran: https://github.com/frankhinek/prototype-tbdocs/actions/runs/3027820249
PR opened on Dev Site mock repo: https://github.com/frankhinek/prototype-tbdocusaurus/pull/5

This is amazing. Thanks for the patience while I've found the time to grok the comprehensive docs and instructions you've laid out here. All ran great here and I totally see where you're going with this workflow. Eager to get it into the repo and hook things together, and I've granted you admin access here.
I've written up some more details on the forum thread.
To your open questions:

Docusaurus is used for developer.tbd.website, which supports MDX. Should we support including JSX in markdown content for community-contributed docs?
This one may get murky as I believe it's tied into how Docusaurus handles MDX and pulling in external Markdown. Long term we may want to offer docs authors greater flexibility in styling by exposing JSX directly. In service of MVP I'd be thrilled to start by releasing a system which lets us author in Markdown, embed code and images as you've shown, and get things published on the Developer Site. WDYT?

Exactly as you suggest. Let's get some Markdown where we can embed code and images and iterate from there. That alone is a huge win for bootstrapping contribution and getting it published.

When new documentation is approved and PRs merged, GitHub Actions can be triggered to build the doc artifacts and potentially trigger publishing to developer.tbd.website. Should this workflow run in the main Docusaurus site repo or the community-contributed docs repo? What additional steps can we take to automate the publication process and minimize human intervention?
Hot takes: chained builds? The community-contributed docs repo can run builds to compose the output Markdown, and then we trigger a PR into the Developer Site repo to update/add the newly-generated page? This would let us always revert the Developer Site if we needed, and makes clear when a new piece of content is to be published, while letting the docs repo handle its own build to generate the markdown.

Love the chained builds approach and it's given me success before. Because: then we've cleanly decoupled the docs contribution piece into its own workflow, and the publishing step will show us in each commit exactly what's to be pushed live on the dev site. Also makes for a super clean audit trail in the case we need to roll back changes on the Dev Site. I'm hoping this is a really easy contribution path for people by letting them focus only on the writing and docs generation, knowing the grander details of publishing will just (waves magic wand) be handled for them through automation.
@saeedjabbar had an open question too:

Q: Does the current developer.tbd.website Docusaurus instance already have i18n configured, and if so, can you share a few details that can guide how to structure community contributed docs?

Docusaurus has i18n support but we're not taking advantage of it yet, and I'm thinking that once we get this plugged in, i18n is an awesome thing to enable and let the community run with for translations. I was once astounded at how eager folks were to translate the Arquillian Quides into so many languages.


Y axis bar values are overlapping with each other in apache superset bar chart

When I try to show the bar value in the bar chart of apache superset, y axis bar values overlap with each other.
To fix this issue, I want to rotate the y-axis values with 45 degree so that those values will look vertically and won't overlap with each other, just like it is there in x-axis values.

Can someone suggest me a way to fix this issue?

Still facing this issue. Please suggest any way to resolve this

Hi @piyush-singhal, looks like there's no support for this yet. While this could probably be fixed through a change to the NVD3 plugin (https://github.com/apache-superset/superset-ui/tree/master/plugins/legacy-preset-chart-nvd3) we plan to migrate to echarts in the future and will track supporting this feature
I'm going to close this since there are no plans to fix this with the current nvd3 implementation. Feel free to open a PR to address this yourself and tag me for review if you want though!

Isn't the plugin now moved to https://github.com/apache/superset/tree/master/superset-frontend/plugins/legacy-preset-chart-nvd3 ?

The plugin is now moved to https://github.com/apache/superset/tree/master/superset-frontend/plugins/legacy-preset-chart-nvd3 .