test compilation warnings

I'm getting following warnings:
riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S: Assembler messages:
riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S:37: Warning: shift count out of range (-1 is not between 0 and 63)
riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S:47: Warning: shift count out of range (-1 is not between 0 and 63)
riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S:62: Warning: shift count out of range (-1 is not between 0 an

...
is this expected?

This looks incorrect. It is not an expected warning message.

And what should I do about this?

This is mostly a problem in the LI macros. Its not due to your execution environment. I don't see any problem in the loaded values. You can ignore these warnings for now. They will be fixed soon.

the only problem is that if riscof fails - my terminal is filled with these warning messages, I don't see real reason for the failure ..

Which version of the arch_test.h macro are you using? I thought that issue
was fixed.
On Mon, Feb 13, 2023 at 6:36 AM algrobman @.***> wrote:

the only problem is that if riscof fails - my terminal is filled with
these warning messages, I don't see real reason for the failure ..
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1428046911,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJVKCJSL2ZUQFHUQK2TWXJBH3ANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

OK, then LI needs to be fixed; can you send an example of where that
occurred and any values that are possible to extract to cause this?
This is the first I've heard of it, so it must have something to do with
the linker relocations, right?
On Tue, Feb 14, 2023 at 12:53 AM S Pawan Kumar @.***>
wrote:

I see this issue on the main branch of arch-test.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1429349407,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJSBPJI6CFIQ3QGBW73WXNBYXANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you commented.Message ID:
@.***>

I didn't change a character in the test sources and env files .
These warnings are not seen if all tests pass, but fill shell window if any of the test fail for whatever reason, including signature comparison

Hmm, cause or effect? Can you send the failure report, and possibly the
linker scripts?
On Wed, Feb 15, 2023 at 10:46 AM algrobman @.***> wrote:

I didn't change a character in the test sources and env files .
These warnings are not seen if all tests pass, but fill shell window if
any of the test fail for whatever reason, including signature comparison
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1431844840,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJTNT5DOO6M5B7IDHO3WXUQARANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you commented.Message ID:
@.***>

I did not change anything from the tests repo, including linker scripts.

If that's the case, you must be comparing Spike with Sail, and there were
no failures when we did it.
If instead you were comparing Sail or Spike vs your DUT, then you are
responsible for the DUT linker script, aren't you?
On Wed, Feb 15, 2023 at 7:59 PM algrobman @.***> wrote:

I did not change anything from the tests repo, including linker scripts.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1432476461,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJW2GCODSUHE5NMQ74LWXWQZNANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you commented.Message ID:
@.***>

Again, I ran  riscof as is without changing files from the tests repo.

But you also said that you didn't see the message when all tests pass, only
when they fail,
which implies that there were test failures - but when we ran the tests
from the test suite,
we got no failures (and if we did, we would not have merged any new
changes).
So which tests failed, and what were the signature mismatches?
On Thu, Feb 16, 2023 at 6:03 AM algrobman @.***> wrote:

Again, I ran riscof as is without changing files from the tests repo.
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1433137078,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJULOAZKG4UYGWR56O3WXYXTJANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you commented.Message ID:
@.***>

I had failure due two issues 1) my core supported misaligned load/stores, but sail was not configured with that.
2) when DUT simulations timed out/killed before I  increased the run timeout as I was advised.
this 2nd case was pretty confusing since this happened after I added B-ext tests, but the failing was a I-ext test and I couldn't see the failure reason as whole the shell window was overloaded with these warnings .
I think you can model this  issue if you set execution timeout to let say 1s

Ah, thanks for that extra information. This starts to make sense, though I
can't say why those warnings are generated.
On Thu, Feb 16, 2023 at 9:38 AM algrobman @.***> wrote:

I had failure due two issues 1) my core supported misaligned load/stores,
but sail was not configured with that.
2) when DUT simulations timed out/killed before I increased the run
timeout as I was advised.
this 2nd case was pretty confusing since this happened after I added B-ext
tests, but the failing was a I-ext test and I couldn't see the failure
reason as whole the shell window was overloaded with these warnings .
I think you can model this issue if you set execution timeout to let say 1s
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1433464859,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJRD6YLEZOLI7JIVCIDWXZQXZANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you commented.Message ID:
@.***>

To reiterate: you say you are not changing any scripts, but you needed to configure Sail to support misaligned (which will be fixed at some point), and you changed the timeout value (are you running on a particularly slow server?) and you had to supply your own custom linker script.
IT is completely unclear for the above description if those warning and failures go away when misaligned is supported and the timeout is increased or not - you are not giving us enough information.
IF you are still seeing these issues, please send us a copy of the shell window so we can see what is going on.
If not - it would still be useful to figure out why a timeout - or an actual test failure - would cause the specific error message that you're seeing.

@allenjbaum , Are you reading the thread? @pawks sees the same issue. (i.e. warnings caused by LI instructions).
Assembler warnings don't kill the tests and seems the tests are simulated correctly. But 1) the tests shouldn't generate warnings if written correctly. 2) if something is going wrong, these warnings from all these tests just fill shell history, making hard to figure out the failure reason.
Regarding my updates - I'm changing only sail simulator and DUT python plugins, just adding -m option for sail run command and
updating execution command for my RTL simulator . Running verilog simulation more than 5min for more than 100 tests seems to me quite reasonable. Again I do not change any file from the RISCV tests repository, so you should be able reproduce these warnings and fix your tests

if you run one test target  you can see all these warnings.

these warnings come from your super complex macro: (arch_test,h)
#define LI(reg, imm)                                                            ;\
  .option push                                                                  ;\
  .option norvc                                                                 ;\
  .set even,    (1-BIT(imm, 0)) /* imm has at least 1 trailing zero     */      ;\
  .set immx,    (imm & MASK)    /* trim to XLEN (noeffect on RV64)      */      ;\
  .set imm12,   (SEXT_IMM(immx))                                                ;\
  .set absimm,  ((immx^(-BIT(immx,XLEN-1)))&MASK) /* cvt to posnum to simplify code */  ;\
  .set imme,    ((immx^(-BIT(immx,0     )))&MASK) /* cvt to even, cvt back at end */    ;\
  .set cry,     (BIT(immx, IMMSGN))                                             ;\
  .set cryh,    (BIT(immx, IMMSGN+32))                                          ;\
  .set pos,      0                                                              ;\
  .set edge1,   -1              /* 1st "1" bit pos scanning r to l      */      ;\
  .set edge2,   -1              /* 1st "0" bit pos scanning r to l      */      ;\
/**** find 1st 0->1, then 1->0 transition fm LSB->MSB given even operand ****/  ;\
  .rept XLEN                                                                    ;\
    .if     (edge1<0)           /* looking for first edge?              */      ;\
      .if (BIT(imme,pos)==1)    /* look for falling edge[pos]           */      ;\
        .set  edge1,pos         /* fnd falling edge, don’t chk for more */      ;\
      .endif                                                                    ;\
    .elseif (edge2<0)           /* looking for second edge?             */      ;\
      .if (BIT(imme,pos)==0)    /* yes, found rising edge[pos]?         */      ;\
         .set  edge2, pos       /* fnd rising  edge, don’t chk for more */      ;\
      .endif                                                                    ;\
    .endif                                                                      ;\
    .set    pos,  pos+1         /* keep looking (even if already found) */      ;\
  .endr                                                                         ;\
  .set immxsh, (immx>>edge1)    /* *sh variables only used if positive  */      ;\
  .set imm12sh,(SEXT_IMM(immxsh))/* look @1st 12b of shifted imm val    */      ;\
  .set crysh,     (BIT(immxsh, IMMSGN))                                          ;\
  .set absimmsh, immxsh         /* pos, no inversion needed, just shift */      ;\
