Fix LOCK, XACQUIRE, XRELEASE instruction prefix for x86

Edit3: This PR should be ready for merging/internal edits and testing.
Edit2: This PR is mostly complete with respect to decoding. See this comment for latest update
Edit: This PR now also includes changes for XACQUIRE and XRELEASE prefixes because they are closely related to the LOCK prefix. (See here for details on that implementation https://github.com/NationalSecurityAgency/ghidra/pull/4336#issuecomment-1157664283)
I am looking for feedback (and suggestions for bugfixes) on the current implementation before fixing any other instructions and submitting for a real PR.

Summary:
This commit is a proof-of-concept (POC) implementation to fix how sleigh
interprets the LOCK prefix on x86 architecture. Previously, the sleigh
specification interpreted LOCK as a standalone instruction; however,
that is wrong. The following is a description of a possible
implementation to fix this. This implementation only fixes the INC and
XADD instructions to demonstrate and hopefully determine whether this
implementation is on the right track or if a better implementation
exists that we can use.
The "LOCK" disassembly text appears after the mnemonic, which is
similar to the REP prefixes. I do not know if making "LOCK" appear
before a mnemonic like LOCK INC dword ptr[EAX] is possible or even
preferable.
The Intel manual states the following for the LOCK prefix:

The LOCK prefix can be prepended only to the following instructions
and only to those forms of the instructions where the destination
operand is a memory operand: ADD, ADC, AND, BTC, BTR, BTS, CMPXCHG,
CMPXCH8B, CMPXCHG16B, DEC, INC, NEG, NOT, OR, SBB, SUB, XOR, XADD, and
XCHG. If the LOCK prefix is used with one of these instructions and
the source operand is a memory operand, an undefined opcode exception
(#UD) may be generated. An undefined opcode exception will also be
generated if the LOCK prefix is used with any instruction not in the
above list. The XCHG instruction always asserts the LOCK# signal
regardless of the presence or absence of the LOCK prefix

Implementation:
Add lockprefx to contextreg to track the appearance of the prefix
and identify the LOCK prefix bit pattern during instruction decoding.
It can appear in any order along with the other prefixes. I increased
the size of the context register because I do not understand the
interaction of the existing fields, and it looks like there are no more
free bits. I do not know whether increasing the context register size
from 4 to 8 has any adverse or unforeseen effects elsewhere.
Explanation, suggestions, or confirmation about this change would be
greatly appreciated!
Use the with statement to protect against invalid LOCK prefixes on
all instructions that cannot use the LOCK prefix. Instructions that
can take the LOCK prefix (only INC and XADD in this POC) should
close the with statement (closing } bracket) and handle the LOCK
variants explicitly. The with statement is also added in the top-level
'*.slaspec' files to surround the @include files for other
instructions not in ia.sinc and prevent incorrect disassembly. I
discovered this technique by noticing a similar structure in the
68000.sinc file with extGUARD.
Handle INC and XADD with LOCK prefix decoding only with a memory
destination operand. I struggled a bit with this, but I think what I've
done is okay? I had trouble getting anything else to compile and
function correctly. Still, I attempted to split out the memory and
register destination operands to only apply LOCK to the memory
destination operands. Suggestions on whether a better alternative
implementation exists are appreciated!
... admittedly, I only tested the disassembly result and did not inspect
the generated pcode with the LOCK prefix. I'm hoping I correctly
understood how the pcode is built and that everything lines up
correctly. The LOCK() pcodeop should be first for each instruction
followed by the normal semantics.

Addresses the bug report about LOCK in https://github.com/NationalSecurityAgency/ghidra/issues/2033

The instruction bytes I've tested are the following. S_SUCCESS means Ghidra should correctly decode to the following disassembly text and S_FAILURE means Ghidra was correctly unable to disassemble the bytes.

I've also been looking into the XACQUIRE and XRELEASE prefixes, which are related to LOCK. They require new pcodeops and context register fields.
I am working on that implementation, which will look similar to this, and will make a new commit to this branch when ready.
Again, I'm only going to make the fix for a few instructions until I learn that this implementation is on the right track or I should be doing something different.

After applying there are only BAD-Instruction on previously analyzed binaries. On the other side binaries analyzed with applied patch have problems if opened without patch. Is there a way to fix that?

@jobermayr You would want to increment the minor version number in the ldefs file for the language. This definitely requires an upgrade. I think major version updates are mostly only needed if register definitions are moved around (this PR adds to the context register but doesn't move anything).

I've pushed a commit for how I think XACQUIRE and XRELEASE prefix
should be handled, but in my first attempt, I cannot figure out how to
disassemble XCHG correctly for all of the cases. From my commit
message, copied here:
XACQUIRE and XRELEASE are related to the LOCK instructions so this proof
of concept fix attempts to reuse the LOCK prefix logic to combine the
checks.
I need help with one thing that I could not figure out:
For XCHG, you are allowed to have an XACQUIRE or XRELEASE prefix without
LOCK, and I thought that by listing both prefix constructors that sleigh
would choose those constructors when also faced with a memory operand
(where the prefixes are valid only), but this did not work and I had to
explicitly state that all three XACQUIRE, XRELEASE, and LOCK prefixes
were zero even though both XACQUIRE and XRELEASE constructors handle
that case. However, this is wrong because the byte for XACQUIRE and
XRELEASE is still valid when there is no memory destination, but
removing this breaks disassembly for the memory destinations. The
following are my expectations of disassembly for x86-64:
  * "87d9"       - "XCHG ECX,EBX"
  * "f287d9"     - "XCHG ECX,EBX" # Current implementation fails
  * "f387d9"     - "XCHG ECX,EBX" # Current implementation fails
  * "f087d9"     - ""
  * "f2f087d9"   - ""
  * "f0f287d9"   - ""
  * "f2f387d9"   - "XCHG ECX,EBX" # Current implementation fails
  * "8719"       - "XCHG dword ptr [RCX],EBX"
  * "f08719"     - "XCHG.LOCK dword ptr [RCX],EBX"
  * "f28719"     - "XCHG.XACQUIRE dword ptr [RCX],EBX"
  * "f38719"     - "XCHG.XRELEASE dword ptr [RCX],EBX"
  * "f0f28719"   - "XCHG.XACQUIRE.LOCK dword ptr [RCX],EBX"
  * "f2f08719"   - "XCHG.XACQUIRE.LOCK dword ptr [RCX],EBX"
  * "f3f08719"   - "XCHG.XRELEASE.LOCK dword ptr [RCX],EBX"
  * "f3f2f08719" - "XCHG.XACQUIRE.LOCK dword ptr [RCX],EBX"
  * "f2f3f08719" - "XCHG.XRELEASE.LOCK dword ptr [RCX],EBX"

Is this MR also intended to fix
Bytes:          Meaning:                            Ghidra (also patched):
f0 48 0f b1 11  lock cmpxchg QWORD PTR [rcx],rdx    ??; CMPXCHG qword ptr [RCX],RDX
f0 0f b1 0a     lock cmpxchg DWORD PTR [rdx],ecx    ??; CMPXCHG dword ptr [RDX],ECX
f0 01 01        lock add DWORD PTR [rcx],eax        ??; ADD dword ptr [RCX],EAX
f0 01 08        lock add DWORD PTR [rax],ecx        ??; ADD dword ptr [RAX],ECX

These latest commits should allow Ghidra to correctly disassemble the set of instructions that are LOCK-compatible.
I also just realized I missed a special case for XRELEASE only:

The XRELEASE prefix hint can only be used with the following instructions (also referred to as XRELEASE-enabled when used with the XRELEASE prefix):

The “MOV mem, reg” (Opcode 88H/89H) and “MOV mem, imm” (Opcode C6H/C7H) instructions. In these cases, the XRELEASE is recognized without the presence of the LOCK prefix.

While fixing the rest of the instructions and re-reading the ISA docs, I think a correct pcode implementation would include an opening LOCK(); at the beginning and closing UNLOCK(); at the end of the instruction's pcode.
More commits will come soon to fix the above two issues.

OK, I've (finally) had a chance to look this over, think about it a bit, and discuss it internally.  Using the with statement to protect against invalid disassembly is probably the best way to go here.
One suggestion is to pull all of the lockable instructions out of ia.sinc into a separate file.
Unfortunately, there are a number of related issues in the existing sleigh that should be fixed, particularly when adding support for the XACQUIRE and XRELEASE prefixes.  Ideally, we would be able to use the existing context fields for the f2 and f3 prefixes.  As far as I can tell, the manual only specifies the "last one wins" rule for which prefix applies when there are multiple f2,f3 prefixes in the cases where f2 and f3 are interpreted as XACQUIRE and XRELEASE.  Experimentally, it seems to be the case that this rule holds for those prefixes in general (i.e., for the REPE and REPNE cases as well).  It makes me sad to resolve undefined behavior by looking at one example, so there should probably be some more investigation, but it seems like the conditions in ia.sinc that prevent disassembly when both prefixes occur can be relaxed.
There are a number of variants of lockable instructions with the byte=0x80 | byte=0x82 constraint.  The byte=0x82 condition is not valid for 64-bit code.
There's a substantial amount of overlap between x86.slaspec and x86-64.slaspec.  Most of the content could be moved to x86.slaspec, which x86-64.slaspec could then include.
I'm not suggesting that you would need to do all of this for the PR to be accepted; just a heads up that other changes are needed in related code and some amount of coordination is probably needed.  I guess you have several options (in no particular order):

We take the PR (after the lockable instructions are moved to a separate file) but will add to it (and do more testing) before merging.  We'll keep the initial commit so you get credit.
You could forge ahead with XACQUIRE and XRELEASE, taking the above comments into account.
Finally, I suppose you could decide that you never wanted to step in this mess and just convert the PR to an issue report.

Thank you for the comments and suggestions @ghidracadabra!

Using the with statement to protect against invalid disassembly is probably the best way to go here.

👍

One suggestion is to pull all of the lockable instructions out of ia.sinc into a separate file.

Good call. Just to confirm, you only want the lockable versions of the instructions in a separate file? For example, using BTS as a small case:
# ia.sinc
@ifdef IA64
:BTS Rmr64,Reg64 ...
@endif
:BTS Reg16,imm8  ...
:BTS Reg32,imm8  ...
@ifdef IA64
:BTS Reg64,imm8  ...
@endif

# lockable.sinc
@ifdef IA64
:BTS^lockx Mem,Reg64 ...
@endif
:BTS^lockx m16,imm8  ...
:BTS^lockx m32,imm8  ...
@ifdef IA64
:BTS^lockx m64,imm8  ...
@endif

And I would move the with : lockprefx=0 { statement in the *.slaspec files to include ia.sinc and exclude the new lockable.sinc.

Unfortunately, there are a number of related issues in the existing sleigh that should be fixed, particularly when adding support for the XACQUIRE and XRELEASE prefixes. Ideally, we would be able to use the existing context fields for the f2 and f3 prefixes. As far as I can tell, the manual only specifies the "last one wins" rule for which prefix applies when there are multiple f2,f3 prefixes in the cases where f2 and f3 are interpreted as XACQUIRE and XRELEASE. Experimentally, it seems to be the case that this rule holds for those prefixes in general (i.e., for the REPE and REPNE cases as well). It makes me sad to resolve undefined behavior by looking at one example, so there should probably be some more investigation, but it seems like the conditions in ia.sinc that prevent disassembly when both prefixes occur can be relaxed.

Yeah, I searched the manual just now and couldn't find a reference for the "last one wins" rule applying to REPE and REPNE cases, but it probably makes sense that it follows the same rule. I can also take a look at this.

There are a number of variants of lockable instructions with the byte=0x80 | byte=0x82 constraint. The byte=0x82 condition is not valid for 64-bit code.

I think I'm missing something. Is this a bug in the existing pcode (in master branch) or a bug I introduced in this PR? From what I understand, the LOCK prefix is valid for 32-bit code as well.

There's a substantial amount of overlap between x86.slaspec and x86-64.slaspec. Most of the content could be moved to x86.slaspec, which x86-64.slaspec could then include.

Sounds good. This should probably be a single, separate commit.

As for what I will do next, I can rebase this PR to be a bit more organized with good commit messages, taking into account the suggestions (and clarification answers) above.
I think it's a good idea to continue with completion of the XACQUIRE and XRELEASE prefixes because they are pretty closely tied to LOCK and there isn't too much left.
I can notify you when I'm done with that, and you can do some internal testing of the PR and modify it as you see fit (option 1).
Thanks again!

I think that just having the lockable versions in the separate sinc file is the way to go.  I would put comments in ia.sinc for each instruction stating where the lockable variants can be found (so one comment for ADD, one for ADC, etc).
The byte=0x80 | byte=0x82 is a bug in the master branch that I noticed while reviewing your code.  The LOCK prefix is valid for 32-bit code, but using opcode 0x82 instead of 0x80  is not valid in 64-bit code.  Sorry for the confusion; I was just providing this as an example of an existing error in the sleigh in code that this PR touches.   I can fix it after you've submitted.

I believe you may need to just have a thought for 16-bit versions of x86 as well.  (Tbh, I don't know if what you're proposing affects 16-bit or not, I just know there are quite a few oustanding issues in this regard and don't want it to be made any worse!!!)

@ghidracadabra I think this is ready for internal review/testing.
I've rebased and split up the changes into a few commits based on some of your suggestions. Feel free to cherry-pick those for faster merge if you'd like. I also combined the LOCK and XACQUIRE/XRELEASE implementation into a single commit because, honestly, it would be a lot of changes and time to split into two commits, so I hope you don't mind.
If there's anything else I can do on my end to make it easier or faster to review, please let me know. Thank you.

Is there an easy way to fix stack after updating from v20220616 to current patch version?

@ekilmer To fix an IP issue while building I need:

diff --git a/Ghidra/Processors/x86/certification.manifest b/Ghidra/Processors/x86/certification.manifest
index 7d95a8f6a..2e66f4848 100644
--- a/Ghidra/Processors/x86/certification.manifest
+++ b/Ghidra/Processors/x86/certification.manifest
@@ -11,6 +11,7 @@ data/languages/cet.sinc||GHIDRA||||END|
data/languages/clwb.sinc||GHIDRA||||END|
data/languages/fma.sinc||GHIDRA||||END|
data/languages/ia.sinc||GHIDRA||||END|
+data/languages/lockable.sinc||GHIDRA||||END|
data/languages/lzcnt.sinc||GHIDRA||||END|
data/languages/macros.sinc||GHIDRA||||END|
data/languages/mpx.sinc||GHIDRA||||END|

@jobermayr Thank you for the comments! And yes, it looks like I made a very big mistake with regards to splitting out the memory and register destination for lockable instructions. I am still getting familiar with sleigh, so I thought I could replace something like spec_rm8 with Reg8 to get only the register, but this is very wrong because the masks don't align (as shown in your screenshot). Thank you for the review.
I am in the process of correcting this for the register-destination instructions. The lockable versions should be fine, but I will double check.

@jobermayr Please try now. I force-pushed to fix the Rmr issue.

@jobermayr Please try now. I force-pushed to fix the Rmr issue.

It works now. Thanks a lot for doing this.
Would be really nice if the decompiler could one day also simplify the Interlocked functions like IDA:

@ekilmer I'm still reviewing this, but I wanted to mention two things.

In the semantic section of the CMPXCHG variant on line 139 of lockable.sinc, there is a comment about an error due to duplicate build unlock; statements.  You can avoid duplicate build statements by appending
<end>
build unlock;
to the end of the section and replacing the goto inst_next; with goto <end>;.
While testing, I noticed something peculiar.  In a few linux libc .so files I examined (both 32 and 64 bit), there is an interesting optimization.  The code looks something like this:
74 01 JZ +1
f0 4c 0f b1 29 CMPXCHG.LOCK qword ptr [RCX], R13
Basically, the code checks a value to determine whether it wants the locked variant of an instruction.  If it wants the unlocked variant, it jumps 1 byte over the f0 prefix.  With this PR, such code results in a disassembly error in the listing since you can't have overlapping instructions.  In master this error does not occur since f0 is considered a one-byte instruction.  You can see this in your branch by importing and analyzing a libc so from linux, opening the "Bookmarks" menu, and typing "conflicting" into the filter.

I experimented with a fix using a delayslot directive, but as far as I can tell the manual does not forbid repeating the lock prefix and nested delay slots result in a disassembly error.  This isn't a reason to reject the PR, but I figured I'd mention it in case it's of interest to you.

@ekilmer I'm still reviewing this, but I wanted to mention two things.

In the semantic section of the CMPXCHG variant on line 139 of lockable.sinc, there is a comment about an error due to duplicate build unlock; statements.  You can avoid duplicate build statements by appending
<end>
build unlock;
to the end of the section and replacing the goto inst_next; with goto <end>;.

Thank you! Fixed in latest force-push.

While testing, I noticed something peculiar.  In a few linux libc .so files I examined (both 32 and 64 bit), there is an interesting optimization.  The code looks something like this:
74 01 JZ +1
f0 4c 0f b1 29 CMPXCHG.LOCK qword ptr [RCX], R13
Basically, the code checks a value to determine whether it wants the locked variant of an instruction.  If it wants the unlocked variant, it jumps 1 byte over the f0 prefix.  With this PR, such code results in a disassembly error in the listing since you can't have overlapping instructions.  In master this error does not occur since f0 is considered a one-byte instruction.  You can see this in your branch by importing and analyzing a libc so from linux, opening the "Bookmarks" menu, and typing "conflicting" into the filter.

I experimented with a fix using a delayslot directive, but as far as I can tell the manual does not forbid repeating the lock prefix and nested delay slots result in a disassembly error. This isn't a reason to reject the PR, but I figured I'd mention it in case it's of interest to you.
Edit: It might be possible to avoid the nested delay slots error by introducing some context; not sure whether it's worth it though.

Ahhh, yes, @pgoodman mentioned that in an earlier comment too 😬 https://github.com/NationalSecurityAgency/ghidra/pull/4336#issuecomment-1153251230.

Ok, I've finished reviewing this.  Overall looks good, thank you for taking this on!
There are a few minor issues to address before we can accept this:

Although certain MOV instructions can take an XRELEASE prefix, they do not accept a LOCK prefix.  For example, f0 48 89 18 is an invalid instruction and should not disassemble.  So the MOV instructions should probably be moved back to ia.sinc.
Possibly related to this, but there are some TODO statements about identical patterns (e.g. line 3038 of ia.sinc.).  Were we missing variants?  Is this an consequence of moving some of the MOV variants to lockable.sinc?
XCHG with a memory operand asserts a lock signal whether or not there is a LOCK prefix, so the pcode section should just have calls to LOCK and UNLOCK rather than build directives.

There are some other possible improvements, such as better handling of the one-byte jump and having the "LOCK" appear as a prefix in the disassembly.  These touch areas of the code other than those relevant to this PR and can be considered after this is merged.

Ok, I've finished reviewing this. Overall looks good, thank you for taking this on!

 And thank you again for the review(s).

There are a few minor issues to address before we can accept this:

Although certain MOV instructions can take an XRELEASE prefix, they do not accept a LOCK prefix.  For example, f0 48 89 18 is an invalid instruction and should not disassemble.  So the MOV instructions should probably be moved back to ia.sinc.

Fixed. Force-pushed.

Possibly related to this, but there are some TODO statements about identical patterns (e.g. line 3038 of ia.sinc.).  Were we missing variants?  Is this an consequence of moving some of the MOV variants to lockable.sinc?

It was a consequence of splitting the original pattern into one that only accepts memory destination operand (so that I could look for a valid XRELEASE prefix) and one that only supports a register destination operand.
In the original pattern,
:MOV spec_rm8,imm8       is vexMode=0 & byte=0xc6; (spec_rm8 & reg_opcode=0 ...); imm8        { spec_rm8 = imm8; }

I wasn't certain what reg_opcode=0 actually meant, so I was just following my process of replacing spec_rm8 with spec_m8 (for only capturing memory operands)
MOV^xrelease spec_m8,imm8       is vexMode=0 & xrelease & byte=0xc6; spec_m8 & reg_opcode=0 ...; imm8        { build xrelease; spec_m8 = imm8; }

and then, for the register destination, replacing spec_rm8 with Rmr8 and adding mod=3
:MOV Rmr8,imm8 is vexMode=0 & byte=0xc6; (mod=3 & Rmr8 & reg_opcode=0); imm8 { Rmr8 = imm8; }

which caused the identical pattern error with an existing pattern that looks very similar but with a CRmr8 instead of Rmr8
MOV CRmr8,imm8     is vexMode=0 & byte=0xc6; (CRmr8 & mod=3 & reg_opcode=0); imm8      { CRmr8 = imm8; }

So, I don't fully understand some of the pattern matching going on here, and thought it'd be good to call out the error 😕.

XCHG with a memory operand asserts a lock signal whether or not there is a LOCK prefix, so the pcode section should just have calls to LOCK and UNLOCK rather than build directives.

Good catch! Fixed. Force-pushed.

There are some other possible improvements, such as better handling of the one-byte jump and having the "LOCK" appear as a prefix in the disassembly. These touch areas of the code other than those relevant to this PR and can be considered after this is merged.
Edit: I see your above comment related to #2. I'll investigate and make any necessary fixes after you've submitted.

Sounds good!

@ekilmer Can you please adapt it to 71dcf8e ?

@jobermayr Rebased and pushed

From https://github.com/NationalSecurityAgency/ghidra/pull/4336#issuecomment-1244435811

Would be really nice if the decompiler could one day also simplify the Interlocked functions like IDA:

diff --git a/Ghidra/Processors/x86/data/languages/ia.sinc b/Ghidra/Processors/x86/data/languages/ia.sinc
index a7017dec1..c457f5248 100644
--- a/Ghidra/Processors/x86/data/languages/ia.sinc
+++ b/Ghidra/Processors/x86/data/languages/ia.sinc
@@ -1090,11 +1090,11 @@ xrelease: ".XRELEASE"	is xacquireprefx=0 & xreleaseprefx=1 { XRELEASE(); }
 xrelease: 	is epsilon { }

 # LOCK prefix
-lock:  ".LOCK"	is lockprefx=1 { LOCK(); }
+lock:  ".LOCK"	is lockprefx=1 { }
 lock:        	is epsilon { }
-unlock:		is lockprefx=1 { UNLOCK(); }
+unlock:		is lockprefx=1 { }
 unlock:		is epsilon { }
-lockx: xlockprefx^".LOCK"	is lockprefx=1 & xlockprefx { build xlockprefx; LOCK(); }
+lockx: xlockprefx^".LOCK"	is lockprefx=1 & xlockprefx { build xlockprefx; }
 lockx: 		is epsilon { }

 # Some macros
diff --git a/Ghidra/Processors/x86/data/languages/lockable.sinc b/Ghidra/Processors/x86/data/languages/lockable.sinc
index d62535415..0921f24e0 100644
--- a/Ghidra/Processors/x86/data/languages/lockable.sinc
+++ b/Ghidra/Processors/x86/data/languages/lockable.sinc
@@ -127,6 +127,7 @@
 :BTS^lockx^unlock m64,imm8     is $(LONGMODE_ON) & vexMode=0 & lockx & unlock & opsize=2 & byte=0xf; byte=0xba; m64 & reg_opcode=5 ...; imm8   { build lockx; local bit=imm8&0x3f; local val=(m64>>bit)&1; m64=m64 | (1<<bit); CF=(val!=0); build unlock; }
 @endif

+define pcodeop _InterlockedCompareExchange;
 :CMPXCHG^lockx^unlock m8,Reg8  is vexMode=0 & lockx & unlock & byte=0xf; byte=0xa6; m8 & Reg8 ...           { build lockx; _cmpxchg(m8, Reg8); build unlock; }
 :CMPXCHG^lockx^unlock m16,Reg16  is vexMode=0 & lockx & unlock & byte=0xf; byte=0xa7; m16 & Reg16 ...           { build lockx; _cmpxchg(m16, Reg16); build unlock; }
 :CMPXCHG^lockx^unlock m8,Reg8  is vexMode=0 & lockx & unlock & byte=0xf; byte=0xb0; m8 & Reg8 ...           { build lockx; subflags(AL,m8); local tmp=AL-m8; resultflags(tmp);
@@ -139,28 +140,11 @@
 					  build unlock; }
 :CMPXCHG^lockx^unlock m32,Reg32    is vexMode=0 & lockx & unlock & opsize=1 & byte=0xf; byte=0xb1; m32 & Reg32 ... & check_EAX_dest ...
 {
-    build lockx;
-	#this instruction writes to either EAX or m32
-	#in 64-bit mode, a 32-bit register that is written to
-	#(and only the register that is written to)
-	#must be zero-extended to 64 bits
-	subflags(EAX,m32);
-	local tmp=EAX-m32;
-	resultflags(tmp);
-    if (ZF==1) goto <equal>;
-    EAX = m32;
-    build check_EAX_dest;
-    goto <inst_end>;
-<equal>
-    m32 = Reg32;
-<inst_end>
-    build unlock;
+    EAX = _InterlockedCompareExchange(m32, Reg32, EAX);
 }
 @ifdef IA64
-:CMPXCHG^lockx^unlock m64,Reg64    is $(LONGMODE_ON) & vexMode=0 & lockx & unlock & opsize=2 & byte=0xf; byte=0xb1; m64 & Reg64 ...  { build lockx; subflags(RAX,m64); local tmp=RAX-m64; resultflags(tmp);
-                                          local diff = m64^Reg64; m64 = m64 ^ (zext(ZF) * diff);
-                                          diff = RAX ^ m64; RAX = RAX ^ (zext(ZF==0) * diff);
-					  build unlock; }
+define pcodeop _InterlockedCompareExchange64;
+:CMPXCHG^lockx^unlock m64,Reg64    is $(LONGMODE_ON) & vexMode=0 & lockx & unlock & opsize=2 & byte=0xf; byte=0xb1; m64 & Reg64 ...  { RAX = _InterlockedCompareExchange64(m64, Reg64, RAX); }
 @endif

 :CMPXCHG8B&lockx  m64        is vexMode=0 & lockx & unlock & byte=0xf; byte=0xc7; ( mod != 0b11 & reg_opcode=1 ) ... & m64 {


Add option to specify custom test host

Description
Add option to specify path to dotnet host
Related issue
Fixes #1749

@ViktorHofer  Tested this withing VS by copying from C:\Projects\vstest\src\package\package\bin\Debug\net451\win7-x64 to C:\Program Files (x86)\Microsoft Visual Studio\2019\IntPreview\Common7\IDE\Extensions\TestPlatform

LGTM
Just ensure that the documentation is updated with <DotnetHostPath> available under <RunConfiguration>


Transpiling ml-matrix to ES-5

Hello, I am trying to transpile ml-matrix to es5 using babel and webpack but it is not getting transpiled. Can someone pl tell me why is it not getting transpiled?

Maybe your node_modules directory is ignored by babel?

Nevermind, it worked. I added the @babel/preset-env and it worked. Thanks anyway.


Memory corruption of Pascal Titan X for some shapes

It seems like some kernels tend to corrupt memory. This problem does not show on the benchmarks but breaks the BLAS3-test (despite computing the correct matrix).

Fixed in ba1520ae986e.


HLIL optimization is aggressive.

Binary Ninja version 3.0.3233 Personal Build e250f0a3.
Rootme System 1:
#include <unistd.h>
#include <sys/types.h>
#include <stdlib.h>
#include <stdio.h>

int main()
{

  int var;
  int check = 0x04030201;
  char buf[40];

  fgets(buf,45,stdin);

  printf("\n[buf]: %s\n", buf);
  printf("[check] %p\n", check);

  if ((check != 0x04030201) && (check != 0xdeadbeef))
    printf ("\nYou are on the right way!\n");

  if (check == 0xdeadbeef)
   {
     printf("Yeah dude! You win!\nOpening your shell...\n");
     setreuid(geteuid(), geteuid());
     system("/bin/bash");
     printf("Shell closed! Bye.\n");
   }
   return 0;
}

Results in the following HLIL:
08048546  int32_t main(int32_t argc, char** argv, char** envp)

0804854d      void* const var_4 = __return_addr
08048555      int32_t* var_14 = &argc
0804857d      void var_4c
0804857d      fgets(buf: &var_4c, n: 0x2d, fp: *stdin)
08048593      printf(format: "\n[buf]: %s\n", &var_4c)
080485a8      printf(format: "[check] %p\n", 0x4030201)
0804863b      return 0

ch13.zip

Fyi expected output (IDA)
int __cdecl main(int argc, const char **argv, const char **envp)
{
  __uid_t v3; // esi
  __uid_t v4; // eax
  char s[40]; // [esp+0h] [ebp-44h] BYREF
  int v7; // [esp+28h] [ebp-1Ch]
  int *p_argc; // [esp+38h] [ebp-Ch]

  p_argc = &argc;
  v7 = 67305985;
  fgets(s, 45, stdin);
  printf("\n[buf]: %s\n", s);
  printf("[check] %p\n", v7);
  if ( v7 != 67305985 && v7 != -559038737 )
    puts("\nYou are on the right way!");
  if ( v7 == -559038737 )
  {
    puts("Yeah dude! You win!\nOpening your shell...");
    v3 = geteuid();
    v4 = geteuid();
    setreuid(v4, v3);
    system("/bin/bash");
    puts("Shell closed! Bye.");
  }
  return 0;
}

In your binary, if you declare var_4c as a char[0x2d] (which it kind of is according to the fgets n argument), the HLIL looks like what you expected.

Without this, there would have been no cross reference to the "check" variable, so it seems pretty legitimate to me that BN treats it as constant and eliminates dead branches.
PS: By the way, an optimizing compiler would perform the same optimizations, since buffer overflows are undefined behavior. Here is your code compiled with -O3:

Reply, you are missing the point of the issue in question.
IDA finds the var_4c  without any interaction, Binary Ninja does not.
That is all.

If the only difference in analysis is the creation of a stack array then this is a duplicate of #1637 so it's a useful comment, thanks! I will double check and if I can confirm I will close this after this comment links it to the other issue as extra samples are always helpful but we wouldn't need an extra issue.

Well its related for sure, yet assigning it a buffer size of 0x2d (45) would be incorrect as the buffer size of 0x28 (40).
When setting to 0x28 HLIL is still to aggressive with filtering the 'unused' values.
08048546  int32_t main(int32_t argc, char** argv, char** envp)

0804854d      void* const var_4 = __return_addr
08048555      int32_t* var_14 = &argc
0804857d      char var_4c[0x28]
0804857d      fgets(buf: &var_4c, n: 0x2d, fp: *stdin)
08048593      printf(format: "\n[buf]: %s\n", &var_4c)
080485a8      printf(format: "[check] %p\n", 0x4030201)
0804863b      return 0

The thing is the source code is "incorrect" from the start, so we could argue that the buffer size is in fact 45, not 40,  since it is the size used by fgets. There is not a unique way to "correcty" decompile the program.
I guess if we compile the following program, we would have the more or less exact binary, thus only having a 45 bytes buffer :
#include <unistd.h>
#include <sys/types.h>
#include <stdlib.h>
#include <stdio.h>
#define CHECK *(int*)&buf[40]

int main()
{

  int var;
  char buf[45];

  fgets(buf,45,stdin);

  printf("\n[buf]: %s\n", buf);
  printf("[check] %p\n", CHECK);

  if ((CHECK != 0x04030201) && (CHECK != 0xdeadbeef))
    printf ("\nYou are on the right way!\n");

  if (CHECK == 0xdeadbeef)
   {
     printf("Yeah dude! You win!\nOpening your shell...\n");
     setreuid(geteuid(), geteuid());
     system("/bin/bash");
     printf("Shell closed! Bye.\n");
   }
   return 0;
}

Personally, I think it is a good thing that HLIL eliminates dead branches "aggressively" the way it does, to me it is one aspect where BN is better than IDA, because that the control flow presented in the decompiled view directly reflects the information provided by the user (i.e. user variable values, or in your case, variable types and sizes).

Additionally it would be nice if we offered some way to allow people to see that branches have been eliminated. Also it would be nice if we supported "volatile" for stack variables to tell HLIL that it should assume that value can change at anytime.

Issue tracking dead branch display: #2219

This issue has been largely addressed due to improved stack variable aliasing. The detection of the non-constant stack arrays still exists but the original purpose of this issue has been addressed. This is the current output of Binary Ninja

Follow: https://github.com/Vector35/binaryninja-api/issues/2570 for updates on stack array creation.


Fix typo: return value of AbstractProcess::terminate.

Hi @waywardmonkeys, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

:+1:
@dbaeumer fyi

@waywardmonkeys thanks !


Add "Introduction to Design Systems" online book

Online Book: https://fem-design-systems.netlify.app/
Repository of the book: https://github.com/emmabostian/fem-design-systems

Thanks for your contribution!! 👏


(minishift) Add new package maintainer

Description
Add a new maintainer for the minikube package.
Motivation and Context
Add new package maintainer and update to reflect current contribution
guidelines and package details.  Specific changes made:

Refresh README to reflect current product description
Update copyright to reflect Kubernetes Authors
Include copyright handling for Nuspec updates
Correct handling for checksum type
Powershell script formatting and style changes

chocolatey-community/chocolatey-package-requests/issues/1006
How Has this Been Tested?
The updates to the package do not reflect any functional change. Package has been tested by:

Resetting version numbers to force a package update followed by:
i) Add and remove the built package in the Chocolatey test environment
ii) Inspection of the package to ensure only expected changes are present in updated files

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[x] My code follows the code style of this repository.
[x] My change requires a change to documentation (this usually means the notes in the description of a package).
[x] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[x] All files are up to date with the latest Contributing Guidelines
[x] The added/modified package passed install/uninstall in the chocolatey test environment.
[x] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review

@dgalbraith Do you still want to merge this? Can you address the issues raised by @AdmiringWorm ?

Closing as requested changes have not been made or responded to.


official bazel support?

Hello,
I have been trying to use GRPC with bazel for the past few days and am continuously running into errors, including:

Implicit (and undocumented?) //external dependencies
Compilation errors, e.g.

ERROR: /Users/traviskaufman/dev3/cpp/third_party/grpc/BUILD:529:1: undeclared inclusion(s) in rule '//third_party/grpc:grpc_unsecure':
this rule is missing dependency declarations for the following files included by 'third_party/grpc/src/core/ext/lb_policy/grpclb/proto/grpc/lb/v1/load_balancer.pb.c':
  'third_party/nanopb/pb.h'.

No workspace macros

I was wondering if bazel is officially supported and if not is there a near-term plan to provide official support?
Thanks
p.s. I am running into errors using the cc_grpc_library macro from bazel's genproto rules.

+Yang Gao<EMAIL_ADDRESS>has been doing some work on getting this build
tested.
We plan on having something working soon, and something really supported
and working well by end-of-quarter.
On Mon, May 30, 2016 at 12:27 PM Travis Kaufman<EMAIL_ADDRESS>wrote:

Hello,
I have been trying to use GRPC with bazel for the past few days and am
continuously running into errors, including:

Implicit (and undocumented?) //external dependencies
Compilation errors, e.g.

ERROR: /Users/traviskaufman/dev3/cpp/third_party/grpc/BUILD:529:1: undeclared inclusion(s) in rule '//third_party/grpc:grpc_unsecure':
this rule is missing dependency declarations for the following files included by 'third_party/grpc/src/core/ext/lb_policy/grpclb/proto/grpc/lb/v1/load_balancer.pb.c':
'third_party/nanopb/pb.h'.

No workspace macros

I was wondering if bazel is officially supported and if not is there a
near-term plan to provide official support?
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/issues/6728, or mute the thread
https://github.com/notifications/unsubscribe/AJpudXQ9EvbixgwJ3Wjuft9P2nLvzSkcks5qGzoOgaJpZM4Ip_kG
.

Awesome! Please let me know if/how I can help.
On Tue, May 31, 2016 at 11:02 Craig Tiller<EMAIL_ADDRESS>wrote:

+Yang Gao<EMAIL_ADDRESS>has been doing some work on getting this
build
tested.
We plan on having something working soon, and something really supported
and working well by end-of-quarter.
On Mon, May 30, 2016 at 12:27 PM Travis Kaufman<EMAIL_ADDRESS>wrote:

Hello,
I have been trying to use GRPC with bazel for the past few days and am
continuously running into errors, including:

Implicit (and undocumented?) //external dependencies
Compilation errors, e.g.

ERROR: /Users/traviskaufman/dev3/cpp/third_party/grpc/BUILD:529:1:
undeclared inclusion(s) in rule '//third_party/grpc:grpc_unsecure':
this rule is missing dependency declarations for the following files
included by
'third_party/grpc/src/core/ext/lb_policy/grpclb/proto/grpc/lb/v1/load_balancer.pb.c':
'third_party/nanopb/pb.h'.

No workspace macros

I was wondering if bazel is officially supported and if not is there a
near-term plan to provide official support?
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/issues/6728, or mute the thread
<
https://github.com/notifications/unsubscribe/AJpudXQ9EvbixgwJ3Wjuft9P2nLvzSkcks5qGzoOgaJpZM4Ip_kG
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc/issues/6728#issuecomment-222716459, or mute
the thread
https://github.com/notifications/unsubscribe/ABIV9XUj0zOc2Lk6Q6F6VAZvrso0hH_pks5qHE1rgaJpZM4Ip_kG
.

@yang-g

Is there any updates on that ? I'm also running on a lot of compilation issues.


Issue/3 circular bootstrap

Pull Request Testing

[ ] Describe testing already performed for these changes:
The result of calculation the percent of rejected values for 0 hypothesis test
for CI for mean statistic of the normal distribution of 100 values
'for mean = 0 p = 9.3'
'for mean = 1 p = 22.0'
'for mean = 2 p = 57.6'
'for mean = 3 p = 87.7'
'for mean = 4 p = 97.7'
'for mean = 5 p = 99.9'

[ ] Recommend testing for the reviewer to perform, including the location of input datasets:

[ ] Will this PR result in changes to the test suite? [Yes or No]
If yes, describe the new output and/or changes to the existing output:

[ ] After merging, should the reviewer DELETE the feature branch from GitHub? [Yes or No]

Pull Request Checklist
See the METplus Workflow for details.

[ ] Complete the PR definition above.
[ ] Ensure the PR title matches the feature or bugfix branch name.
[ ] Define the PR metadata, as permissions allow.
Select: Reviewer(s), Project(s), and Milestone
[ ] After submitting the PR, select Linked Issues with the original issue number.

Test to check the validity of the new method were performed

Test to check the validity of the new method were performed


Error wait: no child process

When make local test,  will run into this error wait: no child process intermittently. In here  and here when we call cmd.Run.
When look deep in the golang source code, will see a race condition in cmd.Run, that process may finished before cmd.Wait could be scheduled.
I don't think this is a serious problem, so we may be need to filter it manually.

@runcom I have checked related man page with ECHILD

ECHILD
(for waitpid() or waitid()) The process specified by pid
(waitpid()) or idtype and id (waitid()) does not exist or is
not a child of the calling process.  (This can happen for
one's own child if the action for SIGCHLD is set to SIG_IGN.
See also the Linux Notes section about threads.)

As pointed early, when a race condition happen, we may receive an ECHILD error, since this imply that we have set SIGCHLD to SIG_IGN(not sure when did that, maybe set by golang defaultly), this won't lead to a zombie problem, so it's not harm to ignore them. Do you have other concerns about this?

See https://github.com/kubernetes-incubator/cri-o/pull/272


Can this project change and modify the hairstyles of yellow men?(I tried to process photos of Chinese male stars, but the results were not good)

same problem

I have the same issue


Restore previous functionality to "/tourettes"

Ensuring 3-10 profanities spewed when using the command without following text.
Also, preferably, the functionality that was under development that made e.g. /tourettes 35 spew 35 random profanities.

Will fix this, but the /tourettes 35 thing is an issue on its own (#5)

Fixed in PR #17

Strip inputText of commands so that arguments can be properly evaluated.


Am I Using Ox Correctly?

I've been following Ox since its inception: https://github.com/objektwerks/ox
I recently added Ox to this project: https://github.com/objektwerks/house
See: Server, Dispatcher and Handler.
Am I using Ox correctly in this app?
Any comments would be most welcome. Otherwise, I'll assume I'm an Ox genius. ;)

Am I the only one using Ox? Gosh, I should hope not. :)
I've refactored my above house project to minimize Ox exposure / usage.
To do so, though, I had to use IO.unsafe directly in Dispatcher and DispatcherTest.
Otherwise, using IO would have threaded itself through Handler and Dispatcher.
The Ox docs recommend against using a class constructor to pass using IO.  And I strongly suspect I agree.
Yet IO.unsafe hides the classic using IO from an entry point method signatures. Oops. :(
For instance, def dispatch(command: Command)(using IO): Event = ... is replaced with:
def dispatch(command: Command): Event =
  IO.unsafe:
    command.isValid match
    ...

But one must adhere to the Scala compiler's demands. ;)
...
I will look into replacing Helidon SE with Tapir ( with the over-the-top simple solution ).
...
Your continued support in this matter is much appreciated --- given my Ox genius status, at this point in time. :)

Closing issue due to inactivity.

Let me address these one by one :)
First - is anybody using Ox? no idea :) But I think it would be be to post usage questions to the forum, as not many people might be following new GitHub issues. Also, Ox is still an 0.x project, hence it might (and I hope it will!) experience changes to the API.
Secondly, your project:

