Add your title here

We ask that you please be patient as our team works through approving and publishing all articles/tutorials in a timely manner. Allow 1-3 days for a topic to be reviewed and/or approved - allow 3-7 days for an articles to be reviewed and/or published.
Be sure to visit our Resources Page for tools, resources, and example articles to go over.
NOTE: (Please ensure that you have only one open issue + linked pull request at a time. This will ensure that we complete the article in a timely manner from inception to publishing.)
NOTE: We tend to stray away or tend not to publish reviews/comparisons of commercial product offerings.
We're looking for the first 2-3 paragraphs of the article that appropriately summarize what your article will be about.
Proposed title of article
Your title should be descriptive of the article/tutorial. Be Specific. Use keyword research to gain your article higher ranking.
Introduction paragraph (2-3 paragraphs):
Please write the Introductory paragraph(s), that would be included in your article. We will use this writing snippet to help us assess overall quality before approval. We're looking for the first 2-3 paragraphs of the article that appropriately summarize what your article will be about.
Take your time and write the content as you would intend to get it published.
Key takeaways:
What are the 3-5 most important things the reader should understand or be able to do after reading this article? Use this area to get your ideas down on the bulk of your article or tutorial.
References:
Please list links to any published content/research that you intend to use to support/guide this article.
Templates to use as guides

How To Guide Template
Software Review Template
Tutorial Template

@shegz101 kindly re-work on your issue. Follow the laid guidelines

Kindly fill out your suggestion and add a title. @shegz101

Thank you for the topic suggestion @shegz101 , however this is a bit outside of our preferred topic areas. We're more interested in original, practitioner-focused content that takes a deeper dive into programming-centric concepts. Please feel free to suggest an alternate topic to explore. 🚀