/*******does it fit into std li or lui+li sequence****************************/ ;\
  .if     ((absimm>>IMMSGN)==0) /* fits 12b signed imm (properly sgnext)? */    ;\
       li   reg, imm12         /* yes, <= 12bit, will be simple li       */    ;\
  .elseif (XLEN < 64 || (absimm+ (cry << IMMSZ) >> WDSGN)==0) /* fits 32b sgn imm?(w/ sgnext)?    */    ;\
        lui  reg, (((immx>>IMMSZ)+cry) & LIMMMSK) /* <= 32b, use lui/addi */    ;\
    .if   ((imm&IMMMSK)!=0)     /* but skip this if lower bits are zero   */    ;\
        addi reg, reg, imm12                                                    ;\
    .endif                                                                      ;\
 /*********** look for various masks 0s->1s->0s, etc **********************/    ;\
  .elseif ( even && (edge2==-1))        /* only rising  edge, so 111000   */    ;\
         li      reg, -1                                                         ;\
        slli    reg, reg, edge1         /* make 111s --> 000s mask        */    ;\
  .elseif (!even && (edge2==-1))        /* only falling edge, so 000111   */    ;\
        li      reg, -1                                                         ;\
        srli    reg, reg, XLEN-edge1    /* make 000s --> 111s mask        */    ;\
  .elseif (imme == (1<<edge1))          /* check for single bit case      */    ;\
        li      reg, 1                                                          ;\
        slli    reg, reg, edge1         /* make 0001000 sgl bit mask      */    ;\
    .if   (!even)                                                               ;\
        xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\
    .endif                                                                      ;\
  .elseif (imme == ((1<<edge2) - (1<<edge1))) /* chk for multibit case    */    ;\
       li      reg, -1                                                         ;\
        srli    reg, reg, XLEN-(edge2-edge1) /* make multibit 1s mask     */    ;\
        slli    reg, reg, edge1         /* and put it into position       */    ;\
    .if   (!even)                                                               ;\
        xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\
    .endif                                                                      ;\
  /************** look for 12b or 32b imms with trailing zeroes ***********/    ;\
  .elseif ((immx==imme)&&((absimmsh>>IMMSGN)==0))/* fits 12b after shift? */    ;\
        li      reg, imm12sh            /* <= 12bit, will be simple li    */    ;\
        slli    reg, reg, edge1         /* add trailing zeros             */    ;\
  .elseif ((immx==imme)&&(((absimmsh>>WDSGN)+crysh)==0)) /* fits 32 <<shft? */  ;\
        lui     reg, ((immxsh>>IMMSZ)+crysh)&LIMMMSK /* <=32b, use lui/addi*/    ;\
    .if   ((imm12sh&IMMMSK)!=0)         /* but skip this if low bits ==0  */    ;\
        addi    reg, reg, imm12sh                                               ;\
    .endif                                                                      ;\
        slli    reg, reg, edge1         /* add trailing zeros             */    ;\
  .else                                 /* give up, use fixed 8op sequence*/    ;\
   /******* TBD add sp case of zero short imms, rmv add/merge shifts *******/   ;\
        lui     reg, ((immx>>(XLEN-LIMMSZ))+cryh)&LIMMMSK /* 1st 20b (63:44)*/  ;\
        addi    reg, reg, SEXT_IMM(immx>>32)            /* nxt 12b (43:32) */   ;\
        slli    reg, reg, 11    /* following are <12b, don't need SEXT     */   ;\
        addi    reg, reg, (immx>>21) & (IMMMSK>>1)      /* nxt 11b (31:21) */   ;\
        slli    reg, reg, 11                            /* mk room for 11b */   ;\
        addi    reg, reg, (immx>>10) & (IMMMSK>>1)      /* nxt 11b (20:10) */   ;\
        slli    reg, reg, 10                            /* mk room for 10b */   ;\
    .if   ((imm&(IMMMSK>>2))!=0) /* but skip this if lower bits are zero   */   ;\
        addi    reg, reg, (immx)     & (IMMMSK>>2)      /* lst 10b (09:00) */   ;\
    .endif                                                                      ;\
    .if (XLEN==32)                                                              ;\
        .warning "Should never get here for RV32"                               ;\
    .endif                                                                      ;\
 .endif                                                                         ;\

BTW, just curious, why isn't  just assembly 'li' pseudo instruction sufficient?

I was quite certain that it came from LI; what I would like to know is
which immediate is causing that to happen;
I don't recall seeing it when we tested it, and looking through the code,
it shouldn't be possible (with the latest version of the macro)
It shifts by edge1 (which is the result of a count_trailing_zeros loop on
an even number), so must be in the range 1..XLEN-1
If it all zeroes, it is -1, but the all-zeros case never shifts anything
(because it fits into a 12bit immediate)
IF there is an escape in this logic, I'd like to find it.
But, that's a good question - why our own version.
The answer is that we need these to have the same length, regardless of
toolchain,
and we couldn't guarantee that all tochains did that, or even if they did,
used exactly the same instructions.
So we guaranteed it by making our own definition.
On Mon, Feb 20, 2023 at 3:05 PM algrobman @.***> wrote:

these warnings come from your super complex macro: (arch_test,h)
#define LI(reg, imm)                                                            ;\
.option push                                                                  ;\
.option norvc                                                                 ;\
.set even,    (1-BIT(imm, 0)) /* imm has at least 1 trailing zero     */      ;\
.set immx,    (imm & MASK)    /* trim to XLEN (noeffect on RV64)      */      ;\
.set imm12,   (SEXT_IMM(immx))                                                ;\
.set absimm,  ((immx^(-BIT(immx,XLEN-1)))&MASK) /* cvt to posnum to simplify code */  ;\
.set imme,    ((immx^(-BIT(immx,0     )))&MASK) /* cvt to even, cvt back at end */    ;\
.set cry,     (BIT(immx, IMMSGN))                                             ;\
.set cryh,    (BIT(immx, IMMSGN+32))                                          ;\
.set pos,      0                                                              ;\
.set edge1,   -1              /* 1st "1" bit pos scanning r to l      */      ;\
.set edge2,   -1              /* 1st "0" bit pos scanning r to l      */      ;\
/**** find 1st 0->1, then 1->0 transition fm LSB->MSB given even operand ****/  ;\
.rept XLEN                                                                    ;\
.if     (edge1<0)           /* looking for first edge?              */      ;\

  .if (BIT(imme,pos)==1)    /* look for falling edge[pos]           */      ;\

    .set  edge1,pos         /* fnd falling edge, don’t chk for more */      ;\

  .endif                                                                    ;\

.elseif (edge2<0)           /* looking for second edge?             */      ;\

  .if (BIT(imme,pos)==0)    /* yes, found rising edge[pos]?         */      ;\

     .set  edge2, pos       /* fnd rising  edge, don’t chk for more */      ;\

  .endif                                                                    ;\

.endif                                                                      ;\

.set    pos,  pos+1         /* keep looking (even if already found) */      ;\

.endr                                                                         ;\
.set immxsh, (immx>>edge1)    /* *sh variables only used if positive  */      ;\
.set imm12sh,(SEXT_IMM(immxsh))/* look @1st 12b of shifted imm val    */      ;\
.set crysh,     (BIT(immxsh, IMMSGN))                                          ;\
.set absimmsh, immxsh         /* pos, no inversion needed, just shift */      ;\
/does it fit into std li or lui+li sequence*********************/ ;\
.if     ((absimm>>IMMSGN)==0) /* fits 12b signed imm (properly sgnext)? */    ;\
   li   reg, imm12         /* yes, <= 12bit, will be simple li       */    ;\

.elseif (XLEN < 64 || (absimm+ (cry << IMMSZ) >> WDSGN)==0) /* fits 32b sgn imm?(w/ sgnext)?    */    ;\
    lui  reg, (((immx>>IMMSZ)+cry) & LIMMMSK) /* <= 32b, use lui/addi */    ;\

.if   ((imm&IMMMSK)!=0)     /* but skip this if lower bits are zero   */    ;\

    addi reg, reg, imm12                                                    ;\

.endif                                                                      ;\

/*********** look for various masks 0s->1s->0s, etc **********************/    ;\
.elseif ( even && (edge2==-1))        /* only rising  edge, so 111000   */    ;\
     li      reg, -1                                                         ;\

    slli    reg, reg, edge1         /* make 111s --> 000s mask        */    ;\

.elseif (!even && (edge2==-1))        /* only falling edge, so 000111   */    ;\
    li      reg, -1                                                         ;\

    srli    reg, reg, XLEN-edge1    /* make 000s --> 111s mask        */    ;\

.elseif (imme == (1<<edge1))          /* check for single bit case      */    ;\
    li      reg, 1                                                          ;\

    slli    reg, reg, edge1         /* make 0001000 sgl bit mask      */    ;\

.if   (!even)                                                               ;\

    xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\

.endif                                                                      ;\

.elseif (imme == ((1<<edge2) - (1<<edge1))) /* chk for multibit case    */    ;\
   li      reg, -1                                                         ;\

    srli    reg, reg, XLEN-(edge2-edge1) /* make multibit 1s mask     */    ;\

    slli    reg, reg, edge1         /* and put it into position       */    ;\

.if   (!even)                                                               ;\

    xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\

.endif                                                                      ;\

/************** look for 12b or 32b imms with trailing zeroes ***********/    ;\
.elseif ((immx==imme)&&((absimmsh>>IMMSGN)==0))/* fits 12b after shift? */    ;\
    li      reg, imm12sh            /* <= 12bit, will be simple li    */    ;\

    slli    reg, reg, edge1         /* add trailing zeros             */    ;\

