Only catch plugin loader exception

address issue #10

@Levi-Armstrong why don't you add me as a maintainer to the organization so I can do reviews. I think at this point it makes sense to add me as an overall maintainer to the project.

@johnwason You have been added.


Typo

Minor typo (bracket needed)

Proposed changes
Minor typo (bracket needed)
Unreleased project version (optional)

Related issues (optional)

Deploy preview for docsdocker ready!
Built with commit e1390a2c531010ef241aa41979b5ed406285779e
https://deploy-preview-7634--docsdocker.netlify.com


icepll: added options to save PLL config as Verilog and for quiet output

e.g. to do be able to do

$ icepll -i 12 -o 90 -q -f pll_90mhz.v

Nice idea. I think maybe -f would be even more useful if it would only write the generated parameters to the output file (and maybe a comment). I.e. something like this:
/* ..............................
 * ..............................
 * ..............................
 */

.FEEDBACK_PATH("simple"),
.DIVR(4'b0000),
.DIVF(7'b1001111),
.DIVQ(3'b100),
.FILTER_RANGE(3'b001)

So the user could run for example icepll -i 12 -o 90 -q -f pll_90mhz.vh and then in use something like the following in her HDL code:
SB_PLL40_CORE #(
    `include "pll_90mhz.vh"
) uut (
    .LOCK(locked),
    .RESETB(1'b1),
    .BYPASS(1'b0),
    .REFERENCECLK(clock_in),
    .PLLOUTCORE(clock_out)
);

This way the mechanism would work with all five PLL primitives (SB_PLL40_CORE, SB_PLL40_PAD,
SB_PLL40_2_PAD, SB_PLL40_2F_CORE, and SB_PLL40_2F_PAD) and the user could still set the other parameters manually, and/or decide to use ports like BYPASS and RESETB.

I implemented your suggestion. Both variants (header file and module) are now be possible.
Check it out: https://github.com/matthiasbock/icestorm/commit/14fd3eec5b2eb4fe1673755673286cecda32687e
Example to create an includeable Verilog header file:

icepll -q -f pll.vh

produces

/**
 * PLL configuration
 *
 * This Verilog header file was generated automatically
 * using the icepll tool from the IceStorm project.
 * It is intended for use with FPGA primitives SB_PLL40_CORE,
 * SB_PLL40_PAD, SB_PLL40_2_PAD, SB_PLL40_2F_CORE or SB_PLL40_2F_PAD.
 * Use at your own risk.
 *
 * Given input frequency:        12.000 MHz
 * Requested output frequency:   60.000 MHz
 * Achieved output frequency:    67.500 MHz
 */

.FEEDBACK_PATH("SIMPLE"),
.PLLOUT_SELECT("GENCLK"),
.DIVR(4'b0000),         // DIVR =  0
.DIVF(7'b0101100),      // DIVF = 44
.DIVQ(3'b011),          // DIVQ =  3
.FILTER_RANGE(3'b001)   // FILTER_RANGE = 1

Example to create a standalone Verilog module:

icepll -q -m -f pll.v

produces

/**
 * PLL configuration
 *
 * This Verilog module was generated automatically
 * using the icepll tool from the IceStorm project.
 * Use at your own risk.
 *
 * Given input frequency:        12.000 MHz
 * Requested output frequency:   60.000 MHz
 * Achieved output frequency:    67.500 MHz
 */

module pll(
        input  clock_in,
        output clock_out,
        output locked
        );

SB_PLL40_CORE #(
                .FEEDBACK_PATH("SIMPLE"),
                .PLLOUT_SELECT("GENCLK"),
                .DIVR(4'b0000),         // DIVR =  0
                .DIVF(7'b0101100),      // DIVF = 44
                .DIVQ(3'b011),          // DIVQ =  3
                .FILTER_RANGE(3'b001)   // FILTER_RANGE = 1
        ) uut (
                .LOCK(locked),
                .RESETB(1'b1),
                .BYPASS(1'b0),
                .REFERENCECLK(clock_in),
                .PLLOUTCORE(clock_out),
                );

endmodule

Implemented. Have a look: https://github.com/matthiasbock/icestorm/commit/b6dcaaee4d39d1914418cb27b07bb6c0d076c8a3


Make new server NIC filtering configurable

As part of #4919 I introduced a very simple and hard coded way to have the game server exclude certain virtual NICs from being set up as listening targets (so the server can be found on one or more local networks). This is likely only of relevance on developer-heavy systems where a lot of virtualization is being used. For my setup see the snippet in the linked PR. Before my change it took more than 30 seconds to set up listeners on all my NICs (including in MTE type tests!) while after it only took 3 seconds. It won't affect a lot of systems but it can make a substantial difference on a few, especially when running certain types of tests.
I only picked two obvious NIC names to filter out, but surely there are others and at least two more of mine could be excluded (anything with "tunnel" is likely fair game, and maybe "TAP" would be wider but not too wide vs "ISATAP"). It may also be possible to have legit NICs named something that ends up in a banlist, so it should be possible to configure the filter patterns, likely inside config.cfg set to my initial pattern or an improved one by default.
I am not sure if this is worthwhile to add to the game UI, under some sort of multiplayer settings screen, but maybe. It could be enough just to keep it in config.cfg we do have a few other things that are only toggleable via config not UI.
To approach this as a GFI: run the game, see what shows up in config.cfg, search the code for a somewhat unique term (that optionally has a UI setting), then examine the code related to handling the values in our config system. Then introduce a new section for this feature, update the hard coded bit in NetworkSystemImpl.java (see the linked PR), and test! It may also be worthwhile trying to make the feature more visible, like through better logging, UI fields/popups (if relevant), and a note in our documentation.

Never mind - in my sleep-deprived state I didn't catch that the related code actually does nothing but log stuff - lines 180-198 seem more like candidates for deletion entirely. At least then that'd probably be even faster!


Maybe missing _base variants in overrides

Continuing the discussion from #631 since that one is closed....
After applying the patch that also overrides _msize_base, the project compiles. but got greeted with many "Not allocated by this allocator" error.
Running dumpbin /SYMBOLS on the ucrt lib shows there is a _base variant for many other heap related APIs.
I wonder these information that might requires some microsoft internal employee's knowledge:

Why these _base variant calls appeared in the final binary when no source code referenced them?
Should snmalloc provide overrides for them too?

This seems to workaround existing issue, though it seems you also need to implement _recalloc and maybe _recalloc_base

The jemalloc compat basically has _recalloc.  If you specialise to the flag being set to say it should be zeroed:
https://github.com/Naville/snmalloc/blob/583cd5da55de58fe320a7054ce15d980071ed44c/src/snmalloc/override/jemalloc_compat.cc#L267-L302
Happy to add this overrides.


static files should use strong etag

I have git rev b783caaaeddaee61384b963ce48bfe385a65b9a5 cloned on master.
This issue is about github.com/mholt/caddy/caddyhttp/staticfiles/fileserver.go.
At line 125
e := fmt.Sprintf(`W/"%x-%x"`, d.ModTime().Unix(), d.Size())

a weak etag is generated from the modification time and file size.
Is this correct? I think possibly not: it should instead be a strong etag (i.e. without the "W/" prefix).
For static files, it is clear that the representation will not change until the modification time and/or file size change. This allows the use of strong etags.
From Wikipedia,

A strongly validating ETag match indicates that the content of the two resource representations is byte-for-byte identical and that all other entity fields (such as Content-Language) are also unchanged. Strong ETags permit the caching and reassembly of partial responses, as with byte-range requests.

A weakly validating ETag match only indicates that the two representations are semantically equivalent, meaning that for practical purposes they are interchangeable and that cached copies can be used. However the resource representations are not necessarily byte-for-byte identical, and thus weak ETags are not suitable for byte-range requests. Weak ETags may be useful for cases in which strong ETags are impractical for a web server to generate, such as with dynamically-generated content.

I noticed this because it stood out as a difference between Nginx and Caddy on my static website.

I've had an alternative idea - I have been developing my own file-serving handler for some time (hence the interest in this topic). You might like to take a look at it: https://github.com/rickb777/servefiles
We might merge some of this code into Caddy's fileserver, or possibly just link to my servefiles directly.

You're probably right.

I noticed this because it stood out as a difference between Nginx and Caddy on my static website.

I wonder, by this do you mean that when loading a page, the browser loads an old version because the weak eTag is the same even though the file has changed?

I have been developing my own file-serving handler for some time (hence the interest in this topic).

Cool, I'll take a look!

I think this is now done in #1435


Update Android to use ESRP

This is the initial set of changes to get Android publishing through ESRP.

First, move the Resource->Repositories from the individual ci.yml files into the archetype-sdk-client.yml. This is what we do in Java for the azure-sdk-build-tools repository so we don't have to add it to every ci.yml file. This also required changing the stages to extends in the ci.yml files.
Add a ci.yml file for template so it can actually be built and tested. Template is the library used for release testing.
Fixed template so it'll actually work. Note: The updates to template's gradle.properties was done for release purposes.
Like Java, move the tooling into the Android repository. Right now, the files are copied from the Java repository to just get things working and the set of files to do this is rather small.

eng/pipelines/templates/steps/java-publishing.yml
eng/pipelines/templates/steps/publish-artifact.yml
eng/scripts/MavenPackaging.ps1
eng/scripts/Publish-MavenPackages.ps1
eng/scripts/SignAndHash-MavenPackages.ps1
eng/maven.publish.settings.xml

Bring forward githubIODocs publishing, which was using an archaic tools script. This required adding the Publish-andriod-GithubIODocs to the LanguageSettings.

Fixes #1169

@weshaggard @vcolin7 - Here's the deal, in order to move the azure-sdk-build-tools ref forward, to what Java is using, the doc publishing had to change. The previous ref was like a year old and was stuck there because it was using the docs publishing pre-azure storage and the files it was using have been gone for like a year. Unfortunately, this means that this respository's docs githubIO needs to be converted to use the blob storage, just like everything else as no new docs will be published to the original location @sima-zhu is going to be writing a transition doc.
More than half the commits here are from dealing with the githubIO publishing. The scripts are pretty unforgiving with missing functions and sometimes let you know and sometimes fail silently. A number of commits were made to add more temporary diagnostics output and those diagnostics changes have been removed. The final commit is a version update for template.
@vcolin7 with these changes it should be trivial to add nightly publishing to the android dev feed but it's going to require something that can manipulate the versions in the repository.


[indexer] move objects snapshot processing into its own pipeline (#18…

not really needed as if indexer operators upgrade to 1.27, the client should be consistent on both sides.


Dragonfire takes more than 30 min to install

Hi..I tried to install Latest hotfix of Dragonfire on Ubuntu 17.10...the installation keeps going and
does not seem to finish even after 2 hours...May I know whether I am doing anything wrong?I am following the instructions given

I had a similar issue. It would seem the install is extremely memory-intensive, resulting in a lot of paging which can cause very long runtimes.

@Vipult and @hosford42 Dragonfire compiles Kaldi ASR on installation time. This is why it takes so much time and consumes that amount of memory.


including additional form of combining validations in javadoc

Current coverage is 96.09%

Merging #1219 into master will decrease coverage by -0.01% as of 85714b0

@@            master   #1219   diff @@
======================================
  Files           78      78
  Stmts         9161    9161
  Branches      1717    1717
  Methods          0       0
======================================
- Hit           8804    8803     -1
- Partial         92      93     +1
  Missed         265     265

Review entire Coverage Diff as of 85714b0

Powered by Codecov. Updated on successful CI builds.

@danieldietrich Hi! Been while since I've contributed to JavaSlang, but wanted to say congrats on release 2.0! I absolutely LOVE the new pattern matching API, fantastic work there.

Hi :) Thank you Eric. We've build a great release! Now I want to spend some time to write about the features.


lnwallet: apply BIP69+CLTV tie-break to HTLC signature order

Fixes #4118
This PR fixes an issue in which HTLC signatures sent to the remote peer could be improperly ordered. This can occur when multiple HTLCs share the identical payment hashes and amounts, but have differing CLTV values. In particular, if these HTLCs are added in such a way that subsequence has descending CLTVs, the HTLC signatures would not reflect the HTLC tie-breaker used to sort the commitment.
#3412 partially fixed the issue, by ensuring that we properly sort the actual commitment and second-level transaction refer to the proper txid in their previous outpoint, however it failed to apply this sorting when generating the signing jobs and hence the final ordering that is sent on the wire.

One small nit regarding d2fa2b5 commit's message: the test addition is no longer in the prior commit.

Fixed


how to start

i downloaded it succesfully but i dont know how to launch the script

you can't its still in development

@Morsmalleo is it still in development?

@Morsmalleo is it still in development?

Yes it is still in development, I'm doing the best i can to the help the
dev on this project
On Sat., 2 Jan. 2021, 11:30 pm hokd2905<EMAIL_ADDRESS>wrote:

@Morsmalleo https://github.com/Morsmalleo is it still in development?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Open-Security-Group-OSG/HiddenEyeReborn/issues/31#issuecomment-753487008,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APK5A2GVNBVCVOORHZTWGTLSX4327ANCNFSM4T7BC55A
.

Yes it is still in development, I'm doing the best i can to the help the
dev on this project
On Sat., 2 Jan. 2021, 11:30 pm hokd2905<EMAIL_ADDRESS>wrote:

@Morsmalleo https://github.com/Morsmalleo is it still in development?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Open-Security-Group-OSG/HiddenEyeReborn/issues/31#issuecomment-753487008,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APK5A2GVNBVCVOORHZTWGTLSX4327ANCNFSM4T7BC55A
.

Duplicate of #11


WIP : v0.5.0

Codecov Report
Patch coverage: 97.90% and project coverage change: +0.77 :tada:

Comparison is base (50b0c6e) 82.22% compared to head (5d28d41) 83.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #118      +/-   ##
==========================================
+ Coverage   82.22%   83.00%   +0.77%
==========================================
  Files          37       38       +1
  Lines        2701     2754      +53
==========================================
+ Hits         2221     2286      +65
+ Misses        480      468      -12

Impacted Files
Coverage Δ

src/settings.jl
8.00% <ø> (ø)

src/variables.jl
77.64% <ø> (+11.64%)
:arrow_up:

src/types.jl
85.71% <87.50%> (-0.65%)
:arrow_down:

src/presolver.jl
94.73% <94.73%> (ø)

src/Clarabel.jl
100.00% <100.00%> (ø)

src/cones/compositecone_type.jl
94.59% <100.00%> (-0.28%)
:arrow_down:

src/cones/cone_types.jl
93.54% <100.00%> (+0.10%)
:arrow_up:

src/cones/coneops_compositecone.jl
87.64% <100.00%> (ø)

src/cones/coneops_nncone.jl
82.08% <100.00%> (+0.55%)
:arrow_up:

src/cones/coneops_psdtrianglecone.jl
96.15% <100.00%> (+0.35%)
:arrow_up:

... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


VS Code attach to shared process does not work with node2 type

Testing #14341

VSCode Version: Latest Insiders
OS Version: Mac OS

Steps to Reproduce:

Set up VS Code development workspace
Launch vs code dev using ./scripts/code.sh
Configure the shared process launch to use node2 type
Start the launch

It fails

How do you configure the shared process launch to use node2? Is it an Electron renderer process? If so it won't work because of https://github.com/Microsoft/vscode-node-debug2/issues/4.

@roblourens It is not a renderer process.. It is a node process. I just changed type from node to node2.

In the launch config though? That's an attach config, so where does it get started in debug mode?

Oh right node-debug can put running processes into debug mode, but node2 can't. https://github.com/Microsoft/vscode-node-debug2/issues/15 - so, can't support this unless you can get it to start up in debug mode somehow.

@roblourens I suspect that the 'code.sh' script configures VS Code to launch the shared process with '--debug'. This prevents node-debug2 from connecting successfully because it needs the '--inspect' flag. The https://github.com/nodejs/node/issues/8464 approach is not used here.

Oh I see this - https://github.com/Microsoft/vscode/blob/master/src/vs/code/node/sharedProcess.ts#L35 but, there's no way to know ahead of time whether someone will want to attach with node or node2. Maybe at some point we want to switch it to --inspect. I don't know who uses it and cares one way or the other.

The shared process runs on Electron's node. Does this already support '--inspect'?
Is it possible to launch node with both '--debug' and '--inspect' and decide later what debugger protocol to use?

I guess I'm not sure whether it will have the same problem as forking a renderer process with --inspect. It's not possible to use both though, you can only pick one.


Fix rgb565 / bgr565 interchange issue in Zephyr

There is a wrong assumption about the "byte swap" in Zephyr that makes RGB565 and BGR565 formats are used interchangeably.
This mistake (perhaps) originally comes frome the display samples that leads to the confusion in display drivers, shields, video sample. This PR fixes it.

Fix display sample
Fix video sample
The NXP eLCDIF driver should not force BGR565 to RGB565.
The rkxxx panel overlays should declare RGB565, not BGR565.

@danieldegrasse : The display format is RGB565, not BGR565. I think there are two mistakes that makes it "works" in practice but make it confused, and that impacts the video capture where you forced RGB565 to BGR565.

The display overlays should declare RGB565, not BGR565.
The NXP eLCDIF driver should not force BGR565 to RGB565.

Taking the example of RK055HDMIPI4MA01:
https://www.nxp.com/docs/en/data-sheet/RK055MHD091A0-CTG.pdf

I did not test on hardware though.

@danieldegrasse : I did check with both samples/drivers/display and samples/drivers/video/capture (where we used video_sw_generator to generate RGB565 color bar patttern) and see it works correctly.

I will look through Jason's explaination but honestly, I can't understand where and how Zephyr define a RGB565 to become with BGR565. If it happens, it has to be at least symetrically : RGB565 -> BGR565 and vice versa.
If it's an issue with only NXP's displays, it should not be enforced widely in Zephyr.

Oh, just retested. Indeed, with the display sample, the colors are wrong : R -> B, G -> R, B -> G and the grey box cycling through a set of incorrect colors as you said, sorry for that (I am not too familiar with the display sample, so I didn't check carefully).
But for the video capture sample, the color bar pattern are all correct, how do we explain that ?
/* Black, Blue, Red, Purple, Green, Aqua, Yellow, White */

@danieldegrasse The display sample didn't work correctly because it also made a mistake when doing BGR565 for RGB565. After fixing this, it works fine.
I think there exists a long-time, wrong assumption about the "byte swap" that may originally from the display sample and spread out to display drivers, shields, video sample.
Even if there is some thing like "byte swap", "big endian" etc., it is at specific hardwares and should not be taken widely and wrongly in Zephyr like that.
Could you revisit ?

@danieldegrasse The display sample didn't work correctly because it also made a mistake when using BGR565 and RGB565 interchangeably. After fixing this, it works fine.
I think there exists a long-time, wrong assumption about the "byte swap" in Zephyr that may originally come from the display sample and spread out to display drivers, shields, video sample.
I think even if there is really something like "byte swap", "big/little endian" issue for some specific hardwares, it should be fixed at these hardwares and should not be taken widely and wrongly in Zephyr.
Could you revisit ?

The problem is that a long time wrong assumption quickly becomes an API contract. The display sample treats BGR565 format a certain way, and all in tree displays have been designed to work with this format. If we want to change the meaning of these format definitions, we need to do the following:

change all in tree usages
clearly document this change in the migration guide

I'm not opposed to fixing this- the way that we define display formats has always bothered me. We just need to make sure we minimize churn for downstream display drivers.

The problem is that a long time wrong assumption quickly becomes an API contract. The display sample treats BGR565 format a certain way

RGB565 and BGR56 are two different formats. The display sample just does BGR565 but names it RGB565 (function fill_buffer_rgb565()) and vice versa. Anyways, it is just a sample. You mentioned several times the term "API", could you point me to some display APIs (?) or macro or anything else in Zephyr that defines RGB565 as BGR565 ?

Some extra material which could be of interest:

https://gix.github.io/media-types/
https://lwn.net/Articles/218798/
https://ffmpeg.org/doxygen/trunk/pixfmt_8h.html#ac006ecccd336ce7280ef0155568ebfb6
https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dformat

I'm fully for fixing this. If we're afraid of breaking display API, maybe fix video subsystem for now and do the explicit mitigation into the sample.

https://github.com/zephyrproject-rtos/zephyr/blob/6e653a96f7903fc932575b37f449ceaf4e94c3e7/include/zephyr/drivers/display.h#L39

@danieldegrasse Thanks for the info and your support. The document (comment) just says that byte order is big-endian. It's just the order the bytes are stored. Difference in endianess does not mean RGB565 becoming BGR565 and vice-versa. They are still two disctinct formats. I think the misunderstanding comming from this.
RGB565 in

big-endian machine:   RRRRRGGG  GGGBBBBB
little-endian machine: GGGBBBBB  RRRRRGGG

BGR565 in

big-endian machine:   BBBBBGGG GGGRRRRR
little-endian machine: GGGRRRRR BBBBBGGG

@loicpoulain I want to do so but the problem is if we fix the video sample, we also need to fix a display driver (e.g. eLCDIF) to correctly display the video frames. But if we fix that display driver, the display sample need to be fixed too to work correctly on that display.

RGB565 in

big-endian machine:   RRRRRGGG  GGGBBBBB
little-endian machine: GGGBBBBB  RRRRRGGG

BGR565 in

big-endian machine:   BBBBBGGG GGGRRRRR
little-endian machine: GGGRRRRR BBBBBGGG

It looks like this thread has a similar comments:

https://github.com/zephyrproject-rtos/zephyr/issues/53642

LWN article

for each color field, the lighter-shaded bit is the most significant

This is Little Endian, and the most significant bit of each series is on the left, so this is a Verilog/VHDL-friendly representation with most significant bit at the left:
little-endian, MSBit first:
7  6  5  4  3  2  1  0  15 14 13 12 11 10 9  8
g  g  g  R  r  r  r  r  B  b  b  b  b  G  g  g

big-endian, MSBit first:
15 14 13 12 11 10 9  8  7  6  5  4  3  2  1  0
B  b  b  b  b  G  g  g  g  g  g  R  r  r  r  r

This makes it look like R last, but if considering that BIT(0) is first, then red is first.
Back to an ordering starting from 0 at  the left (least significant bit first):
big-endian, LSBit first:
0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
r  r  r  r  R  g  g  g  g  g  G  b  b  b  b  B

Intel libvpl
Looking at Intel interpretation of the Microsoft Media Foundation format definitions:
https://github.com/intel/libvpl/blob/5f6bd8a1e753c8f63a3fd8b36894d6968b808a6d/api/vpl/mfxstructures.h#L140

2 bytes per pixel, uint16 in little-endian format, where 0-4 bits are blue, bits 5-10 are green and bits 11-15 are red
-- https://intel.github.io/libvpl/latest/API_ref/VPL_enums.html#_CPPv417MFX_FOURCC_RGB565

Assuming the most significant bit is at BIT(0), this is the opposite!
libavformat
Let's look at actual code:
https://github.com/libav/libav/blob/c4642788e83b0858bca449f9b6e71ddb015dfa5d/libavfilter/vsrc_testsrc.c#L403
This takes r, g, b 8-bit integers (stored in an int though), and pack them into a big-endian RGB565 integer (big endian otherwise, Green would have to be split:
    case AV_PIX_FMT_RGB565: ((uint16_t*)(dst + y*dst_linesize))[x] = ((b>>3)<<11) | ((g>>2)<<5) | (r>>3); break;

Each color gets shifted down to drop some information of each channel R, G or B, and we are left with this:
    case AV_PIX_FMT_RGB565: ((uint16_t*)(dst + y*dst_linesize))[x] = (b<<11) | (g<<5) | r; break;

R is not shifted => R least significant bit is at BIT(0).
(b<<11) | (g<<5) | r

According to libavformat, this is correct, though shown with least significant bit first:

RGB565 in

big-endian machine:   rrrrRggg ggGbbbbB
little-endian machine:   ggGbbbbB rrrrRggg

15 14 13 12 11 10 9  8  7  6  5  4  3  2  1  0
     ...(b<<11)        ...(g<<5)          ...r
B  b  b  b  b  G  g  g  g  g  g  R  r  r  r  r

P.S.: there is the RGB565X which Linux uses as RGB565-BE:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/videodev2.h#n564

After looking for more reference material, it looks like both the LWN example and libav test source disagree with the majority of the implementations. In hope I did not confuse anyone for too long! @ngphibang representation is correct in its most natural MSBit first representation.
Someone searching for a description of the RGB565 format might end-up on this LWN article from 2007, and this could be the source for the confusion for Zephyr and libavformat test source pattern generator.

Thank you for citing different sources of references. Yes, I believe strongly that the LWN article is WRONG. Personally, If I need a reference, I am usually based on the kernel document. The kernel document of the latest Linux release (6.11) describes the layout of the RGB565-LE the same as I pointed in the above comment:
https://www.kernel.org/doc/html/v6.11/userspace-api/media/v4l/pixfmt-rgb.html

Thank you for citing different sources of references. Yes, I believe strongly that the LWN article is WRONG. Personally, If I need a reference, I am usually based on the kernel document. The kernel document of the latest Linux release (6.11) describes the layout of the RGB565-LE the same as I pointed in the above comment:
https://www.kernel.org/doc/html/v6.11/userspace-api/media/v4l/pixfmt-rgb.html

So is the action here to attempt to make this correction? I think it would be worth doing, but we need to document it clearly (both in release notes and migration guide), and update all display drivers/samples.
In theory if we simply swap all usages, things should just work fine. That being said, I think it would be best to test this as much as possible :)

Hi @danieldegrasse , thank you for reminding me of this.
I double checked in Zephyr display drivers and shields regarding this RGB565/BGR565 interchange issue. Fortunately, the problem does not span much, only the following drivers and shields are implicated:

elcdif and dcnano_lcdif drivers with rk0xxx overlays : fixed in this PR, tested elcdif OK, dcnano_lcdif is not tested, could you help to test this one as I don't have the hardware ?
st7735r drivers with longan_nano-common.dtsi, mini_stm32h743.dts, mini_stm32h7b0.dts : not fixed
st7796s with rd_rw612_bga.overlay : not fixed

The two latter introduced the config->madctl and config->rgb_is_inverted with all comments about "supporting buggy modules, etc." that make me doubt whether they falls into the same rgb/bgr issue we fixed here or there are really "buggy modules" that need all of these madctl and rgb inverted configs. As you worked on these drivers, could you help to guide how to fix them, e.g. by just set rgb_is_inverted = false or removing all the logics around madctl and rgb reverted boolean ? or even better, could you make commits to fix them :-) ?
Thank you !

Maybe I'm missing something here, but won't we effectively just need to replace all usages of PIXEL_FORMAT_RGB_565 with PIXEL_FORMAT_BGR_565, and vice versa? I think that should result in no logical changes to the code, as long as we catch all usages

The two latter introduced the config->madctl and config->rgb_is_inverted with all comments about "supporting buggy modules, etc." that make me doubt whether they falls into the same rgb/bgr issue we fixed here or there are really "buggy modules" that need all of these madctl and rgb inverted configs. As you worked on these drivers, could you help to guide how to fix them, e.g. by just setting rgb_is_inverted = false or by removing all the logics around madctl and rgb reverted boolean ? or even better, could you make commits to fix them :-) ?

For this, the best explanation I know of is by @zejiang0jason here: https://github.com/zephyrproject-rtos/zephyr/pull/71406#discussion_r1602564853
Essentially, MADCTL swaps the color channel itself, but Zephyr swaps the bytes of the color data. I think for these panels we want to send data using RGB565 (using the Linux format naming, not what Zephyr has now) when using 8 bit or 16 bit parallel mode, or RGB565x (big endian mode) when using SPI. MADCTL should not need to change based on the color format Zephyr uses.
Best I can tell, we used RGB565 the way we did in Zephyr because the first displays supported were SPI displays, which do need big endian RGB565 data.
As far as rgb-is-inverted, the only place I've used it is as a very bad workaround- on the RW612, the LCD controller can swap the RGB data bytes in flight, so we actually want to report the pixel format as RGB565 (again, linux format naming) for SPI mode displays.

Maybe I'm missing something here, but won't we effectively just need to replace all usages of PIXEL_FORMAT_RGB_565 with PIXEL_FORMAT_BGR_565, and vice versa? I think that should result in no logical changes to the code, as long as we catch all usages.
I don't think we should swap all usages of PIXEL_FORMAT_RGB_565 and PIXEL_FORMAT_BGR_565. Only the four drivers pointed out in my previous comments misused BRG/RGB. For the other drivers, when looking at the code, I see they treat RGB565 as it is and BGR565 as it is, I mean between the pixel format in the overlays and the driver codes.

I have these three boards with me and hopefully a bit of time this week-end:

st7735r driver with longan_nano-common.dtsi, mini_stm32h743.dts, mini_stm32h7b0.dts : not fixed

Maybe I'm missing something here, but won't we effectively just need to replace all usages of PIXEL_FORMAT_RGB_565 with PIXEL_FORMAT_BGR_565, and vice versa?

Ok, I see your point now. So, apart from the logic fixes in elcdif, dcnano_lcdif drivers as done in the current PR and maybe logic fixes in st7735r and st7796s drivers will be done. We also need to swap all usages of PIXEL_FORMAT_RGB_565 / PANEL_PIXEL_FORMAT_RGB_565 and PIXEL_FORMAT_BGR_565 / PANEL_PIXEL_FORMAT_RGB_565 assumming that they are all based on the display sample to test their functionality before getting in upstream.
For example, the following snippet:
	ret = nt35510_write_reg_val(dev, NT35510_CMD_COLMOD,
				    data->pixel_format == PIXEL_FORMAT_RGB_565
					    ? NT35510_COLMOD_RGB565
					    : NT35510_COLMOD_RGB888);

will be changed to:
	ret = nt35510_write_reg_val(dev, NT35510_CMD_COLMOD,
				    data->pixel_format == PIXEL_FORMAT_**BGR**_565
					    ? NT35510_COLMOD_**BGR**565
					    : NT35510_COLMOD_RGB888);

right ? So, it's just rather a naming change and will not affect the functionality.

Hi @ngphibang ,
Thanks for the investigation, my understanding about pixel format is the same as https://www.kernel.org/doc/html/v6.11/userspace-api/media/v4l/pixfmt-rgb.html.
When driving display panels though DBI interface, the case is complicated, we need to consider the 8-bit interface, 16-bit interface. The chip MCXN947 supports both 8-bit interface and 16-bit interface, so we had a lot of discussion in #71406
The display IC can be configured for how to use the received data (st77096s MADCTL), that's another thing need to consider.
So in all, there are three parts need to take care: 1. pixel format in MCU memory. 2. pixel format sent on the bus. 3. How the display IC uses the pixel.

For this, the best explanation I know of is by @zejiang0jason here: #71406 (comment)
Essentially, MADCTL swaps the color channel itself, but Zephyr swaps the bytes of the color data. I think for these panels we want to send data using RGB565 (using the Linux format naming, not what Zephyr has now) when using 8 bit or 16 bit parallel mode, or RGB565x (big endian mode) when using SPI. MADCTL should not need to change based on the color format Zephyr uses.
Best I can tell, we used RGB565 the way we did in Zephyr because the first displays supported were SPI displays, which do need big endian RGB565 data.
As far as rgb-is-inverted, the only place I've used it is as a very bad workaround- on the RW612, the LCD controller can swap the RGB data bytes in flight, so we actually want to report the pixel format as RGB565 (again, linux format naming) for SPI mode displays.

This 's complicated for me, especially when having no hardware. But if you cannot make the commits, I will try myself :-)

Removing the rgb-is-inverted works after applying this commit:
https://github.com/zephyrproject-rtos/zephyr/commit/82573fd201436f386e3ae2480e22ea78f3291071
longan_nano: before/after 82573fd2

mini_stm32h743: before/after 82573fd2

mini_stm32h7b0: before/after 82573fd2

Maybe I'm missing something here, but won't we effectively just need to replace all usages of PIXEL_FORMAT_RGB_565 with PIXEL_FORMAT_BGR_565, and vice versa?

Ok, I see your point now. So, apart from the logic fixes in elcdif, dcnano_lcdif drivers as done in the current PR and maybe logic fixes in st7735r and st7796s drivers will be done. We also need to swap all usages of PIXEL_FORMAT_RGB_565 / PANEL_PIXEL_FORMAT_RGB_565 and PIXEL_FORMAT_BGR_565 / PANEL_PIXEL_FORMAT_BGR_565 assumming that they are all based on the display sample to test their functionality before getting in upstream.
For example, the following snippet:
	ret = nt35510_write_reg_val(dev, NT35510_CMD_COLMOD,
				    data->pixel_format == PIXEL_FORMAT_RGB_565
					    ? NT35510_COLMOD_RGB565
					    : NT35510_COLMOD_RGB888);

will be changed to:
	ret = nt35510_write_reg_val(dev, NT35510_CMD_COLMOD,
				    data->pixel_format == PIXEL_FORMAT_**BGR**_565
					    ? NT35510_COLMOD_**BGR**565
					    : NT35510_COLMOD_RGB888);

right ? So, it's just rather a naming change and will not affect the functionality.
But the problem is except the rk0xx overlays that uses PANEL_PIXEL_FORMAT_BGR_565, all others shields / overlay uses PANEL_PIXEL_FORMAT_RGB_565, so per my observation, it seems the interchange issue only happens to certains drivers / shields. Others are already correct. This can be checked by looking at display datasheets to see whether they supports RGB_565 or BGR_565 by default.

But these shields that use PANEL_PIXEL_FORMAT_RGB_565 need to be changed as well- in the current definition Zephyr uses, RGB_565 is byte swapped versus the standard definition Linux uses. So for consistency, those displays (which are mostly SPI based, I believe), also need to be changed to now use PANEL_PIXEL_FORMAT_BGR_565, since that is what we now use to define byte swapped RGB565 data (or we can define something like PANEL_PIXEL_FORMAT_RGB_565x if we'd prefer to follow what Linux does)


Updated workflows

#546  👈
main

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

Join @CatChen and the rest of your teammates on  Graphite


Fixed typos

Fixed some typos in the project.

I've found some more typos and I want to correct them (to make the project better ^^). So I've changed this to a draft as I think this could be in a single pull request.

I think this is already much and I hope you are happy with that.
If you want me to reword some more things you can ask, but now I will open this pull request.

Thanks so much!


Fixed discrepancies in icon hash between YARA and retdec-fileinfo

let's run TC tests

The original test failed because this branch was not merged with master. When merged, they pass - except Doxygen, which is, in turn, failing in master.  For an unknown reason, tests are not published from TC to GitHub, so they are still red, even though they are green in TC -> merging anyway.


NET-282: removed proxy-to-proxy comms, removed proxy udp server

Describe your changes
Provide Issue ticket number if applicable/not in title
Provide link to Netmaker PR if required
Provide testing steps
No testing is required as it is mostly code deletion/movement
Checklist before requesting a review

[ ] My changes affect only 10 files or less.
[ ] I have performed a self-review of my code and tested it.
[ ] If it is a new feature, I have added thorough tests, my code is <= 1450 lines.
[ ] If it is a bugfix, my code is <= 200 lines.
[ ] My functions are <= 80 lines.
[ ] I have had my code reviewed by a peer.
[ ] My unit tests pass locally.
[ ] Netclient & Netmaker are awesome.

will re-open after resolving merge conflicts


Buildtool not executable

Hi @Akron
Please review the PR.
Many Thanks.
Best Regards,
Mohammad S Anwar

Thank you, Mohammad! That's absolutely reasonable - I adopted your changes and will review my other repositories!
Thank you very much for your contributions!


Derivative verification!

https://github.com/SMRT-AIST/fast_gicp/blob/7798ac5afafdb58fc8f0c8794572a695b0c503a1/include/fast_gicp/gicp/impl/fast_vgicp_impl.hpp#L157
I have some questions about the derivative of the rotating part. The code in the link means "skewd(Ra + t)". Should it be "skewd (Ra)"?

Hi @nkliuhui,
Please refer to https://github.com/SMRT-AIST/fast_gicp/issues/20#issuecomment-1017108211

I see. Thank you!


Add examples, clarify usage in lilypond README

Examples of the proper use of the lilypond filter could be deduced from
the test files and the Makefile, but not all users would know to
look there. The README has been updated to make this explicit. It
has also been revised to note that the test files can be compiled
with make.
Example conversion commands have also been added to the README,
for the benefit of new users.
The command-line examples contain a note about musical symbols in
running text with PDF output: one’s TeX engine of choice must be
configured to use a typeface that contains such glyphs as Unicode
characters.
See: https://github.com/pandoc/lua-filters/issues/167

The lilypond executable must be installed to a location on your PATH

Oh sorry, completely missed that one :sleepy:

Thanks, and sorry for the wait.


bad case  in https://github.com/itchyny/gojq

a main.go file
package main

import "fmt"

func Hello(arg interface{}, msgs ...interface{}) {
	fmt.Println(arg, len(msgs))
}

func main() {

	Hello(1)
	Hello(1, []interface{}{4, 5})
	Hello([]interface{}{1, 2, 3})

}

asasalint show that
main.go:12:11: pass []any as any to func Hello func(arg interface{}, msgs ...interface{})
main.go:13:8: pass []any as any to func Hello func(arg interface{}, msgs ...interface{})

the second report is bad, the []any is only for arg, not the msgs... ,
should not only check Args[len(Args) - 1], need prove it is really the last one

fixed in https://github.com/alingse/asasalint/commit/dae1c727399a48cf5842d8257ed6cb4239228f19


[Table] Warning on rendering attempt of unsupported child

[x] PR has tests / docs demo, and is linted.
[x] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[x] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

Table silently omits components that it does not expect. This PR adds warning, so developer can be aware what's happening without need to check source code of the Table component.

@dantix Thanks!


clip-path

I use svg clip-paths all the time to do cool things, are there any plans to bring clip-path to react-art? Can't seem to find anything about it in the codebase.

oops duplicate of #26. closing


It does not compile

Thank you for porting libsodium to Elixir.
Elixir version: 1.6.3
Erlang/OTP: 20
Build log (libsalty 0.1.1 - I tried to build from any commit and it just won't compile):
https://pastebin.com/raw/fjuYnwM6
Let me know if you need further informations.
Thank you and great job!

Which OS are you using?
The errors seem to indicate that your system is missing the header files for libsodium, or the compiler is unable to locate them.
maybe the instructions at https://download.libsodium.org/doc/installation/#compilation-on-unix-like-systems can help solve your problems? If I recall correctly, running the sudo make install command should install the library (.so) and development headers in your system's include folder where the compiler can find them.

Thanks for the quick reply!
OS Version:
> lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.4 LTS
Release:	16.04
Codename:	xenial

> dpkg -l | grep -e libsodium
ii  libsodium-dev:amd64                   1.0.8-5                               amd64
ii  libsodium18:amd64                     1.0.8-5                               amd64

In the meanwhile I will try to compile libsodium from source..

Ok, salty compiles fine with libsodium compiled from sources.
However, version 0.1.1 still does not compile because of deprecation warnings treated as errors.
Compiling salty from branch master complains about missing app file:
* libsalty (https://github.com/ArteMisc/libsalty)
  could not find an app file at "_build/dev/lib/libsalty/ebin/libsalty.app". This may happen if the dependency was not yet compiled, or you specified the wrong application name in your deps, or the dependency indeed has no app file (then you can pass app: false as option)

It looks like the .app file is misnamed:
_build/dev/lib/libsalty/ebin/salty.app
I tried to rename it to libsalty.app but now I get:
Unchecked dependencies for environment dev:
* libsalty (https://github.com/ArteMisc/libsalty)
  the app file at "_build/dev/lib/libsalty/ebin/libsalty.app" is invalid
** (Mix) Can't continue due to errors on dependencies

Could you give me the commands you are using, so I can try to reproduce these errors?

In my mix.exs:
  defp deps do
    [
      {:libsalty, git: "https://github.com/ArteMisc/libsalty"}
    ]
  end

Then I run:

mix deps.get
iex -S mix  (here I get the error)
 mv ./_build/dev/lib/libsalty/ebin/salty.app ./_build/dev/lib/libsalty/ebin/libsalty.app
vim ./_build/dev/lib/libsalty/ebin/libsalty.app
change the first line as described in my previous comment
iex -S mix

Have you tried including the package as a hex dependency?
  defp deps do
    [
      {:salty, "~> 0.1.2", hex: :libsalty}`
    ]
  end

Or try changing the direct github dep to be called salty instead of libsalty
  defp deps do
    [
      {:salty, git: "https://github.com/ArteMisc/libsalty"}
    ]
  end

It seems that these errors originate from the difference between the library's package name (salty) and the repository's name (libsalty).

Thank you! Now it's working! gj


Remove speedrun-relevant cutscenes

As opposed to CSR 1.x's reliance on watching the game's memory at a set interval, CSR 2.0 leverages a postfix hook of the game's event loading function, allowing us to modify the Atel script directly.
This means replacing most instructions with NOP, as well as occasionally teleporting the player and more miscellaneous changes.
Cutscenes that need removal:

Dream Zanarkand

[ ] Skip Intro
[ ] Beginning
[ ] Naming Tidus
[ ] Kids
[ ] Fangirls
[ ] Tidus leaves fans
[ ] Tidus looks at Jecht sign
[ ] Blitzball FMV
[ ] Tidus wakes up and follows Auron
[ ] Tidus sees the fayth and follows Auron
[ ] Ammes
[ ] Tidus sees Jecht sign again
[ ] Tanker
[ ] Tidus and Auron run as bridge explodes
[ ] This is your story FMV
[ ] Tidus swimming looking at himself as a child
[ ] A dream of being alone

Baaj Temple

[ ] Tidus wakes up
[ ] Tidus falls in the water
[ ] Geosgaeno eats a Sahagin
[ ] Escape from Geogaesno
[ ] Tidus in a collapsed corridor
[ ] Tidus needs fire
[ ] Tidus makes fire
[ ] Tidus has a dream about Auron
[ ] Klikk
[ ] Rikku punches Tidus

Cid's Ship

[ ] Tidus wakes up on boat + Sphere Grid tutorial
[ ] Rikku explains the mission
[ ] They enter the submerged ruins

Underwater Ruins

[ ] Tidus bashes the machine
[ ] Tidus bashes the machine + Tros arrives
[ ] They leave the submerged ruins
[ ] Airship is shown
[ ] Tidus gets back onto the boat

Cid's Ship

[ ] Naming Rikku
[ ] Rikku suggests going to Luca

Besaid

[ ] Tidus wakes up in the sea
[X] Lagoon drop
[X] Wakka asks Tidus to join his team
[ ] Wakka explains his life story
[ ] Tidus arrives at Besaid Village
[ ] Tidus enters the temple
[ ] Tidus speaks to the priest
[ ] Priest enters Wakka's tent
[ ] Tidus dreams about a flashback
[ ] Tidus goes back into the temple
[ ] Wakka catches up with Tidus in trials
[ ] Tidus meets Lulu and Kimahri + FMV
[ ] The gang leave the cloister of trials
[ ] Naming Valefor
[ ] Besaid Night
[ ] Tidus sleeping
[ ] Tidus has a dream about Yuna, Tidus wakes up + FMV
[ ] Tidus wakes up again (Party healed at this point)
[ ] Yuna says goodbye to Besaid
[ ] Yuna says goodbye to Besaid again
[ ] Kimahri Intro
[ ] Post-Kimahri
[ ] S.S. Liki departs

S.S. Liki

[ ] Tidus goofing around
[ ] Lord Braska's daughter?
[ ] She's the daughter of High Summoner Braska
[ ] Tidus talks to Yuna
[ ] Sin Fin
[ ] Echuilles
[ ] Recovering on the boat
[ ] Map shown

Kilika

[ ] Undocking in Kilika
[ ] Sending
[ ] Tidus wakes up
[ ] Tidus speaks to Wakka
[ ] Camera pan + Yuna wants a new guardian
[ ] Race up the stairs
[ ] Pre-Geneaux
[ ] No replacement for Chappu
[ ] Arrival at temple
[ ] Camera pan in Kilika Temple
[ ] Pray or Stand
[ ] Tidus is denied access
[ ] Trials Entry
[ ] Trials Camera Pan
[ ] Guardians are annoyed at Tidus
[ ] Fayth explanation
[ ] Naming Ifrit
[ ] Exit Temple
[ ] Tidus misses home
[ ] Setting off to Luca

S.S. Winno

[ ] Opening scenes
[ ] Meet O'aka
[ ] Eavesdropping on Lulu and Wakka
[ ] Tidus looks at the blitzball
[ ] Zanarkand flashback
[ ] Jecht Shot Failure
[ ] Jecht Shot Success
[ ] Tidus speaks to Yuna

Luca

[ ] Luca FMV + Kilika Beasts undock
[ ] Inside the Cafe
[ ] Besaid Aurochs undock
[ ] Seymour arrives
[ ] Yuna enters the changing room
[ ] Speaking to the Al Bhed
[ ] Camera pan
[ ] Crowd mob Yuna
[ ] Crowd mob Yuna
[ ] Tidus and Yuna talk about Luca
[ ] Tidus and Yuna talk about Luca
[ ] Tidus and Yuna at the cafe
[ ] Mika begins the tournament
[ ] Al Bhed Auroch game starts
[ ] Kimahri Yuna's gone
[ ] Lulu explains the situation
[ ] Wakka takes a beating
[ ] Party jumps on the boat
[ ] Oblitzerator
[ ] Aurochs win the game
[ ] Wakka is injured
[ ] Wakka subs himself
[ ] Lulu speaks to Wakka
[ ] Pre-Blitzball
[ ] Halftime talk
[ ] Fans are getting impatient
[ ] Wakka chants
[ ] Ah! It's Wakka!
[ ] Aurochs win/lose the game
[ ] Pre-Sahagins
[ ] Lulu what's happening
[ ] Vouivre to Anima
[ ] Wakka quits the Aurochs
[ ] Wakka joins Yuna
[ ] Tidus shouts at Auron
[ ] Tidus and Auron join the group
[ ] HA HA HA HA

Mi'ihen

[ ] Tidus runs up the stairs
[ ] Meet Calli
[ ] Luzzu, Gatta and Shelinda scenes
[ ] Auron is tired
[ ] Tidus chats with Yuna
[ ] Tidus chats to a guy
[ ] Meet Rin
[ ] To the chocobo corral
[ ] Chocobo Eater
[ ] Chocobo Eater loss - Fall down the cliff
[ ] Chocobo Eater win - Rin thanks the party
[ ] Luzzu and Gatta move a cart
[ ] Seymour helps out

Mushroom Rock Road

[ ] Tidus distrusts Seymour
[ ] Send Clasko to the shadow realm
[ ] Preparing for Sin
[ ] Sinspawn Gui
[ ] Tidus wakes up
[ ] Tidus sees Gatta
[ ] Sin FMV + Tidus chases after Sin
[ ] Yuna tries to summon
[ ] Tidus is swimming
[ ] Nucleus
[ ] Zanarkand flashback
[ ] Tidus monologue on beach (Terra Skip)
[ ] Tidus monologue on beach
[ ] Kinoc retreats
[ ] Tidus speaks to Auron
[ ] Leaving Mushroom Rock Road"

Djose

[ ] Kimahri speaks
[ ] Tidus is eager to go to Zanarkand
[ ] Tidus whoa
[ ] Arrival at Djose Temple
[ ] Meet Isaaru
[ ] Entering the Djose trials
[ ] Naming Ixion
[ ] Tidus wakes up
[ ] Tidus wakes Yuna up
[ ] Yuna has bed hair
[ ] Clasko wait for me
[ ] Moonflow here we come

Moonflow

[ ] Biran and Yenke taunt
[ ] Tidus sees the Moonflow river
[ ] Tidus sees a shoopuf
[ ] The chocobos cannot cross
[ ] All Aboards!
[ ] Shoopuf launching + map
[ ] A sunken city
[ ] Debate about machina
[ ] Extractor
[ ] Back on the shoopuf
[ ] Reunite with Rikku + FMV
[ ] Map shown

Guadosalam

[ ] Meet Tromell + Customise tutorial
[ ] Tromell invites the gang in
[ ] Seymour's House
[ ] Seymour proposes to Yuna
[ ] Yuna drinks a glass of water
[ ] The gang discuss the proposal
[ ] Tidus freaks out about the undead
[ ] Auron and Rikku stay behind
[ ] Tidus enters the Farplane
[ ] Farplane
[ ] Zanarkand flashback
[ ] Tidus is embarrassed
[ ] Jyscal returns
[ ] Tidus asks about Jyscal
[ ] Affection scene
[ ] Tidus speaks to Shelinda
[ ] Yuna asks Jyscal what she can do
[ ] Macarena Temple

Thunder Plains

[ ] Map + Rikku afraid + tutorial
[ ] Rikku freaks out
[ ] Rikku asks to go to the agency
[ ] Tidus barges in Yuna's room + Sleep
[ ] Leaving the agency
[ ] Yuna decides to marry Seymour

Macalania

[ ] Arriving at Macalania
[ ] Tidus is worried about Yuna
[ ] Barthello has lost Dona + Butterfly guy
[ ] Auron open ways to Spherimorph
[ ] Spherimorph
[ ] Tromell
[ ] Crawler
[ ] Jyscal Skip
[ ] Seymour!
[ ] Post-Seymour
[ ] Naming Shiva
[ ] Backflip Skip
[ ] Wendigo
[ ] Under the lake

Bikanel

[ ] Bikanel
[ ] Wakka Glare
[ ] Sanubia to Home
[ ] Home
[ ] Home to Airship
[ ] Airship Bridge Cutscene
[ ] Red carpet has teeth
[ ] Pre-Evrae

Bevelle

[ ] Evrae to Guards
[ ] Guards
[ ] Bevelle Guards to Trials
[ ] Trials to Bahamut naming
[ ] Via Purifico - Tidus side
[ ] Via Purifico - Yuna side
[ ] Isaaru
[ ] Evrae Altana
[ ] Enter Highbridge
[ ] Seymour Natus
[ ] Natus Death

Calm Lands

[ ] Lake Scene
[ ] Calm Lands Intro
[ ] Father Zuke
[ ] Defender X
[ ] Calm Lands - Gorge intro

Gagazet

[ ] Yuna reflects
[ ] Biran + Yenke
[ ] Ronso Singing
[ ] Seymour Flux
[ ] Fayth FMV + Tidus collapses
[ ] Tidus wakes up in Zanarkand
[ ] Tidus enters his house
[ ] The fayth asks Tidus to end the dream
[ ] The dream disintegrates
[ ] Tidus wakes up
[ ] Gagazet Cave scenes
[ ] Sanctuary Keeper

Zanarkand

[ ] Zanarkand Campfire
[ ] Zanarkand Trials Begin
[ ] Pre-Spectral Keeper"
[ ] Spectral Keeper to Yunalesca
[ ] Pre-Yunalesca
[ ] Auron reveals the truth
[ ] Airship arrives

Airship, Highbridge, Sin

[ ] Yuna/Kimahri talk about defeating Sin
[ ] Shelinda + Mika
[ ] Bahamut Fayth
[ ] Return from Highbridge
[ ] Sin destination cutscene
[ ] Left Fin
[ ] Left fin Pre-Boss
[ ] Right Fin Pre-Boss
[ ] Star Players First!
[ ] Sin Core
[ ] Yuna monologue
[ ] Overdrive Sin
[ ] Pre-Omnis
[ ] Enter Tower of the Dead
[ ] Pre-BFA
[ ] BFA Death
[ ] Contest of Aeons!

Cavern of the Stolen Fayth

[ ] Lady Ginnem Attacks
[ ] Yojimbo Fayth Intro

Post Battle Transitions

[ ] Klikk
[ ] Geneaux
[ ] Ifrit
[ ] Machina
[ ] Oblitzerator
[ ] Sinspawn Gui 2
[ ] Spherimorph
[ ] Crawler
[ ] Wendigo
[ ] Bikanel Zu
[ ] Home Bombs
[ ] Home Dual Horns
[ ] Home Chimera
[ ] Evrae
[ ] Seymour Natus
[ ] Defender X
[ ] Biran + Yenke
[ ] Seymour Flux
[ ] Sanctuary Keeper
[ ] Spectral Keeper to Yunalesca
[ ] Yunalesca
[ ] Left Fin
[ ] Right Fin
[ ] Sin Core
[ ] Seymour Omnis
[ ] Yojimbo

Due to the sheer number of tasks on this list, I'm going to check them off as I develop the CSR, instead of whenever a PR gets merged.


Add CI workflow

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@7d78d3d). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   57.72%
=======================================
  Files           ?       11
  Lines           ?      369
  Branches        ?        0
=======================================
  Hits            ?      213
  Misses          ?      155
  Partials        ?        1

Flag
Coverage Δ

unittests
57.72% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out 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 7d78d3d...18008c7. Read the comment docs.


:gift: Add custom rubocop rule to double combo

Summary
ref: https://assaydepot.slack.com/archives/C0313NKG2DA/p1712176060340309

Notes
https://github.com/samvera/hyrax/pull/6221/files

https://github.com/samvera/hyrax/commit/ef2ffa446fc1fccfa36793d2ba0404931dd35ce8


Explicitly state PROJECTS_ROOT & PROJECT_SOURCE are reserved

Signed-off-by: Maysun J Faisal<EMAIL_ADDRESS>What does this PR do?
This schema explicitly specifies that PROJECTS_ROOT & PROJECT_SOURCE env are reserved and cannot be overridden via component container's env
What issues does this PR fix or reference?
Fixes #132
Is your PR tested? Consider putting some instruction how to test your changes
Docs PR

I have generic comment, is it necessary to add the full definitions for PROJECTS_ROOT and PROJECT_SOURCE to all the places that may potentially use two env vars? It seems like a little bit redundant and it's not easy to maintain (we have to update all the places if it's necessary). Would it be better to define on one place then let all other places point to that place?

Yeah, I agree with @elsony, I think we just need a section in the container.env schema that outlines which variables are reserved and can't be set by the user.

@elsony @GeekArthur @johnmcollier updated the PR! Makes sense.

@maysunfaisal It looks cleaner to me! I didn't find a PR review guide for this repo, probably we should let the code owner do the final review.

@davidfestal @amisevsk @sleshchenko Can I pls get a review on this? Thx!

I've rebased and updated the PR!


2514 - Change MSGraph version beta to v1.0 for teams user app remove

Enhancement: teams user app remove

Thank you! We'll review it asap

Looks good to me! Merged and Thank you!


Fix email change bug

Problem

Changing your email address in the app would cause a crash

Solution

Use user.id instead of user.email in the JWT sub claim.
Implement a workaround for folks who are using old style tokens (to be removed in 30 days)

Other Things

Got rid of the fw_update_server claim. We haven't used that in months.

Next Steps

Run email verification on email updates

Coverage remained the same at 54.225% when pulling a3c113472455ebfec9222bf2e9ccf87707ca2097 on RickCarlino:fix_email_change_bug into 5ebe62bc1e3b4f9767c8318fa5c63ac3f661ca71 on FarmBot:master.

Coverage remained the same at 54.225% when pulling a3c113472455ebfec9222bf2e9ccf87707ca2097 on RickCarlino:fix_email_change_bug into 5ebe62bc1e3b4f9767c8318fa5c63ac3f661ca71 on FarmBot:master.

Coverage remained the same at 54.225% when pulling a3c113472455ebfec9222bf2e9ccf87707ca2097 on RickCarlino:fix_email_change_bug into 5ebe62bc1e3b4f9767c8318fa5c63ac3f661ca71 on FarmBot:master.


Keep "lock" metadata when changing a Node's type, if applicable

This means that when changing a CanvasItem inherited Node to another one also inherited by it, the lock status (of itself or all of its children) will be preserved.

Cast change made.

Thanks!

Cherry-picked for 3.2.2.


feat: adding stateless CNI pipeline test

Reason for Change:
Adding a pipline test for stateless CNI to check the cns State and the datapath

[X] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[X] relevant PR labels added

Notes:

/azp run Azure Container Networking PR


Create getAccount endpoint of the audio module

Description
As a part of #14, we should implement an endpoint that retrieves the accounts stored in the AudioAccountSubstore created by #8.
Request

Parameter
Type
Validation
Default
Comment

address
string
Lisk 32 address validation
(empty)
-

Response
OK
{
  "audios": [/* List of AudioIDs in buffer */]
}

Not found
{
  "error": true,
  "message": "Account <address> not found."
}

Bad request
{
  "error": true,
  "message": "Parameter address is required."
}

Resolved by #24


Check our copyright statement

We currently reserve all copyright rights. Should we instead use a cc-by license?
This is what we currently state in the Kubeflow footer:
Copyright © 2018 Kubeflow.org. All Rights Reserved.
For comparison, this is what the Kubernetes site states:
© 2018 The Kubernetes Authors | Documentation Distributed under CC BY 4.0
Copyright © 2018 The Linux Foundation ®. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page

@ewilderj @abhi-g Do you have the history behind the copyright statement on the Kubeflow site, and do you think we should move to cc-by?

I really didn't put any deep thought into the copyright statement of the
website.
Please feel free to update as necessary and appropriate.
Regards
Abhishek
On Sun, Dec 16, 2018 at 7:58 PM Sarah Maddox<EMAIL_ADDRESS>wrote:

@ewilderj https://github.com/ewilderj @abhi-g
https://github.com/abhi-g Do you have the history behind the copyright
statement on the Kubeflow site, and do you think we should move to cc-by?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/website/issues/363#issuecomment-447715909,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALOqZiI3ucnc7_AoQEVryBv8qdh5GYwyks5u5xZ7gaJpZM4ZVo-b
.

I've checked with the Open Source Programs Office. We should have the following copyright notice on the Kubeflow docs:
Copyright 2018 The Kubeflow Authors | Documentation Distributed under CC BY 4.0

/close


Document if the classes are threadsafe.

Can a Parser or HtmlRenderer be used in a threaded environment - shared across threads?

Yes it can! It takes care to use new state for each parse/render call. Although I should probably add tests for that and document it properly.

Thanks, @robinst -- as suggested, please add a note about this in the README. Thanks!

Added tests and a section to the README now, thanks for raising this!


Add support for npm

This would be great. Adding a 'main' field to a package.json file and publishing on npm would be a big help so we can more easily use media-match with Browserify.

Feel free to reopen when the conflicts are resolved, if you feel this is still useful.


Prevent call to back() on empty std::string

Possible to hit this case if user discards any file selection.

Thanks for spotting this! I made an additional change because if for some reason the string is "/" it will still crash.


fix: check if argv has elements in array

I'm using this library in wordpress and $_SERVER['argv'] doesn't have any elements in array but the array exist, so when the code is checking if element [0] has something, the code will fail.

I've checked now, you already fixed this issue.


SAFE_USER_MIN as a parameter instead of hardcoded

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

40 of 45 (88.89%)  changed or added relevant lines in 10 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.2%) to 66.274%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core/src/oracle_config.rs
1
2
50.0%