Endpoint - looks good, one thing I'm not sure about is what is Thread.currentThread().join() for? Is it for blocking indefinitely? If so, never might be better. Also, jdkHttpServer.stop(0) should probably be added as a cleanup step, before blocking, using releaseAfterScope(jdkHttpServer.stop(0))
Handler - why Try+recover instead of try-catch?

As for IO - I know it could end up being threaded through multiple classes, and hence a bit cumbersome to use. That's what I somewhat discussed here. However, if we want signatures that don't lie, the IO information needs to go somewhere. I'm still not certain on IOs future, though.

Can the Ox plugin be enhanced to output useful info on IO usage and the like?

Probably, but you'd need to write more on what you exactly mean by that :)

Yet, I was unable to add required Schema(s) to implement Jsoniter support for my Tapir endpoint. Nothing worked.

Some more details would be needed here - what kind of error messages did you get, and what did you write in code.

Thanks for the reply, Adam!
Sorry, I don't do Discord; hence my post on Github.
Using Thread.currentThread().join() blocks the main thread from exiting and shutting down the JdkHttpServer. It works fine as is; but I added a sys.addShutdownHook { ... } block for a more elegant look. ;) Some of Tapir's other http server options are more sophisticated and don't required this technique.
As for Try: recover:, I suspect it's a habit vis-a-vis Try: catch:. I see your point, though. :) Thanks!
No worries on IO. I understand Ox is in flux. I was just trying to follow the docs. And I'll adjust as Ox evolves.
I was thinking the Ox plugin could print out any and all IO relevant information useful to developers. I figured you and your team might have some ideas. :)
I wrote my thoughts down on Tapir here: https://github.com/objektwerks/house/blob/main/README.md I wouldn't read too much into it. My experience with Tapir is quite limited. And the old-school approach works just fine.
Thanks, again, for your time. Cheers! :)