.elseif ((immx==imme)&&(((absimmsh>>WDSGN)+crysh)==0)) /* fits 32 <<shft? */  ;\
    lui     reg, ((immxsh>>IMMSZ)+crysh)&LIMMMSK /* <=32b, use lui/addi*/    ;\

.if   ((imm12sh&IMMMSK)!=0)         /* but skip this if low bits ==0  */    ;\

    addi    reg, reg, imm12sh                                               ;\

.endif                                                                      ;\

    slli    reg, reg, edge1         /* add trailing zeros             */    ;\

.else                                 /* give up, use fixed 8op sequence*/    ;\
/******* TBD add sp case of zero short imms, rmv add/merge shifts *******/   ;\
    lui     reg, ((immx>>(XLEN-LIMMSZ))+cryh)&LIMMMSK /* 1st 20b (63:44)*/  ;\

    addi    reg, reg, SEXT_IMM(immx>>32)            /* nxt 12b (43:32) */   ;\

    slli    reg, reg, 11    /* following are <12b, don't need SEXT     */   ;\

    addi    reg, reg, (immx>>21) & (IMMMSK>>1)      /* nxt 11b (31:21) */   ;\

    slli    reg, reg, 11                            /* mk room for 11b */   ;\

    addi    reg, reg, (immx>>10) & (IMMMSK>>1)      /* nxt 11b (20:10) */   ;\

    slli    reg, reg, 10                            /* mk room for 10b */   ;\

.if   ((imm&(IMMMSK>>2))!=0) /* but skip this if lower bits are zero   */   ;\

    addi    reg, reg, (immx)     & (IMMMSK>>2)      /* lst 10b (09:00) */   ;\

.endif                                                                      ;\

.if (XLEN==32)                                                              ;\

    .warning "Should never get here for RV32"                               ;\

.endif                                                                      ;\

.endif                                                                         ;\
BTW, just curious, why isn't just assembly 'li' pseudo instruction
sufficient?
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1437653467,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJXJ7FR5OZKSCCHVJSDWYP2EXANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you were mentioned.Message ID:
@.***>

The answer is that we need these to have the same length, regardless of toolchain,

Could you please elaborate, what do you mean by "the same length" (or length of what) and why did you need this? - the goal of LI is just to set a register a value. Thus for 64 bits CPU li translates to different number of instructions than for 32 bit CPUs.
Also the compiler can exploit constant value to use less instructions. Looking in your macro, seems it  generates different number of instructions as well, depending on the constant,  and uses different instructions too.
We always use LI/LA pseudos' in our tests with no need in special macro.

I was quite certain that it came from LI; what I would like to know is which immediate is causing that to happen;

see initial description. the warnings  point to exact test code lines .

The same length means the same number of ops/bytes in the expansion of the
LI.
If LI generates differing lengths, (between the reference and the DUT),
then trap signatures will have different xEPC, and xTVAL values.
Because the linker scripts can be different as well, we compensate by
adjusting EPC and TVAL (when it holds an address)
to be an offset from the rvtest_data_begin and rvtests_code_begin labels.
But that doesn't compensate for random
different offsets caused by different sized li pseudoops. , .align
directives can also magnify the effect of that (or remove it...).
We have a fixed sized version that does a .align before, and a .align
after, but it really blows up the length of the tests,
which is why I wanted something much more compact. This isn't perfect, but
captures most of the use cases for the trap handler.
Tests are stuck with using that form of LA, though, especially as a bare
"la" won't work with different linker scripts.
The trap handler has been updated to remove almost all cases of LA from it
(that will be in the next version),
at the cost of requiring tests that create/update/modify page tables have
to update trp handler data structures to match.
On Mon, Feb 20, 2023 at 5:55 PM algrobman @.***> wrote:

The answer is that we need these to have the same length, regardless of
toolchain,
Could you please elaborate, what do you mean by "the same length" (or
length of what) and why did you need this? - the goal of LI is just to set
a register a value. Thus for 64 bits CPU li translates to different number
of instructions than for 32 bit CPUs.
Also the compiler can exploit constant value to use less instructions.
Looking in your macro, seems it generates different number of instructions
as well, depending on the constant, and uses different instructions too.
We always use LI/LA pseudos' in our tests with no need in special macro.
I was quite certain that it came from LI; what I would like to know is
which immediate is causing that to happen;
see initial description. the warnings point to exact test code lines .
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1437753396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJQUVVS3QQJGG6QMYVLWYQOCZANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you were mentioned.Message ID:
@.***>

What is strange is we have test code using those constants, and it compiled
correctly.
For RV32, it should always generate either  should always generate the
sequence
addi, reg, x0, imm
for small numbers in the range -2048..2047 inclusive, or
addi, reg, x0, (imm+(cry<<12)>>12; addi reg, reg, SEXT_IMM(imm)
otherwise, with no shifting - all that other cod in that complicated macro
is essentially for RV64 (or 128, I suppose)
I don't suppose you could produce a disassembly listing of this test...?
On Mon, Feb 20, 2023 at 9:42 PM Allen Baum @.***>
wrote:

The same length means the same number of ops/bytes in the expansion of the
LI.
If LI generates differing lengths, (between the reference and the DUT),
then trap signatures will have different xEPC, and xTVAL values.
Because the linker scripts can be different as well, we compensate by
adjusting EPC and TVAL (when it holds an address)
to be an offset from the rvtest_data_begin and rvtests_code_begin labels.
But that doesn't compensate for random
different offsets caused by different sized li pseudoops. , .align
directives can also magnify the effect of that (or remove it...).
We have a fixed sized version that does a .align before, and a .align
after, but it really blows up the length of the tests,
which is why I wanted something much more compact. This isn't perfect, but
captures most of the use cases for the trap handler.
Tests are stuck with using that form of LA, though, especially as a bare
"la" won't work with different linker scripts.
The trap handler has been updated to remove almost all cases of LA from it
(that will be in the next version),
at the cost of requiring tests that create/update/modify page tables have
to update trp handler data structures to match.
On Mon, Feb 20, 2023 at 5:55 PM algrobman @.***>
wrote:

The answer is that we need these to have the same length, regardless of
toolchain,
Could you please elaborate, what do you mean by "the same length" (or
length of what) and why did you need this? - the goal of LI is just to set
a register a value. Thus for 64 bits CPU li translates to different number
of instructions than for 32 bit CPUs.
Also the compiler can exploit constant value to use less instructions.
Looking in your macro, seems it generates different number of instructions
as well, depending on the constant, and uses different instructions too.
We always use LI/LA pseudos' in our tests with no need in special macro.
I was quite certain that it came from LI; what I would like to know is
which immediate is causing that to happen;
see initial description. the warnings point to exact test code lines .
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1437753396,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJQUVVS3QQJGG6QMYVLWYQOCZANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you were mentioned.Message ID:
@.***>

We think that this may be a quirk in the way assembler macros are processed; e.g. it generates all possible code paths, then chooses the right one depending on the conditions it has evaluated, but that process generates warnings that are not suppressed in code that is generated but not selected. We could fix this for RV32, but unclear if we can for RV64 (which is where the bulk of the code is used)

What I care about is RV32 for now. You could have two versions of the macro - one for 32 and another for 64 bits platforms

I'm working on that theory.
To be clear: you can pass all the tests when misaligned is properly
configured in sail, and timeouts are increased - but still get those
warnings, and you want the warnings removed.
On Tue, Feb 21, 2023 at 6:10 AM algrobman @.***> wrote:

What I care about is RV32 for now. You could have two versions of the
macro - one for 32 and another for 64 bits platforms
—
Reply to this email directly, view it on GitHub
https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1438561021,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJVC4ARNELD5V35PG53WYTEHDANCNFSM6AAAAAAUY5JYLE
.
You are receiving this because you were mentioned.Message ID:
@.***>

but still get those warnings, and you want the warnings removed.

Exactly  - warning removal/fix was the original intent of this issue! . Other stuff is just ways to see the warnings impact on user.
One more way to see these warnings  probably is to corrupt one of the tests to make it fail compilation ..


feat: duality results for the right homology of short complexes

This PR shows duality results for left and right homology of short complexes. From the corresponding result for left homology, it is deduced that a morphism of short complexes which is epi on the left object, iso on the middle object and mono on the right object induces an isomorphism in right homology.

[x] depends on: #6089

bors merge


Setting up CORS properly

Hi,
I don't know what I am doing wrong here but when trying to setup CORS with an example config like this:
corsHandler: {       value: {         origin: ['some.site.ever.com'],         methods: ['POST']       },       route: ''     }
But when I'm posting using insomnia to localhost:3000/api/test it gives me result like this, my assumption is that the access-control-allow-origin key would change but it stays at *.
Am I doing something wrong here or is it some kind of a bug?

After reading the CORS documentation, it seems to me that in order to correctly handle CORS, a request that is coming to a server would need to have a header Origin set to the some.site.ever.com so that the server will then compare it with access-control-allow-origin: ['some.site.ever.com'] and if there will be a match, then in the response headers you will get access-control-allow-origin: ['some.site.ever.com']
Also another useful resource -> https://web.dev/cross-origin-resource-sharing/

Added to https://github.com/Baroshem/nuxt-security/issues/97

@jfrelik
Hey, if you need some additional info on setting CORS, please let me know. Otherwise, could you please close the issue? :)