core/src/cli_commands/bootstrap.rs
3
5
60.0%

core/src/cli_commands/prepare_update.rs
3
5
60.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
1969

Relevant Lines:
2971

💛  - Coveralls

Please, make Clippy happy. :)

Clippy is happy now. 😀


Clarifying the run_interval unit in config.yaml

Hi,
Thanks for making this. It's a really beautiful app.
I was trying to create a custom widget, but wasn't really able to determine what the units for run_interval are.
In the sample config.yaml, I see
        # run every hour
        run_interval: 6000000

but I wasn't sure what unit that could be.
Looking through the code, it appears we're using QTimer behind the scenes, and from what I could tell from their docs, it should be in milliseconds. In that case this comment would be wrong since it's 3600000 ms in an hour. I was thinking it might be a little bug.

Hey @TransientError, thanks for checking out the project.
You are correct in that the amount of milliseconds specified in the example config for the CustomWidget is incorrect, and should indeed be 3600000 milliseconds. This has just been changed in https://github.com/denBot/yasb/commit/0726bcab838f51dd0fff9a5e8f6c95880e5de141


Fix nested has many

(I have rebased this branch against the PR that bumps the version to 0.7.0)
In the current state of affairs, if we were to have factories building
nested has_many relationships the built models cannot be saved. When
creating a model with such a factory (like the shipment factory in
ecto_has_many_test.exs) a user would see the following error:
(see the changes in 0573f23 for the model & factory definitions)
** (ArgumentError) model ExMachina.EctoHasManyTest.Package has value `[%ExMachina.EctoHasManyTest.PackageStatus{__meta__: #Ecto.Schema.Metadata<:built>, id: nil, package: #Ecto.Association.NotLoaded<association :package is not loaded>, package_id: nil, status: "ordered"}, %ExMachina.EctoHasManyTest.PackageStatus{__meta__: #Ecto.Schema.Metadata<:built>, id: nil, package: #Ecto.Association.NotLoaded<association :package is not loaded>, package_id: nil, status: "sent"}, %ExMachina.EctoHasManyTest.PackageStatus{__meta__: #Ecto.Schema.Metadata<:built>, id: nil, package: #Ecto.Association.NotLoaded<association :package is not loaded>, package_id: nil, status: "shipped"}]` set for assoc named `statuses`. Assocs can only be manipulated via changesets, be it on insert, update or delete.