[#2800] Optimizing ArrayUtils

Codecov Report

Merging #2805 into master will increase coverage by 0.01%.
The diff coverage is 15%.

@@            Coverage Diff             @@
##           master    #2805      +/-   ##
==========================================
+ Coverage   40.78%   40.79%   +0.01%
==========================================
  Files        1775     1775
  Lines       61276    61276
  Branches     8608     8608
==========================================
+ Hits        24991    24998       +7
+ Misses      36285    36278       -7

Impacted Files
Coverage Δ

...com/navercorp/pinpoint/common/util/ArrayUtils.java
29% <15%> (-4%)
:arrow_down:

.../com/navercorp/pinpoint/rpc/packet/PongPacket.java
50% <0%> (-21.43%)
:arrow_down:

...vercorp/pinpoint/rpc/packet/ServerClosePacket.java
68% <0%> (-12%)
:arrow_down:

...om/navercorp/pinpoint/rpc/codec/PacketDecoder.java
71.08% <0%> (-7.23%)
:arrow_down:

...rp/pinpoint/rpc/server/PinpointServerAcceptor.java
79.39% <0%> (-3.04%)
:arrow_down:

.../pinpoint/rpc/client/PinpointClientHandshaker.java
74.3% <0%> (+6.94%)
:arrow_up:

...rp/pinpoint/rpc/control/ControlMessageDecoder.java
80.35% <0%> (+14.28%)
:arrow_up:

...p/pinpoint/rpc/client/WriteFailFutureListener.java
93.75% <0%> (+18.75%)
:arrow_up:

...a/com/navercorp/pinpoint/rpc/util/StringUtils.java
28.57% <0%> (+28.57%)
:arrow_up:

... and 1 more

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 0c6ee26...e409832. Read the comment docs.


Avoid usage of bool in foster_platform.h

Avoid usage of bool (as it has C# issues) and add FosterBool (which is typedef to uint8_t/byte C#), as per https://github.com/NoelFB/Foster/commit/9852f3e3b75fbfe119ddf3063b4fd398b8caf5a2

Good call! Thanks for this!


src: report errors to sentry

Note: need to add the dsn under the SENTRY_DSN secret.
Was going to use Sentry's official client @sentry/node , but I'm not sure if it's compatible with Workers. toucan-js is specifically meant as a Sentry client for Workers, and it's even being used in some of Cloudflare's own modules https://github.com/cloudflare/worker-sentry/blob/74ffc72bbd305fcbf832f873342967ae9de7088f/package.json#L17

I'v added the DSN (took the default one from here) as a secret


Cargo: Use upstream openssh-keys 0.6.2 instead of a branch

Now that https://github.com/coreos/openssh-keys/pull/68 was merged, we should simply use upstream openssh-keys 0.6.2, instead of a custom branch.

(please ignore the unit test failure, as it will be fixed in the other PR)

CI passed: https://github.com/flatcar/scripts/pull/1313#issuecomment-1781716261


Error during helm install

I recently hit this problem, we should add something about this in the Helm installation docs:
$ helm install --name my-release stable/spring-cloud-data-flow
Error: release my-release failed: namespaces "default" is forbidden: User "system:serviceaccount:kube-system:default" cannot get namespaces in the namespace "default"

Googling the error, I found https://github.com/fnproject/fn-helm/issues/21 , which fixes the problem:
$ kubectl create serviceaccount --namespace kube-system tiller
serviceaccount/tiller created
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io/tiller-cluster-rule created
$ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
deployment.extensions/tiller-deploy patched

i think pointing to the helm docs, calling out RBAC should be sufficient:
https://docs.helm.sh/using_helm/#role-based-access-control

closing - our docs already link to the helm readme which should be sufficient rather than duplicating


flutter upgrade stuck

problem
PS D:\flutter\vedioapp> flutter upgrade
Upgrading Flutter from D:\flutter\flutter_windows_v1.5.4-hotfix.2-stable\flutter...
why  is it keeping this

What is the issue you are seeing?  How is the upgrade failing?

When I execute flutter upgrade, the program will remain: "Upgrading Flutter from D:\flutter\flutter_windows_v1.5.4-hotfix.2-stable\flutter..."

Its not really clear from looking at this whether there is actually a bug here or if it is just taking a long time to download. We should consider what diagnostics could help us accurately diagnose a problem with this script

am having the same problem, any solving yet?


Path to jfxrt.jar loading issue with 1.8.0_202-ea-b03

require 'jrubyfx' on 1.8.0_202-ea-b03 fails with:
JavaFX runtime not found.  Please install Java 7u6 or newer or set environment variable JFX_DIR to the folder that contains jfxrt.jar
If you have Java 7u6 or later, this is a bug. Please report to the issue tracker on github. Include your OS version, 32/64bit, and architecture (x86, ARM, PPC, etc)

..jfxrt.jar seems to be in the same place and I have had no trouble with 1.8.0_192, I am getting around this issue with a pre-require $LOAD_PATH << File.join(ENV_JAVA["sun.boot.library.path"], "/ext") but unsure about whether something has changed and it now needs to be explicitly loaded somewhere around https://github.com/jruby/jrubyfx/blob/master/lib/jrubyfx/part_imports.rb#L25
Environment details:
jruby <IP_ADDRESS> (2.5.0) 2018-12-06 6d5a228 Java HotSpot(TM) 64-Bit Server VM 25.202-b03 on 1.8.0_202-ea-b03 +jit [darwin-x86_64]

#also
jruby <IP_ADDRESS> (2.5.0) 2018-12-06 6d5a228 OpenJDK 64-Bit Server VM 25.202-b08 on 1.8.0_202-b08 +jit [darwin-x86_64]

A possibly similar issue was seen at #82

JRubyFX 2.0 has been released. Your issue may have been fixed in 2.0 If your issue still applies to JRubyFX 2.0, please reopen this issue.


Fixed the spanish translation.

📋 Description
Hi! I just fixed the spanish translation since it looked very machine translated and had many errors.
🚀 Changes made to ...

[ ] 🔧 Server
[ ] 🖥 Client
[ ] 📚 Documentation
[x] 🔄 Other: lang ES

✅ Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have looked for similar pull requests in the repository and found none

🔗 Related Issues
Fixes #(issue)

Hi, there.
I also update Spanish translation through Crowdin a weeks ago and I haven't any update from @gnmyt, Maybe I did wrong?
I like your translations, one thing I would change.

To this

This words are literally the same "bajada", "más baja", "subida", "más alta". In my suggest, although is not the word to translate I think it fits better, or even "Máximo" and "Mínimo"  by the context.
Thanks, for your time.

You are right. To be honest when I reached that part I was already a bit tired of translating this and I didn't know exactly what to put here since the context is a bit akward, but you're right.
My logic was: Valores de bajada - (Velocidad) Más baja (Velocidad) Más Alta But Peor and Mejor is definitely easier to understand and less verbose.

uhm... @gnmyt ?


can I set a Date to datepick?

I didn't see it in document.
some time we need set a Date to datepick
Not This
This will change the Attr not Date
$scope.$broadcast('pickerUpdate', 'pickerToUpdate', {
    format: 'D MMM YYYY HH:mm',
    maxDate: maxSelectableDate, //A moment object, date object, or date/time string parsable by momentjs
    minView: 'hours',
    view: false //Use default
});

It default show Tody
But I need set it start in some day
not user minDate and maxDate to limit it

@axetroy if you set your model with the date that you want and add the following directive:
 watch-direct-changes="true"
It will work as you expect.

@eralha I would close this issue.

@brunokrebs thasnk,i will try


Add configuration file support (put the tokens there)

Also use gofmt to format the file.
Keep compatibility with old behavior, if ".tokens" file exists and not -c option is specified, then it will be used.

Just from my POV, -t option should be dropped as there's already option for config file, tokens using system variables, ".tokens" file.


build(sequence-deprecated): convert to fluid-tsc

Blocked on https://github.com/microsoft/FluidFramework/pull/19832
semi-automated

CI was green except for credscan.


Refactoring Model Organization and Improved Neural Network Instantiation

Motivation for the feature

Current neural net architecture organization could use a bit more reorganization as it is a 1500+ lines model.py files of various modules/layers/architectures that are somewhat tangentially related.

More importantly, there are key problems with how models are instantiated:

Currently, it is instantiated via get_attribute call, which implies two things:

If you don't spell the class name EXACTLY right, it will fail to initialize with a unable to get attribute error. This becomes a maintenance issue should we rename class names, forcing all external calls to fail. Instead, there should be a layer of abstraction where config model name provided are parsed and then the proper model chosen to be instantiated int he above line. In addition, this can enable us to provide a more user friendly experience for misconfiguration or even guess what user want Unet vs UNET etc.
To a lesser degree, any named class in model.py can be instantiated... even though not all of them are models.

Benefit of the proposed changes include:

Facilitate reviews of code in the model sections
Explicit code reference to specific architecture model (right now, if you want to find where Unet used, the above line will not be identified by IDE as it is VERY generic representation of model instantiation process)
More specific user feedback, may even recommend likely fixes on user misconfiguration (you spelled UNet instead of UNET) or offer flexibility in terms of config.json to permit both UNET and unet to instantiate

Description of the feature

Proposal: Two separate PRs:

Separate each model to its own class python file (currently in 1500+ lines model.py) + Create /architecture folder/module
String constant vs Explicit Model class reference.

Alternatives

We could also have:

one python module (e.g. layers) for layers/neural network modules/layer groups (e.g. attention module)
one python module for each model families (e.g. UNet)

Additional context

This came about while reviewing the feasibility related to implementing a parameterizable 3D Unet.
Work in progress at yd/model_refactoring

Hey @dyt811, maybe I'm misinterpreting your latest comment but I see this issue and what it tries to solve independent of #1116, which is about integrating MONAI models into ivadomed. As seen in the draft PR, we can achieve this by mapping ivadomed keywords to MONAI keywords without going too much into their codebase. As opposed to relying on MONAI and its building blocks for the modeling in ivadomed, I see MONAI as an additional tool that we can rely on to provide model architectures that don't exist in ivadomed to the end-user. The refactoring proposed here, which I completely agree with BTW, can therefore live together with #1116!

I recommend maybe 1116 to already start splintering MONAI related functions into separate .py module to avoid conflict.
If you can't do it, that is fine as during PR I will merge it and resolve conflict on my side to migrate changes if you merged first.


Clean up indent and whitespaces in 'modules'

Whitespace and indent cleanup of 'modules' folder.

Remove trailing whitespace
Ensure one and only one final newline at the end of file
Fix indentation

From my point of view, I think fixing white-space is good.
It always annoys me when it doesn't fit..
@hnyman what do you think?
I'm just thinking of the history when you want to check with git blame.
That could make it difficult to find the last time who changed the area.

From my point of view, I think fixing white-space is good.
It always annoys me when it doesn't fit..
@hnyman what do you think?
I'm just thinking of the history when you want to check with git blame.
That could make it difficult to find the last time who changed the area.

I feel that it is nice tidying, but a bit unnecessary.
git history (blame etc.) gets more cryptic, like you said.

I feel that it is nice tidying, but a bit unnecessary.
git history (blame etc.) gets more cryptic, like you said.

git blame has option -w to skip whitespace-only changes, in that case it will display directly the commit prior to that. But yes, strictly speaking all the touched lines would alter the basic git blame.
Still, I personally hate trailing whitespace, and would hope you consider accepting the PR. I only restricted the cleanup to "modules" but it should be done project-wise. This is more like a probe to see maintainers reaction.

git blame has option -w to skip whitespace-only changes, in that case it will display directly the commit prior to that. But yes, strictly speaking all the touched lines would alter the basic git blame.
Still, I personally hate trailing whitespace, and would hope you consider accepting the PR. I only restricted the cleanup to "modules" but it should be done project-wise. This is more like a probe to see maintainers reaction.

So I rebased and now this PR is only related to whitespace and extra newlines at the end of files. I don't think it actually makes much sense as it is, i.e. restricted to the "modules" folder, but applying this change to the whole source tree is a much bigger change.
I will leave the decision to you, it you think it's unnecessary just close it. Thanks!

So I rebased and now this PR is only related to whitespace and extra newlines at the end of files. I don't think it actually makes much sense as it is, i.e. restricted to the "modules" folder, but applying this change to the whole source tree is a much bigger change.
I will leave the decision to you, it you think it's unnecessary just close it. Thanks!


Many D81 images cannot be read

The CBM library (https://github.com/simmons/cbm) is used to handle CBM disk images. However it refuses to open many images and it should be investigated why.

See https://github.com/simmons/cbm/issues/1


Add Apache-2.0 license

@DavidKnott I just realised you've committed to here before. Do you agree to the Apache-2.0 license? Please just response with a yes 😉


cwtv.com doesn't work

According to http://rg3.github.io/youtube-dl/supportedsites.html CWTV is a supported site.
However when I execute the following line, it returns me generic instead of CWTV and dowloads the thumbnail from cwtv.com:
youtube-dl -v http://www.cwtv.com/shows/the-100/inside-the-100-thirteen/?play=479caa3c-546c-4871-911d-043d1fc826d3

Output:
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', 'http://www.cwtv.com/shows/the-100/inside-the-100-thirteen/?play=479caa3c-546c-4871-911d-043d1fc826d3']
[debug] Encodings: locale 'UTF-8', fs 'UTF-8', out 'UTF-8', pref: 'UTF-8'
[debug] youtube-dl version 2014.02.17
[debug] Python version 2.7.6 - Linux-3.19.0-32-generic-i686-with-LinuxMint-17.3-rosa
[debug] Proxy map: {}
[generic] ?play=479caa3c-546c-4871-911d-043d1fc826d3: Requesting header
WARNING: Falling back on generic information extractor.
[generic] ?play=479caa3c-546c-4871-911d-043d1fc826d3: Downloading webpage
[generic] ?play=479caa3c-546c-4871-911d-043d1fc826d3: Extracting information
[download] Destination: The 100 Video - Inside The 100 - Thirteen _ Watch Online Free-The100-308-TermsAndConditions-3J5758-CW-Stereo_b17fbf868_CWtv_720x400.jpg
[download] 100% of 59.21KiB in 00:00

Just as a note, I can stream the video, I just can't download it.
Is this because of copyright, or is it because cwtv.com changed there naming scheme? Can it be fixed? Thanks for any help.

[debug] youtube-dl version 2014.02.17

You are using a very old version. The latest one is version 2016.03.18. Please update via updating instructions

I was using the version from the Linux package manager, but apparently they never updated. Will install directly then, thanks.

I am posting is update the CW don’t work with YouTube-dl no more if you try to down a show you will download a video but say is now
This version of the app
is no longer supported
More info at: support.cwtv.com
I try the YouTube dL on my window 10 it doesn’t work


Hit testing disregards Orientation

Hey
Is it possible that hit testing disregards Orientation? I thought that the Xaml side should be in sync with the visuals' position, but in my experience the PointerEntered/Exited events don't consider the change.
This can be observed here: https://github.com/tomzorz/Composition_fun/tree/master/Composition_Hotchkiss
Thanks,
Tamás

@tomzorz, sorry yesterday was a busy day. Thanks for a link to code example that is super helpful. Screenshots are helpful too if you can share them. We understand if you can't because you may/may not be working on something sensitive.
Anyway, when you say "Orientation" do you mean changing the Visual.RotationInDegrees property or the Orientation property on some XAML controls?
I think this is the scenario you are asking about:
"If I change the RotationInDegrees property on the Visual I get back from ElementCompositionPreview.GetElementVisual(myElement), does hit testing and pointer events update accordingly?"

I wrote Orientation because I meant the Orientation property of a visual (which came from a xaml element). I recorded a short video where I explain the issue in detail: https://www.youtube.com/watch?v=wBQHIDBmW20 I hope this helps understanding my issue :)

I actually have noticed the same hit testing issue on InsetClip. Would it be a good idea to disable hit testing on the areas that are clipped?

@JustinXinLiu clipping is debatable IMO, I can imagine scenarios where I'd want to have it and others where I don't. An "IsClippedAreaHitTestVisible" property could be the solution :bulb:

@tomzorz I can totally live with that. :)

We disregard hittesting support on Orientation via XAML interop by design as the XAML framework itself has no notion of quaternions right now, so this can't be carried through effectively. That means you need to roll your own as you would do in a frameworkless app or an island of composition Visuals inside a XAML app. For the InsetClip behavior, the current challenge there for updating hittesting is something you may have already noticed about InsetClip, to set one you need to explicitly set the size in our API as we don't pass that over from XAML in the current Interop. This makes passing back how the clip has changed to the framework for updated hittesting challenging. We're looking at better Interop in the next release and love to see feedback on this, like tomzorz's suggestion. Hope this helps to explain these issues.

@sernaj Understood. At least for now I could break down the element that's clipped into smaller segments and manually set their IsHitTestVisible property in the XAML. Cheers.

@sernaj thanks for the explanation! :) I'd definitely love to see things like this carry over to the xaml world (or as I've discussed in the other ticket: get more / easier input support on the composition side.)