Hi @Baroshem,
first of all, thank you for such a nice and flexible solution to set up the security settings of the Nuxt app, that's helped me a lot!
I hope you can help me to understand one question because I'm a bit stuck with settings up the CORS settings correctly.
There's a situation when I need explicitly set the Access-Control-Allow-Origin header to a specific URL, regardless of whether the Origin request header is set or not.
So, when some request was made from the resource that does not correspond to a specific URL specified in Access-Control-Allow-Origin, it must be rejected.
And I expect to see such an error response if the origins are not matched (or if the Origin header isn't set in the request at all):
Access to fetch at 'https://myapp.com/' from origin 'https://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

But now, if the request Origin header isn't set, in the response an * is added to the Access-Control-Allow-Origin header, even if it was set explicitly.
So, how to handle that?
Thank you

I also found this info about it:

If the Origin request header is not set, the server cannot determine the origin of the request. In this case, if the Access-Control-Allow-Origin header is also not set to * or to the specific origin of the request, the server should reject the request by sending an HTTP 403 Forbidden response.
This is because the Access-Control-Allow-Origin header is a crucial security mechanism that is used to protect against cross-site request forgery (CSRF) attacks. By specifying the origins that are allowed to access a resource, the server can prevent unauthorized access and protect sensitive data.
If the Access-Control-Allow-Origin header is not set, it means that the server is not explicitly allowing any origins to access the resource. In this case, if the Origin header is also not set, the server cannot determine the origin of the request and should reject it to prevent any potential security vulnerabilities.

Hey @maxdzin
You have asked this question in a bit bad moment as I just yesterday deprecated the current CORS handler and will be migrating to a new one in the upcoming weeks (h3-cors package that I was using was deprecated and merged to core H3 functionality).
I will be diving into the topic more and will be able to deliver a new functionality that would allow to correctly handle CORS.
For now, you can check the H3 docs about using CORS.
Also, if you would be interested in doing a bit of research on how to implement this in Security module that would be much appreciated!
https://github.com/unjs/h3

Hi @Baroshem
Thank you! I saw about the deprecation and looked at how it was merged into H3.
I checked sources and I can see that the problem is in createOriginHeaders method:
export function createOriginHeaders(
  event: H3Event,
  options: H3CorsOptions
): H3AccessControlAllowOriginHeader {
  const { origin: originOption } = options;
  const origin = getRequestHeader(event, "origin");

  if (!origin || !originOption || originOption === "*") {
    return { "access-control-allow-origin": "*" };
  }

  if (typeof originOption === "string") {
    return { "access-control-allow-origin": originOption, vary: "origin" };
  }

  return isCorsOriginAllowed(origin, options)
    ? { "access-control-allow-origin": origin, vary: "origin" }
    : {};
}

That's where this check is - if the Origin request header is not set, then an "*" is set to the access-control-allow-origin is returned.
I'll check more on how it should be solved, maybe some nice idea will come to mind.
But at first glance, it seems that this method needs to be changed (maybe add some additional option for that check).
Or add some changes where defineCorsEventHandler is used.
Let's see then.

Hey @maxdzin
I think that I have an answer to you. The CORS wont work when you are fetching data from the same nuxt app as it the origin of the request is the same for browser and server.
It will start working when the origin is different.
For example, you can create two nuxt applications where one is listening on port 3000 while the second on port 8000 for example. Normally the app 8000 can request the app 3000 without any issues ( because of access-control-allow-origin: *). The CORS will start working once we set configiuration origin to something, i.e.
  security: {
    corsHandler: {
      value: {
        origin: 'http://localhost:3000'
      }
    }
  }

Now, when you will try to fetch data from app 3000 in app 8000, you will get a proper CORS error because the origin header is present and has a value of 8000 while the first app is configured to only accepts request:

Hi @Baroshem
OK. Let me tell you what I noticed.
Yes, I used these corsHandler settings before:
    corsHandler: {
      value: {
        origin: process.env.NUXT_APP_URL ? [process.env.NUXT_APP_URL] : '*',
        methods: ['GET', 'HEAD', 'PUT', 'PATCH', 'POST', 'DELETE'],
        preflight: {
          statusCode: 204,
        },
      },
      route: '',
    },

I passed that value as string[], i.e. [process.env.NUXT_APP_URL] since it shows a type error if string value is used instead of array.
interface CorsOptions {
    origin?: "*" | "null" | (string | RegExp)[] | ((origin: string) => boolean);
    ...

and this one merged in unjs/h3 as well:

export interface H3CorsOptions {
  origin?: "*" | "null" | (string | RegExp)[] | ((origin: string) => boolean);
  ...

So, I believe, there's some fix is needed at least on that option type.
And the problem is probably with this method:
export function createOriginHeaders(
  event: H3Event,
  options: H3CorsOptions
): H3AccessControlAllowOriginHeader {
  const { origin: originOption } = options;
  const origin = getRequestHeader(event, "origin");

  if (!origin || !originOption || originOption === "*") {
    return { "access-control-allow-origin": "*" };
  }

  if (typeof originOption === "string") {
    return { "access-control-allow-origin": originOption, vary: "origin" };
  }

  return isCorsOriginAllowed(origin, options)
    ? { "access-control-allow-origin": origin, vary: "origin" }
    : {};
}

In the last line check - if it is not isCorsOriginAllowed, then it is not set access-control-allow-origin.
But in order to set the response correctly, I think, it must return the originOption value, isn't it?
Or am I missing something?
So, when corsHandler.value.origin is set as a string, it works, but if it is set as an array of strings or an array of RegExp, it is not.

Hey,
I believe it is a bug on h3-cors and now H3. Would you mind if I create an issue in H3 package with your findings and firing a pull request to them to coreect the type? :)

@Baroshem Oh. I created an issue in H3 and just saw your message.
If you think that you should create a PR, sure, go ahead. Or I can do that.

@maxdzin
I can create a PR tomorrow :)

@Baroshem nice!
Please, take a look at these lines in the createOriginHeaders method as well:
if (!origin || !originOption || originOption === "*") {
  return { "access-control-allow-origin": "*" };
}

Probably it should be like this:
if ((!origin && !originOption) || originOption === "*") {
  return { "access-control-allow-origin": "*" };
}

Otherwise, it set the header to * when the origin value (from the request header) is empty and the originOption is set to some specific URL.
Besides, maybe that method can be even simplified if access-control-allow-header should be set by originOption if its value is different from * or null or undefined, but I'm not sure.

@maxdzin
Hey,
I needed to do some fixes to the module (for some reason I couldn't load the h3 types to the app and because of that the build command was failing). To fix that, I needed to create my local CorsOptions type where I have included the different type for the CORS options -> https://github.com/Baroshem/nuxt-security/commit/1b94de66f38706ee419646a2a447bd63dc2da138
When using CORS from Nuxt security this will be now valid origin: 'http://your-page.io'
origin?: "*" | "null" | string | (string | RegExp)[] | ((origin: string) => boolean);

@Baroshem It works well! Thank you 🙏


Skip armv7 for iOS11+ AppCheck

Fix #7981
Surgical fix for building AppCheck and avoiding failure trying to build armv7.
Makes the build order deterministic to avoid hard to repro issues and because AppCheck needs to be built last.
We'll need a more robust fix if we continue iOS 10 support for much longer.
#no-changelog

LGTM mostly, one question about Apple silicon Macs, plus reverting the .yml files afterwards.

The GHA failure is weird. It doesn't repro in a small example. I got it to reproduce in the debugger. Somehow a simple archive is being built instead of an architecture?
Compiling PromisesObjC for iphonesimulator (i386 x86_64 arm64) with command:
/usr/bin/xcodebuild build -configuration release -workspace /var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/FrameworkMaker.xcworkspace -scheme PromisesObjC GCC_GENERATE_DEBUGGING_SYMBOLS=NO ARCHS=i386 x86_64 arm64 VALID_ARCHS**=i386 x86_64 arm64** ONLY_ACTIVE_ARCH=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES SUPPORTS_MACCATALYST=NO BUILD_DIR=/var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator -sdk iphonesimulator OTHER_CFLAGS=$(value) -DFIREBASE_BUILD_ZIP_FILE
2021-04-27 15:51:44.259833-0700 xcodebuild[19796:32669959] Metal API Validation Enabled
2021-04-27 15:51:44.455908-0700 xcodebuild[19796:32669889] warning:  The file reference for "GoogleAppMeasurement-xcframeworks.sh" is a member of multiple groups ("Support Files" and "Support Files"); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2021-04-27 15:51:44.455965-0700 xcodebuild[19796:32669889] warning:  The file reference for "GoogleAppMeasurement.debug.xcconfig" is a member of multiple groups ("Support Files" and "Support Files"); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2021-04-27 15:51:44.455991-0700 xcodebuild[19796:32669889] warning:  The file reference for "GoogleAppMeasurement.release.xcconfig" is a member of multiple groups ("Support Files" and "Support Files"); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
Successfully built PromisesObjC for iphonesimulator. Build log is at file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/build_logs/PromisesObjC-iphonesimulator.txt.
buildDir: file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/
buildSliced returns file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/
Compiling PromisesObjC for catalyst (x86_64 arm64) with command:
/usr/bin/xcodebuild build -configuration release -workspace /var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/FrameworkMaker.xcworkspace -scheme PromisesObjC GCC_GENERATE_DEBUGGING_SYMBOLS=NO ARCHS=x86_64 arm64 VALID_ARCHS=x86_64 arm64 ONLY_ACTIVE_ARCH=NO BUILD_LIBRARY_FOR_DISTRIBUTION=YES SUPPORTS_MACCATALYST=YES BUILD_DIR=/var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/catalyst -sdk macosx OTHER_CFLAGS=$(value) -DFIREBASE_BUILD_ZIP_FILE CODE_SIGN_IDENTITY=-
2021-04-27 15:51:48.889876-0700 xcodebuild[19827:32670303] Metal API Validation Enabled
2021-04-27 15:51:49.024656-0700 xcodebuild[19827:32670234] warning:  The file reference for "GoogleAppMeasurement-xcframeworks.sh" is a member of multiple groups ("Support Files" and "Support Files"); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2021-04-27 15:51:49.024701-0700 xcodebuild[19827:32670234] warning:  The file reference for "GoogleAppMeasurement.debug.xcconfig" is a member of multiple groups ("Support Files" and "Support Files"); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
2021-04-27 15:51:49.024725-0700 xcodebuild[19827:32670234] warning:  The file reference for "GoogleAppMeasurement.release.xcconfig" is a member of multiple groups ("Support Files" and "Support Files"); this indicates a malformed project.  Only the membership in one of the groups will be preserved (but membership in targets will be unaffected).  If you want a reference to the same file in more than one group, please add another reference to the same path.
Successfully built PromisesObjC for catalyst. Build log is at file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/build_logs/PromisesObjC-catalyst.txt.
buildDir: file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/catalyst/
buildSliced returns file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/catalyst/Release-maccatalyst/PromisesObjC/FBLPromises.framework/
fatal error: /Applications/Xcode12.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: input file (/var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/FBLPromises) must be a fat file when the -thin option is specified
Fatal error: lipo command exited with 1 when trying to extract the i386 slice from /var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/FBLPromises. Output:
The task completed: file zip_builder/FrameworkBuilder.swift, line 850
2021-04-27 15:51:52.476623-0700 zip-builder[93903:32580995] Fatal error: lipo command exited with 1 when trying to extract the i386 slice from /var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/FBLPromises. Output:
The task completed: file zip_builder/FrameworkBuilder.swift, line 850
(lldb) po binary
▿ file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/FBLPromises

_url : file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/FBLPromises

(lldb) po frameworks
▿ 3 elements
▿ 0 : 2 elements
- key : zip_builder.TargetPlatform.iOSSimulator
▿ value : file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/
- _url : file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphonesimulator/Release-iphonesimulator/PromisesObjC/FBLPromises.framework/
▿ 1 : 2 elements
- key : zip_builder.TargetPlatform.iOSDevice
▿ value : file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphoneos/Release-iphoneos/PromisesObjC/FBLPromises.framework/
- _url : file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/iphoneos/Release-iphoneos/PromisesObjC/FBLPromises.framework/
▿ 2 : 2 elements
- key : zip_builder.TargetPlatform.catalyst
▿ value : file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/catalyst/Release-maccatalyst/PromisesObjC/FBLPromises.framework/
- _url : file:///var/folders/mk/9ccbvq8x00q20q0f7mfxbtrw00bzqz/T/ZipRelease/2021-04-27T15-27-11/project-ios/catalyst/Release-maccatalyst/PromisesObjC/FBLPromises.framework/
(lldb)

Going to merge here since the nightly is broken anyway and this might work.
I'll address any review and follow-on issues in a subsequent PR


fix(#275): implement weekly log rotation

Added weekly log rotation.
This fix creates a RotatingFileHandler that extends the Mono/RotatingFileHandler and overwrites only the methods required to make this work. Might be considered hacky by some.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>6
Details

29 of 35 (82.86%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.005%) to 81.764%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/Tempest/Log/src/FileHandlers/RotatingFileHandler.php
10
16
62.5%

Totals

Change from base Build<PHONE_NUMBER>4:
0.005%

Covered Lines:
6340

Relevant Lines:
7754

💛  - Coveralls

Sorry for missing the extension part :) Thanks for contributing!


Use with CommonJS require?

Hey,
really liking your library, but is there a way to use it with browserify?
If I try
var offside = require('offside-js');
offside( '#main-navigation', {
        slidingElementsSelector:'#container',
        buttonsSelector: '.toggle-navigation',
    });

Chrome throws Uncaught TypeError: Cannot read property 'factory' of undefined.

Okay, solved it with
const offside = require('offside-js');
global.offside = offside;
offside( '#main-navigation', {
        slidingElementsSelector:'#container',
        buttonsSelector: '.toggle-navigation',
    });

as far as I understood just requiring offside-js doesn't binds it to window so one has to do this manually.
But maybe there exists a better solution?

Hi Robin, I'll be honest, I've never tested Offside as Browserify dependency. But I suspected something could have been wrong.
I'll check it out as soon as possible. Thank you for your advice.
Greetings!

Should be fixed by 0dc99c4.
I'm not happy with the patch because currently Offside still relies on window object, even when called as require dependency.
A better solution would involve non backwards-compatible changes to plugin interface. I'll keep them for next major release (coming soon).
Please let me know if 1.2.4 release solves your bug. Cheers!

Has this been fixed in v1.3? Still having the same issue :(

Hi @stevebauman, thank you for your report.
I just pushed a branch to address this bug. Would you be able to check out if it works on your project?
I'll set up a test environment as soon as I have time, too. Sadly I had written no unit test for this plugin 😄.

Fixed by v1.4.0.

Thanks @toomuchdesign! Appreciate it.


:sparkles: concrete help suggestions, singleton handling

Merge after #55

why ain't u wanna undraft & merge it, buddy? @ShuffleZZZ @Shuffle45 (tg tag xd)


Support AssetBundle container paths for export paths, invalid tag exception workaround

Support reading AssetBundle container paths and using them for asset export paths. This addresses #56.

Avoid IndexOutOfRangeException for tag indices > 7 and < 20000.
For an older Unity project, I discovered the following tag indices with a TagManager that had no tags:
"GameRoot(GameObject)" => tag 8
"MapInitParams(GameObject)" => tag 9
"Camera(GameObject)" => tag 10
I have no idea what those tags refer too, nor do I have access to the source.

(new) Avoid duplicate file extensions in export paths if container paths also contain file extensions.

Since asset bundles are just a single file (AFAIK) and the asset bundle's filename is often the same as the asset bundle's internal name, this can lead to redundant export paths like:
myassetbundle/AssetBundles/myassetbundle/<containerpath>
Should the export path just be cut down to: <assetbundlefilename>/<containerpath> foregoing the AssetBundleName/<assetbundlename>/ part?

Decided to remove the redundant AssetBundles/<assetbundlename>/ prefix in the export path.
I also noticed that my test asset bundle container paths included file extensions, which both resulted in duplicated extensions in the export path and broke the asset name case replacing logic. Fixed the issue by stripping out file extensions from container paths.

It is better to separate unrelated PR changes.
Those tags has to be either part of switch block
https://github.com/mafaca/UtinyRipper/blob/a06eb1a028d1ec72cd2d6e8f8cd19c463ec7299a/uTinyRipperCore/Converters/Project/Exporter/ProjectAssetContainer.cs#L209
or part of some other specific check. Tags with index >= 20000 are user tags, tags < 20000 are unity default tags. Tags you mentioned doesn't look like unity tags. Maybe those are custom tags added by developer right into engine. In that case ripper doesn't has to support them because it doesn't support any custom data.

It is better to separate unrelated PR changes.

Sorry about conflating changes in the PR. They were developed side-by-side experimentally, intended for personal use at first.

Those tags has to be either part of switch block
https://github.com/mafaca/UtinyRipper/blob/a06eb1a028d1ec72cd2d6e8f8cd19c463ec7299a/uTinyRipperCore/Converters/Project/Exporter/ProjectAssetContainer.cs#L209
or part of some other specific check. Tags with index >= 20000 are user tags, tags < 20000 are unity default tags. Tags you mentioned doesn't look like unity tags. Maybe those are custom tags added by developer right into engine. In that case ripper doesn't has to support them because it doesn't support any custom data.

It doesn't exactly add "support" for such unknown tag ids - it just avoids causing an exception that effectively crashes uTinyRipper. The method already treats invalid tags ids >= 20000 with $"unknown_{tagID}", and this just does the same for tags ids > 7 and < 20000.

Crash is expected behavior of the program since it helps to find cases that are not covered by developer. There are only several known cases that may has ID less than 20000. Later unity may add new such IDs and this crash will help to indicate it.
tagIndex < m_tagManager.Tags.Length
this check is valid one, because it is expected behavior of unity engine to has tags that are not present in tag manager. You can reproduce it by yourself. Create new tag in tag manager, assign this tag to an object, delete this tag from tag manager, build project. Voila, you get a build that has object with a tag that isn't present in tag manager.
But you can't create a build that contains a tag with index 10, or 15 or any other. So such check is redundant and misleading.

I suspect that the invalid tag ids were the result of various early unity version migrations. The project in question was started around 2011 and this particular version of the project is around 2016 (was built using Unity 5.3.4f1).
I'll revert the invalid tag check, but there needs to be a way to extract from asset packages that are only partially "corrupt" and in a very minor way at that.
Right now, uTinyRipper fails fast rather than fail gracefully. When an error is encountered, it should report the error at the end, yet continue extracting.

Right now, uTinyRipper fails fast
That is exactly how it should work. Ripper is in the middle of development. Priority is straightforward and reliable way of finding bugs, exceptions and incorrect behavior. At this moment this tool isn't intended for the end user. Users who uses ripper right now are testers in the first place. Crash in the middle of export process is the most convincing way to force them create an issue and provide game files. In turn, any person who know c# can easily download source code and modify it any way he want. So as long as I need such "feedback" from users, I will keep such fast fail approach.
Regarding point 3 "file extensions". I checked how it works with resources. It ruins file names that contains a dot (Resources/Main.Camera.prefab has Main.Camera file name so Camera is file extension). I will fix it myself but I want to test it in more details at first. I will do it later.

Looking at the history of the asset file with the invalid tag ids, I strongly suspect that the invalid tag ids are the result of a migration from Unity 4.6 to Unity 5.3, and somehow the TagManager did not preserve tags and Unity (back then) defaulted the existing now-invalid tag ids to 8+.

That is exactly how it should work. Ripper is in the middle of development. Priority is straightforward and reliable way of finding bugs, exceptions and incorrect behavior. At this moment this tool isn't intended for the end user. Users who uses ripper right now are testers in the first place. Crash in the middle of export process is the most convincing way to force them create an issue and provide game files. In turn, any person who know c# can easily download source code and modify it any way he want. So as long as I need such "feedback" from users, I will keep such fast fail approach.

That sounds rather ... suboptimal. If it's in active development, shouldn't you be using some sort of telemetry service that automatically collects errors?

Regarding point 3 "file extensions". I checked how it works with resources. It ruins file names that contains a dot (Resources/Main.Camera.prefab has Main.Camera file name so Camera is file extension). I will fix it myself but first I want to test it in more detail. I will do it later.

Oh yeah, that's an issue, and I'm not sure what the best way to solve it would be. My solution for now that's agnostic of known extension types: only replace end of asset path (container path) with an extension if asset path without extension ends with (ignoring case) actual asset name.
Given asset name: MyFile
Container path path/to/myfile => export path path/to/MyFile (unchanged)
Container path path/to/myfileblah => export path path/to/myfileblah (unchanged)
Container path path/to/myfile.ext => export path path/to/MyFile (new behavior)
Container path path/to/myfileblah.ext => export path path/to/myfileblah.ext (unchanged)
Container path path/to/myfile.blah.ext => export path path/to/myfile.blah.ext (unchanged)

the result of a migration from Unity 4.6 to Unity 5.3

My solution ...

I will check those later.

That sounds rather ... suboptimal.

But that is the best way to work for me. Error message is useless in most of the cases. I need game files to reproduce and find a solution for the issue. In any case, user won't send any crash report if the program don't stuck. Such service require time to integrate it. Then it requires time to analyze all those issues. Graceful fail approach also requires time. And I don't want to waste time on something that I consider useless (at this moment) and that is not interesting to work with.

somehow the TagManager did not preserve tags and Unity (back then) defaulted the existing now-invalid tag ids to 8+

yes, it is unity bug. i added additional check for this case in 203e16644171c84a9c019ee4c2b5f2d81e9e2607

Thanks for merging and addressing the Unity 5 invalid tag case!


Test: Injected Text Adoption For Inline Suggestions

Refs

[x] anyOS @isidorn
[ ] anyOS @TylerLeonhardt

Complexity: 3
Create Issue
Create Issue

Inline Suggestions now use the new Injected Text feature of the core editor.
This fixes some issues that inline suggestions had and enables line wrapping of inline suggestions.
Prep
Install the copilot extension.
Testing
Play around with copilot and verify that

the cursor is never inside of an inline suggestion
When wrapping is enabled, long inline suggestions are wrapped correctly
Hover works correctly on ghost text
There are no weird UI artifacts.

I've pretty much finished testing this item but since the steps are "use copilot" I'm not gonna unassign myself yet and will just give it another day of testing since it's easy to test.


Show details about Isolate components

State (VALID, INVALID, ERRONEOUS) -- use colors
Component properties (in the model view)
Stacktrace in case of ERRONEOUS components

Implemented in debug rest api


feat(641) social login providers screen

What does this PR do:
Implemented UI for social login providers screen
Added colours and images to assets

Add an explanation of what your changes do and why you'd like us to include them.
Visual change - screenshot before:
Delete if change is not visual.
Visual change - screenshot after:
Delete if change is not visual.
Ticket Links:

Related PR(s):
List any PR's that Need to be merged before this one.
Delete if there's no dependencies.
Any of check_pr_for_aws_creds failed. What to do?
It means AWS credentials leaked.
Please adhere to these steps.

@Alexdive It seems that root view of view controller of modal is not UIScrollView. Please use scroll view with bouncing enabled so that we can scroll the content.
Here, comparison of screen with buttons and screen with form. The end result should be like on form's screen.
https://user-images.githubusercontent.com/7137128/209565960-a8a16b8e-f5a1-4521-8fd5-3c691208896d.mov

@Alexdive It seems that root view of view controller of modal is not UIScrollView. Please use scroll view with bouncing enabled so that we can scroll the content. Here, comparison of screen with buttons and screen with form. The end result should be like on form's screen.
does-not-scroll.mov

It doesn't make sense on this screen, as we do not have input forms, unlike the email login screen, where the view scrolls up when keyboard appears.

please rebase on the latest main branch


Swagger / UI is awailable under beta9 package

Hi, I was just browsing around and found this.
RC2 repo is under https://github.com/domaindrivendev/Ahoy
Creating API without swagger is just miserable experience for me, so here you go.
"Swashbuckle.SwaggerGen": "6.0.0-beta9",
"Swashbuckle.SwaggerUi": "6.0.0-beta9",

Thanks @jcob-ross
I have added support for Swagger.


player is rendered behind obstacles

Fixed by setting the zIndex of the container holding the sprite.
Background is also forced to the back this way.


Move settings to dedicated dialog

From<EMAIL_ADDRESS>on 2009-10-17T20:33:28Z
The menus are a bit cluttered in 1.0. It would make things a lot nicer if
most options were moved to a centralized dialog instead.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=80

From pierre.raybaut on 2010-02-06T07:46:00Z
Labels: -Milestone-Release1.1 Milestone-Release1.2

From pierre.raybaut on 2009-10-19T12:17:40Z
Status: Accepted
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low Milestone-Release1.1

From pierre.raybaut on 2010-08-03T23:12:16Z
Done in v2.0.0alpha4
Status: Fixed

From pierre.raybaut on 2010-02-06T07:47:39Z
Labels: -Milestone-Release1.2 Milestone-Release2.0


i18n is null in getServerSideProps on app startup

🐛 Bug Report
When starting up our nextjs app, we import i18n to be used in getServerSideProps, however, the module does not exist initially, and returns null.
How do we wait for/account for this prior to starting the app?

To Reproduce
A minimal reproducible example.
A codesandbox example or similar
or at least steps to reproduce the behavior:
import { i18n } from 'next-i18next';

export const getServerSideProps = async ({ locale }) => {
  const t = i18n.getFixedT(locale);
  return { props: {} }
}

Expected behavior
No error, and getFixedT exists on the i18n object
Your Environment

runtime version: i.e. node v18.12.1
i18next version: 22.4.9
os: Mac
any other relevant information

#2079

@adrai so no fix/workaround right now?

Are there any other fixes/workarounds that you know of? @adrai


BUG: [Display(Prompt="...")] not working on textarea elements.

Model:
[DataType(DataType.MultilineText)]
[Display(Prompt =nameof(Issue))]
public string Issue { get; set; }

Using input:
placeholder attribute render correctly
<input asp-for="Issue" class="form-control" />

<input class="form-control"
       type="text"
       id="Issue"
       name="Issue"
       placeholder="Issue"
       value=""
       data-val="" data-val-required="The Issue field is required."  />

Using textarea:
placeholder attribute missing from output
<textarea asp-for="Issue" class="form-control"></textarea>

<textarea class="form-control"
          data-val="true"
          data-val-required="The Issue field is required."
          id="Issue"
          name="Issue">
</textarea>

Expected:
Both textarea and input should have the placeholder attribute populated.

A small feature gap. We implemented support for placeholder only in <input> elements i.e.DefaultHtmlGenerator.GenerateTextArea() lacks code we have in DefaultHtmlGenerator.GenerateInput().

I implemented that, and pretty sure it works. But solution wont compile now, so I'm not sure. As soon as I can compile and test I'll send a pull request.

@dougbu assigning to you for PR https://github.com/aspnet/Mvc/pull/4907.

a852352


Add package.json

Though I just noticed it's actually on npm, it's probably a good idea to have the package metadata here.

I am actually the one publishing it on npm but I'll gladly remove it so it could be republished using this repository.
I needed it badly on multiple locations/clients so that's why

Thanks, glad you did. Was useful for me. We'll see if this gets merged up.


Print info when catching Exception during install

How would this feature be useful?
We catch any Exception in install() but are silent about it--there is no way to know what happened.
For debugging user bugs, this would be extremely helpful (see #273 for example.)
Describe the solution you'd like
Save the caught exception using something like except Exception as e and then use either a output what it is using plain repr(e) or more sophisticated printout using the traceback library for example.  We could do this only if pipx --verbose is on.
Describe alternatives you've considered
None.
I think any more information than the current "no information" would be helpful

Great suggestion. We could also log verbose output, or just errors, to a file regardless of what the user does. The error message could say "see logs at ..." if an error was caught, rather than dumping Python exceptions to the user's CLI (that should never happen).

I think a rotating log that saves the last N pipx invocations sounds excellent.


Added beforeShow and beforeHide events (Issue #84)

Thanks for the feedback @i-like-robots . I hadn't much change to test.
I changed the code now to default to null. I also checks for if(beforeXX) to allow false to be used as a default as well.

Nice one!
I've thought of a second option, maybe the function should explicitly return false. The default options could remain $.noop and the condition changed to this.opts.beforeShow.call(this) === false.
What I like about this is that I think it will cause fewer mistakes for developers using the feature.
What do you think?

Like this?

Exactly what I had in mind, does this way still fit your needs?

Sure it does. I just have to adjust my code. No biggie ;)

Thanks! I will update the docs before releasing


Tooltips still not satisfactory

OpenUI5 version: 1.68.1
I have found this issue https://github.com/SAP/openui5/issues/1612 and I have to say I agree and conclude it is not fixed still.

All Controls show a tooltip aggregation and the documentation keeps sending you in circles. For example, the https://openui5.hana.ondemand.com/#/api/sap.f.Card has a tooltip aggregation, it tells you the option to use the two TooltipBase objects but they are deprecated. Shouldn't you simply change that to a tooltip=string property in the docs then? As this is the only supported option at the moment.
For most controls the tooltip=string simply does not work. Buttons are fine, but above Card for example does not show anything.
Tooltips are so common, they should be supported out of the box. Not with mouseover, delegate and popover.

Agree?

No, I don't agree to point 2 . From my experience, tooltips of type string work for most controls (where they make sense). Please name other controls besides sap.f.Card for which you encountered issues so that we can discuss those issues.
P.S.: For sure I agree to 3 and partially to 1. But please note that type string is already mentioned there.

@codeworrior In regards to "most controls tooltipps do not work"
I am still working on the proof, so far all objects I remembered I had issues with, do work. So either I did something wrong back then or it was a UI5 version. I tested button, textarea, input, icon.
https://jsbin.com/decuquw/edit?html,js,output

About tooltips, as media specific feature, they should not be used for providing information of high importance to the user. Tooltips can be used for image only UI, which will also help screen readers to announce details for that UI if other alt or hidden text is not present:
https://experience.sap.com/fiori-design-web/using-tooltips/#usage
What is the use case that requires tooltips?
Would details about tooltips be sufficient here, https://openui5.hana.ondemand.com/#/api/sap.ui.core.Element/methods/setTooltip
?

The use case is pretty much along those guidelines. If you click on a button, an icon, a card,... in all cases you want to add additional, optional help like "Press here to jump to the next screen".
Regarding the details and setTooltip method, I am not sure what your thoughts are. Personally, I would modify your Element page, move the tooltip from aggregation to properties and talk about the tooltip=string only. And then remove the additional tooltip line from all implementing classes (Control, Button, Icon,....) as they are mentioned there again (copy) instead of being shown as borrowed item. This is inconsistent anyhow. Makes sense?

Makes sense, but is hard to achieve.
In UI5, documentation is not independent from the source. As we can't change tooltip from "aggregation" to "property" in the source (due to our compatibility guidelines), it has to stay an aggregation also in the documentation.
The only thing that we can do is to add a more explanatory text to the tooltip aggregation or to the setTooltip method.
Reg. redundancy: I don't know why the borrowed aggregations now are shown always and without the possibility to suppress them. Looks strange to me.

The redundancy is for historical reasons. Prior to the "borrowed checkbox" all the very important items have been copied again. When they have a different description, that would make sense, but as you rightly pointed out it is a 1:1 text copy often. Just some house keeping task for docs team.
Regarding aggregation/properties, this is understood. Can you then at least remove the TooltipBase mention and keep the string only? It will be confusing though, because the setting
<tooltip>Some Text</tooltip>

as an aggragtion of type String would implicate, is not allowed. You have to use the properties syntax
<Button tooltip="Some Text" />

All very confusing for beginners.

The help information should be hold in a help system, otherwise on some mobile devices the user will not be able to see the instructions.
About documentation, I am forwarding internally to colleagues for further checks: #1970388173

Can you then at least remove the TooltipBase mention and keep the string only?

I don't know. Apps can still extend TooltipBase and put it in the <tooltip> aggregation (sample) since TooltipBase itself is not deprecated. I think there are still valid use cases extending it for desktop-only users although I agree with the general guidelines about the tooltips.

Hi,
With https://github.com/SAP/openui5/commit/d6bc822f5a7bb20933208e11d7279768ef9adbc5
the sap.f.Card now supports tooltips.
Let us check once again whether the documentation should be updated.
Best,
Teo


TF 2.0 / SequenceFeatures shows an error when I put same sequence length of features.

keras.experimental.SequenceFeatures requires SparseTensor but it measures the sequence length without 0 values.
For example, sequence data [[0,0,1,2], [0,1,2,3]] has 4 sequence lengths but when it converted to SparseTensor, it has a 2 sequence length and a 3 sequence length.
It shows an error as below:
Traceback (most recent call last):
  File "pipeline2.py", line 280, in <module>
    seq_input, seq_len = seq_feature_layer(inputs)
  File "/Users/seungbaeji/anaconda3/envs/tf2/lib/python3.6/site-packages/tensorflow/python/keras/engine/base_layer.py", line 660, in __call__
    outputs = self.call(inputs, *args, **kwargs)
  File "/Users/seungbaeji/anaconda3/envs/tf2/lib/python3.6/site-packages/tensorflow/python/feature_column/sequence_feature_column.py", line 140, in call
    sequence_length = _assert_all_equal_and_return(sequence_lengths)
  File "/Users/seungbaeji/anaconda3/envs/tf2/lib/python3.6/site-packages/tensorflow/python/feature_column/sequence_feature_column.py", line 489, in _assert_all_equal_and_return
    assert_equal_ops.append(check_ops.assert_equal(tensors[0], t))
  File "/Users/seungbaeji/anaconda3/envs/tf2/lib/python3.6/site-packages/tensorflow/python/ops/check_ops.py", line 496, in assert_equal
    (message or '', index_and_values_str, summary_msg)))
tensorflow.python.framework.errors_impl.InvalidArgumentError:
Condition x == y did not hold.
Indices of first 3 different values:
[[0]
 [1]
 [2]]
Corresponding x values:
[95 94 93]
Corresponding y values:
[96 96 96]
First 3 elements of x:
[95 94 93]
First 3 elements of y:
[96 96 96]

tf.feature_columns.utils.sequence_length_from_sparse_tensor doesn't count 0 value as an element of the sequence. Therefore, if you have a 0 in your sequence, you have to apply indices of 0.


chore: remove redundant peerDeps

Peer Dependencies use case:

There's one use case where this falls down, however: plugins. A plugin package is meant to be used with another "host" package, even though it does not always directly use the host package.

We always directly use toad-scheduler and we don't let the user pass a toad-scheduler instance, so I think having it as peerDep is unnecessary here:
https://github.com/fastify/fastify-schedule/blob/1e5554bfc6a93ae2c7d24f14adc8f6f55f054325/index.js#L6-L16

I can also change the range to ^3 but that might be breaking, not sure

@gurgunday Key reason here is to allow user to bring their own major toad-scheduler version if they choose to do so, without needing to release a new version of fastify-schedule
What are the benefits of a new approach?

Oh so how does it work though? By manually mutating the decorated instance? I thought a custom instance would be a setting that’s passed or something, like it is in rate-limit
Also the range only seems to allow versions 2 or 3 and not 4 or higher, so it’s only those 2?

Yeah I see now, I misunderstood this, I was trying to align it with the custom redis instance handling of rate-limit
In rate-limit, it's not a peerDep and just a passed option, but here it seems like the peerDep is the only option
I'll revert to not make it breaking

@gurgunday let's remove the upper version ceiling, though

@gurgunday Key reason here is to allow user to bring their own major toad-scheduler version if they choose to do so, without needing to release a new version of fastify-schedule
What are the benefits of a new approach?

This is why modules like our Redis one provide a way to supply your own instance.

@jsumners but that is an overkill if all I want is a different version

I disagree. It is flexible and avoids the nonsense associated with peer dependencies.


Update changelog

Signed-off-by: Alex Co<EMAIL_ADDRESS>
Summary

Ticket:
What's Changed

Changed

Update CHANGELOG.md

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: onimsha
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


⚠ ClamAV has degraded performance

In 0c8080c, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 71 ms

Resolved: ClamAV performance has improved in 9e6dfe0 after 6 minutes.


[CDS-85246] CDS release 81614 (hotfix for CDS-85692)

Harness Developer Pull Request
Thanks for helping us make the Developer Hub better. The PR will be looked at
by the CODEOWNERS.
What Type of PR is This?

[ ] Issue
[ ] Feature
[ ] Maintenance/Chore
[x] Release notes

If tied to an Issue, list the Issue(s) here:

CDS-85246

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screen Shoot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://6569ceb52e05de190edda5b1--harness-developer.netlify.app


Tweak the vulnerability schema.

This is in progress and temporarily served from /v1new.

Hoist out some fields for affected ranges to reduce duplication.
Generalize "cves" to "aliases".
Add an output-only lastModified field.

FYI more changes were requested. See latest commit.

lgtm,
i am even fine with just removing v1new and keeping just v1. can do later (tbr) whenever.

Need to coordinate some migration details, so holding off on that for now.


Namespaces for keys

Ciao Roberto,
really good job, I like your library a lot! I was trying to understand which is better: this or ng2-translate, and I decided I'll give this a try, especially because I like the api more and your pipes are pure, and although I'm just starting with a new project, I know it'll become big, with a lot of translations in page. I can't assess the impact of impure pipes, but if the angular team itself discourages their use... :)
Anyway, I seem to understand that your library doesn't support namespaced keys like ng2-translate does e.g.:
{
"HOME": {
"TITLE": "Homepage",
"FOOTER": "Text in the footer"
},
"HELP": {
"TITLE": "Help page
}
}
I think it would be very useful to implement. Medium to big projects will certainly be split into multiple components which will need the same key, but with a namespace (like "TITLE", many components might use this key). Ofc we could use a prefix but we'd lose the nesting in the json file.
What do you think?
Once again good job, and kind regards.
Andrea

Ciao Andrea,
I was already planning to implement this feature, and because you have confirmed that it would be helpful, I will try to do it as soon as possible.
Thanks!

Ciao Andrea,
I added this feature in the latest version of the library compatible with Angular 2.0.0 Final Release.
I'm working to the other feature.
Saluti

Thanks man, that was quick! :)