This PR fixes this issue by calling put_assoc_changes recursively in nested has_many relations.
(I would like to add more tests stressing more complex relationships if I get some more time before the review. I will probably send some commits in the next couple of days)

Hi @rranelli Thanks for this PR! I'll take a look more deeply this week. Does this also cover nested belongs_to? I think it would be a good idea to add a test case for those types of associations as well. What do you think?

nested belongs_to works just fine :)

Great! That is fantastic news. Could you add a test for nested belongs_to? If  you don't have time that is ok. LMK and I can tackle it when I have a chance

I have added a new commit with a test for the nested belongs_to.
I have noticed a somewhat unintuitive behavior I documented in the commit message (b22f4e8e).
We will probably need to address this issue in the future, but I think it does not block this PR though.

@rranelli Thank you for adding the test and documenting that behavior. I think that is ok for now. Once Ecto 2.0 comes out most of this code will be handled automatically by Ecto so it should be ok. See https://github.com/elixir-lang/ecto/issues/1102#issuecomment-166909384

Merged without the version update commits because I still need to add a changelog and clean those up a bit. Thanks for the pr @rranelli!


🚀 [Feature Request] - Theme

Is your feature request related to a problem ? Please describe. ✍
Enhancement
I would like to add theme icon which toggle dark and light theme for website.
Describe briefly how you would implement this enhancement.
Some steps to implement this enhancement-
1. Add theme icon at right top corner.
2. write css for dark theme.
3. write logic to toggle theme.