Sorry, I don't do Discord; hence my post on Github.

I also dislike Discord ;) The forum is Discourse - something quite different.

Using Thread.currentThread().join() blocks the main thread from exiting and shutting down the JdkHttpServer. It works fine as is

Ah ok. That's what generally never is for, but both do the job equally fine

but I added a sys.addShutdownHook { ... } block for a more elegant look.

That's also what OxApp is doing - adding a shutdown hook to release any resources allocated within the main Ox scope (the top-level one that is provided to the app)
Thanks for testing Tapir & Ox, if you would have any specific questions on the derivation problems, please open new threads / issues.

Ok, Adam, I just plugged in releaseAfterScope and never and Endpoint works as expected! I'm fully Ox-compliant, now! ;) Thanks!
I've located the Discourse SoftwareMill forum. I'll check it out. And, perhaps, I can get my Tapir schema issues resolved. ;)
Thanks, again, for your time! Cheers! :)


Supporting legacy versions of CABLE

Currently benchcab only supports the CABLE v3 build system. This is fine for the use case where a developer is attempting merge a branch into the trunk because the development branch will be forced to adopt the newer CABLE v3 build system.
Problem: there is also the use case where a developer wants to do a scientific evaluation for older versions of CABLE which use a legacy build system.
For example, when developers are preparing to merge some old branch of CABLE (label as branch_old) into the trunk, it may be easier to first merge an older revision of the trunk into branch_old as opposed to merging the head of the trunk into branch_old (as the former will likely be easier to resolve any merge conflicts). The developer may then want to compare the output between a new version of branch_old with the original branch_old to verify if any changes in the new version have impacted the results.
This would require benchcab to be able to build and run legacy versions of CABLE.
Possible solutions:

Write separate "drivers" that build CABLE for each legacy version into benchcab.

pro: this might not take much work as there is only a finite number of legacy build systems for CABLE
con: requires updating benchcab every time we encounter a build system that is not supported

Allow the user to specify the commands/instructions required to build a particular branch in the config file. These commands are then run instead of the default CABLE v3 build scripts.

pro: benchcab can support any arbitrary build system
con: requires extra work for the user
con: it is difficult to make this an automated step in the work flow as the user must know the directory structure of the working directory

Update the legacy build system to use the CABLE v3 build system.

con: this requires major refactoring of the code base for legacy branches of CABLE which should be avoided

Allow the user to specify the path to a prebuilt CABLE executable.

pro: this is already an issue #33
pro: this functionality is great for this specific use case. However, con: this is not ideal for the use case where a developer is testing a branch that is about to be merged into the trunk as this would allow for potential uncommitted changes to leak into the test suite.

@ccarouge I think I'm leaning towards option 4. What do you think?
@rkutteh I am interested if you have any thoughts on this as well

I think option 2 can be very easy to implement. Probably faster than option 4. And this:

con: it is difficult to make this an automated step in the work flow as the user must know the directory structure of the working directory

can be avoided. If we ask the user to give a path to a build script relative to the root of their source code directory. It's easy for the user to know, they don't need to know where it will live when benchcab runs, benchcab can find it as it knows where the root of each source directory is.
It also makes it easier for people to test other users' branches without having to do the checkout and compilation by hand first.
Probably, we will want both options 2 and 4 in eventually. It's just a question of which one to put in first.