Thanks again for all the feedback on this. I'm going the close issue but keep the feedback coming!


DESIGN: Updating the user status

Updating and reworking the user status that features all of the version numbers
Review feature with Cat
Come up with alternative concepts
Visuals will be needed
Consider an idle status
Add analytics to the status bar as well

About modal with version numbers on it.
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5MtU2ZFMzhOVEVKZnM/view?usp=sharing
Any feedback or comments on it are welcome! @bdellasc @mindreeper2420 @catrobson

Idle status and icon
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5MtZXZjSHNBdE5pU0U/view?usp=sharing
Any feedback or comments on it are welcome! @bdellasc @mindreeper2420 @catrobson

Status bar with different layout options. Also included is an exploration of what would happen if a user clicked on the red x icon and some sort of error message popped up to let them know what the error might be.
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5MtS05mVl9yMWhaUlU/view?usp=sharing
Any feedback or comments on it are welcome! @bdellasc @mindreeper2420 @catrobson

@lwrigh Thanks for posting these!
On the about modal, is there a particular reason to show all the detail in the time stamp?  Sometimes there is, so I wanted to ask before just suggesting that maybe we change that to a more human-readable format.
On the status that has children, what would show on the parent if one child was green and the other red?  Is that even a case it could get into?  Same question, I guess, for the rollup icon on the navigation bar -- does it show the most severe (worst?) status icon?

@Essjaysee Thank you for the feedback SJ! The timestamp is currently like that so I pulled from what is already on the current about modal but I totally agree that a more human format would be easier to read. I can make a version that features a more human time stamp for comparison.
That is an excellent question. I am not exactly sure what would happen in that situation.
Do you know what that sort of use case would mean on the technical side?
"On the status that has children, what would show on the parent if one child was green and the other red? Is that even a case it could get into? Same question, I guess, for the rollup icon on the navigation bar -- does it show the most severe (worst?) status icon?"
@dgutride @dlabrecq @catrobson

Updates:
Here are the links to edited versions of the status bar and about modal based off of feedback:
About modal:
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5MtMENOZzVTQ3NWUXM/view?usp=sharing
A more human timestamp (based off of the timestamp from Planner) was added to the about modal.
Status bar:
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5Mtelg2OUd3cFhmZVk/view?usp=sharing
Different layouts (nested vs. not nested) were explored and subtle, horizontal lines were added to demarcate the platforms into categories.
Status bar tooltips & version numbers:
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5Mtd3NLMHRCcDFlbkk/view?usp=sharing
Tooltips were added to each status in order to let the user hover over the item in order to see the current running version number. Tooltips, info buttons, and accordions were experimented with.
Any feedback or comments are much appreciated! Let me know if there is any other information that should be easy to surface from the status bar.

I think the rules are not helping in the status pop-up, its too much clutter.   I feel like indenting without the bars worked best to organize the information.
Sorry if I wasn't clear in my ask for the version numbers.  I actually meant that we need a way to capture all the version numbers for all components within the about box, not within the status bar.  We can review tomorrow if you'd like Laura!

That would be helpful, I can send you an event invite.

Based off of feedback from our meeting this morning, I made edits to the about modal and the status bar. I also played around with the idea of having an info tip next to the component if there was a caution or an error associated with it. It does feature a pop up within a pop up however so let me know what you think about that.
About modal: https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5MtRDQ5aEpOWEotYU0/view?usp=sharing
Status bar:
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5MtS0xDUkV3Y1FkczQ/view?usp=sharing
Status bar with error message:
https://drive.google.com/a/redhat.com/file/d/0ByyY35rYs5MtRGJ5YWNSN2VTVEE/view?usp=sharing

Here is the status bar with an error message without the info icon


[Generator] Reference the correct file for the yeoman generator in package.json

Hi there!
Instead of using the globally installed yeoman generator for this project, we're using a local version with yeoman-environment. When using the environment directly, we require this package in order to get a reference to the generator itself.
Unfortunately, the reference to the main in the package.json points to a file that doesn't exist. Everything seems to be fixed by fixing this one line :)
Let me know if this has any other implications. I don't think it should have any implications to the globally installed generator but I could be wrong.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks @negativetwelve!


Create a new repo under Scaffold-ETH called "DeFi-SubBranch" or some other name

The idea is that there will be more and more DeFi focused tutorials / challenges for students. These are for students that are comfortable writing smart contracts at the beginner level and want to level up.
Having all DeFi focused tutorials and challenges in their own repo would keep things organized. In conjunction with these tutorials, I envision smaller telegram group chats to be started where students can ask questions to one another similar to other scaffold-eth challenges (like DEX and Multisig).

This disclaimer would be in the main branch of the "DeFi-SubBranch" Repo. It could be copy and pasted into each tutorial too, just trying to lessen the amount of repetitive copy though within the tutorials to come (see below):
DeFi Sub-Branch Context
This challenge is part of the DeFi Sub-Branch, where students are invited into writing smart contracts that incorporate actual DeFi protocols. The sub-branch projects are ever-expanding as DeFi is too. The goal of the Defi sub-branch projects/tutorials are to provide students tutorials that foster self-learning in actual DeFi protocols, guide you through some of the basics of integrating with specific protocols, and other useful tips to increase competence to be potentially hireable as an intermediate developer.
Teams are looking for developers with real experience; mainnet/real contracts deployed, battle tested, TVL locked in, audited, etc. These tutorials won't give you smart contracts to deploy and test outright as your own, but give you the framework for possible starting points for your own ideas! Be original 😉
Students taking on this challenge will be expected to embrace self-learning since tying into DeFi protocols and actual professional crypto projects do not guide developers, step-by-step. If you are new to trying to actually plug into a professional project, no worries! We'll touch on some helpful tips as you sort out what the 'norm' is when going through this process. These tips will be specific to each protocol that we are integrating into and learning about.


Make variables not be null by default in VisualScript

If you create a new setter node or a change the type of a member variable it will be set to null by default. If you want to set a boolean variable to false, you have to click twice for it to not be null.
Also, why is it that when you set a member variable to the String type for the first time that it sets displays the text as Null, although it should be [Null]?

Is this a missing assignment to the false or 0 bit pattern value?

This is the same bug as https://github.com/godotengine/godot/issues/27611


Declare event handler after variable declaration if needed