Additional context or screenshots
Additional context
Are you contributing for a program?
GSSoC2023
Code of Conduct

[X] I have read and agree to the Contributing Guidelines of this project.

Hey @BhartiNagpure ! someone's working on this. Checkout: #442


Merge latest master into dataflow branch

[...] The one new issue (exposed with the review changes) is the delete document button which does not function correctly. We can either knock that our here or wait and tackle it in another PR if it's heavier lifting.

I fixed this in app-config via a !isDeleted property, delete should now be working in Dataflow for Programs and Data.

Note, that we also need to determine what the right thing to do is if the user attempts to delete the last remaining document.  At present, it doesn't appear in the right nav, but it does still remain loaded.

... and deleting the last remaining document would also make it impossible to create more since the only UI is on the title bar of the document, so I think we just have to prevent deletion of the last document of a given type.


Is there a way to do scrollTo in BS?

Hi,
is there a way to do scrollTo little more automatic in Bootstrap?
I mean something like this:
<button class="scrollTo" data-scrollto="target_id">scrollTo</button>

Target

but without that js part. Only with using class="scrollTo" and data-scrollto="target_id" attributes. It would be fine to have it. Also it could work with anchors and add #fragment to window.location.
What do you think about it?

Thanks, but we'll pass for now.


RQ-3183: Make end-month parameter non-mandatory as in public API