Actually, option 4 is probably as easy to implement as option 2. So @rkutteh , which one would work best for you:

specify an executable existing on the filesystem
specify the relative path to the build script in the branch

The most elegant and "black box" solution in my view is (1), but of course it requires more work than the others, although we only need to worry about v2 and v3 for now (and ensure the build workflow is not needlessly altered in future CABLE versions).
My second choice would be (2).
On the other hand (3) is a definite no for me.
Lastly, I don't like (4) at all, partly for the 'con' reason mentioned, but in general whatever is getting tested should be committed already as this would allow others to reproduce the test. In addition, both builds being compared should be compiled in the same manner (same compiler flags) for a true comparison of results. There are simply too many things in this scenario that could corrupt an accurate comparison of results (e.g., we don't know how the prebuilt exec was compiled, what exactly was compiled at the time,...). In my view, benchcab should only be allowed to compare versions already in a repo as this keeps things "in check" so to speak.

@ccarouge @SeanBryan51 as per my comments above, I like (2) but not (4). In other words I prefer to "specify the relative path to the build script in the branch"

One of the use cases for option 4 is during development. When people develop, it would be good if they could quickly fire up a test on one site as a sanity check they haven't broken anything by inadvertence. Obviously, these test results would not be admissible to show the quality of a new feature. The problem is to quickly identify which tests have been done using a pre-built executable so no mistake is done.
I'll see about option 1. I also like option 2 because if someone comes with yet a different build script, they can use benchcab before "we" (preferably "they") develop a new driver.

So again the problem with (4) is that even during development I may do a test today with my current working copy but forget after a bit more development what my working copy looked like when I did that test. Because I did not checkout the copy for the test from a repo then I do not really have a record for what the test corresponded to. Again to me this feature encourages poor development practices, but I guess for really incremental work it is useful to have.

There is a bug in the proposed change in case we want to build with MPI. Need to provide a fix.


SfArrow

Related issue
default

long

Scope of work
Screenshots of visual changes
default

long arrow

Checklist

[x] I followed composition rules for my component
[x] I tested the component in most common device sizes (can be tested in Storybook from viewport addon in top menu)

@filrak I fixed all problems


Need the files of 'CONTRIBUTING.md' & 'LICENSE'

Hi,
I'm from ARM. We need to enable this project to support multi-arch.
I have fixed the same issue in sonobuoy. Please see:
https://github.com/heptio/sonobuoy/pull/491
But our legal department need to check the policy for contribution & license.
I can't find the files of 'CONTRIBUTING.md' & 'LICENSE'
For your reference:
https://github.com/heptio/sonobuoy/blob/master/CONTRIBUTING.md
https://github.com/heptio/sonobuoy/blob/master/LICENSE

@chuckha @liztio
Can you check it?
Thanks.

@lubinsz I'm confused about what you're asking for. Are you looking for https://github.com/heptio/kube-conformance/blob/master/LICENSE ? I can add a contributing.md file, we should have had that already.


Export generated defines directory