Usually, code like this:

Results in this:
spriteutils.createRenderable(0, function (screen2) {

})
// On start
let inventory_z_index = 100

But then if I do this:

It results in this:
spriteutils.createRenderable(inventory_z_index, function (screen2) {

})
// On start
let inventory_z_index = 0
inventory_z_index = 100

Which is obviously an error:

So the code converter should convert the above blocks into:
// On start
let inventory_z_index = 0
inventory_z_index = 100
// On start end
spriteutils.createRenderable(inventory_z_index, function (screen2) {

})

This is legacy, we always registered the events first and then the on start code. This is to  ensure if there is an infinite loop in the on start events can still trigger.
We can't change this without breaking lot of projects. Can't fix on our end.


Pre-processing for HAR dataset

Hi, thanks for releasing your code! May I check if you are also able to include the data preprocessing code for the HAR dataset as well?

Furthermore, it seems that the sleep-edf data pre-processing code does not results in files which match the description in the README. Hope that you are able to release the data pre-processing code which matches the dataloader code.
Also, is it possible to include a requirements.txt file, because it seems that some libraries being used are not backward compatible.
https://github.com/emadeldeen24/TS-TCC/blob/5c5efa7b695b7425d3ded4a93a7a6010102aa9b0/data_preprocessing/sleep-edf/preprocess_sleep_edf.py#L90
The latest version of mne does not have scaling_time as an argument to raw.to_data_frame.
Thank you for your time!

Hello,
thank you for reaching me out and reporting these issues.
I solved all your issues ... please check the updated version of README file as well as preprocessing files.

Hi @emadeldeen24
The Sleep EDF dataset contains two folders, i.e., sleep-cassette and sleep-telemetry. I am wondering which folder you used exactly, or you use the data from both two folders. Thanks.

I used sleep-cassette .. more specifically these files .


fix: Updates to RStudio Integration tests

Issue #, if available:
Description of changes:

Remove extraneous comments
Don't run rstudio tests if rstudio config is 'N/A'
Move advanced tests into common folder so they get executed

Checklist:

[ ] Have you successfully deployed to an AWS account with your changes?
[ ] Have you written new tests for your core changes, as applicable?
[ ] Have you successfully tested with your changes locally?
[ ] If new dependencies have been added, have they been pinned to specific versions?
[ ] Is this change also required on the AWS Solution version?
[ ] Have you updated openapi.yaml if you made updates to API definition (including add, delete or update parameter and request data schema)?
[ ] If you had to run manual tests, have you considered automating those tests by adding them to end-to-end tests?
[ ] If you are updating the changelog and vending out a new release, have you updated versionNumber and versionDate in .defaults.yml

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

Note: Before we can merge this PR in, we need to refactor  the Cypress AppStream disabled workspace test to terminate workspaces that it launches. This is because the RStudio Integration test checks that all RStudio instances are terminated, before it runs.
An example of how to refactor the Cypress AppStream disabled workspace tests.

Terminated RStudio instances manually on the e2e test environment. PR for automatic termination depends on this PR merge.


Proposal: Use term "property" instead of "field"

AFAIK, neither JavaScript nor TypeScript use the term "field"; it's "property".  Further, in conventional OOP, the term "member" refers to both fields and methods (which is reinforced even more so in JavaScript, since all objects have keys that can contain data or functions, which are effectively "methods").
I propose to effectively rename, with appropriate backward-compatible deprecations,

MemberSelector to PropertySelector,
fieldNamePattern to propertyNamePattern,
fields to properties, and
any other uses of the term "field" to "property" in code & documentation.

After all, the current MemberSelector into alignment with its own current fields property, which is defined to be of type PropertyDescriptor[], which contributes to confusion.  Further, the pointcuts beforeGetter, beforeSetter, afterGetter, afterSetter, aroundGetter & aroundSetter, which intercept calls to get xxx () { /* ... */ } & set xxx (value) { /* ... */ } methods.  Unless I'm mistaken, you cannot intercept property reads & writes without defining your own property methods with the get & set keywords, respectively.  The documentation incorrectly describes this as "field" interception, which is a misnomer.
IMHO, if "field interception" could be supported, then that should be manifested in such a way as to not require the class whose "fields" are being intercepted to not have to define get or set property methods.  I don't know if that's even possible right now.
Discussion welcome on this topic.

We should better release the incompatible API changes (i.e. this and #67) as 1.0.0.

@mgechev Yes, since these are breaking changes, they would necessitate a 1.0.0 version.


[Enhancement] Enable ordinal aggregation in aggregation layer (hex, grid, cluster)

Enable ordinal aggregation type mode and count unique in aggregation layer
Added additional validation in visual channel updater to validate aggregation type and scale based on selected field
Added more condition clause to layer visConfigSettings to render configuration selectively based on current layer config
Specify aggregation type in layer legend and map popover

Hexbin aggregation by event type

Legend

https://github.com/uber/kepler.gl/issues/98


Add profile support for jit-compiled functions.

This patch allows profilers to see jit-compiled functions.
The patch creates a synthetic frame object and attaches the code object from the original (python) function to it, so the functions shows up in the profiler with the location of the non-compiled python code.
The one thing still missing is a 'locals' dictionary containing the objects referenced as function arguments. I'm not sure yet how to efficiently create that.

I have reworked the patch a bit, and added an incref to the locals when they are passed to the frame object. (I have to admit that I find the entire handling of locals using the frame API confusing, or even wrong (The PyFrame_New() constructor takes a locals argument, but then ignores it. That can't be right !).
At least now the code is consistent. And the tests still pass. :-)
So I think this is ready to be merged.

Ok, so the refleak has disappeared?
How about adding some simple test that the function does show up in the profiler's output?
(also, be sure to fix the indentation of the C code :-))

The ref leak has disappeared when I didn't reset frame->f_locals to NULL, as you suggested. I then added an incref for symmetry (to make the code look correct), which didn't seem to make an observable difference.
And I have corrected the indentation (including untabifying the whole file).

Ok, good enough :) Thank you!


Feat/#762: add synth markets on dashboard

Description
Display Spot markets table on dashboard. Enable Spot markets button for switching between futures and spots market. The table is displaying:

Market name
Price
24h price change
24 volume

Currently, the click event is disable on the table as it's not mentioned in issue.
Related issue
#762
Motivation and Context
Refer to the related issue above.
How Has This Been Tested?

Open dashboard
Click button Spots Market
All synths are displayed in table

Questions

FuturesMarketTable and SpotsMarketTable use same table styling and it'd be nice to refactor bot components so that the styling code won't be repeated in two places. For instance, add a parent component to contain both 2 component as children and share styling code in parent module. Do we wanna do the refactoring in this task?
TrendingSynths doesn't seem to be used anywhere in v2. Should we remove it?
Query issue is mentioned in Discord

Screenshots (if appropriate):

Had to study quite lot in order to understand roughly how query works. Now I managed to show 24h price change but it requires a serious review. 24h volume is not yet solved.

Now the issue is subgraph.useGetSynthExchanges won't accept other filters but timestamp. For instance, including fromSynth or fromSynth_in, which are documented as supported filters, would produce empty result. Without passing any filter query returns records regardless synth type and from/to transactions. Current approach resolves volume based on such dataset but is relatively tedious since it first finds all exchange records related a specific synth by checking fromSynth and then sums up fromAmountInUSD. Ideally the query should be fixed so that fromSynth_in filter can be used. Then implementation can be simplified.

Now the issue is subgraph.useGetSynthExchanges won't accept other filters but timestamp. For instance, including fromSynth or fromSynth_in, which are documented as supported filters, would produce empty result. Without passing any filter query returns records regardless synth type and from/to transactions. Current approach resolves volume based on such dataset but is relatively tedious since it first finds all exchange records related a specific synth by checking fromSynth and then sums up fromAmountInUSD. Ideally the query should be fixed so that fromSynth_in filter can be used. Then implementation can be simplified.

@Xiaolei-Shawn  We have to pass the token address (not token symbol) to fromSynth_in to filter the results. To do this, we need a new tokenListQuery to retrieve the token address by the token symbol (or CurrencyKey). I agree that if we could pass the token symbol directly to fromSynth_in, the solution would be simpler. However, the proposed solution in this PR seems the best attempt we can have without extra development efforts.

We have to pass the token address (not token symbol) to fromSynth_in to filter the results.