Is there an option to get rid of this feature in my project?
I have a notation like this in my files:
{
"my.key":"my.value",
"my.next.key":"my.next.value"
}
That's why this feature brakes my translation files!

No, there isn't.
Do you really need this option? I'll evaluate an alternative and let you know.

Yes an option would be great.

Ok. I see.

Hi @jhwegener,
I added a commit that implements the option. By default, the feature is still present, but if you want to disable it, when you initialize the LocalizationService, you can invoke the following method before the updateTranslation method:
this.localization.setComposedKey(false);
If you don't want giving up the feature, but simply you want to use a different separator from the point, you can pass it to the method. For example:
this.localization.setComposedKey(true, "-");
If you want to test it, or use it immediately, you must remove the library from your node_modules, clone this project, and follow the instruction to build and install the library in README file.
I think I'll release a new version of the library when Angular 2.3.0 will be realeased.
Greetings,
Roberto

hi Roberto,
this works like a charm!
Thx for this quick response and implementation!
Greetings
Henning


Will this work with Expo?

Currently have an Expo app, but I keep getting an error:
TypeError: undefined is not an object (evaluating '_NativeBridges.GoogleAnalyticsBridge.trackScreenView')
I can't do manual install because I would have to detach.

Hi @rshellborn.
Probably not, Expo only works with modules made for Expo (i.e. part of their offering). So as you say, to make use of custom modules from the rest of the RN ecosystem you will have to detach.