This will make the library usable via add_subdirectory from another CMake-based project (without this change, the build fails because it can't find the header with generated defines).

Thanks. Looks good. Pending verification

@MaxSavenkov can you describe in this PR how this would be used?  I think you mentioned this earlier but I cannot find it.  I need this information to be able to replicate the issue and the solution to the issue.
Thanks

@KjellKod
Issue: currently, if you try to use g3log as a sub-project in your CMakeLists.txt by using add_subdirectory and target_link_library( my_project PRIVATE g3log ) command, and use g3log in that project by including its header, you will not be able to compile the resulting project, because the main g3log's header would include a generated g3log header, yet the path where generated headers reside is not propagated from sub-project to the main project.
Solution: added a directive for CMake to export the path to generated files (in addition to currently exported path to static header files), so when g3log is imported from another CMakeLists.txt, all necessary include directories will also be imported.
Result: g3log can now be used via add_subdirectory/target_link_library in CMake, without the need to install the library into system or manually specify necessary paths.


Upgrade all scripts to the latest

Using create-react-app I upgraded all the main configuration files and scripts.
mean, I'm removing legacy code.
PS. Everything is working fine, just the CDN that I’m not so sure about. If it will break.

This change is

Ratel Preview:

This looks fine at a surface level, but a few questions:

Why can't we stay on NPM? I really don't like yarn.
Can you explain the steps you took here? The PR is way to huge to review line by line (though most changes look benign)

@gja

There is a dependency conflict, but you can use npm cache clean --force and npm install --legacy-peer-deps that will work fine. Yarn solve this internally without prompt anything.
The dependency conflicts are in third-party deps.
What I did is, inspect all dependencies used in the repo. Create a new "Create React app", migrate all configs and the folder src to the new CRA. Then I started the client, also run the tests and also check the tests in TC. All fine.

Even still. One random issue is not a good reason to abandon npm. Please stick to npm everywhere.

I can't do anything if third party don't upgrade their deps - It is not a choice. Thats the issue of using third party dependencies. We have to rely in their work, trust that they will keep updated, that they won't add security issues.
Or we remove as much deps we can, or we force it. Really, there's no issue there.
About NPM vs YARN, not sure why you would not like it. It is faster, solve issues on the fly, run in parallel. I personally use it for a long time and rarely it fail to me. NPM otherwise, all the time it has an issue to solve. For me it is just a personal taste, there is not a problem in fact.


send push to the channel process when using push_async/3

Thank you for this library.
I was trying to use it with GenServer using push_async/3. But it wasn't sending the message the server.
This is a fix for it.

It looks like the use case you are presenting here is that you want to push_async a message to the server which has a {:reply, payload, socket} response, and you want to send that response as a broadcast message to the channel's caller. I could see this being useful. Thanks for the addition!

Published to hex in v0.9.0

Regarding this functionality, would it possible to have push_async return the ref so that when the reply comes back it can be matched?  Or would this no longer be fully async as it would involve a potentially blocking call to the Socket?


Need more resilience for managing the rancher install

If some of the helm charts are still installed, both install and uninstall will fail
If k8s is in an ERROR state, it should let the user know that (beyond the red-colored icon), and offer to fix whatever the problem is rather than do a reset.

As we are no longer going to offer Rancher as part of the experience I'm going to close this issue.
If we bring it back later in some form we can bring this up again.


Documentation is incomplete

This documentation in incomplete.  This process should either state the Fixed Asset needs to be created or have the process for creating a Fixed Asset.  A key piece of information left out of this documentation is for the acquisition journal to work, you must have a acquisition price on the fixed assets.    This should be documented here.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c6bd2315-361d-a269-e644-932d0e7d1136
Version Independent ID: 3f6b368b-fa55-0a79-59af-1606caad0cc5
Content: Propose fixed asset acquisitions - Finance | Dynamics 365
Content Source: articles/finance/fixed-assets/tasks/propose-fixed-asset-acquisitions.md
Service: dynamics-ax-applications
Product: ****
Technology: ****
GitHub Login: @saraschi2
Microsoft Alias: saraschi

@RobertRudd, thank you for your feedback!
@roschlom, please assign to the appropriate PM.

Bug 445543 has been logged to track this issue.


No query document supplied error

I have a weird issue where the no query document supplied error pops up.
Whenever I run the server locally or access the remote one, on one laptop everything works fine, but on the other, both local and remote servers return No Query Document supplied error with 400 status code...
Both laptops are macbook pros.
I also tried Safari and Chrome on the faulty one

Hi @DaveElGhoul please use the forums or other Elixir chat locations for debugging help. When you ask there please be sure to provide copies of the code you're running and how you're making requests.


Hub SSOT - Do we want to support package + metadata versioning?

Migrated from GitLab: https://gitlab.com/meltano/hub/-/issues/223
Originally created by @pnadolny13 on 2022-03-24 14:17:25

First proposed in https://gitlab.com/meltano/hub/-/issues/180.
If we allow users to pin a version of their package, they need to be able to pin the metadata at that point in time too as metadata changes with the code. If a user has a 0.9.0 package version installed and a breaking change (say a new required setting was added) was introduced to the 1.0.0 (latest) version along with metadata updates, they cant just pull the latest metadata or their pipeline will break.
This may be resolved by the lock mechanism https://gitlab.com/meltano/meltano/-/issues/3031 but we should decide if we only want to the hub to represent the "latest" or "current" metadata.
This decision affects the way we implement the V2 API and the organization of the files in the hub.

View 11 previous comments from the original issue on GitLab

Notes from chat with AJ:

supported Meltano versions: meltano-version: ~2.5.0
Columns: date changed, meltano version constraints, comment of update type

Figure out how to automate on Hub, then figure out how Meltano can resolve it.


fix jenactl script

I fixed a minor bug in the jenactl script. You need to create the dir /vagrant/repos if it is absent otherwise the provisioning will fail:
==> default: /usr/local/bin/jencactl: line 99: cd: /vagrant/repos: No such file or directory
==> default: /usr/local/bin/jencactl: line 102: cd: /vagrant/repos/jenca-authorization: No such file or directory
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

lgtm merging thanks!


Update user-information.md

Fixes #117768

@craigshoemaker
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Multipart upload splits CRLF across 2 chunks

Expected behavior
CLRF is always part of a single chunk.
Actual behavior
CRLF can be split across 2 chunks (in some super rare exotic circumstances), causing the first CR to be considered part of the multipart payload and being offered to the Decoder, causing
io.netty.handler.codec.http.multipart.HttpPostRequestDecoder$ErrorDataDecoderException: java.io.IOException: Out of size: 5043445 > 5043444
	at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.loadDataMultipartOptimized(HttpPostMultipartRequestDecoder.java:1190)
	at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.getFileUpload(HttpPostMultipartRequestDecoder.java:926)
	at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.decodeMultipart(HttpPostMultipartRequestDecoder.java:572)
	at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.parseBodyMultipart(HttpPostMultipartRequestDecoder.java:463)
	at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.parseBody(HttpPostMultipartRequestDecoder.java:432)
	at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.offer(HttpPostMultipartRequestDecoder.java:347)
	at io.netty.handler.codec.http.multipart.HttpPostMultipartRequestDecoder.offer(HttpPostMultipartRequestDecoder.java:54)
	at io.netty.handler.codec.http.multipart.HttpPostRequestDecoder.offer(HttpPostRequestDecoder.java:223)

This is very much a theory. Any hints to figure out whether something else could cause this would be appreciated.
Steps to reproduce
We have a test in Apache Flink that uploads a multipart HTTP request containing a bit of JSON as a MemoryAttribute and a FileUpload.
When the size of these attributes is just right (deviating by as much as 3 bytes hides the issue) the decoding of the request fails.
If it fails, then it is always with an off-by-one error as shown above, one more byte arriving than expected.
While debugging I inspected the chunk that causes the error. The last readable byte in the chunk had the value '13', i.e., CR. This makes me to believe that it is somehow possible that the CRLF can be split across chunks.
According to the the 4.1.49 decoder this should be impossible, but the explicit check was removed in 1529ef1794e0a6654fa4334fd979b769d6940e61.
We further consistently observe that the return value HttpPostRequestEncoder#length() after finalizing the request differs by exactly 1 between successful and failed runs, e.g., 5043832 (successful) vs 5043831 (failed).
Not sure what to make of that, but it's too consistent to ignore.
We have only observed this error after upgrading from 4.1.49 to 4.1.65.
Minimal yet complete reproducer code (or URL to code)
Still working on that. I could provide a reproducer that relies on a few Apache Flink classes if that would be acceptable.
Netty version
4.1.65.Final
JVM version (e.g. java -version)
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
OS version (e.g. uname -a)
Windows 11, but we also observed it on Ubuntu 20.

cc @fredericBregier

This code does look suspicious for cases when CRLF are split across buffer boundaries:
https://github.com/netty/netty/blob/4.1/codec-http/src/main/java/io/netty/handler/codec/http/multipart/HttpPostBodyUtil.java#L164-L168

IMHO, it is the contrary:

when the CR is there but not LF, then it returns -1 since it does not found the boundary ending
when it gets the next buffer, then LF will be found
However, I think I can do a reproducer as you described (very easy). It will then show the bug, if any, and finally I will propose a fix (of course, if I found the root cause).

Just to let you know that I can reproduce with the following scenario (could you confirm that this one is the same as yours):

Last-1 buffer contains last chunk + CR only (no LF)
Last buffer contains LF and separator (with LF/CRLF at the end, but even with a n+1 buffer containing LF or CRLF it's the same)
Issue is on Last-1 buffer: CR is included in the final data (which should not)

If the following scenario occurs, it's OK:

Last-1 buffer contains last chunk + LF/CRLF + separator + CR
Last buffer contains LF
No issue

Last-1 buffer contains last chunk + CR only (no LF)
Issue is on Last-1 buffer: CR is included in the final data (which should not)

yep, this sounds like the issue we're having.

Last buffer contains LF and separator

I haven't confirmed this detail yet (because well, things crash when processing Last-1 buffer), but I can try to do that if that would help.

The last buffer did indeed contain \n--9dd083c5bacd1377--\r\n

OK, thanks ! I'm trying to find out the best way to fix it (with no new issue of course)...


fix: cves should be permitted

we should permit .releaseNotes.cves since the docs mention them and populate-release-notes-images requires them

With https://github.com/konflux-ci/release-service-catalog/pull/695 being merged, do we agree we can reverse this PR? I don't think it makes sense to add things into the schema that aren't user provided (but before 695 I see why this was needed)

how does #695 help us here?

It allows additional properties. Before this PR, the pipeline was failing because releaseNotes.cves existed in the data file but wasn't in the schema. The schema blocked undefined keys. Now with 695, undefined keys should be allowed (it should still type check the defined ones though IIUC.. @seanconroy2021 correct?)

isn't it safer to have the schema for cves in particular defined? therefore keeping #695?

My feeling on it is basically that the cves section should exist in the schema once, not twice, and be in the spot that we expect them when check-data-keys runs

so users are instructed to provide .spec.releaseNotes.cves ... so that should exist in the schema.
populate-release-notes-images then uses that and generates the cves in content.images
we should definitely have the schema for .spec.releaseNotes.cves to ensure data is provided correctly.
The second definition also seems somewhat helpful (but not critical) since it found a problem with the generated content which eventually makes its way to the advisories which is crucial.

so users are instructed to provide .spec.releaseNotes.cves ... so that should exist in the schema. populate-release-notes-images then uses that and generates the cves in content.images
we should definitely have the schema for .spec.releaseNotes.cves to ensure data is provided correctly. The second definition also seems somewhat helpful (but not critical) since it found a problem with the generated content which eventually makes its way to the advisories which is crucial.

https://github.com/hacbs-release/app-interface-deployments/blob/main/internal-services/catalog/create-advisory-task.yaml#L161 will validate the advisory information with the schema file in the gitlab repo. It sounds like the cves key should be in releaseNotes then and not content.images in this repo's schema. I am going to file a bug for this

https://issues.redhat.com/browse/RELEASE-1298


Form and DB

Basic form information for a Database and displaying in a card based on the design spec in https://wiki.canterbury.ac.nz/display/QuakeCore/Plan+for+development. Note (Just basic look for now till functionality is sorted)

Requires a database sqlite and a file path in the enviournment variables for running.
Includes a yaml file with each runs metadata that is not stored on dropbox.
Next Steps:
Adding functionality for download links for IM and Source data and test idea for downloading
Background process to run daily to check runs on dropbox to ensure database is up to date with the current state
Functionality for filters

For now have renamed the cybershake naming to simulation. Will keep in mind that additional simulation data with a different path might be added so might add some small functionality around that in later PR's for support.


v3.0.1 doesn't have cache.Has method while it's documented in README.md of master branch

We'll release a new version once #107 is merged, after that readme should match what's available in the latest version.

The default branch is now v3.


fix(lifecycle-operator): duplicate version in project file

Fixes # (issue)
Checklist

[ ] My PR fulfills the Definition of Done of the corresponding issue and not more (or parts if the issue is separated
into multiple PRs)
[ ] I used descriptive commit messages to help reviewers understand my thought process
[ ] I signed off all my commits according to the Developer Certificate of Origin (DCO)
see Contribution Guide
[ ] My PR title is formatted according to the semantic PR conventions described in
the Contribution Guide
[ ] My code follows the style guidelines of this project (golangci-lint passes, YAMLLint passes)
[ ] I regenerated the auto-generated docs for Helm and the CRD documentation (if applicable)
[ ] I have performed a self-review of my code
[ ] I have made corresponding changes to the documentation (if needed)
[ ] My changes result in all-green PR checks (first-time contributors need to ask a maintainer to approve their test runs)
[ ] New and existing unit and integration tests pass locally with my changes

Thanks for finding and fixing this error @geoffrey1330 🙌


Allow inserting entropy to images

because images are cloned, they all start with the same entropy, which means you can have an attack where you can somewhat-predict the pseudo-random generator if on boot the device hasn't had enough time to gather entropy

We can do it by populating /var/lib/systemd/random-seed (at least in the case of systemd images): https://www.freedesktop.org/software/systemd/man/systemd-random-seed.service.html
From https://github.com/resin-io/reconfix/issues/8

Closing as a duplicate of #718


rename class name to HourRotator

this file is Hour Rotator not day Rotator

Checklist

[ ] npm test passes
[ ] tests and/or benchmarks are included
[ ] documentation is changed or added
[ ] commit message follows commit guidelines

Affected core subsystem(s)

Description of change

👍


Decide how to keep clean the terminal output when running on prod

Currently we have configured that the logs are output to the stderr instead of the stdout to be able to distinguish them from actual terminal output.  This will enable that the stderr is output to a file on the running application, and then the stdout will be what will be shown in the terminal for the processing part.
We should consider some options to enable this processing to be useful, showing the progress, what was done, any possible failure, etc:

Create a reporter interface that contains an implementation to both log and print to the stdout. The ammount of information might depend on some parameter that can be set into the CLI.
Change the output for all the logs to a file directly instead of logging to stderr, and then control on the log that is output to stderr/stdout only the loggers that belong to our application (for example, INFO to stdout and WARN or higher to stderr).

Also, as we are refining/simplifying now the application configuration, we will remove the customization on the format for the logs in production, but this config can be useful if we go for the stdout logging idea to keep only the processing info:
quarkus:
  log:
    console:
      format: "[%-5p - %d{yyyy-MM-dd HH:mm:ss}] - %s%n"


Update README.md

added name
Related issue

What changes does this PR do?
Screenshots (If any)
Questions

duplicate of #3056


Variable copy/paste

Can copy value or path from any variable in list with buttons
Can paste value or path into any Value field with a button

Path

Literal changes to reference
Reference sets value
Expression adds variable

Value

Literal sets value
Reference changes to literal
Expression adds variable

Going to change this to use a custom right click menu


Allow running tests directly on runner

Changes

Adds useContainer that when set to false will just execute GUT tests on local runner
Adds godotExecutable to change/configure executable for GUT to use

Great job for your work, this PR actually fit my needs. I was struggled with container network issue in the pass few days.

@deflinhec, glad it was able to do so! Let me know if you encounter any issues.


Content Out of Date

Working through this article and notice that When I follow "Accessing Office Connectors in Outlook on the Web" with an Office 365 account, settings no longer shows "Manage Connectors", actually the screen shot shows Skype in Outlook on the Web, so probbaly has been out of date for some time.
Outlook on the Web Group Settings looks a little different now as well, but I can see the option for connectors there.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fc039d3b-b1e6-79ae-3b83-6e90d7d8af94
Version Independent ID: f72d624f-36b9-bab1-9c14-e9fc1e81082b
Content: What are actionable messages in Office 365? - Outlook Developer
Content Source: docs/actionable-messages/index.md
Product: outlook
Technology: o365-connectors
GitHub Login: @jasonjoh
Microsoft Alias: jasonjoh

I'm working with the engineering team to get an answer on this. Thanks for reporting @dkotars!

@SiddharthaVinnakote @avijityadav can you clarify?


Could someone please extend the so called API on the website with clearer examples?

As it is VERY vague at best. I find it hard to see exactly HOW this is so much greater that other grid systems, as I'm having a hard time figuring out exactly what MOVE does. What's it good for? When I click the View example button, it scrolls me to a section with three cols that's prefixed with the word SHIFT!? Totally confusing ...
Could someone please elaborate on the API documentation without assuming a hell of a lot?
Thanks (if anyone is listening at all ...).

Hey, sorry, yes the docs on the website are wrong. I'm so sorry for wasting your time.
I'm extremely poor right now or I'd fix them. These docs are correct: https://github.com/mojotech/jeet/tree/master/docs
And if you'd like to help others who might be in your situation, feel free to fork/clone this repo, checkout gh-pages, follow the README (https://github.com/mojotech/jeet/tree/gh-pages), and update the docs to be correct.
shift was replaced with move since "shift" is a reserved word in Stylus (and maybe Sass as well).
It's used for source ordering (http://zurb.com/word/source-order). tl;dr If you want a sidebar to be on the right on desktop, and content on the left. But on mobile you want the sidebar to appear above the content, you'd need to either use flexbox order (which is what most people do nowadays—Jeet is pretty old and move is really only useful for old browsers), or you could have the html look like this:

  Sidebar

Content

...then on desktop have some CSS that turns it into columns:
@media (min-width: 700px) {
  div {
    float: left;
    width: 75%;
  }

  aside {
    float: right;
    width: 25%;
  }
}

This is just an example of the concept of "source ordering". Jeet, and many other grids, does this shifting around (or "moving") via position: relative; left: some percentage.
Hope that clears it up.
Again, I'm extremely sorry for the frustration. Please help me out and contribute so others don't run into this problem. 🙇

Hi Cory,
Sorry to hear that. And I’d be more than happy to help. My problem is, that I simply don’t understand the docs. The description of what move and offset actually do is unclear – it should be shown by an example (I’d be happy to provide those if I understood their purpose).
At the moment I’m trying (very time consuming) to have jeet ‘ignore’ the first child of a container. And in that process I can see a major problem with jeet: If I assign a method to a child with a specific class ALL children are taken into consideration – classname or not. I can therefore not get jeet to ignore the first child, let me explain by example:
I’m trying to achieve this (and I have to have them all in the same container due to the flow):
But this is what I get:
Now, I thought (!) that either offset or move would be what I’d need in a situation like this. Well, it’s not. And reading the docs didn’t clear that up.
Now using simple illustrations like the ones above, I’m sure that it would be easier to explain what the various methods actually do …
I’ll help all that I can. But need help understanding the basics (and I don’t get the $cycle either, as it seems like just doubling the functionality of ratio – why is 1/2 not enough to have two cols? .. cycle is somewhat redundant).
Sam Blåsvær
Senior Frontend Architect
20 70 33 60
<EMAIL_ADDRESS>Ådiget 16
2610 Rødovre
www.blaasvaer.dk

On 6 Jul 2017, at 21.52, Cory Simmons<EMAIL_ADDRESS>wrote:
Hey, sorry, yes the docs on the website are wrong. I'm so sorry for wasting your time.
I'm extremely poor right now or I'd fix them. These docs are correct: https://github.com/mojotech/jeet/tree/master/docs https://github.com/mojotech/jeet/tree/master/docs
And if you'd like to help others who might be in your situation, feel free to fork/clone this repo, checkout gh-pages, follow the README (https://github.com/mojotech/jeet/tree/gh-pages https://github.com/mojotech/jeet/tree/gh-pages), and update the docs to be correct.
shift was replaced with move since "shift" is a reserved word in Stylus (and maybe Sass as well).
It's used for source ordering (http://zurb.com/word/source-order http://zurb.com/word/source-order). tl;dr If you want a sidebar to be on the right on desktop, and content on the left. But on mobile you want the sidebar to appear above the content, you'd need to either use flexbox order (which is what most people do nowadays—Jeet is pretty old and move is really only useful for old browsers), or you could have the html look like this:

Sidebar
Content

...then on desktop have some CSS that turns it into columns:
@media (min-width: 700px) {
div {
float: left;
width: 75%;
}
aside {
float: right;
width: 25%;
}
}
This is just an example of the concept of "source ordering". Jeet, and many other grids, does this shifting around (or "moving") via position: relative; left: some percentage.
Hope that clears it up.
Again, I'm extremely sorry for the frustration. Please help me out and contribute so others don't run into this problem. 🙇
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/mojotech/jeet/issues/534#issuecomment-313501145, or mute the thread https://github.com/notifications/unsubscribe-auth/ABI1KQa_PIjbLkTTlhvyjmBoKoWumjGhks5sLTrpgaJpZM4OP-sl.

And if it’s used to reverse the order of dom flow, then move gives the wrong association (move over, as do offset). Reverse would be more descriptive.
Sam Blåsvær
Senior Frontend Architect
20 70 33 60
<EMAIL_ADDRESS>Ådiget 16
2610 Rødovre
www.blaasvaer.dk

On 6 Jul 2017, at 21.52, Cory Simmons<EMAIL_ADDRESS>wrote:
Hey, sorry, yes the docs on the website are wrong. I'm so sorry for wasting your time.
I'm extremely poor right now or I'd fix them. These docs are correct: https://github.com/mojotech/jeet/tree/master/docs https://github.com/mojotech/jeet/tree/master/docs
And if you'd like to help others who might be in your situation, feel free to fork/clone this repo, checkout gh-pages, follow the README (https://github.com/mojotech/jeet/tree/gh-pages https://github.com/mojotech/jeet/tree/gh-pages), and update the docs to be correct.
shift was replaced with move since "shift" is a reserved word in Stylus (and maybe Sass as well).
It's used for source ordering (http://zurb.com/word/source-order http://zurb.com/word/source-order). tl;dr If you want a sidebar to be on the right on desktop, and content on the left. But on mobile you want the sidebar to appear above the content, you'd need to either use flexbox order (which is what most people do nowadays—Jeet is pretty old and move is really only useful for old browsers), or you could have the html look like this:

Sidebar
Content

...then on desktop have some CSS that turns it into columns:
@media (min-width: 700px) {
div {
float: left;
width: 75%;
}
aside {
float: right;
width: 25%;
}
}
This is just an example of the concept of "source ordering". Jeet, and many other grids, does this shifting around (or "moving") via position: relative; left: some percentage.
Hope that clears it up.
Again, I'm extremely sorry for the frustration. Please help me out and contribute so others don't run into this problem. 🙇
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/mojotech/jeet/issues/534#issuecomment-313501145, or mute the thread https://github.com/notifications/unsubscribe-auth/ABI1KQa_PIjbLkTTlhvyjmBoKoWumjGhks5sLTrpgaJpZM4OP-sl.


Fix the metadata mismatch

Based on Issue #17
See the analysis at: https://github.com/deepjyoti30/ytmdl/issues/272
to understand why this approach is more accurate than the native ytmdl implementation.

I didn't test this in different ways - just the latest config and data bits I had. Works perfectly. 👍🏻

@ology, thank you so much, Gene! I will write some relevant unit tests this week, and also tidy it up a bit. I'm optimistic that we can merge this PR by Friday.

LGTM! Tests seem to work. Merging this PR.
If we find any future issues, we can open a new issue in the future.


NoSuchMethodError with 0.6.4 and 1.0

07:57:41 CONSOLE: [INFO] User issued server command: /ht c Tour1
07:57:41 CONSOLE: [INFO] World: world regions 12 Region: hotel-tour1
07:57:42 CONSOLE: ERROR]: null
07:57:42 CONSOLE: exception executing command 'ht' in plugin Hotels v1.0.0
07:57:42 CONSOLE: Source) [?:1.8.0_121]
07:57:42 CONSOLE: Source) [?:1.8.0_121]
07:57:42 CONSOLE: Source) [?:1.8.0_121]
07:57:42 CONSOLE: java.lang.NoSuchMethodError: com.sk89q.worldguard.protection.flags.DefaultFlag.fuzzyMatchFlag(Ljava/lang/String;)Lcom/sk89q/worldguard/protection/flags/Flag;

