MSVC link error

I have downloaded that latest 4.0 release, new leptonica and tried to buid it under MSVC 2017, unicode project. After several hours of I almost succeded in building the project but one problem is still remaining unresolved, I don't know how to fix it.
network.cpp (line 209):
network = new Convolve(stub.name_, stub.ni_, 0, 0);
MSVC gives the linker error:
error LNK2001: unresolved external symbol "public: __thiscall tesseract::Convolve::Convolve(class STRING const &,int,int,int)" (??0Convolve@tesseract@@QAE@ABVSTRING@@HHH@Z)
If this line is commented, project is built normally without errors.
convolve,cpp is included and Convolve::Convolve is definetely presented.
Weird thing that there is another file - networkbuilder.cpp where
one can see almost the same code, and it works fine:
  Convolve* convolve =
      new Convolve("Convolve", input_shape.depth(), x / 2, y / 2);

But after being copied to network.cpp it give the same link error.
I spent an hour trying to fix but failed.
What if I just comment this line? When it is used?

Commenting that line is not a good idea.
https://msdn.microsoft.com/en-us/library/f6xx1b1z.aspx
CC: @egorpugin

Are you trying to build with cppan?

No, never heard of it. MSVC project, mostly assembled manually. The previos versions 3.02, 3.04, were assembled and compiled normally.
First I thought that maybe it's leptonica's "convolve.c" that have collisions with lstm's "convolve.cpp" module and renamed the "convolve.c" to "convolve2.c" with no effect.

Please, see this page for build instructions https://github.com/tesseract-ocr/tesseract/wiki/Compiling#windows

cppan --build pvt.cppan.demo.google.tesseract.tesseract-master.
gives an error
boost::filesystem::path codecvt to wstring: error

What is you system version? Are you using windows 7?

WIndows 10, MSVC 2017 community

And what is your account name? Is it in russian?

Account to where? I have no account in Russian letters, though I am Russian

Windows user account.

Oh I see, I changed it to another user, now cppan goes further but no enough "There errors during test start". Log files are empty

Do you use the latest cmake?

I use the latest MSVC, is this enough for the latest cmake?
I solved the problem just by copied the source code from convolve.cpp (it's very small) to network.cpp and everything went fine.

It's ok to have manual fixes. But as you can see, windows build bots are fine. So there are some unusual things in your system setup.

When I was building 3.02 and 3.04 I didn't know about cppan, so i just manually added all required libraries and everything went fine. Today I found that there is 3.05 version, I downloaded it, added libs and evrything was compiled and linked perfectly as always, it took me around 15 minutes. Obviously I like that way and prefer to use it again with 4.0 version.
As per my PC, I didn' do to it something unusual, OS  was installed a month ago, MSVC 2017, the tesseract code was not changed, As I said, I resolved the problem, so no need to do anything to the code, perhaps you are right and the problem is with my machine

so i just manually added all required libraries

It was added during 3.05.

so i just manually added all required libraries

Cppan is developed to do this for you.

Thank you for your efforts!
Ok, Egor, I will try to use cppan on a new virtual machine with Win10, pure MSVC and a proper Administrator.

After creating MSVC project again more accurately ()adding files one by oneI succeeded in  building MSVC project without changing the source code. Nevertheless one weird thing I made - I had to add convolve.cpp in the main project. Now it contains two files - main.cpp (my own source code) and convolve.cpp (other dependencies are through lib files).
MSVC also gives a warning  while linking:
warning LNK4042: object specified more than once; extras ignored
I don't know what it means

Please, use tesseract user forum for asking support for your project.


Uplink/Liveupdate binary reporting after blob length mismatch

I tried to liveupdate a really tiny elf binary: http://timelessname.com/elfbin/ it is only 142Bytes
What happens is the following:

Uplink is established before the liveupdate, no binary is part of the uplink information (as is correct).
Update started and received.
Mismatch between blob length and expcted elf file size. I don't know why this mismatch occurs? The elf binary size is reported as 142 bytes by mothership, but that is not the main issue here.
Uplink is reestablished, but now the binary field is set to the checksum of the tiny elf binary which it is not running.

Raw output from the instance:
[ Uplink ] {"uuid":"00000000000000000000000000000000","version":"v0.12.0-rc.2-29-g2ce07b04-dirty","service":"IncludeOS Starbase","arch":"x86_64","physical_ram":134217728,"cpu_features":["SVM","LM","SSE","MMX","CLFLUSH","PSE_36","PAT","CMOV","MCA","PGE","MTRR","SEP","APIC","CX8","MCE","PAE","MSR","TSC","PSE","DE","FPU","SYSCALL","CX16","NX","SSE3","FXSR","SSE2"],"devices":["Storage controller Intel (V 0x8086 / P 0x7010)","Network controller VMWare (V 0x15ad / P 0x7b0)","Network controller VMWare (V 0x15ad / P 0x7b0)","Network controller VMWare (V 0x15ad / P 0x7b0)"],"net":[{"name":"eth0","addr":"<IP_ADDRESS>","netmask":"<IP_ADDRESS>","gateway":"<IP_ADDRESS>","dns":"<IP_ADDRESS>","mac":"c0:01:0a:00:00:2a","driver":"vmxnet3"}]}
     [ Uplink ] Sending uplink
     [ Uplink ] {"url":"<IP_ADDRESS>:9090","token":"kappa123","reboot":true}
     [ Uplink ] Update received - commencing update...
*** There was a mismatch between blob length and expected ELF file size:
EXPECTED: 309448 byte
ACTUAL:   142 bytes
                LiveUpdate::exec() failed: ELF file was incomplete

     [ Uplink ] Sending auth request to http://<IP_ADDRESS>:9090/auth
     [ Uplink ] Auth success (token received)
     [ Uplink ] Dock attempt to ws://<IP_ADDRESS>:9090/dock
     [ Uplink ] Websocket established
     [ Uplink ] Sending ident
     [ Uplink ] {"uuid":"00000000000000000000000000000000","version":"v0.12.0-rc.2-29-g2ce07b04-dirty","service":"IncludeOS Starbase","binary":"adc90f652390d1bae060f61a4126c16140c34804","arch":"x86_64","physical_ram":134217728,"cpu_features":["SVM","LM","SSE","MMX","CLFLUSH","PSE_36","PAT","CMOV","MCA","PGE","MTRR","SEP","APIC","CX8","MCE","PAE","MSR","TSC","PSE","DE","FPU","SYSCALL","CX16","NX","SSE3","FXSR","SSE2"],"devices":["Storage controller Intel (V 0x8086 / P 0x7010)","Network controller VMWare (V 0x15ad / P 0x7b0)","Network controller VMWare (V 0x15ad / P 0x7b0)","Network controller VMWare (V 0x15ad / P 0x7b0)"],"net":[{"name":"eth0","addr":"<IP_ADDRESS>","netmask":"<IP_ADDRESS>","gateway":"<IP_ADDRESS>","dns":"<IP_ADDRESS>","mac":"c0:01:0a:00:00:2a","driver":"vmxnet3"}]}

  void WS_uplink::update(const std::vector<char>& buffer)
  {
    static SHA1 checksum;
    checksum.update(buffer);
    binary_hash_ = checksum.as_hex(); // BINARY HASH UPDATED HERE

    // send a reponse with the to tell we received the update
    auto trans = Transport{Header{Transport_code::UPDATE, static_cast<uint32_t>(binary_hash_.size())}};
    trans.load_cargo(binary_hash_.data(), binary_hash_.size());
    ws_->write(trans.data().data(), trans.data().size());
    ws_->close();

    // do the update
    Timers::oneshot(std::chrono::milliseconds(10),
    [this, copy = buffer] (int) {
      try {
        liu::LiveUpdate::exec(copy); // THIS FAIL
      }
      catch (std::exception& e) {
        INFO2("LiveUpdate::exec() failed: %s\n", e.what());
        liu::LiveUpdate::restore_environment();
        // establish new connection
        this->auth();
      }
    });
  }

The first thing it does is calculating AND setting the binary_hash_. The solution would be to set it after Liveupdate::exec is run and successful, but then I guess it's too late.
Maybe ask LiveUpdate if the binary is valid before trying to update to it? What do you think @fwsGonzo ?

Confirmed fixed :) Nice job! I'll close this.


Serial Freezing after a long time - then unfreezing

We have been using this package successfully - except that after the create 2 has been in the charger for a long time, it seems to become either partially or fully unresponsive. By taking it off the charger by hand, or by sending it random combinations of of FULL/PASSIVE commands and /UNDOCK commands, it seems to sometimes become fully responsive after a minute or two but not always.
Expected behavior: We should just send it an /undock command which puts it into full mode and it should start responding to movement commands.
Actual behavior: When it is in this mode, we are sending in an /undock command and it is not showing a toggled /mode or /battery/charging_state in the ROS topic outputs and does not drive around or go beep, etc.
Background:
We have seen this across 3 Create 2's, multiple USB-> Serial cables and multiple computers so it doesn't seem to be a state of the hardware but instead something core to the system.
I have been running this for 4 days (over the weekend) and could see our code internally toggling passive / full every few minutes but then tried to undock it and back it up and it would not come out of the passive mode when I sent a FULL command.