System.OutOfMemoryException during Deletion

I know that OOM exception is exception that in every line of code, and often it falls somewhere else and not in real point of memory overusage.
Today I used LiteDB to put in FileStorage really big file (140MB) and then during attempt of deletion LiteDB falls with OOM.
I investigated the stack and found this line of code:
https://github.com/mbdavid/LiteDB/blob/697b81d64d1d230172769f0901db66af458a2734/LiteDB/Engine/Services/PageService.cs#L142
If I'm not mistaken you are loading all pages and all its content to single array and this operation really requires a huge amount of memory.
I'm sorry that i missed full StackTrace, if I reproduced it again all attach it.

Hi @podkolzzzin, yes, now it's using a single array for all pages deleted. And I know that could be use lot of memory if you are deleting lots of documents in a single Delete command.
But, in FileStorage this cloud not happing because each file are splited in many documents (each document has 256kb). So, if you delete a file it's could delete 256kb data pages, clear cache, delete more 256kb.... So, max memory usage must be 256kb". You can see here:
https://github.com/mbdavid/LiteDB/blob/master/LiteDB/Storage/LiteStorage.cs#L209
Can you write a simple console program to reproduce this problem (you could add #483 issue together)

Ok, I found an issue when writing file. When initialize LiteFileStream for write, if file already exists, LiteDB first delete all file content using "single-delete-operation", and this operation use all memory. I'm fixing.

Yes It's really my case!
My application very often rewrites files in FileStorage.

And it's wrapped by transaction....

Issue opened https://github.com/mbdavid/LiteDB/issues/2541


Feat/add t5 support

Add t5 support in convert script (transformer-deploy).
WIP

@pommedeterresautee I'm still testing triton but i need your review for the other parts (conversion onnx and tensorRt) and i'd like to see if those conversions can run on your machine without errors.

Not sure I understand, there is a conflict and the comments from my previous review are not addressed, is it the right branch ?

@ayoub-louati Thanks for your great work. I was able to successfully run the T5 conversion with ONNX. But I'm facing issues with the TensorRT conversion, from what I can read in the code, the implementation is ready yet, correct?

hello @WissamAntoun, Thanks for your feedback, can you please share the issues you're facing with TensorRT ?

@ayoub-louati could you investigate ? Tests are failing. And one of my previous comments are not answered

@gaetansnl which test please ?

@gaetansnl which test please and which comment ?
In CI
https://github.com/ELS-RD/transformer-deploy/actions/runs/4241022630/jobs/7370728282