What does this PR do?
In the public API, end_month is not mandatory for cbt endpoint.
This PR makes end-month parameter non-mandatory in the client as in the public API.
cf. https://github.com/DataDog/datadog-api-spec/pull/3154

Additional Notes

Review checklist
Please check relevant items below:

[ ] This PR includes all newly recorded cassettes for any modified tests.

[ ] This PR does not rely on API client schema changes.

[ ] The CI should be fully passing.

[ ] Or, this PR relies on API schema changes and this is a Draft PR to include tests for that new functionality.

Note: CI shouldn't be run on this Draft PR, as its expected to fail without the corresponding schema changes.

Should not commit to this auto-gen repo


bat: install man page

Motivation for this change
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[X] NixOS
[X] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[X] Fits CONTRIBUTING.md.

@GrahamcOfBorg build bat

Success on x86_64-darwin (full log)
Attempted: bat
Partial log (click to expand)

test result: ok. 23 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

installing
post-installation fixup
gzipping man pages under /nix/store/448al9dmirw7dg6rs3g9safpbqgl1jh5-bat-0.7.0/share/man/
strip is /nix/store/df6k4mgdjxciy0f637lryp7c9ln7n1m3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/448al9dmirw7dg6rs3g9safpbqgl1jh5-bat-0.7.0/bin
patching script interpreter paths in /nix/store/448al9dmirw7dg6rs3g9safpbqgl1jh5-bat-0.7.0
/nix/store/448al9dmirw7dg6rs3g9safpbqgl1jh5-bat-0.7.0