Using the USB --> Serial cable that comes with the create 2
ROS Kinetic
Toggling into FULL mode and back to PASSIVE every 4 minutes to try to make sure it doesn't go asleep (A hack based on forum posts)
We have seen the Create start in sleep mode (Booted computer 20 minutes before, then started it - and it was frozen from the beginning. We have also had it start in regular mode where it seems to get stuck, even when we are triggering a change in states to full every 4 minutes (Well within the 5 minute limit)

Below I can see that there 9M packets which have been sent. When it was not responding, this number was staying constant for a while then jerking up then flat.
Excerpt from /diagnostics
        {
            "message": "Serial connection is good",
            "hardware_id": "CREATE_2",
            "values": [
                {
                    "key": "Corrupt packets",
                    "value": "0"
                },
                {
                    "key": "Total packets",
                    "value": "9731905"
                }
            ],
            "name": "ca_driver: Serial Status",
            "level": 0
        }

After toggling things for a while, I started to see it incrementing again by 60 packets / s and it was fully responsive (No ROS reset, unplugging, moving off the charger, etc).
Questions:

Is Create Autonomy sending in the wake up command and other elements to toggle it back awake? Is there something I am missing?
Have other people encountered it freezing after a while.
Is there a command we should be sending in separately to keep the robot from going to sleep "hard" when in passive mode rather than toggling to FULL then PASSIVE again?

Thanks!

Thanks for reporting this. I can't recall myself experiencing this issue, but I have not had the driver running continuously for days. To clarify, does this issue only present itself when the robot is charging (or just coming off of an extended charge)?

Only when it is charging. We have actually isolated it to 2 things. 1) hardware flow control has to be on to trigger the keep alive on the create USB cable or it goes to sleep after 5 min. This is not enabled in libcreate. 2) we have found that when it toggles from full to passive and then charges, we are the packets dying right at that point which says it could be a power thing on our setup. When we toggle it a few times more, it comes back with packets so it is the serial connection resetting.
But a key change would be to enable hardware flow control.
Verified on multiple roombas.


German press article

by Alexander Neumann published on heise online

Wow! :smile: Thanks!

You're welcome. Great Work!


Arguments for GradScaler

So I can pass arguments to torch.cuda.amp.GradScaler
For example, learn.to_native_fp16(init_scale=2048., growth_interval=10**4)

I originally pass the test.
But I messed up with doing git rebase upstream/master and git push -f origin fp16
and git status give me
branch fp16
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   docs (new commit)
	modified:   nbs/examples/migrating_ignite.ipynb

no changes added to commit (use "git add" and/or "git commit -a")

and I don't know how to do ...

@richarddwang can you do git add nbs/examples/migrating_ignite.ipynb; git commit -m'modified ignite notebook'; git push ?


How to use a class as the content of a tab?

Hi,
How can I use another class as the content of one of my tabs?
Let's say I have a test.js, and in it I have a text box. Instead of:
content = This is the content 1
I want to use that class to render one of my tabs. Is that possible here?
Thanks for your help in advance.

I'm doing it in Android, BTW


/bin/bash: /etc/nginx/conf.d/st2.conf: Permission denied

when i'm trying to run st2web on openshift it requires root previelages in openshift which is not supported

After security context to run as nonuser, I'm facing this error in k8s environment

Duplicate of #185


Add docker-compose file

Since this is a very simple container, I think I'm going to leave this out.  I don't know there is enough benefit for adding a compose file for a single-container app.  If you disagree and can help me understand why this would be a preferable way to run the relay, let me know and i'll re-evaluate.
Thanks!


Unhelpful PartialFailureError when doing a raw insert.

Having trouble doing a "raw" insert, as described in the API docs here: https://googleapis.dev/nodejs/bigquery/latest/Table.html#insert
It fails with PartialFailureError.
Digging into the errors array on it, there's one element:
{ message: '', reason: 'invalid' }, which doesn't give me much to go by.
The operation itself is super simple. It's simply inserting a string into a table with one column (string).
Environment details

OS: MacOS
Node.js version: 8 (Cloud Functions engine version)
npm version: 6.13.6
@google-cloud/bigquery version: 4.6.1

Steps to reproduce

Doing a table.insert like so:
const bq = new BigQuery({ location: 'EU' });
const dataset = bq.dataset('firestore_export');
const table = dataset.table('test');

table.insert({
   skipInvalidRows: false,
   ignoreUnkownValues: false,
   rows: [
      {
        insertId: event.eventId, // (comes from the CF trigger's context.eventId)
        json: {
          document_name: 'test',
        }
      }
   ],
}, { raw: true });

My code is based this, which seems to work fine:
https://github.com/firebase/extensions/blob/next/firestore-bigquery-export/firestore-bigquery-change-tracker/src/bigquery/index.ts
Anyway, is PartialFailureError not supposed to give a bit more info about what went wrong?

?

No, I dont use raw inserts as a result

Essentially, this error response is informing you that the the row data you've sent is invalid (it doesn't conform to what the streaming API understands to be the current schema of the table).
You've disabled skipInvalidRows, so the system is surfacing this error.
It may be the case that you're constructing incompatible messages, or it may be a case of a table has recently changed (deleted/recreated, schema change, etc) and the streaming system hasn't yet picked up the change.  More info here: https://cloud.google.com/bigquery/docs/error-messages#streaming
There's nothing really actionable here beyond that from the library perspective..  The API will not provide more expansive responses describing what's wrong.
Closing this one for now.

I have the same problem.
The same insert without the raw option goes through without a problem.

In case someone need it, instead put all rows in one insert, I insert it line by line to avoid this bug.
await Promise.all(rows.map(async row => {     bq.dataset('dataset').table('table').insert(row) }))
hope this helps

In case someone need it, instead put all rows in one insert, I insert it line by line to avoid this bug.
await Promise.all(rows.map(async row => {     bq.dataset('dataset').table('table').insert(row) }))
hope this helps

So I decided to give this one another go, and managed to make raw inserts work in a controlled setting:
import { BigQuery } from '@google-cloud/bigquery';
import { logger } from 'firebase-functions';

async function test() {
    const data = { val: 1 };
    const bq = new BigQuery({ location: 'EU' });

    const table = bq.dataset('firebase_export').table('bqtest');
    const row: { insertId?: string, json: any } = {
      insertId: context.eventId,
      json: data,
    }

    try {
      await table.insert([row], {
        skipInvalidRows: false,
        ignoreUnknownValues: false,
        createInsertId: false,
        raw: true,
      });
    } catch (e) {
      logger.error(e);
      if (e.name === 'PartialFailureError') {
        for (const err of (e.errors as { errors: { message: string, reason: string }[], row: any }[])) {
          logger.error(err);
        }
      } else {
        logger.error(e);
      }
    }
}

The table is called bqtest with one field: val which is an integer.
Have yet to try it with a more complex table, but it's a start.
EDIT A more complex table also worked.

This was helpful


Handling WebSockets

Is there any way I can handle WebSockets connections using Responder?

I've just made a PR #114

in master


The to icon is has wrong link

See the screenshot. The to icon on the left is wrong. And I fixed it in the console on the right hand side.
The wrong url is having /java/java 2 times as prefix instead of only 1.

Ah, probably just need to change those to relative urls, will look in a few..


Create PackageCloud repo

https://packagecloud.io/vorakl/vbl

https://github.com/vorakl/vbl/projects/1#card-40475626


SM75 (Turing) support for FP6 kernel

The FP6 CUDA kernel is currently limited to >=SM80, i.e. at least Ampere generation NVIDIA GPUs. However, as mentioned in this issue, the FP6 kernel could theoretically work for any card with uint8_t and fp16 support.
This PR adds FP6 support for SM75 (Turing generation) GPUs. Given the modest support for SM75 GPUs (e.g. the NVIDIA T4) in torchao, I'm hoping this can be a step towards improving that.
Most important changes:

Replace asynchronous copy operations with vectorized loads (diff)
Replace m16n8k16 Tensor core operation with two m16n8k8 operations (diff)
Account for a difference in expected parameters for the ldmatrix operation (diff)

Before this, FP6 failed to run on SM75 (specifically, it would error out with "RuntimeError: operator torchao::quant_llm_linear does not exist").
Below are the benchmark and correctness test results (using ao/benchmarks/benchmark_fp6.py). Compared to the initial FP6 results done by @gau-nernst, we still see a speedup of at least 2x compared to FP16 in most cases.
Testing specs:

NVIDIA T4 GPU (SM75 generation)
Torch version: 2.6.0.dev20240917