Is there more to the error?
What version of bukkit/spigot and worldguard and worldedit do you have?
Is your flags.yml the default one?
What build of hotels 1.0.0 are you using?
Sorry for the many questions they are to understand where the issue is as I haven't encountered it.

Flags is default.
Spigot 1.11.2 R0.1-Snapshot
Worldguard 6.2.1-Snapshot-1703-85693b9
I will send you the whole error later when home
Eric
Le 2017-03-03 09:54, "gvlfm78"<EMAIL_ADDRESS>a écrit :

Is there more to the error?
What version of bukkit/spigot and worldguard and worldedit do you have?
Is your flags.yml the default one?
What build of hotels 1.0.0 are you using?
Sorry for the many questions they are to understand where the issue is as
I haven't encountered it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gvlfm78/BukkitHotels/issues/28#issuecomment-283974214,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHPdOHG_CuknjsRcIUKPq_zMkPQzDvScks5riCmngaJpZM4MSO_E
.

Could you try with the latest test build of Hotels, and then, if the issue is still present, paste the whole error from the new build?

I tried the build 72
here the full log:
[11:41:40 INFO]: Antoineprime issued server command: /ht c Tour1
[11:41:40 INFO]: World: world regions 12 Region: hotel-tour1
[11:41:40 ERROR]: null
org.bukkit.command.CommandException: Unhandled exception executing command
'ht' in plugin Hotels v1.0.0
at org.bukkit.command.PluginCommand.execute(PluginCommand.java:46)
~[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
org.bukkit.command.SimpleCommandMap.dispatch(SimpleCommandMap.java:141)
~[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
org.bukkit.craftbukkit.v1_11_R1.CraftServer.dispatchCommand(CraftServer.java:650)
~[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.PlayerConnection.handleCommand(PlayerConnection.java:1344)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.PlayerConnection.a(PlayerConnection.java:1179)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.PacketPlayInChat.a(PacketPlayInChat.java:45)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.PacketPlayInChat.a(PacketPlayInChat.java:1)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.PlayerConnectionUtils$1.run(SourceFile:13)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
Source) [?:1.8.0_121]
at java.util.concurrent.FutureTask.run(Unknown Source) [?:1.8.0_121]
at net.minecraft.server.v1_11_R1.SystemUtils.a(SourceFile:46)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.MinecraftServer.D(MinecraftServer.java:747)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.DedicatedServer.D(DedicatedServer.java:399)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.MinecraftServer.C(MinecraftServer.java:678)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at
net.minecraft.server.v1_11_R1.MinecraftServer.run(MinecraftServer.java:576)
[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_121]
Caused by: java.lang.NoSuchMethodError:
com.sk89q.worldguard.protection.flags.DefaultFlag.fuzzyMatchFlag(Ljava/lang/String;)Lcom/sk89q/worldguard/protection/flags/Flag;
at
gvlfm78.plugin.Hotels.managers.WorldGuardManager.setFlags(WorldGuardManager.java:262)
~[?:?]
at
gvlfm78.plugin.Hotels.managers.WorldGuardManager.hotelFlags(WorldGuardManager.java:282)
~[?:?]
at gvlfm78.plugin.Hotels.Hotel.create(Hotel.java:259) ~[?:?]
at
gvlfm78.plugin.Hotels.HotelsCreationMode.hotelSetup(HotelsCreationMode.java:86)
~[?:?]
at
gvlfm78.plugin.Hotels.handlers.HotelsCommandExecutor.cmdCreate(HotelsCommandExecutor.java:43)
~[?:?]
at
gvlfm78.plugin.Hotels.handlers.HotelsCommandHandler.onCommand(HotelsCommandHandler.java:72)
~[?:?]
at org.bukkit.command.PluginCommand.execute(PluginCommand.java:44)
~[spigot.jar:git-Spigot-d4f98a3-cb61ac0]
... 15 more
2017-03-04 5:10 GMT-05:00 gvlfm78<EMAIL_ADDRESS>
Could you try with the latest test build
https://jenkins-gvl.rhcloud.com/job/Hotels/lastSuccessfulBuild/ of
Hotels, and then, if the issue is still present, paste the whole error from
the new build?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gvlfm78/BukkitHotels/issues/28#issuecomment-284141824,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHPdOFtxxTSWUR7vhOcPNvWraUz7fR52ks5riTiAgaJpZM4MSO_E
.

I found out what the problem is. The WorldGuard API regarding flags changed with WorldGuard 6.2, and Hotels hasn't been updated for it yet. Why not? Because the Maven server Hotels builds against has not been updated with this version. I will ask them to update it.

Can you tell me when it will be fixed?
Eric
Le 2017-03-04 14:05, "gvlfm78"<EMAIL_ADDRESS>a écrit :

I found out what the problem is. The WorldGuard API regarding flags
changed with WorldGuard 6.2, and Hotels hasn't been updated for it yet. Why
not? Because the Maven server Hotels builds against has not been updated
with this version. I will ask them to update it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/gvlfm78/BukkitHotels/issues/28#issuecomment-284173418,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHPdOCMc8oiZRatEKZZ9VUs2e3E09DzXks5ribXogaJpZM4MSO_E
.

I looked again on the server and realised that they changed the name and location of the projects slightly, and that it was after all updated. I therefore updated Hotels to minimum WorldEdit 6.0 and WorldGuard 6.2 in build #75 upwards

Ok this is working now !!!!!
Thank you sooo much !!!

Ok in case you find any other bug please tell me, also tell what build number you're on when you find it, as I am trying to remove all bugs before releasing Hotels 1.0.0


[PagerDuty] Oncall endpoint is limited to 25 by default

cc @drudge
Thanks for such a useful applet.
The functionality to show Oncall status may not work as expected if there are more than 25 on-call schedules on your PagerDuty account.
The /oncall endpoint, when no limit param is specified is paginated to just 25 results. And your shift may be detailed in later results.

The max limit you can specify is 100, which may not be sufficient on PD accounts with more on-call schedules than that.

For the purpose of determining if the current user is on-call, could we either:

specify user_ids[]=profile['id'] to only list the current user's on-call schedules? (This is still limited to 25, which may cater for the majority of PD users, unless they are part of a NOC).
paginate to following pages if more: true? (could impact performance)

Hi @nchieng, thanks for submitting your issue. I've submitted PR #241 to address your feedback. Once reviewed and merged by the Tidbyt team, it should page through all on-calls when determining if a user is on call or not.

Thank you so much @drudge


Fully rename unity_py to unity-sds-client in pypi and in various notebooks that use it

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

I've updated the package name and will issue a PR shortly. This ticket is part of the unity-py repo, we'll probably need to create a separate ticket if we don't have one already to track the changes for the sounder-sips-tutorial notebooks.

https://github.com/unity-sds/sounder-sips-tutorial/pull/47