Success on x86_64-linux (full log)
Attempted: bat
Partial log (click to expand)
installing
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/j7lin9x7jcck33k7rg0xm6jbgpjga9mv-bat-0.7.0
shrinking /nix/store/j7lin9x7jcck33k7rg0xm6jbgpjga9mv-bat-0.7.0/bin/bat
gzipping man pages under /nix/store/j7lin9x7jcck33k7rg0xm6jbgpjga9mv-bat-0.7.0/share/man/
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/j7lin9x7jcck33k7rg0xm6jbgpjga9mv-bat-0.7.0/bin
patching script interpreter paths in /nix/store/j7lin9x7jcck33k7rg0xm6jbgpjga9mv-bat-0.7.0
checking for references to /build in /nix/store/j7lin9x7jcck33k7rg0xm6jbgpjga9mv-bat-0.7.0...
/nix/store/j7lin9x7jcck33k7rg0xm6jbgpjga9mv-bat-0.7.0


Could not download publickey

I just installed apt-cyg on a fresh installation of cygwin but now it cannot download the publickey.
But I can go to that url in my browser and it resolves
Log:
Cache directory is /setup
Mirror is http://ftp.jaist.ac.jp/pub/cygwin
/tmp/tmp.3qu9rodpCA: No such file or directory
TRUSTEDKEY_CYGWIN: FAILED: Could not download https://cygwin.com/key/pubring.asc.
Error: Could not download TRUSTEDKEY_CYGWIN.

https://cygwin.com/key/pubring.asc is alive.
Your log shows that wget could not open temporary file /tmp/tmp.3qu9rodpCA.
It should have failed at https://github.com/kou1okada/apt-cyg/blob/be081f2d5f6f25ab9e136bd766b4e20d6f6b6a6e/apt-cyg#L484.
Would you check and report your environment by the result of following commands, please?
ls -ld /tmp
which wget
ldd "$(which wget)"
wget --version
wget -O /tmp/tmp.3qu9rodpCA https://cygwin.com/key/pubring.asc
ls -l /tmp/tmp.3qu9rodpCA

Note that you should replace /tmp/tmp.3qu9rodpCA to the temporary file which reported on the log.

Thanks for those steps.
The problem was that wget was from windows in my path.
After installing it from cygwin it works.


Integration with Spring Boot and Micrometer

I'm trying to see the metrics from a Spring boot application on grafana but I'm not able to see any metrics.
I started my spring application on intellij, and everything is working fine. If I go to http://localhost:8303/actuator/prometheus I can  see that the metrics are available.

I changed docker-compose.yml to make it super simple
version: '2.1'

networks:
  monitor-net:
    driver: bridge

volumes:
    prometheus_data: {}
    grafana_data: {}

services:

  prometheus:
    image: prom/prometheus:v2.7.1
    container_name: prometheus
    volumes:
      - ./prometheus/:/etc/prometheus/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'
      - '--storage.tsdb.retention.time=200h'
      - '--web.enable-lifecycle'
    restart: unless-stopped
    expose:
      - 9090
    networks:
      - monitor-net
    labels:
      org.label-schema.group: "monitoring"

  grafana:
    image: grafana/grafana:5.4.3
    container_name: grafana
    volumes:
#      - grafana_data:/var/lib/grafana
      - ./grafana/datasources:/etc/grafana/datasources
      - ./grafana/dashboards:/etc/grafana/dashboards
      - ./grafana/setup.sh:/setup.sh
    entrypoint: /setup.sh
    environment:
      - GF_SECURITY_ADMIN_USER=${ADMIN_USER:-admin}
      - GF_SECURITY_ADMIN_PASSWORD=${ADMIN_PASSWORD:-admin}
      - GF_USERS_ALLOW_SIGN_UP=false
    restart: unless-stopped
    expose:
      - 3000
    networks:
      - monitor-net
    labels:
      org.label-schema.group: "monitoring"

  caddy:
    image: stefanprodan/caddy
    container_name: caddy
    ports:
      - "3000:3000"
      - "9090:9090"
    volumes:
      - ./caddy/:/etc/caddy/
    environment:
      - ADMIN_USER=${ADMIN_USER:-admin}
      - ADMIN_PASSWORD=${ADMIN_PASSWORD:-admin}
    restart: unless-stopped
    networks:
      - monitor-net
    labels:
      org.label-schema.group: "monitoring"

I also changed prometheus.yml
global:
  scrape_interval:     15s
  evaluation_interval: 15s

  # Attach these labels to any time series or alerts when communicating with
  # external systems (federation, remote storage, Alertmanager).
  external_labels:
      monitor: 'docker-host-alpha'

# A scrape configuration containing exactly one endpoint to scrape.
scrape_configs:

  - job_name: 'spring-boot'
    scrape_interval: 10s
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['localhost:8303']

  - job_name: 'prometheus'
    scrape_interval: 5s
    static_configs:
    - targets: ['localhost:9090']

I start the container using ADMIN_USER=admin ADMIN_PASSWORD=admin docker-compose up -d and everything works fine.
When I chose the dashboard  Monitor Services I can see prometheus data,  but when I download the Micrometer dashboard  everything is empty.
When I go http://localhost:9090/grap/ I can find the prometheus metrics, but the micrometer metrics are not there.
What am I missing? Do I need to change the Data Source on Grafana?

Found the problem.
Instead of  - targets: ['localhost:8303'] should be  - targets: ['HOSTED-IP:8303']


error: Can't find variable: list    what is the value of  l   in the example ?   provided here  :   https://goo.gl/ohiWps