m
k
n
fp6_latency (ms)
fp16_latency (ms)
speedup (d/s)
correct

1
8192
8192
223.05
517.205
2.31878
1

1
8192
10240
267.519
644.85
2.41048
1

1
8192
57344
1409.66
3618.91
2.56722
1

1
28672
8192
760.036
1800.83
2.3694
1

2
8192
8192
226.652
550.078
2.42697
1

2
8192
10240
271.363
687.359
2.53299
1

2
8192
57344
1442.43
3795.44
2.63128
1

2
28672
8192
768.993
1945.42
2.52982
1

4
8192
8192
229.543
567.315
2.4715
1

4
8192
10240
276.362
690.747
2.49943
1

4
8192
57344
1457.8
3805.93
2.61074
1

4
28672
8192
776.344
1965.42
2.53163
1

8
8192
8192
237.398
573
2.41367
1

8
8192
10240
284.349
810.79
2.85139
1

8
8192
57344
1521.18
3823.49
2.51349
1

8
28672
8192
783.763
1988.13
2.53665
1

16
8192
8192
273.57
582.142
2.12795
1

16
8192
10240
334.392
815.086
2.43751
1

16
8192
57344
1908.2
3857.97
2.02178
1

16
28672
8192
896.452
2002.43
2.23373
1

32
8192
8192
449.671
659.112
1.46576
1

32
8192
10240
548.003
821.81
1.49965
1

32
8192
57344
3255.59
4543.11
1.39548
1

32
28672
8192
1531.63
2403.52
1.56925
1

64
8192
8192
58.3608
672.911
11.5302
0

64
8192
10240
60.6918
887.669
14.6258
0

64
8192
57344
433.124
4812.82
11.1119
0

64
28672
8192
58.4863
2505.37
42.8369
0

128
8192
8192
58.2865
1096.99
18.8206
0

128
8192
10240
121.688
1202.46
9.88147
0

128
8192
57344
767.995
6741.57
8.77814
0

128
28672
8192
58.5768
3579.83
61.1134
0

256
8192
8192
194.799
1731.37
8.888
0

256
8192
10240
212.755
2273.48
10.6859
0

256
8192
57344
1186.61
11964.1
10.0825
0

256
28672
8192
195.011
5868.9
30.0953
0

512
8192
8192
388.129
3043.3
7.84093
0

512
8192
10240
199.79
3544.64
17.7418
0

512
8192
57344
51.1464
19975.7
390.559
0

512
28672
8192
388.241
10728.5
27.6335
0

As you can see, the kernel produces correct results for m < 64 but incorrect results for m >= 64. So in that sense this kernel is currently not functional for m >= 64. Note also that the latency is drastically reduced for m >= 64, indicating that the kernel is exiting early for some reason. I did some digging and documented my findings below.
Why does m >= 64 produce incorrect results?
After looking into this, I think the problem is allocation of too much shared memory. The A100 has quite a lot more shared memory (164 KB per SM) than the T4, so some assumptions made about shared memory may not hold for the T4.
First, I ran the following script to query the device properties of my T4 GPU:
#include <cuda_runtime.h>
#include <iostream>

int main() {
    cudaDeviceProp prop;
    cudaGetDeviceProperties(&prop, 0);
    std::cout << "Compute Capability: " << prop.major << "." << prop.minor << std::endl;
    std::cout << "Shared memory per block: " << prop.sharedMemPerBlock << " bytes" << std::endl;
    std::cout << "Shared memory per multiprocessor: " << prop.sharedMemPerMultiprocessor << " bytes" << std::endl;
    return 0;
}

Which outputs the following:
Compute Capability: 7.5
Shared memory per block: 49152 bytes
Shared memory per multiprocessor: 65536 bytes