True. It's the fact and the token address is not available on Synth or not coming for free. Imho, filtering by symbol is something we should after without knowing the whole picture. If the fact is we should use token address rather than symbol, I will be disappointed 😄

Checking the deployment, it looks resolving 24h volumes is working but a bit sluggish. The table column shows numbers with few sec latency. I would first suspect that querying all exchange records and then manually filter/sum is the cause of such slowness.

@platschi

Fix the difference of 24h price change between spot and future market
Fix the refreshing issue of 24h volume
Add router to the spot market by clicking the rows

@platschi

Fix the crash issue caused by the wallet actions (root cause: price => 0, while price change => infinity)
Fix the 24h change and price display on L1


Upgrade data files to Unicode 11

As Unicode 11 has been released, bidi type, general category, script, mirror and bracket lookups should be updated accordingly.

Resolved in v2.1


How I got CordovaBadge to work

Hello. I am not entirely sure if this is accurate since I made a few edits trying to get the plugin to work correctly, but just in case:
I couldn't get cordovaBadge to work until I changed this line in ng-cordova.js
promptForPermission: function () {
    return cordova.plugins.notification.badge.promptForPermission();
  },

... changed to
promptForPermission: function () {
    return cordova.plugins.notification.badge.registerPermission();
  },

Greetings @javacado!
I've closed this issue because my sensors indicated it was old and inactive, and may have already been fixed in recent versions of Ionic. However, if you are still experiencing this issue, please feel free to reopen this issue by creating a new one, and include any examples and other necessary information, so that we can look into it further.
Thank you for allowing me to assist you.

This should be a doc update.

I was having difficulty getting this plugin to work too, and this fixed it for me.

This fix works for me too on android.
badge.promptForPermission () does not call badge.registerPermission() as the docs state it should.

+1

promptForPermission: function () {
return cordova.plugins.notification.badge.promptForPermission();
},
... changed to
promptForPermission: function () {
return cordova.plugins.notification.badge.registerPermission();
},
...... Works on few Android devices...
Any permanent solution?

Thank you all... this saved me after one week of researchs

+1

Seems to be requestPermission now :)


Update

👷 Deploy Preview for cding processing.

Name
Link

🔨 Latest commit
dfdcb126247cfac5129b653adba28d15ac476bb4

🔍 Latest deploy log
https://app.netlify.com/sites/cding/deploys/62d178e262f185000984323a


Changed 'featureBounds' method to use 'forEachLatLng'

I made a change to the 'featureBounds' function, so it would support complex geometries, with more than one level of nesting. It was only traversing one layer of the Geometry's points, when in fact Geometries can have any amount of nesting. One example of complex geometries of this type is the 'MultiPolygon' https://tools.ietf.org/html/rfc7946#section-3.1.7
My change to the function makes it use google's forEachLatLng method, provided for geometries. This method iterates over each LatLng of a geometry, regardless of what kind of geometry it is, and how many layers of geometries and points it contains. I use this method to extend the bounds using each LatLng inside the Geometry.

Sorry for not reacting to this yet. I didn'd have the time for looking into this so far, as I'm not currently working on the project for which I created this fork. As soon as I pick that up, I'll give it a try and see if it breaks anything for me. Thanks for the contribution, appreciated!


StoreProducer API

I added a state variable to StoreProducer to enable use of this API
viewStore.producer.state.startWithValues { [weak self] state in self?.update(state) }

instead of this
viewStore.producer.producer.startWithValues { [weak self] state in self?.update(state) }

Your reply, from another thread:

Thanks for the PR @maximkrouk ! Could you split the StoreProducer changes into another PR though? I'm also not very happy with producer.producer but IMO state is not the right name. I need to think about it some more.

Actually, I see another solution, which seems to be the most elegant, but requires contribution to ReactiveSwift.

Future API: store.producer: SignalProducer<State, Never> (requires a PR to ReactiveSwift with @dynamicMemberLookup SignalProducer API)
Default API before the PR is accepted by ReactiveCocoa will look like this: store.producer.map(\.keyPath) which is nice too

Future API: store.producer: SignalProducer<State, Never> (requires a PR to ReactiveSwift with @dynamicMemberLookup addition to SignalProducer API)
Default API before the PR is accepted by ReactiveCocoa will look like this: store.producer.map(.keyPath) which is nice too

I also thought about this, and considered submitting a PR to ReactiveSwift for this. However, the dynamic subscript in StorePublisher does a map on the key path and a skipRepeats(). A @dynamicMemberLookup addition to SignalProducer would likely only support the map and not the skipRepeats which is a specific requirement of TCA.

Coincidentally I was just looking at this issue too. I think that renaming producer to state is confusing and misleading.
The options I am considering are:

just keep it as producer. The times when you need to do producer.producer are pretty rare, for example when you want to subscribe to more than a single value from the state in one go. However, it doesn't behave as .producer would in the rest of ReactiveSwift (eg in Property) so is maybe the wrong term.
revert the name back to publisher (and rename StoreProducer back to StorePublisher. This has the benefit of keeping RAS TCA code closer to Combine TCA code.
rename it to produced.

I'm actually thinking that 3. might be the best option. Let me know your thoughts.

If you mean viewStore.producer.produced: SignalProducer<State, Never>, it's very similar to .state, and leads to a minor misleading too: produced <–––> SignalProducer.
There is one more option, which is to use good-old keyPaths:
ViewStore {
-    public let producer: StoreProducer<State>
+    private let _producer: StoreProducer<State>

+    public func producer<T>(for keyPath: KeyPath<State, T>) -> Effect<T, Never> {
+        _producer.producer.map(keyPath).skipRepeats()
+    }
}

viewStore.producer(for: \.self)  // SignalProducer<State, Never>
viewStore.producer(for: \.value) // SignalProducer<Value, Never> where State has a `value` instance variable

If you mean viewStore.producer.produced: SignalProducer<State, Never>

Sorry, I wasn't clear. I mean't renaming the ViewStore.producer to produced so most uses would be:
viewStore.produced.count.startWithValues { ... }

and if you want the underlying producer:
viewStore.produced.producer

This way produced.producer gives you what you would expect from the rest of ReactiveSwift, and produced allows you to use the dynamic dot syntax.

There is one more option, which is to use good-old keyPaths:

That looks quite nice, but in an effort to keep minimal client code changes (eg in the examples) I would like to keep the dot syntax.

In an effort to keep minimal client code changes (eg in the examples) I would like to keep the dot syntax

Reasonable.
Oh, that looks nice enough:
viewStore.produced.count.startWithValues { ... }

viewStore.produced.producer

In this case maybe it worth replacing StoreProducer with ProducedState for example (with a deprecated typealias StoreProducer = ProducedState)

In this case maybe it worth replacing StoreProducer with ProducedState for example (with a deprecated typealias StoreProducer = ProducedState)

Yes, that's a great suggestion 👍 Do you want to make those changes in this PR?

Ok, I'll submit changes soon 🙂

Not sure if I should keep producer variable like this
var produced: Produced<State>

@available(*, deprecated, message: "Consider using `.produced` instead, this variable is added for backward compatibility and will be removed in the next major release.")
var producer: Produced<State> { produced }

Btw I decided to use just Produced due to it's usage in ViewStore and some kind of "Genericimism" 😅

ProducedState<State> does not look right
Produced(by: upstreamProducer) is generic to any producer, yep .skipRepeats() operation is a bit specific, but anyway I think that kind of naming should fit the framework and shouldn't be misleading.


Support of broadcom wifi card

Hey,
Does this work for both wifi cards or only the intel one?
Cheers,
p3nt4

@p3nt4 I've only tried the WiFi card on the hardware model I bought, which is the XPS 13, with the default WiFi chip.

I think two versions of the XPS 13 exist, one with a broadcom chip and one with an intel chip.

I ran lshw on my machine just now - it looks like an Intel wireless card. Attached the output here:
lshw.txt

Yeah, seems like it.
Thanks for your answer.
I think the ubunutu xps 13 comes with the intel card and the windows come with the broadcom one.


Auth Next: Account Contracts: Prohibit calling check_auth outside of require_auth

Currently check_auth is just a regular contract function and it conceptually cannot be calling require_auth itself (as that would lead to the infinite recursion). This means that anyone can call it currently and hence it has to be read-only. In order to allow for more robust account contracts (e.g. to allow them tracking spent amounts per token/time period), we need to 'special case' this function somehow and either disallow to call it outside of host-based require_auth calls or at least make force it to be read-only when called oustide of require_auth.

Resolved in https://github.com/stellar/rs-soroban-env/pull/722


(dev) WIP: Add support for service access from remote nodes to ipv6route_renderer

Coverage increased (+0.04%) to 76.167% when pulling 1fe56d007aebb3bcc352ff61f392074cc9ed2ba4 on rastislavszabo:dev into cf6c8133fcbc1e6b9e751892be9602c3209a7021 on contiv:dev.


Why is linux triplet configured to build static libraries?

Why are libraries has to be built statically for Linux?
https://github.com/microsoft/vcpkg/blob/16fdd22565330b5b20162b194ae77eeb10166fa2/triplets/x64-linux.cmake#L3
Two obrious problems:

It produces huge executables, especially if you are building multiple programs towards same set of libraries.
It causes licensing issues with LGPL libraries.

It's just the default that we test you can change it in the triplet to build all shared libraries or to build shared libraries on a case by case basis.

The question is rather why it's default. Of course we've changed it and use overlay-triplets, but IMO it would be nice if default would be shared.

I wish both x64-linux-static and x64-linux (producing dynamic libraries) were available in the default distribution.

Yes.. this is very confusing.
x64-linux with set(VCPKG_LIBRARY_LINKAGE static) is basically x64-linux-static and should be renamed.
While x64-linux-dynamic.cmake is this (referencing docs):
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE dynamic) # <------------- static to dynamic (.so)