render () {
  const MenuComponent = (
    <View style={{flex: 1, backgroundColor: '#ededed', paddingTop: 50}}>
      <List containerStyle={{marginBottom: 20}}>
      {
        list.map((l, i) => (
          <ListItem
            roundAvatar
            onPress={() => console.log('Pressed')}
            avatar={l.avatar_url}
            key={i}
            title={l.name}
            subtitle={l.subtitle}
          />
        ))

Hi @jpca999!
I'm not sure if I see how this issue is related to react-native-side-menu. I'd rather recommend you to ask this question on Stack Overflow.


How to generate SSDT-CPU

Hello,
You state that you can create your SSDT-CPU with the following steps...

Use CPUFriendFriend with desired LFM and EPP profiles which generates a modified plist for my Mac model

Use the plist from step 1 to generate ssdt_data with ResourceConverter script in CPUFriend.

Then merge the resultant ssdt_data from Step 2 with CPU-PLUG which is renamed to SSDT-CPU

However, I noticed the following...

CPUFriendFriend directly generates ssdt_data without going through step 2.

When I decompiled your SSDT-CPU, I  see that it has content generated with Piker-Alpha’s ssdtPrGen. Did you mean to merge ssdt_data from CPUFriendFriend (or the ResourceConverter script) with the SSDT generated from Piker-Alpha’s ssdtPrGen? But then I read at many places  that Piker-Alpha’s ssdtPrGen is not needed or obsolete these days. Can you please explain your usage.

Other questions...

The template SSDT-PLUG is for only CPU0, what is the right thing to do for other processor cores?

Thanks in advance.

Hi, as I was saying on Insanelymac's forum, these days I'm trying different stuff to see what does what.  In addition, I'm relatively young to the Hackintosh word; I started only half a year ago, so please, don't assume that what I do is the best way to go.
However, I'm pleased by the response of the community that my work has generated and I'm happy to receive feedback by all of you.
Now speaking about the issue, first thing first, running CPUFrindFriend' script in my case results only in a plist. I did not inspected the script itself since I'm pretty sure it's well crafted by Corpnewt.
I previously tried plain CPU-PLUG with CPUFriend.kext and CPUFirendDataProvider.kext, the I switched to Piker-Alpha’s SSDT with data from ssdt-data.
Haven't really noticed any differences and don't know how to test the result of this work (let me know if you do, I would be happy to benchmark everything).
All I can say is that I'm using the laptop for about 6 hrs/day and it is very reliable and snappy in any task.
Concerning the last question, in OpenCore, you only want to connect the first thread of the CPU.
Take a look here https://khronokernel.github.io/Getting-Started-With-ACPI/Universal/plug.html


installing cutorch with a cuda lib in a non standard directory

Using luarocks install cutorch, I'm trying to install cutorch with cuda 7.0 .
My system has a global installation of cuda 6.5 in /usr/local, however I have cuda 7.0 installed in a non standard library, that I'd like to be used with cutorch. I can't get rid of the global installation.
Changing the LD_LIBRARY_PATH variable to include the non standard library before using luarocks is not enough, it still finds the old 6.5 version.
The issue might be with cmake, but I'm not sure.
Any help would be great.

had to change cuda_bin_path to point to the directory with the desired cuda installation.


Fix non-mac build

ahhh, yes this has been a problem for me in the past too. thank you! We should also get CI going for linux too at some point.


[Hanabi] Watching the game as a guest is confusing

I am every player. Very confusing.
This is giving me multiple personality disorder.

This can be fixed by modifying the view section of HanabiGame.kt and/or the template section of Hanabi.vue
One way might be to simply change the text "You" for observers to "Current Player"? But then the client needs to know that you are just an observer, which it can be told but is currently not available within the Hanabi component. For players it uses view.hand.index which it receives from the server and can therefore display the proper hand.

Opinions about how to fix this wanted.

How about allowing the observer to choose from which perspective to watch? The same principle could also be applied to watching replays, and to playing games in local mode.

I think making a display mode with an omnipotent view is nice. I.e, all players are displayed side by side on the same row (no active player).

@GustaMagik So simply removing the bottom panel then? Should be quite easy to accomplish :)


Here it is.

@ekg @travc

This is epic!

I'm also going to start on testing after we resolve the merge.

I need to merge this with https://github.com/ekg/vcflib/pull/116

I'm thinking it may be easier to pull this one in and then manually fix up vs #116.


Treesitter is unable to parse .jsx files after seing a jsx block in markdown

Describe the bug
After opening a markdown buffer with .jsx codeblocks, Treesitter can't parse new .jsx buffers anymore.
STR:

Have javscript, markdown and markdown_inline TS Parsers installed in Neovim
create file test.jsx

export const abc = () => {
    return
hello
;
};

create file test.md, look at code example below (without the _)
nvim test.md
:e test.jsx, see that jsx is not getting parsed by treesitter

Code example
This is a fun component description:

```jsx
import { Form } from 'somewhere';

<Form>
	{123}
</Form>
``_`
Ignore the `_` above

Expected behavior
Highlight the code snippet as jsx codes
Actual behavior
No highlighting is applied, even worse, Treesitter does not parse .jsx files from now on anymore.
Infos
I found this here: https://github.com/nvim-treesitter/nvim-treesitter/issues/4918
Removing markdown and markdown_inline TS Parsers fixes this issue, so I came here :)

I don't use neovim any more so I don't have it set up to test this. But this seems to work fine in other editors, so I would guess it's a problem of nvim-treesitter.

Removing markdown and markdown_inline TS Parsers fixes this issue

You're saying standalone .jsx files are not parsed correctly when a markdown jsx code block is active in another file, but they are parsed correctly when the markdown parser is not installed?
(Btw you can have nested code blocks in markdown by giving the outer code block more `s: like this
````markdown
Text in outer code block
```jsx
// Comment in inner code block
```
````

)

You're saying standalone .jsx files are not parsed correctly when a markdown jsx code block is active in another file, but they are parsed correctly when the markdown parser is not installed?

Exactly. When uninstalling the markdown parser, there is no problem when opening jsx files while having open markdown buffers.
Thanks for investigating. I realized that jsx blocks in markdown are not correctly recognized/parsed yet, may this be the issue?

I think there's some kind of support for that in nvim-treesitter. Best you ask there

Removing markdown and markdown_inline TS Parsers fixes this issue

Can confirm the same. Uninstalling them works and I no longer get that error.

It's a Neovim issue. I have one merged (https://github.com/neovim/neovim/pull/25151) and one open (https://github.com/neovim/neovim/pull/25143) PR to resolve it.
This can be closed


Update Node to 20 and deps with it

Node should be updated directly to version 22, which is the latest LTS (released this week).

Is there anything blocking from updating directly to node 22 that will become active LTS later this year?

Is there anything blocking from updating directly to node 22 that will become active LTS later this year?

@thebrownfox Not really. We can do that. I just wanted to do it in smaller steps 18->20 with all deps and then 20->22. To solve issues on the way.


Compressed .PNG image files

Hi friends 👋 !
I executed an image compression algorithm over your repo -- using pngquant, recursively optimizing PNG image file sizes. We went from 25.7 MB to 10.1 MB for the 620+ image files in this PR, here are the totals:

Before
After

25.7 MB (26,975,632 bytes)
10.1 MB (10,683,835 bytes)

Saving a total of 16,291,797 bytes (16.3 MB), 2.5x smaller /cc @scottaddie

Thank you for helping out with this, @IEvangelist!

Can you revert this ? It's causing lots of errors. See https://opbuildstorageprod.blob.core.windows.net/report/2020\12\17\332f35cd-658d-4914-0f85-907e40ee89f0\PullRequest\202012170128273371-20971\workflow_report.html?sv=2016-05-31&sr=b&sig=v1c4lWUE%2Bx1jxAHfnYDpYTRzKeAgCcuSvY6WYOMTMzg%3D&st=2020-12-17T01%3A24%3A44Z&se=2021-01-17T01%3A29%3A44Z&sp=r
cc @guardrex

@IEvangelist  @scottaddie  @guardrex   Got a  million errors on png, closed PR rebuilt and errors went away.

I was not worried about this PR, it has been in place for over a year now - and hasn't been an issue. Why would it all of a sudden cause problems? Happy you were able to figure it out.

@Rick-Anderson The related messages in the build report pertain to invalid file links and missing alt text. As far as I can tell, the image compression has been working quite well.

I was able to compress images other than .png in my own website portfolio using Calibre Actions and when I look at the images and screenshots heading in the contribution guidelines.
I notice newcomers are told to use their own image compression tools.
What if I automate the process by implementing a GitHub Action so .jpg, .jpeg and .webp image formats are automatically compressed upon a PR with a new image?
Not trying to say we should scrap the originally approved changes here or anything. Just that we automate the process of compressing other image formats.
Also if you accept that, I was wondering if in the guidelines I could then just change this:
As an optional step, ensure that any images and screenshots used in the documentation are compressed, which helps with file size and page load performance. A few popular tools include TinyPNG (using the TinyPNG website or the TinyPNG API) or the Image Optimiser Visual Studio extension.

To this.
Our site automatically compresses images and screenshots used in the documentation, so any compression on your part is unnecessary. A few popular tools that were used before we automated the process include TinyPNG (using the TinyPNG website or the TinyPNG API) or the Image Optimiser Visual Studio extension.

Just to make contributions easier for others, especially first-timers. No point in doing more compressions if it's done automatically.

I don't think it's worth the effort. It's so rare that folks contribute images.


wrong intent recognition

[Rules]
name = EMMA
radio_station = (SMOOTH JAZZ:RMF_SMOOTH_JAZZ| JAZZ:RMF_SMOOTH_JAZZ)
[SWITCH_TO_RADIO]
<Rules.name>  (PRZEŁĄCZ){item:RADIO_STATION} NA <Rules.radio_station>{value} PROSZĘ
Sentance:
EMMA PRZEŁĄCZ NA SMOOTH JAZZ PROSZĘ
Should give  "entity": "value", "value": "RMF_SMOOTH_JAZZ"
it is giving: "entity": "value", "value": "SMOOTH RMF_SMOOTH_JAZZ"

you are replacing SMOOTH JAZZ as well as JAZZ with RMF_SMOOTH_JAZZ in the rules definition.
try:
[Rules]
name = EMMA
radio_station = ((SMOOTH JAZZ):(SMOOTH RMF_SMOOTH_JAZZ)|(JAZZ):(RMF_SMOOTH_JAZZ))


Blazor.Net Docs link point to Server Side Razor Components

Describe the bug
The docs link from https://blaor.net points to service side razor components doc. It should be pointing to client side razor components aka blazor standalone.
To Reproduce
Steps to reproduce the behavior:

Head over to https://blazor.net
click on Docs link from the menu bar
Notice the link navigated to. It is https://docs.microsoft.com/en-us/aspnet/core/razor-components/?view=aspnetcore-3.0

Expected behavior
Docs link from https://blazor.net should point to client side razor components development docs link.
Screenshots

Additional context
I see that the server side razor components & client side razor components overview point to a single overview page. Looks like a reused page. But if i land from blazor.net i expect to be in client side blazor development. thoughts ?
Feel free to dismiss this issue. I felt a confusion and wanted to check with you folks as to what you think.

Thanks for contacting us, @lohithgn. We're closing this issue as a dupe of https://github.com/aspnet/Docs/issues/10825


EDA on laptop_data.csv

I performed EDA on laptop_data.csv and used 3 different algorithms to predict the price of the laptops and recorded their accuracy score.

Good work @himanshus110 .. Just remove the checkpoints and make a pull request again

Okay


undo https://github.com/Alogani/NimGo/issues/4 please

Explicit logic for timeouts is both cheaper at runtime and easier to understand than these academic "timeout tasks" that in the end don't work because nobody thought about it anymore.

True.
My intention was to have more flexibility, but that is probably a corner case at a high cost. I will revert to timeoutMs: int and add a resumeAfter(task: GoTaskUntyped) for those scarce corner cases of complex cancellation.
Thanks !

Awesome. Now you only need to change proc readlikeProc(): string to proc readlikeProc(buffer: var string) # reuse memory in order to save the expensive copies and allocations and you're onto something.

I thought Nim was smart enough to avoid copies for proc read(): string ?
I have done small mini banchmarks, it doesn't show significant impact. But I can add it no problem

If avoids the copies but it cannot reuse memory. Strings still get allocated.

Technically completed with last release, but I keep it open, because the way I check if timeout woke up happened has some issues.


mysteam.lang.php does not exist

I know its there, I checked the file and re-uploaded it and i still get this errror.

You need to put mysteam.lang.php to both directories:
inc/languages/xxx/
and
inc/languages/xxx/admin/
For "xxx" is the language that you are using on site, english, polish, french etc...


"Cărbunești", "Gogeasca" are listed in the drop-down menu

Description:
When user writes ""Cărbunești" and "Gogeasca" the locations appear in the drop-down menu next to the comune and the county witch is a part according to the law
Precondition:
The website is up an running.

Step 1
Write in the search bar "Cărbunești"
Expected results
The location appears in the drop-down menu as "Sat Cărbunești, PRAHOVA (Cărbunești)"

Step 3
Write in the search bar "Gogeasca"
Expected results
The location appears in the drop-down menu as "Sat Gogeasca, PRAHOVA (Cărbunești)"


SwaggerDocument.FromUrlAsync(url)  waits lots of time to return an error

SwaggerDocument.FromUrlAsync(url).Result
if the url is not correct, or the server is down. It will cost lots of time to wait.
Is there anything I can do, so I can break it in shorter time?

We need to expose the timeout as parameter/setting


CIP-42? | New Plutus Core built-in dataHash

Replaces #218
Rendered

Do note https://github.com/cardano-foundation/CIPs/pull/218#discussion_r803682900

The Plutus team decided to adopt #218 as a new built-in, making this proposal now redundant.
For the sake of keeping a track record, we may still want to merge this proposal as rejected.

The primary reason for adopting https://github.com/cardano-foundation/CIPs/pull/218 over this was the argument from increased composability.

What should I change concretely? status to rejected?


feat: Add get-full-pricing endpoint

Adds the get-full-pricing endpoint from the Pricing API. Also uses the master API key as the default for secret management methods in AccountClient.

Codecov Report

Merging #481 (8c9d2e2) into main (aa56274) will increase coverage by 0.09%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##               main     #481      +/-   ##
============================================
+ Coverage     93.64%   93.74%   +0.09%
- Complexity     2784     2796      +12
============================================
  Files           422      423       +1
  Lines          7164     7175      +11
  Branches        460      460
============================================
+ Hits           6709     6726      +17
+ Misses          257      252       -5
+ Partials        198      197       -1

Files
Coverage Δ

src/main/java/com/vonage/client/HttpWrapper.java
100.00% <ø> (ø)

.../java/com/vonage/client/account/AccountClient.java
98.24% <100.00%> (+0.32%)
:arrow_up:

...com/vonage/client/account/FullPricingResponse.java
100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes


Create flipkart-scraper

created flipkart scrapper
Related Issue
#212
Description
code to scrap Flipkart
Type of PR
Feature enhancement

No we are not focusing on that part.


Model the packing of order bags and order boxes

Given A distribution of 25% of Rush/Same day orders and 75% next day/national orders
When packing a Rush/Same day order
Then The system accounts for a faster packing time to retrieve the order bag and pack the order
Given A distribution of 25% of Rush/Same day orders and 75% next day and national orders
When packing a next day/national order
Then The system accounts for a slower packing time to retrieve the order box and pack the order

See this link for a method to generate a random pick from a binomial distribution with uneven probabilities.

Implemented with #20


fix torch tensor shape output

Hmmm... can't reproduce. This section was also changed earlier, so maybe that fixed it.


fix: log instead of throw when definition validation fails

What issue does this pull request resolve?
https://github.com/epoberezkin/ajv/issues/941
What changes did you make?
When definition validation fails in keyword.js, log the error instead of throwing it so that it doesn't break dependent packages that were passing invalid definitions to it, but still notifies users in some manner.
As this is a breaking change, I believe the throwing should be coupled with a major version bump, rather than a minor one.
Is there anything that requires more attention while reviewing?
I am not sure if there may be other ways in which the latest changes could be breaking dependent packages, but this is the part that surfaced.
To make the tests pass again, I stubbed the error logger to throw so that this change can be rolled out again with a major version bump with minimal effort to fix the tests.

It actually was throwing before, it just was a bit less restrictive... I've released the fix - let's see if there is anybody still affected.

Alright, I'll close this then :)


Fix: Update NodeScopeResolver Constructor Call to Match Latest PHPStan Version

Problem
The code was encountering an error due to a mismatch in the number of arguments passed to the NodeScopeResolver::__construct() method. The latest version of PHPStan expects 24 arguments, but only 23 were provided, leading to a failure when running type coverage checks.
Solution
This PR updates the constructor call for NodeScopeResolver in the PHPStanAnalyser::make method to include the additional parameter required by the latest PHPStan version. The new parameter has been added with a default value (set to false), aligning with the latest method signature.

It seems that it is now 28, and not 24
php artisan test --type-coverage

   ArgumentCountError

  Too few arguments to function PHPStan\Analyser\NodeScopeResolver::__construct(), 27 passed in /Users/tray2/Herd/RecordCollector/vendor/pestphp/pest-plugin-type-coverage/src/PHPStanAnalyser.php on line 54 and exactly 28 expected

  at phar://vendor/phpstan/phpstan/phpstan.phar/src/Analyser/NodeScopeResolver.php:371
    367▕      * @param string[][] $earlyTerminatingMethodCalls className(string) => methods(string[])
    368▕      * @param array<int, string> $earlyTerminatingFunctionCalls
    369▕      * @param string[] $universalObjectCratesClasses
    370▕      */
  ➜ 371▕     public function __construct(ReflectionProvider $reflectionProvider, InitializerExprTypeResolver $initializerExprTypeResolver, Reflector $reflector, ClassReflectionExtensionRegistryProvider $classReflectionExtensionRegistryProvider, ParameterOutTypeExtensionProvider $parameterOutTypeExtensionProvider, Parser $parser, FileTypeMapper $fileTypeMapper, StubPhpDocProvider $stubPhpDocProvider, PhpVersion $phpVersion, SignatureMapProvider $signatureMapProvider, PhpDocInheritanceResolver $phpDocInheritanceResolver, FileHelper $fileHelper, \PHPStan\Analyser\TypeSpecifier $typeSpecifier, DynamicThrowTypeExtensionProvider $dynamicThrowTypeExtensionProvider, ReadWritePropertiesExtensionProvider $readWritePropertiesExtensionProvider, ParameterClosureTypeExtensionProvider $parameterClosureTypeExtensionProvider, \PHPStan\Analyser\ScopeFactory $scopeFactory, bool $polluteScopeWithLoopInitialAssignments, bool $polluteScopeWithAlwaysIterableForeach, array $earlyTerminatingMethodCalls, array $earlyTerminatingFunctionCalls, array $universalObjectCratesClasses, bool $implicitThrows, bool $treatPhpDocTypesAsCertain, bool $detectDeadTypeInMultiCatch, bool $paramOutType, bool $preciseMissingReturn, bool $explicitThrow)
    372▕     {
    373▕         $this->reflectionProvider = $reflectionProvider;
    374▕         $this->initializerExprTypeResolver = $initializerExprTypeResolver;
    375▕         $this->reflector = $reflector;


New service connection object with cert is used

Description
As part of Security Wave1 changes, we are eliminating service principals that are using passwords. I have created a new service connection object that connects to resources in subscription using cert.
Related issues
Addresses [issue #].
Testing
PR and CI pipelines
FHIR Team Checklist

Update the title of the PR to be succinct and less than 65 characters
Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
[ ] CI is green before merge
Review squash-merge requirements

Semver Change (docs)
Patch|Skip|Feature|Breaking (reason)

/azp run

/azp run

/azp run


Compile error

I added the library by NuGet but I get compilation errors.

@opcodewriter do you use it with Xamarin.Forms or with Xamarin.Droid?

@opcodewriter thanks!
Should be fixed in 0.5.4.


Add a Gitter chat badge to README.md

envato/iodized now has a Chat Room on Gitter
@madlep has just created a chat room. You can visit it here: https://gitter.im/envato/iodized.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

will add manually


Fix customization type of padded-modeline.

About doom-themes-padded-modeline and other padded-modeline suffixed customizable variables, I think :type '(or integer boolean) should be :type '(choice integer boolean).
Elisp manual: https://www.gnu.org/software/emacs/manual/html_node/elisp/Composite-Types.html#Composite-Types

Good catch! Thanks for the help!


fullscreen / captions size /Android 6

in css styles, you set captions size to 32px in fullscreen display
.plyr--fullscreen-active .plyr__captions{font-size:32px}
Rendering is awfull on android 6

Glad you like the plugin. Thanks 👍
I'll take a look at the "awful" rendering. Have you heard of a pull request? This is open source, feel free to contribute.


Update docs with LF processes

This PR updates our docs to discuss the new process for accepting commits under the Linux foundation.

Hi,
is there an ETA when this may be merged?