So the available shared memory is indeed highly reduced compared to the A100. At the threshold of m>=64, the kernel gets called with a TilingConfig where WARP_COL_MMA_TENSORS is set to 8, instead of 4:
https://github.com/pytorch/ao/blob/2dea31543635ad747e52047f5091fe0b490c3807/torchao/csrc/cuda/fp6_llm/fp6_linear.cu#L101-L103
This leads to an increased size of TILE_N:
https://github.com/pytorch/ao/blob/2dea31543635ad747e52047f5091fe0b490c3807/torchao/csrc/cuda/fp6_llm/configs.h#L56
Which in turn leads to an increased shared memory allocation:
https://github.com/pytorch/ao/blob/2dea31543635ad747e52047f5091fe0b490c3807/torchao/csrc/cuda/fp6_llm/configs.h#L62-L63
Printing TilingConfig::SMEM_SIZE_C_TILE during runtime shows that when m goes from 32 to 64, TilingConfig::SMEM_SIZE_C_TILE goes from 38912 to 69362. Since 69362 bytes is more shared memory than the T4 has per block and per SM, it seems likely that this is causing problems. (But somehow, this does not throw any kind of error.)  I might look into the details to see if there's any optimizations that can be made for the T4 in this particular case.
I tried creating a guard that checks for sm_75 and m>=64, but this is causing problems. Specifically, I tried to check for __CUDA_ARCH__ in fp6_linear.cu (as done here), but this does not seem to work for some reason  (best reason I can think of is that __CUDA_ARCH__ is not defined because it is not device code, but that doesn't explain why the guard does work at the beginning of the file). However, if I instead try to put the directive inside the device code, it seems that functions like assert don't have any effect (I'm not really sure why).
So currently, the m>=64 case is not handled well (it will lead to incorrect results) and I'd be happy to hear suggestions about how to deal with this case.
Final thoughts

I noticed the splitK paramater for the FP6 kernel is set based on a dictionary that is optimized for the A100 GPU. It might not be optimal for the T4, but I don't have any insights into how much it matters.

Any feedback is very welcome!

@tobiasvanderwerff Thank you for your contribution! The debug when m>=64 is very insightful.
I was the one added this FP6-LLM kernel to torchao. I don't have enough CUDA knowledge to fully understand the changes, but it seems reasonable to me. Have you had the chance to discuss this with the original author about this change? https://github.com/usyd-fsalab/fp6_llm
I will let @msaroufim decide if we should support / improve the kernel for sm75 at all. Concerns include CI testing + deviation from upstream, as well as not worth the efforts due to old age.
General comments:

Low performance for large M is to be expected. I don't think you need to try to optimize for it
Regarding guard for M>=64, if the macro doesn't work, I think you can check with either torch.cuda.get_device_capability() or cudaDeviceProp
Regarding the splitK, yea I don't really like it too. I wish we have an autotune for CUDA kernel, similar to triton 😄
(Can do later, once everything is finalized) Can you add a summary of your changes at the top of each modified file?

Side question. Would you be able to modify this kernel to support BF16? Since all modern models use BF16, it would be useful. I figure it would be a matter of changing the dequant logic + MMA instructions, but again, I'm not too confident with my CUDA skills 😅.

@gau-nernst let me address your comments/questions one by one.

Have you had the chance to discuss this with the original author about this change?

I did not have contact with the original authors. Looking at their repo and paper, I don't have the impression that they had GPUs before A100 generation in mind when they implemented FP6. My main motivation for writing this port is that I thought it was an interesting challenge to try and make this work on a slightly older GPU for a GPU poor person like myself who finds an A100 too expensive to rent for extended periods of time :)

I will let @msaroufim decide if we should support / improve the kernel for sm75 at all. Concerns include CI testing + deviation from upstream, as well as not worth the efforts due to old age.

That's understandable. A little while back I asked around in the GPU-mode discord (formerly CUDA-mode), where @HDCharles mentioned there is potentially a demand for supporting more architectures than what is currently supported.

Regarding guard for M>=64, if the macro doesn't work, I think you can check with either torch.cuda.get_device_capability() or cudaDeviceProp

That's a good idea -- I will try it out.

(Can do later, once everything is finalized) Can you add a summary of your changes at the top of each modified file?

Err, you mean a comment in the C++/CUDA files? As in, add a comment at the top of each changed file saying how I added SM75 support to it? If so, I could do definitely do that.

Side question. Would you be able to modify this kernel to support BF16? Since all modern models use BF16, it would be useful. I figure it would be a matter of changing the dequant logic + MMA instructions, but again, I'm not too confident with my CUDA skills 😅.

I'd love to try that, but unfortunately the T4 does not support BF16 (it requires SM80). So that would require an A100 to work with, which is currently not feasible for me.

@tobiasvanderwerff Thank you for your response
I'm just checking if you ask the original author about this change since he probably can give more feedback in terms of accuracy and perf wise. No worries!
Since bad perf for large M is to be expected (actually FP6-LLM kernel is also slower than FP16 on A100 for M>=128), I think we don't need to check for M>=64? Just use __CUDA_ARCH__ to select tile size accordingly.

Err, you mean a comment in the C++/CUDA files? As in, add a comment at the top of each changed file saying how I added SM75 support to it? If so, I could do definitely do that.

Yes, exactly.

I'd love to try that, but unfortunately the T4 does not support BF16 (it requires SM80). So that would require an A100 to work with, which is currently not feasible for me.

No worries at all! In case you don't know, for sm80 stuff, Lightning AI gives out free 22hrs/month of L4. Some GPU clouds also provide rental service for consumer cards, like 3090 and 4090, which is much cheaper than A100. Just something to consider.
Some other pointers

I think the build wheel CI does not compile for sm75. So interested users have to compile from source. Can you add a line in torchao/dtypes/floatx/README.md saying that sm75 support requires installing torchao from source?
https://github.com/pytorch/ao/blob/64719d5882ac3790e0018bed77d2d7b1e788ac5c/packaging/env_var_script_linux.sh#L16-L19
If possible, can you run the llama2 benchmark for sanity check? https://github.com/pytorch/ao/blob/main/torchao/dtypes/floatx/README.md#end-to-end-benchmarks

I like this PR but am a bit conflicted because we won't be running this in CI so won't get signal on whether SM75 is working and if fp6 in upstream is still actively maintained it'll make it more challenging to fix things upstream

@msaroufim Regarding CI testing, I think we can treat this as "not officially supported", like Windows support. So interested users have to compile from source + no guarantee that future versions will continue working. Since the change is quite small, I think it's still somewhat reasonable.

The kernel now handles the m>=64 edge case to produce correct results for all shapes used in the benchmark (see https://github.com/pytorch/ao/pull/942/commits/650ba03d7df2bbb5c78e0620f71911ecc6c60927).
I couldn't use the CUDA_ARCH constant, so I'm instead checking the CUDA arch at runtime. It unfortunately makes the kernel launch code a bit uglier, since the template parameters of TilingConfig need to be known at compile time. I'm not the most experienced with C++ so there may be a better solution, but this is the best I could come up with to handle this.

Benchmark results on Llama-2-7b-chat-hf
Testing specs:

T4 GPU
Torch version: 2.4.1

float16
python generate.py --compile --precision float16

Average tokens/sec: 19.04
Average Bandwidth: 251.60 GB/s
Peak Memory Usage: 13.90 GB
Model Size: 13.21 GB
fp6
python generate.py --compile --precision float16 --quantization fp6

Average tokens/sec: 40.52
Average Bandwidth: 200.93 GB/s
Peak Memory Usage: 6.61 GB
Model Size: 4.96 GB

Fp6 eval results
python eval.py --compile --precision float16 --quantization fp6

wikitext:

word_perplexity: 12.3653
byte_perplexity: 1.6005
bits_per_byte: 0.6785

@gau-nernst feel free to merge this whenever you feel it's ready


Pothos GUI multi document interface

I think it may have advantages to be able to 'undock' the different tabs from the Pothos GUI in a separate windows.
For a big diagrams we would be able to arrange those windows better, especially having few monitors available.
I am not sure if this can be achieved easily using the current status of the software.

Thats a pretty good idea and its inline with some other gui improvements I was thinking about: https://github.com/pothosware/pothos-gui/issues/102

This issue was moved to pothosware/pothos-gui#147


Collection's toArray() method does not convert nested objects to arrays when called in a PHPUnit test.

Laravel Version: 7.0.7
PHP Version: 7.3.15
PHPUnit Version: 8.5.2

Expected behavior:
Collections toArray() method should convert a collection to a plain array and all of the collection's nested objects that are an instance of Arrayable to an array.
Actual behavior:
toArray() method converts a collection to a plain array but the nested objects are not converted.
Note that this behavior observed only when toArray() called via PHPUnit. When toArray() function called within an app or via Laravel Tinker it works as expected.
Steps To Reproduce:
Repository with a failing test
Test
Clone, install packages, run PHPUnit.
<?php

namespace Tests\Unit;

use App\User;
use Illuminate\Contracts\Support\Arrayable;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

class CollectionToArrayTest extends TestCase
{
    use RefreshDatabase;

    /** @test */
    public function it_converts_nested_objects_that_are_an_instance_of_arrayable_to_an_array()
    {
        factory(User::class)->create();

        $users = User::get();

        // passed
        $this->assertInstanceOf(Arrayable::class, $users[0]);

        // Failed asserting that App\User Object is of type "array"
        $this->assertIsArray($users->toArray()[0]);

        // passed
        $this->assertIsArray($users->toArray()[0]->toArray());
    }
}

Observations:

It've worked before, probably with previous versions of PHP and PHPUnit, however I couldn't identify the moment it has stopped.
It seems that EnumeratesValues::toArray() is not called when ->toArray() is called on Collection in the provided PHPUnit test.

Resolved the issue.
I have Laravel Valet and PHPUnit installed globally. Valet requires tightenco/collect package that is in a conflict with Laravel Collections.
When running PHPUnit, \Illuminate\Support\Collection  gets replaced with Tightenco\Collect\Support\Collection that works differently.
So, I've removed global PHPUnit and used local instead.

Why does valet require that. Could we change it so it doesn't need it?


Create bash-c

What type of PR is this?

[x] Add a new dev container collection
[x] Update to an existing dev container collection
[x] Documentation/spec update
[x] Other containers.dev site update (UX, layout, etc)

Related Issues

Related Issue #
Closes #

Description
Please replace this line with a description of your PR.
Collection checklist
If your PR contributes a new collection, please utilize this checklist:

[ ] Collection name
[x] Maintainer name
[x] Maintainer contact link (i.e. link to a GitHub repo, email)
[x] Repository URL
[x] OCI Reference
[x] I acknowledge that this collection provides new functionality, distinct from the existing collections part of this index.

#399

@JustDontsnitchonme


add --redux option to generator

Add --redux option to generator that will install rwr-redux gem.
rails g react_webpack_rails:install --redux
What do you think?

+1

PR: https://github.com/netguru/react_webpack_rails/pull/77


Digital Screen - nil value error

[ERROR] addons/wire/lua/entities/gmod_wire_digitalscreen/cl_init.lua:51: attempt to perform arithmetic on a nil value
  1. stringToNumber - addons/wire/lua/entities/gmod_wire_digitalscreen/cl_init.lua:51
   2. ProcessBuffer - addons/wire/lua/entities/gmod_wire_digitalscreen/cl_init.lua:81
    3. unknown - addons/wire/lua/entities/gmod_wire_digitalscreen/cl_init.lua:108

Need reproduction steps

Need reproduction steps

Ok. I give you exact E2 code in a zip. (Note: The code inside is completely automatically generated via external program, you're not supposed to change anything.)
Download captainprice-001.zip

Extract captainprice-001 folder from the zip into garrysmod/data/expression2 folder.
Make sure wiring E2 extension is enabled.
Spawn digital screen, and then spawn expression2/captainprice-001/captainprice-001.txt script onto the digital screen entity.
Wait for the upload to finish.
???
Enjoy the script error spam.

Jeez, it lags my game so bad.
Adding this to cl_init.lua:65 fixes the error spam
if #datastr>0 then
	ent:AddBuffer(datastr,pixelbit)
end

but the root of the issue is the decompression fails. I'd have to look at it later.

The data metering is all wrong. That's the problem.

Jeez, it lags my game so bad.

Sort of expected with how wire works currently, everything is just called immediately, it would be much better if certain things used coroutines. Did I say everything? I am pretty sure wire doesn't utilize threads at all. Which results in such a bad performance when dealing with "bigger stuff".

The data metering is all wrong

That's just another sub-issue, yes...

No, coroutines will not make shitty code better - it would just take even longer to load, and no, that was the issue. Check the fix in the PR, I'll test it later.

@CaptainPRICE gmod lua is single threaded. coroutines are not threads.

@Divran

gmod lua is single threaded.

Well, true, and I knew that (it is Lua itself, GLua is nothing more special).

coroutines are not threads.

However, that's a false statement. Lua coroutines are threads (not the same as process thread tho). Read a tutorial to begin with.
Bad performance (and experience) is mostly caused by the Wire editor, not being multi-threaded, GMod freezing up while it is performing code validation on a large buffer (wire_expression2_validate function, parser/compiler being invoked in a sequence). This part of code could really use coroutines, which would make it responsive, and also allow to bring a better user experience, by showing validation progress to the user, while it is doing the hard work in the background.
That was my point. Hopefully you understand it now.


[DOC] Broken links in api documentation in rossmann notebook

 Issue by benfred
Wednesday May 13, 2020 at 21:00 GMT
Originally opened as https://github.com/rapidsai/recsys/issues/126

Rossmann Store Sales Example; http://<IP_ADDRESS>:12800/examples/rossmann-store-sales-preproc.ipynb cannot be found
This might be hard to fix because of how we're rendering the notebook with nbsphinx . See https://github.com/rapidsai/recsys/pull/115 for how we fixed links in the README

this is fixed - and we've updated our build process to fail PR's that have broken links like this in notebooks


update (and broke the review) but got the rest of buttons waiting for…

… routes
Reviews broke.

Looks good! Approved.


Get that cache

This update adds upstash for caching. It will still break if there is no caching available, so I'll add some checks to make sure that we are still working even if cache is not available.


Upgrade to Open5Gs v2.7.1

Components and subsystems
Open5Gs Helm
Proposed functionality
Are you planning the upgrade to v2.7.1? Some bugs were resolved and still exist in version 2.7.0.
New version of helm would be appreciated.
External dependencies
No response

Hi @anabel1012
Yes, I believe we'll upgrade it next week after testing the chart.
Anyway, have you tried to change the image version through values.yaml? That could be a way to use v2.7.1 immediately.
BR,
Álvaro

Hi @anabel1012
New chart is available.
BR,
Álvaro


Add Caption to the table

At the bottom of the last row, there should be an option to display a caption, as a note to the end user

This place is used by pagination


Write chunked batch at the Fragment level

To facilitate the distributed writers, we should have the fine-granularity write control at the Fragment level
Right now, the chunked stream of RecordBatch is done at the global level
https://github.com/lancedb/lancedb/blob/f35f8e451fb6b8f83ca4bad68aefb22c1341eece/node/src/arrow.ts#L36, which only works if we have one single writer.

This seems very doable.
Is that link related?


i18n(pt-BR): update styling.md page

PR #633 added new content to styling page.

Yep! Now is all green :)
import styles from an npm package  was/is very useful during hackathon.


jf audit: SARIF format is missing most of the fields provided by the JSON format

Describe the bug
SARIF format is not on-par with the JSON format.
Current behavior
SARIF format is missing most of the JSON format information:

No license (FOSS) information at all
CVSS Vector
Impacted paths

In-case of a multi-maven project, the uri is "pom.xml" (no module prefix) with startLine, startColumn and endLine set to 0.

Fixed versions
All of the extended information (from the R&D enrichment)

Haven't verified the contextual analysis, but my guess is, it is also missing

References

Note:

I validated the sarif output and apparently it isn't following the SARIF format properly as well, see https://sarifweb.azurewebsites.net/Validation to validate a SARIF file

Reproduction steps

Perform a scan with the JSON format
Perform a scan with the SARIF format
Compare the 2

Expected behavior
SARIF format is on-par with the JSON format in term of information provided.
JFrog CLI version
2.42.1
Operating system type and version
Docker
JFrog Artifactory version
No response
JFrog Xray version
No response

Any update on this?  I can't upload the jf audit sarif file to Github Security

Hi,
I'm not sure if I have the same issue
I cannot import sarif report but on SonarQube.
It works for other dependencies checker (from maven) so I suspect the issue comes from the format of the jf client.
[15:29:34.192+02:00] - [INFO] 13:29:31.682 Sensor Import external issues report from SARIF file.
[15:29:34.192+02:00] - [WARNING] 13:29:31.769 Failed to import an issue raised by tool JFrog Xray SCA, error: URI has an authority component

This is my sarif report

Expand
{
  "version": "2.1.0",
  "$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json",
  "runs": [
    {
      "tool": {
        "driver": {
          "informationUri": "https://docs.jfrog-applications.jfrog.io/jfrog-security-features/sca",
          "name": "JFrog Xray SCA",
          "rules": [
            {
              "id": "CVE-2016-1000027_org.springframework:spring-web_5.3.31",
              "shortDescription": {
                "text": "[CVE-2016-1000027] org.springframework:spring-web 5.3.31"
              },
              "help": {
                "text": "Pivotal Spring Framework through 5.3.16 suffers from a potential remote code execution (RCE) issue if used for Java deserialization of untrusted data. Depending on how the library is implemented within a product, this issue may or not occur, and authentication may be required. NOTE: the vendor's position is that untrusted data is not an intended use case. The product's behavior will not be changed because some users rely on deserialization of trusted data.",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 9.8      | `org.springframework:spring-web 5.3.31`       | [6.0.0]   |"
              },
              "properties": {
                "security-severity": "9.8"
              }
            },
            {
              "id": "CVE-2024-22259_org.springframework:spring-web_5.3.31",
              "shortDescription": {
                "text": "[CVE-2024-22259] org.springframework:spring-web 5.3.31"
              },
              "help": {
                "text": "Applications that use UriComponentsBuilder in Spring Framework to parse an externally provided URL (e.g. through a query parameter) AND perform validation checks on the host of the parsed URL may be vulnerable to a  open redirect https://cwe.mitre.org/data/definitions/601.html  attack or to a SSRF attack if the URL is used after passing validation checks.\n\nThis is the same as  CVE-2024-22243 https://spring.io/security/cve-2024-22243 , but with different input.\n\n",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 8.1      | `org.springframework:spring-web 5.3.31`       | [5.3.33], [6.0.18], [6.1.5]   |"
              },
              "properties": {
                "security-severity": "8.1"
              }
            },
            {
              "id": "CVE-2024-22257_org.springframework.security:spring-security-core_5.8.9",
              "shortDescription": {
                "text": "[CVE-2024-22257] org.springframework.security:spring-security-core 5.8.9"
              },
              "help": {
                "text": "In Spring Security, versions 5.7.x prior to 5.7.12, 5.8.x prior to \n5.8.11, versions 6.0.x prior to 6.0.9, versions 6.1.x prior to 6.1.8, \nversions 6.2.x prior to 6.2.3, an application is possible vulnerable to \nbroken access control when it directly uses the AuthenticatedVoter#vote passing a null Authentication parameter.\n\n",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 8.2      | `org.springframework.security:spring-security-core 5.8.9`       | [5.7.12], [5.8.11], [6.1.8], [6.2.3]   |"
              },
              "properties": {
                "security-severity": "8.2"
              }
            },
            {
              "id": "CVE-2024-22243_org.springframework:spring-web_5.3.31",
              "shortDescription": {
                "text": "[CVE-2024-22243] org.springframework:spring-web 5.3.31"
              },
              "help": {
                "text": "Applications that use UriComponentsBuilder to parse an externally provided URL (e.g. through a query parameter) AND perform validation checks on the host of the parsed URL may be vulnerable to a  open redirect https://cwe.mitre.org/data/definitions/601.html  attack or to a SSRF attack if the URL is used after passing validation checks.\n",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 8.1      | `org.springframework:spring-web 5.3.31`       | [5.3.32], [6.0.17], [6.1.4]   |"
              },
              "properties": {
                "security-severity": "8.1"
              }
            },
            {
              "id": "CVE-2023-48795_org.apache.sshd:sshd-common_2.11.0",
              "shortDescription": {
                "text": "[CVE-2023-48795] org.apache.sshd:sshd-common 2.11.0"
              },
              "help": {
                "text": "The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in<EMAIL_ADDRESS>and (if CBC is used) the<EMAIL_ADDRESS>MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before <IP_ADDRESS>p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through <IP_ADDRESS>, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 5.9      | `org.jenkins-ci.main:cli 2.440.2`       | No fix available   |"
              },
              "properties": {
                "security-severity": "5.9"
              }
            },
            {
              "id": "CVE-2023-48795_org.apache.sshd:sshd-core_2.11.0",
              "shortDescription": {
                "text": "[CVE-2023-48795] org.apache.sshd:sshd-core 2.11.0"
              },
              "help": {
                "text": "The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in<EMAIL_ADDRESS>and (if CBC is used) the<EMAIL_ADDRESS>MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before <IP_ADDRESS>p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through <IP_ADDRESS>, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 5.9      | `org.jenkins-ci.main:cli 2.440.2`       | No fix available   |"
              },
              "properties": {
                "security-severity": "5.9"
              }
            },
            {
              "id": "XRAY-589059_org.jfree:jcommon_1.0.23",
              "shortDescription": {
                "text": "[XRAY-589059] org.jfree:jcommon 1.0.23"
              },
              "help": {
                "text": "This package may be vulnerable to the MavenGate attack",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 0.0      | `org.jfree:jcommon 1.0.23`       | No fix available   |"
              },
              "properties": {
                "security-severity": "0.0"
              }
            },
            {
              "id": "XRAY-589059_org.slf4j:slf4j-api_2.0.11",
              "shortDescription": {
                "text": "[XRAY-589059] org.slf4j:slf4j-api 2.0.11"
              },
              "help": {
                "text": "This package may be vulnerable to the MavenGate attack",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 0.0      | `org.jenkins-ci.main:cli 2.440.2`       | No fix available   |"
              },
              "properties": {
                "security-severity": "0.0"
              }
            },
            {
              "id": "XRAY-589059_com.jcraft:jzlib_1.1.3-kohsuke-1",
              "shortDescription": {
                "text": "[XRAY-589059] com.jcraft:jzlib 1.1.3-kohsuke-1"
              },
              "help": {
                "text": "This package may be vulnerable to the MavenGate attack",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 0.0      | `com.jcraft:jzlib 1.1.3-kohsuke-1`       | No fix available   |"
              },
              "properties": {
                "security-severity": "0.0"
              }
            },
            {
              "id": "XRAY-589059_org.slf4j:jcl-over-slf4j_2.0.11",
              "shortDescription": {
                "text": "[XRAY-589059] org.slf4j:jcl-over-slf4j 2.0.11"
              },
              "help": {
                "text": "This package may be vulnerable to the MavenGate attack",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 0.0      | `org.jenkins-ci.main:cli 2.440.2`       | No fix available   |"
              },
              "properties": {
                "security-severity": "0.0"
              }
            },
            {
              "id": "XRAY-589059_org.slf4j:slf4j-jdk14_2.0.11",
              "shortDescription": {
                "text": "[XRAY-589059] org.slf4j:slf4j-jdk14 2.0.11"
              },
              "help": {
                "text": "This package may be vulnerable to the MavenGate attack",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 0.0      | `org.jenkins-ci.main:cli 2.440.2`       | No fix available   |"
              },
              "properties": {
                "security-severity": "0.0"
              }
            },
            {
              "id": "XRAY-589059_org.jfree:jfreechart_1.0.19",
              "shortDescription": {
                "text": "[XRAY-589059] org.jfree:jfreechart 1.0.19"
              },
              "help": {
                "text": "This package may be vulnerable to the MavenGate attack",
                "markdown": "| Severity Score | Direct Dependencies | Fixed Versions     |\n| :---:        |    :----:   |          :---: |\n| 0.0      | `org.jfree:jfreechart 1.0.19`       | No fix available   |"
              },
              "properties": {
                "security-severity": "0.0"
              }
            }
          ],
          "version": "3.69.3"
        }
      },
      "results": [
        {
          "ruleId": "CVE-2016-1000027_org.springframework:spring-web_5.3.31",
          "ruleIndex": 0,
          "level": "error",
          "message": {
            "text": "[CVE-2016-1000027] org.springframework:spring-web 5.3.31"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "CVE-2024-22259_org.springframework:spring-web_5.3.31",
          "ruleIndex": 1,
          "level": "error",
          "message": {
            "text": "[CVE-2024-22259] org.springframework:spring-web 5.3.31"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "CVE-2024-22257_org.springframework.security:spring-security-core_5.8.9",
          "ruleIndex": 2,
          "level": "error",
          "message": {
            "text": "[CVE-2024-22257] org.springframework.security:spring-security-core 5.8.9"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "CVE-2024-22243_org.springframework:spring-web_5.3.31",
          "ruleIndex": 3,
          "level": "error",
          "message": {
            "text": "[CVE-2024-22243] org.springframework:spring-web 5.3.31"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "CVE-2023-48795_org.apache.sshd:sshd-common_2.11.0",
          "ruleIndex": 4,
          "level": "warning",
          "message": {
            "text": "[CVE-2023-48795] org.jenkins-ci.main:cli 2.440.2"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "CVE-2023-48795_org.apache.sshd:sshd-core_2.11.0",
          "ruleIndex": 5,
          "level": "warning",
          "message": {
            "text": "[CVE-2023-48795] org.jenkins-ci.main:cli 2.440.2"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "XRAY-589059_org.jfree:jcommon_1.0.23",
          "ruleIndex": 6,
          "level": "note",
          "message": {
            "text": "[XRAY-589059] org.jfree:jcommon 1.0.23"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "XRAY-589059_org.slf4j:slf4j-api_2.0.11",
          "ruleIndex": 7,
          "level": "note",
          "message": {
            "text": "[XRAY-589059] org.jenkins-ci.main:cli 2.440.2"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "XRAY-589059_com.jcraft:jzlib_1.1.3-kohsuke-1",
          "ruleIndex": 8,
          "level": "note",
          "message": {
            "text": "[XRAY-589059] com.jcraft:jzlib 1.1.3-kohsuke-1"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "XRAY-589059_org.slf4j:jcl-over-slf4j_2.0.11",
          "ruleIndex": 9,
          "level": "note",
          "message": {
            "text": "[XRAY-589059] org.jenkins-ci.main:cli 2.440.2"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "XRAY-589059_org.slf4j:slf4j-jdk14_2.0.11",
          "ruleIndex": 10,
          "level": "note",
          "message": {
            "text": "[XRAY-589059] org.jenkins-ci.main:cli 2.440.2"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        },
        {
          "ruleId": "XRAY-589059_org.jfree:jfreechart_1.0.19",
          "ruleIndex": 11,
          "level": "note",
          "message": {
            "text": "[XRAY-589059] org.jfree:jfreechart 1.0.19"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "file://Package-Descriptor"
                }
              }
            }
          ]
        }
      ]
    }
  ]
}

Also posted on https://community.sonarsource.com/t/cannot-import-sarif-report-from-jfrog-xray-cli/113649

To make it work for Sonar , had to remove the file:// in uri artifact path... But same issue with multi module maven project. It is missing the correct path for the module. The sarif formar could use some improvement.


TabError: inconsistent use of tabs and spaces in indentation

week ago, I was running the model perfectly, I am trying to use it today  it returns me super bad error when I try to call the package and modules "TabError: inconsistent use of tabs and spaces in indentation"
from spectra import spectra as spc
TabError: inconsistent use of tabs and spaces in indentation
from spectra import spectra_util as spc_tl
TabError: inconsistent use of tabs and spaces in indentation
from spectra import spectra_util as spc_tl
TabError: inconsistent use of tabs and spaces in indentation
I used the original notebook (tutorial notebook) of spectra.
please I need help, How can I avoid this error.

Let me know if the most recent changes fix the issue.


Encoder stops without starting encoding

Hi
I was doing some tests with rav1e windows build 0.1.0 (20190926-19-ge11f06a) and found one video that I couldn't encode. The process started as usual with:
INFO  rav1e > Using y4m decoder: 550x872p @ 30000/1001 fps, 4:2:0, 8-bit
INFO  rav1e > Encoding settings: keyint_min=12 keyint_max=240 quantizer=150 bitrate=0 min_quantizer=0 low_latency=false tune=Psychovisual rdo_lookahead_frames=40 min_block_size=4x4 multiref=true fast_deblock=false reduced_tx_set=false tx_domain_distortion=false tx_domain_rate=false encode_bottomup=true rdo_tx_decision=true prediction_modes=Complex-All include_near_mvs=true no_scene_detection=false diamond_me=true cdef=true quantizer_rdo=true use_satd_subpel=true non_square_partition=false
INFO  rav1e::api::config > CPU Feature Level: SSSE3
INFO  rav1e::api::internal > Using 4 tiles (1x4)

and stopped here without saying why. Output was not readable by media player and had only 32KB. Is there some debug option I could turn on to get what's happening? The parameters I used are:
-v -s 1 --threads 4 --tile-rows 4 --quantizer 150
I tried changing -s and tiles.
Also worth mention is the fact I have the same video but in 1920x1080 and it works just fine. The one here is simply resized and cropped. Maybe it is somehow related to the resolution? Like SvtAv1Enc that works only with dimensions that can be divided by 8?

I tested encoding a clip with the same resolution and parameters and had no problem, so will need a sample to try to reproduce.

Could you test if it works if you try using 1 tile instead of 4? That is my first suspicion for what might be causing this.

@rzumer I was afraid it may have something to do with this specific file. And I can't unfortunately share it because that's some internal thing. :( That's why I asked about some way to debug this, to get an idea why it chooses to stop.
@shssoichiro Nope, it didn't work.

I've made some additional tests by using different video with similar parameters (fullHD, not long etc.) and put it through the same pipeline, which is:
ffmpeg -i "%%a" -preset slow -crf 0 -tune film -vf scale=-1:872,crop=550:in_h "in\%%~na_temp.mp4"
ffmpeg -i "%%a" "in\%%~na.y4m"
rav1e -v -s 1 --threads 4 --tile-rows 4 --quantizer 150 "%%a" -o "out\%%~na.ivf"

And the result are the same like with the previous file - encoding stops. Changing -crf doesn't make any difference. The weirdest part is that I tried ffmpeg to econde into AV1 and it stops always at 53 frame. And it work properly some time ago when I was playing with AV1 from ffmpeg, rav1e and SvtAv1Enc.
I will make another attempt when my friend that made this video show up. I will ask him to render it directly to 550x872 to remove ffmpeg from the variables.

I got 550x872 mp4 file rendered by Premiere Pro that I converted to y4m with ffmpeg and rav1e still won't encode it. The same procedure works for 1920x1080. So I have no idea what is going on.
Especially that I took some stock fullHD clip and do the same thing with it getting the same effect. This one I can attach so here you go. Three files from the three steps: original, cropped and y4m.

I tried to encode the y4m from your zipfile:
rav1e -v -s 1 --threads 4 --tile-rows 4 --quantizer 150 Pexels_Videos_1572432_mobile.y4m -o test.ivf

It works for me.
 INFO  rav1e > Using y4m decoder: 550x872p @ 24000/1001 fps, 4:2:0, 8-bit
 INFO  rav1e > Encoding settings: keyint_min=12 keyint_max=240 quantizer=150 bitrate=0 min_quantizer=0 low_latency=false tune=Psychovisual rdo_lookahead_frames=40 min_block_size=4x4 multiref=true fast_deblock=false reduced_tx_set=false tx_domain_distortion=false tx_domain_rate=false encode_bottomup=true rdo_tx_decision=true prediction_modes=Complex-All include_near_mvs=true no_scene_detection=false diamond_me=true cdef=true quantizer_rdo=true use_satd_subpel=true non_square_partition=false
 INFO  rav1e::api::config > CPU Feature Level: AVX2

Only happens for SSSE3?

Hm...it may be because inspired by your suggestion I did test that stock clip on my tablet that has Intel(R) Core(TM) m3-6Y30 CPU @ 0.90GHz (it's not as slow as one may think XD) and rav1e uses AVX2 for CPU Feature Level here.
Is there a way to change/enforce which CPU Feature Level will be used?

You can set the "RAV1E_CPU_TARGET" environment variable (set to "rust" to disable all ASM), although it won't consistently apply to all ASM until #1717 gets merged.

The issue seems to be with one of the SSE2 functions which we also have an AVX function for. I ran this against the #1717 branch:
➜ RAV1E_CPU_TARGET=avx2 cargo test --release --features decode_test_dav1d,check_asm
running 149 tests
...

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

➜ RAV1E_CPU_TARGET=sse2 cargo test --release --features decode_test_dav1d,check_asm

running 149 tests
test api::test::large_width_assert ... ok
...
test test_encode_decode::low_bit_depth_dav1d ... ignored
test test_encode_decode::odd_size_frame_with_full_rdo_dav1d ... ignored
error: process didn't exit successfully: `/Users/jholmer/repos/rav1e/target/release/deps/rav1e-28480a92d3ad6253` (signal: 11, SIGSEGV: invalid memory reference)

➜ RAV1E_CPU_TARGET=ssse3 cargo test --release --features decode_test_dav1d,check_asm

running 149 tests
test api::test::large_width_assert ... ok
...
test test_encode_decode::low_bit_depth_dav1d ... ignored
test test_encode_decode::odd_size_frame_with_full_rdo_dav1d ... ignored
error: process didn't exit successfully: `/Users/jholmer/repos/rav1e/target/release/deps/rav1e-28480a92d3ad6253` (signal: 11, SIGSEGV: invalid memory reference)

➜ RAV1E_CPU_TARGET=rust cargo test --release --features decode_test_dav1d,check_asm

running 149 tests
...

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

I've tracked the segfault as best I can down to rav1e_sad16x16_sse2. It does not crash on every call to it, only with certain input data. This can be reproduced against the test test_encode_decode::quantizer_100_dav1d.

I was able to produce a backtrace, below, off of my branch for #1717. I also determined that the condition causing this to happen is when the width of the video is not a multiple of 64. The height of the video does not have any effect.
rav1e-0afb1c11afed9f10`rav1e_sad16x16_sse2.loop at sad_sse2.asm:232
->  0x555555d7a8db <+20>: psadbw (%rdi), %xmm1
frame #1: 0x00005555559457b4 rav1e-0afb1c11afed9f10`rav1e::me::full_search::h6a2ee690f2d8e627 at dist.rs:122:8
   119    let dist = match T::type_enum() {
   120      PixelType::U8 => match SAD_FNS[cpu.as_index()][to_index(bsize)] {
   121        Some(func) => unsafe {
-> 122          (func)(
   123            src.data_ptr() as *const _,
   124            T::to_asm_stride(src.plane_cfg.stride),
   125            dst.data_ptr() as *const _,
frame #2: 0x0000555555945226 rav1e-0afb1c11afed9f10`rav1e::me::full_search::h6a2ee690f2d8e627(fi=&0x7ffff014eb10, x_lo=-20, x_hi=22, y_lo=-16, y_hi=16, bsize=BLOCK_16X16, p_org=&0x7ffff7b0d5f0, p_ref=&0x7ffff00c67d8, best_mv=&0x7ffff7b0a248, lowest_cost=&0x7ffff7b0a240, po=PlaneOffset {
x: 2,
y: 0
}, step=1, lambda=0, pmv=[MotionVector {
row: 0,
col: 0
}, MotionVector {
row: 0,
col: 0
}], allow_high_precision_mv=false) at me.rs:976
   973    // Select rectangular regions within search region with vert+horz windows
   974    for vert_window in search_region.vert_windows(blk_h).step_by(step) {
   975      for ref_window in vert_window.horz_windows(blk_w).step_by(step) {
-> 976        let sad = get_sad(
   977          &plane_org,
   978          &ref_window,
   979          bsize,
frame #3: 0x0000555555949bb6 rav1e-0afb1c11afed9f10`rav1e::me::estimate_motion_ss4::h2c1ffaf9be5098c2(fi=&0x7ffff014eb10, ts=&0x7ffff7b0ad68, bsize=BLOCK_64X64, ref_idx=0, tile_bo=TileBlockOffset(BlockOffset {
x: 16,
y: 0
})) at me.rs:1065:4
   1062     // Divide by 16 to account for subsampling, 0.125 is a fudge factor
   1063     let lambda = (fi.me_lambda * 256.0 / 16.0 * 0.125) as u32;
   1064
-> 1065     full_search(
   1066       fi,
   1067       x_lo,
   1068       x_hi,
frame #4: 0x00005555558b789e rav1e-0afb1c11afed9f10`rav1e::api::internal::ContextInner$LT$T$GT$::compute_lookahead_motion_vectors::_$u7b$$u7b$closure$u7d$$u7d$::h719b05ade4c22c28 at encoder.rs:2750:14
   2747           let r = fi.ref_frames[i] as usize;
   2748           if pmvs[r].is_none() {
   2749             pmvs[r] =
-> 2750               estimate_motion_ss4(fi, ts, BlockSize::BLOCK_64X64, r, bo);
   2751           }
   2752         }
   2753         frame_pmvs.push(pmvs);
frame #5: 0x00005555558b72b4 rav1e-0afb1c11afed9f10`rav1e::api::internal::ContextInner$LT$T$GT$::compute_lookahead_motion_vectors::_$u7b$$u7b$closure$u7d$$u7d$::h719b05ade4c22c28(ctx=TileContextMut<u8> @ 0x00007ffff7b0ad68) at internal.rs:596
   593          let ts = &mut ctx.ts;
   594
   595          // Compute the quarter-resolution motion vectors.
-> 596          let tile_pmvs = build_coarse_pmvs(fi, ts, &inter_cfg);
   597
   598          // Compute the half-resolution motion vectors.
   599          let mut half_res_pmvs = Vec::with_capacity(ts.sb_height * ts.sb_width);

Isn't this now resolved?

The crash is resolved, but the ASM is still broken. I've removed this as a blocker on the release, but I'm leaving this open to represent fixing and reenabling the broken ASM function.

The crash is resolved, but the ASM is still broken. I've removed this as a blocker on the release, but I'm leaving this open to represent fixing and reenabling the broken ASM function.

Right, thanks for revising the title of issue.


Config transformation framework

For easy transformation of configuration schemas, a migration framework like used in CommandBook would be useful to implement. There are probably changes that need to be made to accommodate the fact that we exclusively use Object[] paths rather than the strings with path separator characters of previous config library iterations, but these things have been useful in the past

Added in f1704d9dd058941c12ee3d78a28dc45c4875b35e


Map matching does not work

m = #{"foo" => "bar", "bar" => "foo"}
#{"foo" := a, "bar" := b} = m
Unexpected token '#' at line 1, column 1

Are you doing this from the REPL or in a source file?

@xafizoff The REPL does not support top level bindings still:(

Then you should remark this in the docs, I think

Support top level bindings Now.


get power out of amplifier

cannot get power out of a amplifier, power cable connects and energy is stored, but will not transmit

You need to configure the cable to pull mode.

is there a way to keep the laser off while pulling power out?

nevermind


Reference Scoping Fix

with to references to prototype services. Also added test cases that validate proper behavior for references to both singleton and prototype services.

Verify what we do for bundle scoped (whether this defaults to singleton or prototype

Verify what we do for bundle scoped (whether this defaults to singleton or prototype)

@jeffdiclemente It looks like this doesn't matter anymore because we rely on GetService to return the 'correct' thing based on the scope of the service.
For the sake of figuring this question out anyway, we treat BUNDLE_SCOPE as PROTOTYPE_SCOPE in the codebase.


Tag Delimiter Crash

What steps will reproduce the problem?

Set the general tag delimiter to any character (ie. ";").
Save an image with that character in one of its tags.

What is the expected behavior? What do you get instead?
Save should work. Instead, client crashes every time you try to save that image.
What version of the program are you using? On what operating system?
4.7.0, Windows 10 64bit
Please provide any additional information below
This has been driving me nuts for a while and I finally tracked it down. It works for all of the delimiters I've tried and the images save perfectly fine once you set the delimiter to something else.
I suspect this was also the cause of a few bulk downloads that crashed grabber.

At what point does it crash exactly?
I just tried reproducing with no success: I set the general delimiter to ; then saved some random image containing the ;D tag with the %all%.%ext% filename, and nothing happened. Same thing trying to batch download 200 of them.
The only result was files with ...;;d;... inside their filenames which seems to be the appropriate behaviour.

Ah, sorry, it appears to crash when the %all:includenamespace% token is in the Image Command field. It seems to happen regardless of how the token is present. ie. even if it's wrapped in quotation marks; whether it's being passed as an argument or just printed all by itself; etc.

Ok, I could reproduce then, I'll fix this for next version.
It indeed comes from the new includenamespace option.
In the meantime, as a temporary fix, you can use another separator that is not likely to appear in a tag, such as ¤ or §.


Feat: Create an 'Introduction to Open Source' Page

Description

We need to create an 'Introduction to Open Source' page:

Keep the theme intact
Add some placeholder entries to the page as resources as the real ones will be dynamically inserted later
The way in which each resource will show up is up to you

For Assignee:

Ensure that you submit a PR for this issue within 4 days. Otherwise, you will be unassigned from this issue and it will be passed on to the next contributor who asked to be assigned to it.

Note: This issue is for JWoC 2024 participants. If you are not participating in this event, please refrain from asking to get assigned to this issue.

@Sriparno08 I am interested in working on this issue. Kindly assign it to me on/after Jan 15th

Hello, @Sriparno08 I would like to work on this , please assign it to me.

I would like work on this ,please assign it to me JWOC

@Sriparno08 I am interested in working on this issue. Kindly assign it to me on/after Jan 15th

I would like to work on this issue under JWoC. Please assign it to me @Sriparno08

Hey @sanjayh-2022, you're assigned 👍
To Others:
The mentee who is assigned to this issue is chosen because he/she was the first one to ask for assignment on or after 15th Jan, 2024 with the 'JWOC' keyword in his/her comment.

Hi, @Sriparno08, It has been 5 days since this issue was assigned. and the time limit for a hard issue was 4 days...so please re-assign this to me under 2024...I worked on your project before and I can complete this issue in time.

Hey @sanjayh-2022, please submit a PR for this issue as soon as possible. If not, you will be unassigned from this issue.
Hey @Ananyamishra08, @zul132 and @Surajit0573, please make a fresh comment with the 'JWOC' (Case-Sensitive) keyword in your comment to be considered for assignment.
The first one to do it will be assigned if @sanjayh-2022 doesn't respond with a PR soon.

Hey @sanjayh-2022, please submit a PR for this issue as soon as possible. If not, you will be unassigned from this issue.
Hey @Ananyamishra08, @zul132 and @Surajit0573, please make a fresh comment with the 'JWOC' (Case-Sensitive) keyword in your comment to be considered for assignment.
The first one to do it will be assigned if @sanjayh-2022 doesn't respond with a PR soon.

Please assign me in this issue under JWOC 2024, if not completed

Pls assign this issue under jwoc to me

Please assign this issue to me under JWOC, if not completed.

Hey @Surajit0573, you're assigned.
To Others:
The mentee who is assigned to this issue is chosen because he/she was the first one to ask for assignment with the 'JWOC' keyword in his/her comment.


Performance improvements for graph merge

KG-Bioportal is on the large size. As per the latest KGX merge:
 Merged graph has 10180033 nodes and 24585734 edges

and that is without several of the largest ontologies like NCBITAXON.
Merging this graph on our build server requires >24 hours. did not complete after more than 48 hours.
Some options for improved efficiency:

Pre-concatenate some or all graphs, without including KGX functions (so merging only on identical lines and no clique merges)
But note that not all graphs have the same number or order of columns.
Reduce total nodes/edges through namespace mappings where possible (e.g., http://purl.obolibrary.org/obo/BFO_0000004 should always use this URI rather than http://purl.obolibrary.org/obo/bfo#IndependentContinuant )
Pre-process with pandas - it can apparently be quite performant and tolerant to column differences when performing concatenation, even with large files.

I suspect that one issue slowing the merge is that ~10 of the graphs had some residual parsing errors causing their edge values to be shifted over by one column. I've rebuilt the offending transforms, re-uploaded them, and will start a fresh build.

Node and edge counts are now slightly different:
19:29:46  [KGX][cli_utils.py][               merge] INFO: Merged graph has 10173436 nodes and 24590908 edges

and graph appears to still be in merge after ~15 hrs

Even with kgx 1.5.7's streaming merges, this build does not complete in a week.
I suspect it is hitting a memory limit.
For now, will need to try a smaller merge.

Build of 60 ontologies, with 281536 nodes and 610177 edges, completes without issue.
Will try 180 ontologies next.

Build of 180 ontologies, with 1149039 nodes and 2871945 edges, completed without issue in ~4 hrs.
(Did not upload to KG-Hub as it was completed too soon after previous build).
Will try 360 ontologies next.

Merge of 360 ontologies did not complete after 2 days.

For a very similar set of 359 ontologies, the merge completed in 108 minutes.

If cat-merge works here, propagate the function to other KG-Hub repos

896 ontologies (~98% of bioportal ontologies) now merge w/ cat-merge in 3h 11min
Acceptable!


remove comment

hopefully the final test, an end-to-end run that will create a preview deployment that shows up in this PR, with a branch that gets deleted once the PR is merged

preview: https://svelte-dev-git-preview-cli-266-svelte.vercel.app/
this is an automated message


fix: export cancel_transaction

Going through the sdk docs, it seems like cancel_transaction ought to be exported. This PR does that.
https://docs.relational.ai/rkgms/sdk/julia-sdk#transaction-cancellation

@NRHelmi are you okay with merging this?

thanks @mcmcgrath13

(feel free to make a release if you want to; i think you should have permissions. Otherwise i would probably wait til another PR or two, just cause it's tedious)


Use AbsentRep instead of MissingSeparator

In cases where a element in a sequence's prefix separator is not found
use the AbsentRep error instead of MissingSeparator. This causes
us to reset to a PoU rather than just continuing - throwing
out the error from finding out of scope separators.
DAFFODIL-2399

Does this also mean that there is a bug in the TDML Runner where it wasn't detecting tests that returned both an infoset and diagnostics containing errors? This would be good to fix as part of this to ensure we don't accidentally add back this kind of issue.

Does this also mean that there is a bug in the TDML Runner where it wasn't detecting tests that returned both an infoset and diagnostics containing errors? This would be good to fix as part of this to ensure we don't accidentally add back this kind of issue.

I scanned through the TDMLRunner, and I don't see any logic preventing the test from returning both errors and an infoset. There is logic to prevent the TDMLRunner from being started while expecting both however.

I scanned through the TDMLRunner, and I don't see any logic preventing the test from returning both errors and an infoset. There is logic to prevent the TDMLRunner from being started while expecting both however.

It would probably be a good idea to at that, that would show if there are any other tests that have this same issue.

I scanned through the TDMLRunner, and I don't see any logic preventing the test from returning both errors and an infoset. There is logic to prevent the TDMLRunner from being started while expecting both however.

It would probably be a good idea to add that check, that would show if there are any other tests that have this same issue.

Adding a check to enforce no diagnostics - i.e. Assert.invariant(diagObjs.length == 0) in TDMLRunner.scala line 938 or so - causes 76 test failures. It catches a lot of ValidationError type messages, but also a few parse errors.

I think checking that there are no diagnostics is to strict of a check. Things like validation errors and warnings are diagnostics that should be allowed. We really want to ensure that there are no error diagnostics. Each diagnostics has an isError that says whether it's warning vs error.

I've commented out the tests failing due to DAFFODIL-2512, so all tests now pass. I've removed the WIP tag. Since it's been a while since, I'd like for this to get a re-review before squash/merge.


merge from arlac77/npm-package-template-esm-only

.travis.yml

chore(travis): (jobs.include)
chore(travis): add 13.1.0 remove 13.0.1 (jobs.include.node_js)
chore(travis): (script)

:tada: This PR is included in version 1.5.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Removed printf custom specifier (revert back musl compatibility)

Back port logging from dev to v0.5.9

This commit on Dev broke the build on APPLE. Can you also merge the last commit I did in dev to fix that Apple build?

Apple build fix from dev branch was added.