set(VCPKG_CMAKE_SYSTEM_NAME Linux)


mod: fix mod using Semantic Import Versioning for release-3.0

Signed-off-by: Shafreeck Sea<EMAIL_ADDRESS>Update the module name according to the rules of Semantic Import Versioning. It will take effect on the next release, after that, users can get the latest v3.0+ version using go get

What problem does this PR solve?
Fix the module name to make go get<EMAIL_ADDRESS>work
What is changed and how it works?

Rename github.com/pingcap/pd to github.com/pingcap/pd/v3
Update Makefile to use the new package name.

Check List
Tests

Manual test (add detailed scripts or steps below)

Codecov Report

Merging #2113 into release-3.0 will decrease coverage by 0.09%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##           release-3.0   #2113     +/-   ##
=============================================
- Coverage        69.69%   69.6%   -0.1%
=============================================
  Files              170     170
  Lines            16825   16825
=============================================
- Hits             11727   11711     -16
- Misses            4131    4143     +12
- Partials           967     971      +4

Impacted Files
Coverage Δ

tools/pd-simulator/simulator/config.go
0% <ø> (ø)
:arrow_up:

server/statistics/store.go
100% <ø> (ø)
:arrow_up:

server/join.go
62.92% <ø> (ø)
:arrow_up:

server/schedule/range_cluster.go
90.47% <ø> (ø)
:arrow_up:

server/statistics/region.go
95.55% <ø> (ø)
:arrow_up:

server/schedule/filters.go
90.9% <ø> (ø)
:arrow_up:

server/option.go
90.83% <ø> (ø)
:arrow_up:

server/api/health.go
86.36% <ø> (ø)
:arrow_up:

server/schedule/operator.go
87.15% <ø> (-0.43%)
:arrow_down:

server/api/member.go
61.6% <ø> (ø)
:arrow_up:

... and 104 more

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 5cf2711...573a7e0. Read the comment docs.

What version should we use on master? v5?

/run-all-tests

What version should we use on master? v5?

I think it should be v4, we can bump it to v5 when creating the release-v5.0 branch

Will it break projects that depends on pd client? (e.g. tidb)

Will it break projects that depend on pd client? (e.g. tidb)

Will it break projects that depend on pd client? (e.g. tidb)

The project using go mod will not be broken.

maybe we need to wait for v3.0.10 before merge.

/run-all-tests

/merge


fixed typo in modules v2 docstrings and error messages

Description
fixed typo in modules v2 docstrings and error messages
Self Check:
Strike through any lines that are not applicable (~~line~~) then check the box

[ ] Attached issue to pull request
[ ] Changelog entry
[ ] Type annotations are present
[ ] Code is clear and sufficiently documented
[ ] No (preventable) type errors (check using make mypy or make mypy-diff)
[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Correct, in line with design
[ ] End user documentation is included or an issue is created for end-user documentation (add ref to issue here: )

Reviewer Checklist:

[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Code is clear and sufficiently documented
[ ] Correct, in line with design

Processing this pull request

Merged into branches iso5, master in b50ccb94c901b54c92bcdba9cc8d50f589b3aff4


Typo? "/cosmos.base.v1beta.Coin"

"/cosmos.base.v1beta1.Coin" instead of "/cosmos.base.v1beta.Coin".
https://github.com/cosmos/cosmjs/blob/master/packages/stargate/src/signingstargateclient.spec.ts#L166

Hi, thanks for the issue. The typo here is not really important as it's only used by the local registry to find the right codec, but it was intended to conform to the Cosmos SDK URLs.


Fix building the tests in mock/koji

Explanation in the commits.
Phew.

Nice! It's cool to see a simple, not-so-hacky solution. However, I have some concerns. It will require some research from my side, I will post them tommorow.

Note: the travis CI run is green, but somehow didn't report that to GitHub.

Thanks for the updates, answered my questions

I don't know if I like the idea of not using the same set of flags as %gobuild uses. %gobuild definition itself is a mess, for most platforms it looks like this:
%{?gobuilddir:GOPATH="%{gobuilddir}:${GOPATH:+${GOPATH}:}%{?gopath}"} GO111MODULE=off \\
go build -buildmode pie -compiler gc -tags="rpm_crashtraceback ${BUILDTAGS:-}" -ldflags "${LDFLAGS:-}%{?currentgoldflags} -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \\n') -extldflags '%__global_ldflags %{?__golang_extldflags}'" -a -v -x %{?**};

However, for ppc64, the -buildmode pie is omitted. There is even a whole different definition for mips, which uses a different -compiler, but let's not consider it, because it isn't a primary architecture for Fedora.
Let's run rpmspec -P on our spec file to see what %gobuild is expanded into:
  GOPATH="/home/obudai/rpmbuild/BUILD/osbuild-composer-8/_build:${GOPATH:+${GOPATH}:}/usr/share/gocode" GO111MODULE=off \
  go build -buildmode pie -compiler gc -tags="rpm_crashtraceback ${BUILDTAGS:-}" -ldflags "${LDFLAGS:-}-X github.com/osbuild/osbuild-composer/version=8 -B 0x$(head -c20 /dev/urandom|od -An -tx1|tr -d ' \n') -extldflags '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld '" -a -v -x -o _bin/osbuild-composer github.com/osbuild/osbuild-composer/cmd/osbuild-composer;

Yeah, a thing of beauty. Compare it with the addition in this PR (also expanded):
GO111MODULE=off \
  GOPATH=/home/obudai/rpmbuild/BUILD/osbuild-composer-8/_build:/usr/share/gocode \
  go test -c -tags=integration -ldflags="${TEST_LDFLAGS}" -o _bin/osbuild-dnf-json-tests github.com/osbuild/osbuild-composer/cmd/osbuild-dnf-json-tests

There are a lot of differences between our take on -ldflags and the official one. I'm a bit worried by using our own set, because I don't understand the differences. Also, if the authors of go-rpm-macros decide to change something, we won't probably notice it and we will end up using our old set which can have some issues by then.
I know that my proposal looks scary, but I'm happy with the fact that it uses the same flag set as %gobuild. I don't know how the flags were chosen, but I'm alright with it, because I trust the people who did the selection for us. Also, in the future it should stay in sync with any changes in %gobuild. Feel free to correct me.
Finally, I think I'm ok with merging both PRs, because both are solving the issue. However, I think shipping the tests built by the specfile from this proposal to Fedora is questionable, because if someone asks why we did these changes to-ldflags, our answer is basically: "We don't know".

Does it build with RHEL buildroot?

On RHEL it fails with go: GOPATH entry is relative; must be absolute path: "%{gobuilddir}". Interesting...

I don't know if I like the idea of not using the same set of flags as %gobuild uses. %gobuild definition itself is a mess, for most platforms it looks like this:
[...]

Thanks for diving deep on this!
I had included the same flags (well, who knows if I got all of them) in an early version of https://github.com/osbuild/osbuild-composer/pull/301, but we decided on keeping it simple. I agree that that isn't right after all. If we accept this approach, we should copy the %rpmbuild macro as closely as possible.

I know that my proposal looks scary, but I'm happy with the fact that it uses the same flag set as %gobuild. I don't know how the flags were chosen, but I'm alright with it, because I trust the people who did the selection for us. Also, in the future it should stay in sync with any changes in %gobuild. Feel free to correct me.
Finally, I think I'm ok with merging both PRs, because both are solving the issue. However, I think shipping the tests built by the specfile from this proposal to Fedora is questionable, because if someone asks why we did these changes to-ldflags, our answer is basically: "We don't know".

Yeah. Like I said on your PR, it comes down to taste: do we want to duplicate the macros (and use internal flags) in our spec file, or do we want your (brilliant) small hack which uses the upstream one directly. Both have pros and cons.
I'm happy to leave the choice to you. Let me know if you want this one—then I'll fix it up to include the right flags and make it work on RHEL.

For what is worth I prefer the solution in #361. It is indeed a hack but is well documented and follows upstream more closely.
Probably the right solution will be to work with go-rpm-macros upstream and clean up the mess, but I am not qualified to comment on that.

Update to only make the change on Fedora. Tested in fedora-31-x86_64.cfg and rhel-8-x86_64 mocks.
I've also simplified a bit. Redefining the macro for RHEL was too cumbersome.

Travis is green, but forgot mentioning that again.


unable to start provisioner

installed on bare metall with k3s v1.26.3+k3s1(which now is lastest stable version),with command
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml

what's weird is that it deployed success and the pod  local-path-provisioner-xxxxxx running normally,after a restart of k3s cluster,the  local-path-provisioner-xxxxx keeps crash,
NAMESPACE            NAME                                        READY   STATUS             RESTARTS        AGE
local-path-storage   local-path-provisioner-69945974f5-krrbx     0/1     CrashLoopBackOff   543 (75s ago)   47h

but it doesn't affect the normal use of pvc provided by local-path-storage class.all other pod that has pvc mounted that comming from local-path-storage is running normally,
then I full restart the whole k3s cluster again and got this log at first time ,then it goes into crashloop
kubectl logs local-path-provisioner-69945974f5-krrbx -n local-path-storage
time="2023-04-21T22:47:45Z" level=fatal msg="Error starting daemon: invalid empty flag helper-pod-file and it also does not exist at ConfigMap local-path-storage/local-path-config with err: configmaps \"local-path-config\" is forbidden: User \"system:serviceaccount:local-path-storage:local-path-provisioner-service-account\" cannot get resource \"configmaps\" in API group \"\" in the namespace \"local-path-storage\"

it seems like it cannot access some api in namespace local-path-storage,should I reinstall it to kube-system in k3s?but the offical reference told me to use kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml,and the first line of this yaml conf was name space local-path-storage

Same issue with k3s.

Is the issue observed in v0.0.23?

0.0.23 and 0.0.24. Doesn't matter.

still the same

wonder if there was a misunderstanding the typical usage of local-path-provisioner there?
my depolyment was typical 3 machine,1 master with 2 worker node
each got 200GB disk available locally(it's 3 separated physical disk,not the same one physical disk ),so by default local-path-provisioner should using /opt/local-path-provisioner path as storage on system
maybe I should using only one physical disk and make sure the content is all the same on all k3s node under /opt/local-path-provisioner path when using local-path-provisioner?I mean like,using a nfs mounted /opt/local-path-provisioner  point to the same one physical disk on all those 3 node,or like multipath/iscsi etc network mount?

I've using 0.0.23 before and got this issue then migrated to 0.0.24,still the same

@Arryboom
Thank you for the information. Sorry for the delay because of the longhorn developement. I will start to investigate the issue.

@Arryboom
Have you disabled local-path-provisioner shipping with k3s before installing 0.0.23 or 0.0.24?

@Arryboom Have you disabled local-path-provisioner shipping with k3s before installing 0.0.23 or 0.0.24?

Oh!
Never know local-path-provisioner shipping with k3s by default,using k8s before so I thought we might need to manually choose one storage solution thus we need install it manually too.
k3s was installed just like offical site with command but disabled servicelb etc to using metallb in my enviroment before
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable servicelb --disable traefik" sh -s

I thought I found some tutorial said local-path-provisioner is great for using local path as storage and ignore the low-level filesystem implementation etc situation,so I installed it using the command as mentioned at the beginning to install it
but,Is the one comming with k3s available for out of  namespace?
I mean is the one comming with k3s by default was a k3s system internal service using only version? the one that's not publicly available to our business running service/pod etc?or it's just the same as the one I manually installed by
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml

but,Is the one comming with k3s available for out of namespace?
I mean is the one comming with k3s by default was a k3s system internal service using only version? the one that's not publicly available to our business running service/pod etc?or it's just the same as the one I manually installed by

Sure. The default local-path provisioner is available for other applications.
If you don't want to use local-path provisioner shipped with k3s, you can disable it by --disable local-storage and install it by
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml

but,Is the one comming with k3s available for out of namespace?
I mean is the one comming with k3s by default was a k3s system internal service using only version? the one that's not publicly available to our business running service/pod etc?or it's just the same as the one I manually installed by

Sure. The default local-path provisioner is available for other applications.
If you don't want to use local-path provisioner shipped with k3s, you can disable it by --disable local-storage and install it by
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml

Appreciate,
gonna do some research on uninstall the one I manually installed and start using the one coming by default,the crash issue might because of my manually installed one messed up with the one coming by default.
but the cluster,it's kind of "Production Enviroment" now,really don't want to mess it up,Is directly running
kubectl delete -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml
to uninstall the one I manually installed is an option?I'm guess this might remove some components(or all components)on the one coming with k3s by default then I better reinstall the whole k3s again?

but,Is the one comming with k3s available for out of namespace?
I mean is the one comming with k3s by default was a k3s system internal service using only version? the one that's not publicly available to our business running service/pod etc?or it's just the same as the one I manually installed by

Sure. The default local-path provisioner is available for other applications.
If you don't want to use local-path provisioner shipped with k3s, you can disable it by --disable local-storage and install it by
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.24/deploy/local-path-storage.yaml

uninstalled the one I manually installed and reinstall k3s again,so we should be using the one coming with k3s bydefault,the problem not appear again,Thanks so much!


Measure Positive end-expiratory pressure (PEEP) [Backend]

[Backend]
-5–15 cm H2O required; many patients need 10–15 cmH2O (pressure measurement)
-(Face Mask interface, specify model, not GUI monitored)

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5537121/

https://www.youtube.com/watch?v=Gu4sChU9eBo

https://www.medscape.com/answers/304068-104783/what-is-positive-end-expiratory-pressure-peep-therapy-and-how-is-it-used-with-mechanical-ventilation


Test all record types

The record types in the model-analyzer.record.types package is contextual when it uses 'less than' (<) and 'greater than' (>) operators.  The 'less than' and 'greater than' operators are overloaded to mean 'worse than' and 'better than' respectively.

Some record types treat MORE as better (eg, gpu_free_memory, cpu_available_ram)
Other record types treat LESS as better (eg, gpu_used_memory, cpu_used_ram)

So, when comparing two objects of type cpu_used_ram  12 > 13 is actually true, since 12 'is better than' 13.
Based on this context, the code is working fine.

However, not all record types were being tested.
This PR closes the gap so that all record types are tested in two ways:

Make sure that the count of 'less is better tests' plus the count of 'more is better tests' equals the total number of record types.
Update tests that use 'less is better' and 'more is better' to fail if it's not accounted for

Please add a high level description of the file/class near line 21

Done.


Add FromHex::as_hex_backwards

Done on top of #67 and #71
Just the second to last patch (last is API changes), draft for feedback please.
Adds functionality to support printing slices and vectors of bytes backwards as used by rust-bitcoin. The current code is definitely a bit klunky.

I don't understand the motivation, just format the reversed iterator.

Closing, turns out we can just handle backwards in rust-bitcoin.


[Masonry] Extra Right Margin

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
When you set the "spacing" property, it adds the spacing to the right side margin.
If you have a two column layout, currently it:

adds no space on the left of the left column (which makes sense)
adds space between the two columns (which makes sense)
adds space on the right of the right column (which does not make sense)

Similarly for 3, 4, 5, etc. column layouts, it adds space between the columns and on the right of the right-most column but not on the left of the left-most column.
Expected behavior 🤔
The spacing should be applied only between items, not on the right side of the last column. It looks bad on multi-column layouts because spacing on the right ends up being larger than that of the left. This is especially bad on a single column layout for mobile devices in portrait mode where the wider space on the right is very obvious.
Any workarounds?
Steps to reproduce 🕹
Steps:

Go look at the masonry documentation page at https://mui.com/material-ui/react-masonry/
You can probably notice visually the right margins are wider, but if not, you can also:
Inspect the first item in browser dev tools
Go up to the parent element, a div with class="MuiMasonry-root css-1mgjsc9"
There is extra margin on the right side.

Context 🔦
I want the layout to be clean and symmetric as it should be. Left and right margin should be equal.

  Output from `npx @mui/envinfo` goes here.

As a workaround for anyone finding this, you can add a CSS style:
.MuiMasonry-root { margin: 0!important; }
It seems to work so far. You should also be able to set a global style override but I can't get that to work for some reason.

One other observation... I think I was wrong when I said this:

adds no space on the left of the left column (which makes sense)
adds space between the two columns (which makes sense)
adds space on the right of the right column (which does not make sense)

Actually, it seems it adds space to the left of the left-most column, between each column, and to the right of the right-most column. There was this weird calculated -8 margin that made it seem like there wasn't padding to the left of the left-most column because the whole set of columns seems to move left. Looking at it again today, with my temporary CSS fix, I can see there is padding to the left, between columns, and to the right. So, I think the "bug" is the shifting of the whole set of columns to the left due to the negative margin. Dealing with that would be great, because at least it would be symmetric, but while digging into this issue and taking the time to do whatever testing is needed, it might be nice to also consider feature request #34235 which would allow for more flexibility with making that side spacing optional.

Hi @hbjORbj, may I work on this issue? I think the source of this discrepancy is this line in the code:
https://github.com/mui/material-ui/blob/f015784964f177834c475f79b0711bdb5e3ff512/packages/mui-lab/src/Masonry/Masonry.js#L96
As every item in the Masonry component has its own margins calculated based on the spacing value, I think it might be better to change this line as it's forcing extra margins to the parent container. We can set its value to auto to preserve the right margin values for the Masonry container.

@alisasanib
I am sorry for late reply.
https://github.com/mui/material-ui/blob/0246ec2cdd85de48c669da3f84e25f0dd7eb51f0/packages/mui-lab/src/Masonry/Masonry.js#L95-L99
The negative margin applied to the wrapper was applied in order to offset the positive margin applied to every child inside the masonry wrapper.

may I work on this issue?

Sure, you can create a PR and request me a review once you create it.

I just set the width to auto so that the negative margin would have its effect. If it is set to 100%, the MuiMasonry-root block will always take the width of its parent and will not be able to stretch out
.MuiMasonry-root {
    width: auto;
}

I just set the width to auto so that the negative margin would have its effect. If it is set to 100%, the MuiMasonry-root block will always take the width of its parent and will not be able to stretch out
.MuiMasonry-root {
    width: auto;
}

Following this solution, I put it in components override like this and fixed the issue:
MuiMasonry: {
    styleOverrides: {
      root: {
        width: 'auto',
      },
    },
  },


[BUG] Directory is not set when switching session

Hello, I love the idea of bringing sessionizer to Zellij !
I know it's still in the early stage but I wanted to report a bug I currently have (using 0.3.0).
When changing session, the newly created one CWD isn't set to the desired path. Tell me if I can provide useful logs or informations.
Demo
https://github.com/user-attachments/assets/2a0ab07d-2d71-4818-b3ec-fa262009113e

Hey thanks for the report and the video. I can't replicate, can you share the relevant parts of your zellij config ?

Sure ! Here's the code section for settings the keybind. It's basically the default config
https://github.com/elythh/flake/blob/6578a8e90db86c4324d0959338faf4a59b01d016/modules/home/opt/shell/zellij/default.nix#L82-L89

It's a layout problem, cwd seems to just be ignored when zellij fallsback to default_layout. As a temporary fix you can copy your layout to a file called default.kdl, this will prevent the fallback.
I will add a config option today or tomorrow to let users choose their layout, which should fix this.

Thanks for looking into it !

Indeed I renamed my layout to Default and that fixed it.


Detect Unity Version and Report Incompatibility

Investigate detecting the version of the unity editor, preferably when installing modules, and report incompatibility.

One way that we could accomplish this is by having modules installed by some sort of 'installer' that automatically does version checking, dependency checking, and correct file cleaning before installing.  It would be quite an endeavour but might be a good idea.

I'm going to close this since it's right now pretty far from being possible with our current module ecosystem.  If we want to overhaul our release system, we could open up something like this again.


Add another ignored acl

Removal of security.csm is never a good idea, and breaks you on GKE.  So let's not!

Yeah this is no longer needed as we upstreamed it into nix itself.
On Wed, 11 Jan 2023 at 20:29, Jörg Thalheim @.***>
wrote:

@.**** commented on this pull request.
In default.nix
https://github.com/DavHau/nix-portable/pull/39#discussion_r1067429020:

@@ -139,7 +138,7 @@ let

   echo "build-users-group = " > \$dir/conf/nix.conf
   echo "experimental-features = nix-command flakes" >> \$dir/conf/nix.conf

 echo "ignored-acls = security.selinux system.nfs4_acl" >> \$dir/conf/nix.conf

 echo "ignored-acls = security.selinux system.nfs4_acl security.csm" >> \$dir/conf/nix.conf

Is this setting really needed? reading the nix source code this list seems
to be blocked by default already.
—
Reply to this email directly, view it on GitHub
https://github.com/DavHau/nix-portable/pull/39#pullrequestreview-1244570515,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABN425O4YLHROQYLN3OPT5LWR4J3RANCNFSM5V3CL74A
.
You are receiving this because you authored the thread.Message ID:
@.***>


A problem in izer.py

at izer/izer.py, line 188
    # Work with 1D input data
    if data.ndim < 3:
        data = np.expand_dims(data, axis=2)

It seems that it would not work with 1D data but at least 2D. Some situations might be added to solve this.

ops, sorry for misunderstanding this.


feat(ci): add support for python 3.11

This PR aims to add support for python 3.11.

Yay ! Seems like we can support python 3.11 now ❤  !


Complete the invoke instruction

Complete the invoke instruction for mint_to and create_account  in ../src/lib.rs .
Include all these for mint_to :
token_program_id ,
mint_pubkey ,
account_pubkey ,
owner_pubkey ,
signer_pubkeys ,
amount
And, Include all these for create_account :
from_pubkey ,
to_pubkey ,
lamports ,
space ,
owner
Take the help of other completed invoke instructions !

Claim

Claim

Go ahead @anshgeez31

@anshgeez31 you have 4 hours left to complete this issue.

@Srijan-crypto I need more time for corrections

OK @anshgeez31 you have till 12 midnight tomorrow. Try to complete it in time.


Refactoring: Recommendation Engine

The recommendation engine should be isolated to it's own file and class.
This would eliminate data processing from within the API (routes) file, and make our code generally more readable. This would also mean development and iteration on the recommendation engine would be contained to the recommendation file.
When we serve our recommendations, we would simply call the recommendation class with our input data and return our recommendations.
https://github.com/Lambda-School-Labs/betterreads-ds/blob/2496f95424cedcce8512c7d476017ab818698944/readrr_api/routes/recommendations.py#L37

There's a duplicate of this function in the gb_funcs.py file. We could move this out of the script with the recommendation route and replace the outdated one in the module.

This has been implemented here:
https://github.com/Lambda-School-Labs/betterreads-ds/blob/1e2d328b375f0b3e5ef4c14dcc8c27a3fd365492/readrr_api/route_tools/recommender.py#L50


update package.json

desc is missing

Fixed in https://github.com/yoshuawuyts/degrees-radians/commit/b22dcdf746ce3779c7a9d8a5dd1dd84724fb275c?

Haha, yeah. Thanks!


git-vanity-hash: 2020-02-26-unstable -> 1.0.0

Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 249316 run on x86_64-linux 1

1 package built:

git-vanity-hash


fullscreen font size

Hi,
It's possible, when you are in fullscreen (or not) to decrease font size?
or implement a increase/decrease font size?
increase: ctrl+ +
decrease: ctrl+ -

Hi,
unfortunately it's impossible because TIC screen resolution has fixed size 240x136 pixels
same thine with the font it's 6x6 pixels
so, close then