text:
[dv: tl ul] Host agent is not comforming to spec - back2back messages

in conjunction with #3208
While the TL-UL specification does not allow multi beat messages, I cannot find anything in the spec that disallows driving single beat messages back2back.
which would give a burst-like behavior.
Currently, our DV host does not support this functionality. the minimum distance between consecutive messages is 1 clock cycle gap. This basically cuts the bandwidth in half.
figure 4.1 in  the specification version 1.8.1

Message J has opcode 4, which on Channel A indicates a Get. Even though the Get operates on 16
bytes as indicated by a_size, message J itself carries no data and thus fits in a single beat which is
accepted immediately. Message K can then be issued and accepted the following cycle

in the wave below the request is accepted immediately, so the next beat should be presented in the next cycle. but this is not the case

good catch.  Back to back transactions is definitely something we need to check.
I assume at a minimum the icache will do this.

@rasmus-madsen
we do have test a lot of back2back cases in CSR tests.

If you would like to have back2back in the other IP seq, use csr_rd/wr(.blocking(0))
  task automatic csr_rd(input  uvm_object     ptr, // accept reg or field
                        output uvm_reg_data_t value,
                        input  uvm_check_e    check = UVM_CHECK,
                        input  uvm_path_e     path = UVM_DEFAULT_PATH,
                        input  bit            blocking = default_csr_blocking,
                        input  bit            backdoor = 0,
                        input  uint           timeout_ns = default_timeout_ns,
                        input  uvm_reg_map    map = null);
    if (backdoor) begin
        csr_peek(ptr, value, check);
    end else if (blocking) begin
      csr_rd_sub(ptr, value, check, path, timeout_ns, map);
    end else begin
      fork
        csr_rd_sub(ptr, value, check, path, timeout_ns, map);
      join_none
      // Add #0 to ensure that this thread starts executing before any subsequent call
      #0;
    end
  endtask

But if using non-blocking, csr_rw/rd will consume no time, you may need to add some blocking statement.
forever begin
  csr_rd(a_reg, .blocking(0));
  #dly;
end

I feel some TLUL behavior can be covered by CSR test suite, such as back2back access, TLUL error, csr reset value. In the IP seq, we can focus more on IP functionality rather than the register module. WDYT?

@weicaiyang I think I tried that and I concluded that the blocking was for some other feature as it didn't do what I expected.
I can look again tomorrow and try to come up with a solution.
but I disagree that back to back can be covered by CSR tests since AES will be bandwidth limited without this functionality
and I expect that the most common behavior for AES is to write the register groups back 2 back.

but I disagree that back to back can be covered by CSR tests since AES will be bandwidth limited without this functionality
and I expect that the most common behavior for AES is to write the register groups back 2 back.

agree, if it's to stress test the bandwidth limit. We certainly should enable back2back access and zero_delays.
blocking=0 can start next CSR access without waiting for completion of current access.
zero_delays will set all TL random delay to 0. (example).

@weicaiyang I will set the TL UL delays from my test,
I feel  both sides should be configured to one of 5 options.
0 delay (super fast)
fast (delay from 0-5)
slow (delay from 4-10)
very slow (delay 10)
I will randomize host and device to one of the 5 options and set the tl_ul agent config accordingly from my test

@weicaiyang I will set the TL UL delays from my test,
I feel both sides should be configured to one of 5 options.
0 delay (super fast)
fast (delay from 0-5)
slow (delay from 4-10)
very slow (delay 10)
I will randomize host and device to one of the 5 options and set the tl_ul agent config accordingly from my test

there are kinds of delay knobs in agent cfg. TLUL agent acts as a host for AES. You can just control those knobs for host.

that is the plan.

@weicaiyang after taking a closer look I do not believe that the blocking(0) option is appropriate for b2b transactions I don't fully understand this feature.
Each transaction should take 1 clock. but the driver should be ready to present the next transaction on the following clock.
which is why I believe this is a problem in the driver.
virtual task send_a_channel_request(tl_seq_item req);
  .
  .
  .
    // break delay loop if reset asserted to release blocking
    `DV_SPINWAIT_EXIT(repeat (a_valid_delay) @(cfg.vif.host_cb);,
                      wait(reset_asserted);)
    // wait until no outstanding transaction with same source id
    `DV_SPINWAIT_EXIT(while (is_source_in_pending_req(req.a_source)) @(cfg.vif.host_cb);,
                      wait(reset_asserted);)

    if (!reset_asserted) begin
      cfg.vif.host_cb.h2d_int.a_address <= req.a_addr;
      cfg.vif.host_cb.h2d_int.a_opcode  <= tl_a_op_e'(req.a_opcode);
      cfg.vif.host_cb.h2d_int.a_size    <= req.a_size;
      cfg.vif.host_cb.h2d_int.a_param   <= req.a_param;
      cfg.vif.host_cb.h2d_int.a_data    <= req.a_data;
      cfg.vif.host_cb.h2d_int.a_mask    <= req.a_mask;
      cfg.vif.host_cb.h2d_int.a_user    <= '0;
      cfg.vif.host_cb.h2d_int.a_source  <= req.a_source;
      cfg.vif.host_cb.h2d_int.a_valid   <= 1'b1;
      // bypass delay in case of reset
      `DV_SPINWAIT_EXIT(@(cfg.vif.host_cb);, // <<< **WHY IS THIS HERE?**
                        wait(reset_asserted);)
    end
    `DV_SPINWAIT_EXIT(while(!cfg.vif.host_cb.d2h.a_ready) @(cfg.vif.host_cb);,
                      wait(reset_asserted);)
  .
  .
  .

  endtask : send_a_channel_request

I don't see the need for the callback inside the if.
Removing it forces an Assertion to fire.
 `ASSERT(pendingReqPerSrc_A, h2d_pre_S |-> pendingReqPerSrc_S, !clk_i, !rst_ni)

it seems this assertion fires prematurely since there is a check in the driver that should avoid having multiple outstanding requests.
    `DV_SPINWAIT_EXIT(while (is_source_in_pending_req(req.a_source)) @(cfg.vif.host_cb);,
                      wait(reset_asserted);)

That being said I don't see anything in the spec prohibiting multiple outstanding requests.
I have discussed this with @rswarbrick
and we agree on that
The master can send a request on A. Once the slave has ack'ed the request, the master can send another without waiting for the response on D.  This allows clever slaves that have slow responses but support pipelining to still get high throughput.
So I think A rework of both host and device driver is needed to incorporate b2b support.

@rasmus-madsen
TL spec allows outstanding request, but each outstanding request has to use unique source ID.
We had a discussion last year and we decided to make driver wait if the ID of the request is the same as another pending request.
Total source ID is 32 and most of the IPs only supports up to 2 outstanding requests. If seq only sends a few requests, the chance of this case is low, but if sending a lot, it will eventually happens.
If you want to make sure the item is absolutely sent in an outstanding way, need to make sure it's sent with a unique ID.
I think you sends request through RAL, but RAL doesn't provide interface for source ID. You could override tl_seq_item to control the ID or we could consider to add a knob and let driver modify the ID.
    // wait until no outstanding transaction with same source id
    `DV_SPINWAIT_EXIT(while (is_source_in_pending_req(req.a_source)) @(cfg.vif.host_cb);,
                      wait(reset_asserted);)

The assertion checks if source ID is unique
  // a_source: there should be no more than one pending request per each source ID
  sequence pendingReqPerSrc_S;
    pend_req[h2d.a_source].pend == 0;
  endsequence

See my comment below for WHY IS THIS HERE?
    if (!reset_asserted) begin
      cfg.vif.host_cb.h2d_int.a_address <= req.a_addr;
      cfg.vif.host_cb.h2d_int.a_opcode  <= tl_a_op_e'(req.a_opcode);
      cfg.vif.host_cb.h2d_int.a_size    <= req.a_size;
      cfg.vif.host_cb.h2d_int.a_param   <= req.a_param;
      cfg.vif.host_cb.h2d_int.a_data    <= req.a_data;
      cfg.vif.host_cb.h2d_int.a_mask    <= req.a_mask;
      cfg.vif.host_cb.h2d_int.a_user    <= '0;
      cfg.vif.host_cb.h2d_int.a_source  <= req.a_source;
      cfg.vif.host_cb.h2d_int.a_valid   <= 1'b1;
      // bypass delay in case of reset
      `DV_SPINWAIT_EXIT(@(cfg.vif.host_cb);, // <<< **WHY IS THIS HERE?**. // this line is to make a_valid last at least 1 cycle, but looks like it can be merged into the following while loop.
                        wait(reset_asserted);)
    end
    `DV_SPINWAIT_EXIT(while(!cfg.vif.host_cb.d2h.a_ready) @(cfg.vif.host_cb);,
                      wait(reset_asserted);)

@weicaiyang
I was not a part of the referred discussion, but I don't see how "most Ps only support up to two outstanding requests" turns into an environment that only supports 1?
I think this is a place where we need to be compliant, and let the device do the throttling, not the host driver.
also not supporting back2back is effectively cutting AES performance as loading it takes 2x than it needs to.
why don't we give the Driver control of the source ID.
then it can simply increment when a request is accepted and decrement when the response is seen by the monitor.

another question, how did you create that back 2 back simulation you have copied waves from, it looks to me like the driver does not support that in its current state because of that extra @cb

are we testing the Icache with back2back?

@weicaiyang
I was not a part of the referred discussion, but I don't see how "most Ps only support up to two outstanding requests" turns into an environment that only supports 1?

the discussion was last July even before we created this repo. Driver usually doesn't modify data/control info, for example, in a xbar test, I want to use same source ID for all hosts. I set source ID in seq and don't expect driver to modify it.
Besides, there is only 1/256 chance (source is 8 bit wide) the source ID isn't unique. If we really want always back2back, still several ways to implement it in seq level.

I think this is a place where we need to be compliant, and let the device do the throttling, not the host driver.
also not supporting back2back is effectively cutting AES performance as loading it takes 2x than it needs to.
why don't we give the Driver control of the source ID.
then it can simply increment when a request is accepted and decrement when the response is seen by the monitor.

another question, how did you create that back 2 back simulation you have copied waves from, it looks to me like the driver does not support that in its current state because of that extra @cb

you can use this command to get the waveform I shared.
dvsim.py aes_csr_rw -ro "+zero_delays=1" -w
or modify these in your seq

set zero_delays=1 through plusarg or directly change env_cfg.zero_delays = 1
csr_rd/wr/update(..., .blocking(0))

there is only one CB here for a_valid if zero_delays is set and source ID is unique.

are we testing the Icache with back2back?

maybe @rswarbrick can answer this

are we testing the Icache with back2back?

The ICache testing doesn't use TileLink at all. In the actual design, the ICache connects to the rest of the system through an adapter. In the testbench, the DV agent plays the role of that adapter, so we don't get "as far" as the TileLink part.
Also note that the ICache acts as a master/host as far as TileLink is concerned: it responds to requests from the core (with a weird protocol) and then generates requests of the main memory.

are we testing the Icache with back2back?

The ICache testing doesn't use TileLink at all. In the actual design, the ICache connects to the rest of the system through an adapter. In the testbench, the DV agent plays the role of that adapter, so we don't get "as far" as the TileLink part.
Also note that the ICache acts as a master/host as far as TileLink is concerned: it responds to requests from the core (with a weird protocol) and then generates requests of the main memory.

ok, the reason I brought it up was that @tjaychen mentioned it earlier in an earlier comment.

@weicaiyang
I think we are talking past each other.
I understand I can disregard the RAL and go and do my own register accesses.
but I think instead we should fix our RAL layer so it supports outstanding requests.
I think this issue can be changed into RAL does not support back2back (unique IDs)

Since this issue has been rumbling on for a while, and touched on several different topics, maybe it would make the most sense to open a new one for that specific problem? It might make it easier to get stuff closed incrementally.

@weicaiyang
I think we are talking past each other.
I understand I can disregard the RAL and go and do my own register accesses.
but I think instead we should fix our RAL layer so it supports outstanding requests.
I think this issue can be changed into RAL does not support back2back (unique IDs)

I think I may miss some of your points. Sri has sent a meeting invite to discuss this issue.

As we discussed in the meeting, here are some potential solutions to guarantee unique ID for back2back transaction.

Sri: ID allocator in seq_item, when randomizing the item, look at the outstanding window to generate a unique ID. If max outstanding is 2, the ID of every 2 items are unique
Rasmus: have fifo in cfg, driver uses the ID in cfg fifo when fifo isn’t empty
Add a knob to let driver modify the ID to be unique rather than stalling the item

@sriyerg @weicaiyang
I think we can close this do you agree?

@sriyerg @weicaiyang
I think we can close this do you agree?

We can close it now. Sri has added the b2b support in the agent.

We can close it now. Sri has added the b2b support in the agent.

authors: rasmus-madsen rswarbrick tjaychen weicaiyang


text:
[top] Audit xbar connections

It seems the core_d and dm_sba xbar connections list can sometimes get out of sync.
It's probably good to audit these before major milestones to make sure dm_sba is able to access all the modules it is supposed to.

It looks like the only thing that has to be done here is align the rv_core_ibex.cored and rv_dm.sba lists here:
https://github.com/lowRISC/opentitan/blob/0681ffa10a42f151309530fc10511e284a76fc18/hw/top_earlgrey/data/xbar_main.hjson#L198-L211

@GregAC
@andreaskurth
i took a quick look at this.. and the only thing cored can access that sba cannot is rv_dm.mem.
Do we see any reason this should be excluded?  I guess I don't see a ton of utility in the path, but I don't see any reason why it should not be there either.
If it's okay with you all, I will add it back to make the two sides consistent.

I agree, thanks @msfschaffner  and @tjaychen

Sounds good to me

source: gharchive/issue

authors: GregAC andreaskurth msfschaffner tjaychen

repo: lowRISC/opentitan

license_type: permissive

license_source: github-api


text:
[otbn,dv] Tidyups and a bug fix for ISS DMEM handling

The interesting commit is the last in the sequence, which handles a rare case where the otbn_dmem_err test would fail because we were zapping DMEM when the RTL was in the middle of a store.

The CI failure is because I never got around to teaching the C++ code to load up data with integrity if some of the integrity is bad. This comes up when we run with the model instead of the real core. Working on a fix now, and I'll rebase this code once it's working.

Thanks, @rasmus-madsen, for the DV review. To get things working, I had to push a reasonable chunk of C++ to the MemArea code so I think I should wait for a follow-up review before merging.
@GregAC: Would you mind taking a quick look, since you've got experience with that code? The only change since Rasmus's review is to add the first commit.

source: gharchive/pull-request


text:
[sw,dif,aes] dif aes refactoring

This PR Refators the dif_aes.
To have a better understanding, please look at each commit individually.

@vogelpi could review how I've addressed the first item of the issue #10487?

Thanks @silvestrst and @vogelpi for your review.
I've reviewed all the points spotted by you. If you are happy please merge this PR.

Awesome, thanks @doreis-lowrisc ! I can merge this once CI passes.

authors: doreis-lowrisc vogelpi


text:
[chip,aes_idle] Fix comments in aes_idle test

Signed-off-by: Guillermo Maturana maturana@google.com

LGTM, these comments where copied from the testplan, could you also edit it?
https://github.com/lowRISC/opentitan/blob/0124ced9192e6aa2e7f5049164626fb56555ad18/hw/top_earlgrey/data/chip_testplan.hjson#L1642

@engdoreis I updated the test plan. Thanks.

authors: engdoreis matutem


text:
[bazel] Update example functest target names

A couple BUILD comments named a nonexistent functest:
//sw/device/silicon_creator/lib/drivers:fpga_cw310_hmac_functest.
I'm guessing that :fpga_cw310_hmac_functest was renamed to just
:hmac_functest at some point. This PR updates the comments to name the
real target.
Signed-off-by: Dan McArdle dmcardle@google.com

Ping :)

Thanks, Drew! Ready to merge.


text:
[top] Sync verilated earlgrey board model with others

Make the pin-out for the verilated earlgrey model match the GPIOs available on the FPGA board.
This allows the hello_world demo to show GPIO changes.

lgtm. If you're feeling ambitious, we can also change the cio_gpio naming that is currently being used :)

Heh, I'll hold off doing more here until we get a chance to bring the verilated top into the topgen fold.


text:
[rom] Change the endianness of FORS indices for SPHINCS+.

This backwards-incompatible change is part of the changes between the round 3 SPHINCS+ submission to the NIST PQC competition and the SLH-DSA draft standard. Part of https://github.com/lowRISC/opentitan/issues/21944
Corresponds to this commit from the SPHINCS+ reference implementation (consistent-basew branch):
https://github.com/sphincs/sphincsplus/commit/129b72c80e122a22a61f71b5d2b042770890ccee
Test vectors were re-generated from the consistent-basew branch of the reference implementation.
~Note that I think this might break the cryptotest SPHINCS+ setup, because they are right now hard-coded to fetch a specific self-hosted file for the round3 submission: https://github.com/lowRISC/opentitan/blob/5dbbd252ce8531680fde18361614ed07c783b5c7/third_party/sphincsplus/repos.bzl#L19~
~@RyanTorok @milesdai do either of you know if there is another file there, or how we can update it? I don't think NIST is actually hosting a corresponding KAT file for the draft standard yet, so we could also potentially wait until they release final test vectors (but in that case we should probably add a comment that this setup will fail tests on master, and explain why). The round3 tests are still useful for ES sival.~
Edit: now addressed, thanks Ryan!

If we find a new archive with KAT tests for the new version, it would be easy to upload it to the cloud storage and use it (although this would cause the test to break on any branches that do not include this PR).
The archive file in the GCP storage for SPHINCS+ is a bit special compared to the rest of the cryptotest framework. Due to size considerations, the SPHINCS+ archive is manually created by us (which is why the GCP storage is primary, unlike the other algorithms, which use the NIST site as primary and GCP as backup). "Manually created" here just means we un-compressed the archive, removed the KAT tests for all the variations of SPHINCS+ we don't support, and re-compressed it.
That original zip came from the NIST round 3 submission available directly on the SPHINCS+ site, and did not involve the SPHINCS+ repo at all. I took a look at the new branch matching the new draft standard, and it does include a ./vectors.py script that generates the test vectors. However, because it uses a temporary directory to do so, I don't think this can be directly used to hermetically build the test vectors in the OT repo (not to mention there's no release to fetch using an http_archive to begin with).
We may be able to create a new archive file to store in the GCP using the temporary files generated by vectors.py, but the process to create the archive would be more complicated than simply removing a bunch of irrelevant files.

I updated #21681 to switch the source of the test vectors to the new GCP-backed archive for the consistent-basew version of SPHINCS+.

Thanks @jadephilipoom. I assume this will break the current rom e2e sigverify_spx tests.
Is there an equivalent update for opentitantool?

Good point. I looked at the pqcrypto rust crate we're using, and it looks like it pulls from PQClean, which pulls from the master branch of the reference implementation :disappointed: so it's hard to just change something "easy" there and update it. There's an open issue on PQClean to update to the to-be-standardized version, but the timeline is unclear. We could try switching to a different crate, but the ones I can see that advertise "slh-dsa" don't seem very well-established. Not sure what we should do about this. We could depend on one of the newer crates, since it's just for testing anyway, or we could always hold off on merging this PR until the last minute or disable the tests that would fail until pqcrypto updates, but it would be good to run end-to-end tests before ROM freeze.

Thanks for looking into the host side tooling @jadephilipoom. Should we be considering to do a similar thing to what we did on the device side an maintain our own host-side implementation? It seems that there are still additional changes in the pipeline which are going make it difficult for us to run integration testing.
Should we raise this issue to the Software WG?

Yes, seems like a good topic for Software WG (and good timing too!)

This issue was discussed in the software working group today. The consensus was that we should write our own Rust wrapper for the reference implementation.

For visibility: I've cherry-picked the last commit from https://github.com/lowRISC/opentitan/pull/23326; this puts the host-side tooling in sync with the device for the endianness swap so that tests work. If it passes CI, I'll just merge this and close #23326,. Since both sets of changes have been reviewed and approved, I don't think it requires any additional review; just wanted to put an explanation for the new commit post-approve.

There are a couple remaining test failures because (I think) some pre-signed binaries need to be manually re-generated. Can anyone tell me what the procedure is for that? I can see that commit c36ad25e8fbe158314dbe57f9f33a1576b71281d re-generated them due to opentitantool updates, which looks like the same thing I need, but I can't figure out which commands to run to do that again. @timothytrippel , do you remember?

Update: after talking to @cfrantz and @moidx , I understand that none of the pre-signed binaries should need to be regenerated, and the tests are likely failing because the signatures opentitantool are producing are incorrect. I added a KAT on the opentitantool impl and it failed, so that is definitely the case and I'm working on figuring out what the bug is.

Update: CI result has two failing tests, but both appear to be failing on all CI jobs at the moment and I think they're unrelated.

//sw/device/silicon_creator/rom/e2e/boot_policy_flash_ecc_error:a_valid_b_corrupt_manifest_security_version_fpga_cw310_rom_with_fake_keys
//sw/device/tests:uart_smoketest_fpga_cw340_rom_with_fake_keys

I don't have a CW340, but I can replicate the first one on master and both are also failing on https://github.com/lowRISC/opentitan/pull/23598, which only adds test data that's not used by anything. So I think it's safe to say that re-generating the keys fixed all the failures (although I'm not satisfied until I know why).

Fixed to address @moidx's comment on real keys and also to re-generate "unauthorized" keys. I'll consider this OK to merge once CI passes, unless anyone objects.

authors: RyanTorok jadephilipoom mundaym


text:
[hmac,dv] HMAC test vectors for block-level

This adds HMAC NIST test vectors at block-level. Once merged, this would close https://github.com/lowRISC/opentitan/issues/22932 and thus also complete the tasks in issue https://github.com/lowRISC/opentitan/issues/22102.
@moidx @martin-velay

I've rerun CI checks, but the fails here have occurred again and seem unrelated to this PR.

I think the CI failure is "quick lint", which is failing because hw/dv/sv/test_vectors/test_vectors_pkg.sv doesn't have the standard licence header. (Easy enough to fix! You can just copy and paste from another file :-D)

I think the CI failure is "quick lint", which is failing because hw/dv/sv/test_vectors/test_vectors_pkg.sv doesn't have the standard licence header. (Easy enough to fix! You can just copy and paste from another file :-D)

oh yes thanks, this time I can spot this in the logs :D I was getting another issue in the last CI run.

Thanks @rswarbrick  and @martin-velay for your reviews, I think I've addressed most of your comments and pushed again now and also running a block-level regression at my end.

This is failing CI because hw/ip/hmac.h has the wrong header. But it shouldn't be at that path either. Please could you move it somewhere sensible?

that wasn't supposed to get committed actually, that's why CI is so great :-)

authors: gdessouky rswarbrick


text:
[earlgrey_1.0.0] Update after CW 40

This PR updates earlgrey_1.0.0 with the following PRs that were merged to master:

#24586
#24577
#24688
#24601

Thank you @vogelpi. Can please cherry-pick https://github.com/lowRISC/opentitan/pull/24701 as well?

Thank you @vogelpi. Can please cherry-pick #24701 as well?

Yes @sha-ron , I can certainly do that. Sorry for having missed that in the first place.

authors: sha-ron vogelpi


text:
[i2c, dv] Updates for both i2c_agent and i2c_sanity

The main purpose of this PR is to support re-programming registers of DUT during i2c_sanity running (thus improving the coverage of a single test). In addition, some added tasks can be re-used for other tests (i.e. reset/restart, etc.). Minor changes have been made in i2c_agent_cfg to improve its reusability. Finally, redundant code and spaces are cleaned.
Signed-off-by: Tung Hoang tung.hoang.290780@gmail.com

@weicaiyang I re-push PR which covers your comments,

@weicaiyang fixed incorrect alignments, thanks.
@cindychip thanks for the review


text:
[ast] Added DFT interface + logic updates

Signed-off-by: Arnon Sharlin arnon.sharlin@opentitan.org
@Jacob-Levy
@tjaychen
@msfschaffner
Latest AST updates. Most important is the new DFT interface.

@arnonsha last question, are you guys comfortable directly integration this into top_earlgrey? If not, I can walk you through the process, and then you guys can make your own decision about whether to remove ast_wrapper (which is still there at the moment, though I know we've talked about removing it).

@arnonsha last question, are you guys comfortable directly integration this into top_earlgrey? If not, I can walk you through the process, and then you guys can make your own decision about whether to remove ast_wrapper (which is still there at the moment, though I know we've talked about removing it).

@arnonsha last question, are you guys comfortable directly integration this into top_earlgrey? If not, I can walk you through the process, and then you guys can make your own decision about whether to remove ast_wrapper (which is still there at the moment, though I know we've talked about removing it).

No plans of removing ast_wrapper at the moment

@arnonsha last question, are you guys comfortable directly integration this into top_earlgrey? If not, I can walk you through the process, and then you guys can make your own decision about whether to remove ast_wrapper (which is still there at the moment, though I know we've talked about removing it).

No plans of removing ast_wrapper at the moment

The DV regression is failing with
Error-[SV-PPD] Package previously declared
../src/lowrisc_top_earlgrey_pinmux_reg_0.1/rtl/autogen/pinmux_reg_pkg.sv, 7
pinmux_reg_pkg
  Identifier 'pinmux_reg_pkg' is already declared in file
  "../src/lowrisc_ip_pinmux_reg_0.1/rtl/pinmux_reg_pkg.sv", line 7.

I'm having a look now to see how we can resolve that, I'll get back to you.

The DV regression is failing with
Error-[SV-PPD] Package previously declared
../src/lowrisc_top_earlgrey_pinmux_reg_0.1/rtl/autogen/pinmux_reg_pkg.sv, 7
pinmux_reg_pkg
  Identifier 'pinmux_reg_pkg' is already declared in file
  "../src/lowrisc_ip_pinmux_reg_0.1/rtl/pinmux_reg_pkg.sv", line 7.

I'm having a look now to see how we can resolve that, I'll get back to you.

I added a workaround for the pinmux dependency issue in the comment above.  With this fix, the regression will fail at various other points due to ast_wrapper needing updates as well. You can run the regression locally with util/dvsim/dvsim.py hw/top_earlgrey/dv/top_earlgrey_sim_cfgs.hjson -i smoke --tool=vcs.
On a more general note: You'll have a much better time getting such changes integrated if you split them out into smaller changesets. As a rough guidance, whenever you feel tempted to say "Did this and that" in a commit message, it should have probably been two commits or two PRs. Doing multiple PRs is a bit more work, but will make it much quicker to get problems sorted out and them merged, making the overall experience less painful and faster. So whenever you have a small consistent change going forward, please do a PR right away to get it merged and done, and you can then build on top of it.

I added a workaround for the pinmux dependency issue in the comment above.  With this fix, the regression will fail at various other points due to ast_wrapper needing updates as well. You can run the regression locally with util/dvsim/dvsim.py hw/top_earlgrey/dv/top_earlgrey_sim_cfgs.hjson -i smoke --tool=vcs.
On a more general note: You'll have a much better time getting such changes integrated if you split them out into smaller changesets. As a rough guidance, whenever you feel tempted to say "Did this and that" in a commit message, it should have probably been two commits or two PRs. Doing multiple PRs is a bit more work, but will make it much quicker to get problems sorted out and them merged, making the overall experience less painful and faster. So whenever you have a small consistent change going forward, please do a PR right away to get it merged and done, and you can then build on top of it.

The DV regression is failing with
Error-[SV-PPD] Package previously declared
../src/lowrisc_top_earlgrey_pinmux_reg_0.1/rtl/autogen/pinmux_reg_pkg.sv, 7
pinmux_reg_pkg
  Identifier 'pinmux_reg_pkg' is already declared in file
  "../src/lowrisc_ip_pinmux_reg_0.1/rtl/pinmux_reg_pkg.sv", line 7.

I'm having a look now to see how we can resolve that, I'll get back to you.

Thank you @imphil for sorting this out.
Can you say why fusesoc hasn't sorted this out ?

The DV regression is failing with
Error-[SV-PPD] Package previously declared
../src/lowrisc_top_earlgrey_pinmux_reg_0.1/rtl/autogen/pinmux_reg_pkg.sv, 7
pinmux_reg_pkg
  Identifier 'pinmux_reg_pkg' is already declared in file
  "../src/lowrisc_ip_pinmux_reg_0.1/rtl/pinmux_reg_pkg.sv", line 7.

I'm having a look now to see how we can resolve that, I'll get back to you.

Thank you @imphil for sorting this out.
Can you say why fusesoc hasn't sorted this out ?

Can you say why fusesoc hasn't sorted this out ?

Because we don't specify a dependency between lowrisc:ip:pinmux_component and a package providing us with the pinmux_reg_pkg.sv, so FuseSoC has no way of knowing.
Unfortunately, due to the way our current toplevel setup works, we can't simply add the dependency. The short version would be: we have multiple implementations of that dependency/file in the tree and need to ensure we pick the right one, depending on e.g. if we're building top_earlgrey, or if we only build the pinmux component standalone.
I'm working on a proper fix that allows us to specify and select such dependencies in a sane way, but that requires a bit of underlying tooling refactoring first. Until that arrives we have to live with an increasingly ugly set of hacks.

Can you say why fusesoc hasn't sorted this out ?

Because we don't specify a dependency between lowrisc:ip:pinmux_component and a package providing us with the pinmux_reg_pkg.sv, so FuseSoC has no way of knowing.
Unfortunately, due to the way our current toplevel setup works, we can't simply add the dependency. The short version would be: we have multiple implementations of that dependency/file in the tree and need to ensure we pick the right one, depending on e.g. if we're building top_earlgrey, or if we only build the pinmux component standalone.
I'm working on a proper fix that allows us to specify and select such dependencies in a sane way, but that requires a bit of underlying tooling refactoring first. Until that arrives we have to live with an increasingly ugly set of hacks.

We are still failing the CI check :(
The AST uses only typedef from the pinmux_pkg.sv.
I tried to use in the dependency  –lowrisc:ip:pinmux_pkg   and fusesoc failed…
From: Philipp Wagner notifications@github.com
Sent: 27 ינואר 2021 17:09
To: lowRISC/opentitan opentitan@noreply.github.com
Cc: IC10 Jacob Levy jacob.levy@nuvoton.com; Mention mention@noreply.github.com
Subject: Re: [lowRISC/opentitan] [ast] Added DFT interface + logic updates (#4878)
Can you say why fusesoc hasn't sorted this out ?
Because we don't specify a dependency between lowrisc:ip:pinmux_component and a package providing us with the pinmux_reg_pkg.sv, so FuseSoC has no way of knowing.
Unfortunately, due to the way our current toplevel setup works, we can't simply add the dependency. The short version would be: we have multiple implementations of that dependency/file in the tree and need to ensure we pick the right one, depending on e.g. if we're building top_earlgrey, or if we only build the pinmux component standalone.
I'm working on a proper fix that allows us to specify and select such dependencies in a sane way, but that requires a bit of underlying tooling refactoring first. Until that arrives we have to live with an increasingly ugly set of hacks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FlowRISC%2Fopentitan%2Fpull%2F4878%23issuecomment-768349650&data=04|01|jacob.levy%40nuvoton.com|69f3c562f917401fc29308d8c2d577da|a3f24931d4034b4a94f17d83ac638e07|0|0|637473569412781195|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=IZLlJsWkLiGIIoN9IQ2J0AHU70U6M5pdpc2FA2ItLHw%3D&reserved=0, or unsubscribehttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQA3TGS7YZI3EWTAZNKZNNLS4AUANANCNFSM4WIWBP4A&data=04|01|jacob.levy%40nuvoton.com|69f3c562f917401fc29308d8c2d577da|a3f24931d4034b4a94f17d83ac638e07|0|0|637473569412791189|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=OIIDKERyLxN%2BeomY1L1GXji%2FaSdViqDMK3zEi23pSm8%3D&reserved=0.

The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

We are still failing the CI check :(
The AST uses only typedef from the pinmux_pkg.sv.
I tried to use in the dependency  –lowrisc:ip:pinmux_pkg   and fusesoc failed…
From: Philipp Wagner notifications@github.com
Sent: 27 ינואר 2021 17:09
To: lowRISC/opentitan opentitan@noreply.github.com
Cc: IC10 Jacob Levy jacob.levy@nuvoton.com; Mention mention@noreply.github.com
Subject: Re: [lowRISC/opentitan] [ast] Added DFT interface + logic updates (#4878)
Can you say why fusesoc hasn't sorted this out ?
Because we don't specify a dependency between lowrisc:ip:pinmux_component and a package providing us with the pinmux_reg_pkg.sv, so FuseSoC has no way of knowing.
Unfortunately, due to the way our current toplevel setup works, we can't simply add the dependency. The short version would be: we have multiple implementations of that dependency/file in the tree and need to ensure we pick the right one, depending on e.g. if we're building top_earlgrey, or if we only build the pinmux component standalone.
I'm working on a proper fix that allows us to specify and select such dependencies in a sane way, but that requires a bit of underlying tooling refactoring first. Until that arrives we have to live with an increasingly ugly set of hacks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FlowRISC%2Fopentitan%2Fpull%2F4878%23issuecomment-768349650&data=04|01|jacob.levy%40nuvoton.com|69f3c562f917401fc29308d8c2d577da|a3f24931d4034b4a94f17d83ac638e07|0|0|637473569412781195|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=IZLlJsWkLiGIIoN9IQ2J0AHU70U6M5pdpc2FA2ItLHw%3D&reserved=0, or unsubscribehttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQA3TGS7YZI3EWTAZNKZNNLS4AUANANCNFSM4WIWBP4A&data=04|01|jacob.levy%40nuvoton.com|69f3c562f917401fc29308d8c2d577da|a3f24931d4034b4a94f17d83ac638e07|0|0|637473569412791189|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=OIIDKERyLxN%2BeomY1L1GXji%2FaSdViqDMK3zEi23pSm8%3D&reserved=0.

The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.

Can you say why fusesoc hasn't sorted this out ?

Because we don't specify a dependency between lowrisc:ip:pinmux_component and a package providing us with the pinmux_reg_pkg.sv, so FuseSoC has no way of knowing.
Unfortunately, due to the way our current toplevel setup works, we can't simply add the dependency. The short version would be: we have multiple implementations of that dependency/file in the tree and need to ensure we pick the right one, depending on e.g. if we're building top_earlgrey, or if we only build the pinmux component standalone.
I'm working on a proper fix that allows us to specify and select such dependencies in a sane way, but that requires a bit of underlying tooling refactoring first. Until that arrives we have to live with an increasingly ugly set of hacks.

The error says:
'pinmux_reg_pkg' is already declared in file
I assume CI uses fusesoc. Fusesoc knows that the core in question was already used by another core, so why does it add it to the the file a 2nd time ?

Can you say why fusesoc hasn't sorted this out ?

Because we don't specify a dependency between lowrisc:ip:pinmux_component and a package providing us with the pinmux_reg_pkg.sv, so FuseSoC has no way of knowing.
Unfortunately, due to the way our current toplevel setup works, we can't simply add the dependency. The short version would be: we have multiple implementations of that dependency/file in the tree and need to ensure we pick the right one, depending on e.g. if we're building top_earlgrey, or if we only build the pinmux component standalone.
I'm working on a proper fix that allows us to specify and select such dependencies in a sane way, but that requires a bit of underlying tooling refactoring first. Until that arrives we have to live with an increasingly ugly set of hacks.

The error says:
'pinmux_reg_pkg' is already declared in file
I assume CI uses fusesoc. Fusesoc knows that the core in question was already used by another core, so why does it add it to the the file a 2nd time ?

I fixed the core file per your suggestion, but CI still fails.

I fixed the core file per your suggestion, but CI still fails.

Thanks for hashing out the fusesoc issues!
The remaining errors appear to be due to ast interface changes:
Error-[UPIMI-E] Undefined port in module instantiation
../src/lowrisc_systems_ast_wrapper_0.1/rtl/ast_wrapper.sv, 108
  Port "entropy_ack_i" is not defined in module 'ast' defined in
  "../src/lowrisc_systems_ast_0.1/rtl/ast.sv", 11
  Module instance: ast #(.EntropyStreams(ast_wrapper_pkg::EntropyStreams),

Can you take a look and update the ast_wrapper accordingly?

Thanks for hashing out the fusesoc issues!
The remaining errors appear to be due to ast interface changes:
Error-[UPIMI-E] Undefined port in module instantiation
../src/lowrisc_systems_ast_wrapper_0.1/rtl/ast_wrapper.sv, 108
  Port "entropy_ack_i" is not defined in module 'ast' defined in
  "../src/lowrisc_systems_ast_0.1/rtl/ast.sv", 11
  Module instance: ast #(.EntropyStreams(ast_wrapper_pkg::EntropyStreams),

Can you take a look and update the ast_wrapper accordingly?

Thanks for clearing that out Michael
This PR introduces DFT related interface changes, so wrapper has to change accordingly, and the wrapper instantiation in top level. Hopefully @tjaychen will be able to do this soon so this PR can be finally merged.

Thanks for clearing that out Michael
This PR introduces DFT related interface changes, so wrapper has to change accordingly, and the wrapper instantiation in top level. Hopefully @tjaychen will be able to do this soon so this PR can be finally merged.

Could you just add the ports and tie the signals off to zero in the ast wrapper?
That way this does not have to block on @tjaychen, and he can come back to this once he has time.

Could you just add the ports and tie the signals off to zero in the ast wrapper?
That way this does not have to block on @tjaychen, and he can come back to this once he has time.

@imphil
Another failure related to verible on ast_reg_pkg.sv which is autogenerated by regtool.

@imphil
Another failure related to verible on ast_reg_pkg.sv which is autogenerated by regtool.

@imphil
Another failure related to verible on ast_reg_pkg.sv which is autogenerated by regtool.

the verible flakiness is related to a commit that @msfschaffner just reverted last night. Can you guys rebase on the latest and push again? You may see fpga failures, but that's some other unrelated item @imphil is tracking down at the moment.

@imphil
Another failure related to verible on ast_reg_pkg.sv which is autogenerated by regtool.

the verible flakiness is related to a commit that @msfschaffner just reverted last night. Can you guys rebase on the latest and push again? You may see fpga failures, but that's some other unrelated item @imphil is tracking down at the moment.

The part instantiating AST. See here Michael's request.
We have no intention of maintaining the ast wrapper. It is redundant and I believe you can drop it.

The part instantiating AST. See here Michael's request.
We have no intention of maintaining the ast wrapper. It is redundant and I believe you can drop it.

@tjaychen @msfschaffner
I just pushed a commit where no ast_wrapper is removed. It is not complete though and we do not expect CI to pass. Please go over the // TODO comments. However it is a good starting point for you to connect all necessary DFT signals.
Once all is complete, we'd like to understand how to VCS compile the full chip, so on future commits we would be able to run it prior to pushing a PR.

@tjaychen @msfschaffner
I just pushed a commit where the ast_wrapper is removed. It is not complete though and we do not expect CI to pass. Please go over the // TODO comments. However it is a good starting point for you to connect all necessary DFT signals.
Once all is complete, we'd like to understand how to VCS compile the full chip, so in future commits we would be able to run it prior to pushing a PR and see that all works well.

sorry accidentally closed it.

@arnonsha do you think it makes sense to merge this PR without removing ast_wrapper first?
Or do you prefer to do that all in one shot?

@arnonsha @Jacob-Levy
i'm going to go through and integrate this now (with the removed ast_wrapper).
please don't make any additional updates to this PR for now.

@tjaychen I believe we can close this PR now that you have carried over all these commits and integrated AST, right?

o yeah that's close it.
On Thu, Feb 25, 2021 at 7:18 PM Michael Schaffner notifications@github.com
wrote:

@tjaychen https://github.com/tjaychen I believe we can close this PR
now that you have carried over all these commits and integrated AST, right?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/4878#issuecomment-786382925,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSS7DMRDL6YOSYPCX23TA4HHBANCNFSM4WIWBP4A
.

authors: Jacob-Levy arnonsha imphil msfschaffner tjaychen


text:
[fpv] revert back the FPV compile error workarounds

This PR revert back the previous workaround to avoid the compile error.
Now the JasperGold is fixed to support this prim_lc_sync syntax.
Signed-off-by: Cindy Chen chencindy@google.com

great! good to hear!
On Thu, Apr 1, 2021 at 6:29 PM cindychip @.***> wrote:

@cindychip https://github.com/cindychip requested your review on: #5915
https://github.com/lowRISC/opentitan/pull/5915 [fpv] revert back the
FPV compile error workarounds as a code owner.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/5915#event-4543993426, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSRTWA3ODNKJXTKO2PLTGUMWZANCNFSM42ICEHPQ
.

authors: cindychip tjaychen


text:
Update ChipWhisperer

This commit updates ChipWhisperer. As a result, the warnings related to the ADC frequency exceeding the specification (200 MHz) go away. Related to this update, the firwmare of Husky should be updated (follow official instructions).

After applying this commit, you need to source the virtual environment and then type:
pip3 install --upgrade -r python-requirements.txt

repo: lowRISC/ot-sca

license_source: bigquery


text:
🛑 Neo Viewer is down

In 73ea840, Neo Viewer (http://neoclinica.ddns.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Neo Viewer is back up in 8f0eaff after 16 minutes.

repo: lprone/upptime

license: MIT


text:
Development: Upgrade to Angular 14 and Jest 28

Checklist
General

[ ] I tested all changes and their related features with all corresponding user types on a test server.
[x] I chose a title conforming to the naming conventions for pull requests.

Client

[x] I followed the coding and design guidelines.

Motivation and Context

Upgrade to new major versions of Angular and Jest.
Description

Bumped dependencies
Updated form builder stuff

Status
We're currently waiting for

[x] https://github.com/just-jeb/angular-builders/issues/1219

[x] https://github.com/angular-eslint/angular-eslint/pull/1004

[x] https://github.com/danielmoncada/date-time-picker/issues/160

[ ] https://github.com/ng-bootstrap/ng-bootstrap/issues/4340

[ ] https://github.com/orizens/ngx-infinite-scroll/issues/404

[x] https://github.com/KoderLabs/ngx-device-detector/issues/247 (seems dead, unlikely to be updated but people report that it still works)

[x] After we got an update of angular-builders, we probably need to figure out a solution for the uuid ESM problem

We no longer use ngx-device-detector. 🙂
https://github.com/ls1intum/Artemis/commit/c01d5d72b3cbf9823e7fc992a80375f959ab4802

I suggest we change from ngx-infinite-scroll to use virtual scrolling with fetching as implemented in angular material, see e.g. https://zoaibkhan.com/blog/create-a-fast-infinite-scrolling-list-in-angular/
The benefit would be that angular material is maintained with angular, so we don't have external dependencies for which we need to wait

There seems to be a 13.0.0-beta.1 which ng-bootstrap which we can try out and see if it works in our case

Seems like the PR upgrading ngx-infinite-scroll just updates the dependency declarations and does not change anything on the code, so we can just try to override their peer deps for now

I've added the beta version of ng-bootstrap. This should work as the only breaking change noted in the change log is the removal of already depreacted button directives which we don't seem to use.

authors: bassner ge65cer krusche


text:
Arbitrary @method tag handling

Given this code from rspec-mocks:
        [ :with, :and_return, :and_raise, :and_yield,
          :once, :twice, :any_number_of_times,
          :exactly, :times, :never,
          :at_least, :at_most
          ].each do |method_name|
            class_eval(<<-EOM, __FILE__, __LINE__)
              def #{method_name}(*args, &block)
                record(:#{method_name}, *args, &block)
              end
            EOM
        end

I'd like to document each of these methods using the @method tag. I tried doing it like this:
# @method with
# @method and_return
# etc

... and it only doc'd the first method. Then I tried it like this:
# @method with
#
# @method and_return
#
# ...
#
# @method at_most

... and it doc'd the first and last methods, but none in between.

Currently YARD has a limitation in that the @method command can only be used once per docstring. This is a limitation of the macros implementation we currently have. We are planning to shore up the macros support in the next major release (0.8.x) and add standardize the syntax for behaviours like @method/@attribute. Currently you would only be able to document this by extending YARD or plugins. If there was a plugin for this sort of thing, we could install it on rubydoc.info.
As a sidenote, however, in this specific scenario, it might not even be necessary to use @method. I would personally document this by either adding separate method stubs, or by dropping the metaprogramming altogether (a lot can be said about documentability and general code readability for programs with too much metaprogramming). Presumably, the goal is to actually have the docstrings define the method behaviour, not just so that YARD can recognize them as empty undocumented methods, so you would need separate docstrings for their differing behaviour anyway. ie.:
# This is what `with` does....
# @param ...
# @yieldparam ...
# @return ...
def with(*args, &block)
  record(:with, *args, &block)
end

# This is what `and_return` does
# ...
def and_return(...)
  ...
end

...

That would make sense if they did different things. They don't. They all delegate to methods of the same name that are documented elsewhere.
On Nov 28, 2011, at 5:47 PM, Loren Segalreply@reply.github.com wrote:

Currently YARD has a limitation in that the @method command can only be used once per docstring. This is a limitation of the macros implementation we currently have. We are planning to shore up the macros support in the next major release (0.8.x) and add standardize the syntax for behaviours like @method/@attribute. Currently you would only be able to document this by extending YARD or plugins. If there was a plugin for this sort of thing, we could install it on rubydoc.info.
As a sidenote, however, in this specific scenario, it might not even be necessary to use @method. I would personally document this by either adding separate method stubs, or by dropping the metaprogramming altogether (a lot can be said about documentability and general code readability for programs with too much metaprogramming). Presumably, the goal is to actually have the docstrings define the method behaviour, not just so that YARD can recognize them as empty undocumented methods, so you would need separate docstrings for their differing behaviour anyway. ie.:
# This is what `with` does....
# @param ...
# @yieldparam ...
# @return ...
def with(*args, &block)
 record(:with, *args, &block)
end

# This is what `and_return` does
# ...
def and_return(...)
 ...
end

...

Reply to this email directly or view it on GitHub:
https://github.com/lsegal/yard/issues/417#issuecomment-2909600

I don't think it looks like extra code at all. In fact, I wrote something just like it in another part of rspec :) I switched it over to this and it works great, with one catch:
I want to include a @see tag in the macro, but it turns out that the target methods are defined in two different classes (a base class and a subclass). I can make that work with two versions of the delegate method, but I wonder if there's a way to pass arguments to the macro that are not part of the method signature.

I ended up moving all the target methods to the same class (the hierarchy was a relic from days gone by that never got cleaned up), so closing this.

authors: dchelimsky lsegal

repo: lsegal/yard

license: mit


text:
DM-33922: Update exposurelog and narrativelog

Update for new versions of both packages.
Move chart and template files from the charts package to this package.

Thanks for pointing that out. I messed up the updates on a few site-specific files by dropping the leading exposurelog:. Fixed and I also modernized exposurelog/values-roe.yaml (the last of the site-specific value files).

repo: lsst-sqre/phalanx


text:
Sherlock web service failing

Gareth
The API is not running sherlock properly. This is as far as I can push it, since I don't know how your webserver is set up. I think these requests are properly formatted:
ubuntu@lasair-ztf-sherlock-0:~$ curl "http://localhost/object/ZTF21aapvmcu"
{"message": "The browser (or proxy) sent a request that this server could not understand."}
ubuntu@lasair-ztf-sherlock-0:~$ curl "http://localhost/query?ra=123&dec=23"
{"message": "The browser (or proxy) sent a request that this server could not understand."}

ubuntu@lasair-ztf-bootstrap:~/lasair-deploy$ curl -H "Content-Type: application/json" -d '{ "lite": true, "ra": "1.2", "dec": "2.3" }' "http://lasair-ztf-sherlock-0/query"
{"classifications": {"transient_00000": ["ORPHAN", "No contexual information is available for this transient"]}, "crossmatches": []}
ubuntu@lasair-ztf-bootstrap:~/lasair-deploy$ curl -H "Content-Type: application/json" -d '{ "lite": true }' "http://lasair-ztf-sherlock-0/object/ZTF21aapvmcu"
{"classifications": {"ZTF21aapvmcu": ["SN", "The transient is possibly associated with NGC6660; an r=14.53 mag galaxy found in the NED_D/PS1/LASR catalogues. It's located 52.76\" S, 48.77\" E (14.7 Kpc) from the galaxy centre. A host distance of 42.1 Mpc(z=0.014) implies a m - M = 33.12."]}, "crossmatches": [{"transient_object_id": "ZTF21aapvmcu", "association_type": "SN", "catalogue_table_name": "NED D/PS1/LASR", "catalogue_object_id": "NGC6660", "catalogue_object_type": "galaxy", "raDeg": 278.652791667, "decDeg": 22.90967, "separationArcsec": 71.84, "northSeparationArcsec": "52.75514", "eastSeparationArcsec": "-48.76661", "physical_separation_kpc": 14.66, "direct_distance": 42.1, "distance": 61.17, "z": 0.01, "photoZ": null, "photoZErr": null, "Mag": 14.53, "MagFilter": "r", "MagErr": 0.0, "classificationReliability": 2, "major_axis_arcsec": null}]}

In the past, the internal Sherlock service was a GET service
https://github.com/lsst-uk/lasair4/blob/main/webserver/lasairapi/serializers.py
lines 113 and 141
Above you demonstrate that the POST works well. Would it be possible to also make the GET service work again, so I don't need to write new code for POST.

It looks like the fundamental problem here is that the Sherlock API is built using flask-restful (https://github.com/flask-restful/flask-restful), which is not really being actively maintained any more and an underlying package has changed it's default behaviour, which in turn means that the reqparse component of flask-restful can no longer automatically convert everything on the fly.
I see three possible solutions:

Replace reqparse with another package such as webargs.
Re-write the calling code to send the request as JSON.
Work out how to integrate the Sherlock API into the main API so we're not maintaining two sets of API code.

I think 3 is the best (only?) long term solution, and we should probably consider it as part of the web refresh, but it also doesn't help in the short term.
I would normally suggest 1, except that I might not have time to do it this week and then I'm away for a bit.
How much work would 2 be?

authors: RoyWilliams gpfrancis


text:
pick should use array_key_exists instead of isset

pick source code use isset to check if the given key is present in the collection. This implies that  NULL values are not valid but they should be. What about to use array_key_exists?

The behavior difference would be in case you have a default value other than null specified, right?

Hey lstrojny, so sorry for the delay.
From a pragmatic point of view you're right but i think that the real difference is more conceptual. isset doesn't consider null as a valid value but there are cases where a collection contains a mix of null values, falsy value, etc and they are all right.
In that cases current implementation of pick fails.

Makes all sense, should indeed be array_key_exists. Want to open a PR for it?

authors: lorenzomar lstrojny

repo: lstrojny/functional-php


text:
🛑 ZZVoice is down

In 6f9e03c, ZZVoice ($ZZVOICE) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZZVoice is back up in 8443559 after 15 minutes.


text:
🛑 ZZVoice is down

In 91f0ae9, ZZVoice ($ZZVOICE) was down:

HTTP code: 0
Response time: 0 ms

Resolved: ZZVoice is back up in a43d0a5.


text:
🛑 Mirror-爬 is down

In 4accd48, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 867 ms

Resolved: Mirror-鱼露 is back up in 85e496a.


text:
🛑 Mirror-爬 is down

In 558a3ae, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1202 ms

Resolved: Mirror-鱼露 is back up in 9f9ba1d.


text:
🛑 Mirror-木生 is down

In 4b2fc13, Mirror-木生 (https://t.lsy223622.com/ncov-xidian-times) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-爬 is back up in c98b395.


text:
🛑 Mirror-爬 is down

In d01ccd3, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1071 ms

Resolved: Mirror-鱼露 is back up in 85daf59.


text:
🛑 Mirror-木生 is down

In 9655dd0, Mirror-木生 (https://t.lsy223622.com/ncov-xidian-times) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-爬 is back up in b8ef9b7.


text:
🛑 Mirror-爬 is down

In cc306d2, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 919 ms

Resolved: Mirror-鱼露 is back up in e1f0778.


text:
🛑 Mirror-爬 is down

In e995caf, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 824 ms

Resolved: Mirror-鱼露 is back up in b8aa4b2.


text:
🛑 Mirror-爬 is down

In 28802e0, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1014 ms

Resolved: Mirror-鱼露 is back up in c073661.


text:
🛑 Mirror-爬 is down

In 1d534ff, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1185 ms

Resolved: Mirror-鱼露 is back up in 2cf0c2b.


text:
🛑 Mirror-xmgg is down

In 6a9534d, Mirror-xmgg (https://myxdu.moefactory.com/article/covid19_xdu.html) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mirror-xmgg is back up in d91c65f.


text:
🛑 Mirror-爬 is down

In 4537560, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 819 ms

Resolved: Mirror-鱼露 is back up in fc0e907.


text:
🛑 Mirror-爬 is down

In aa62670, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1132 ms

Resolved: Mirror-鱼露 is back up in 98c548e.


text:
🛑 Mirror-爬 is down

In b931c5c, Mirror-爬 (https://ncov.zhouym.tech/) was down:

HTTP code: 404
Response time: 1074 ms

Resolved: Mirror-鱼露 is back up in 3841b75.


text:
🛑 Instagram is down

In b485022, Instagram (https://www.instagram.com/) was down:

HTTP code: 429
Response time: 314 ms

Resolved: Instagram is back up in 20d5245.


text:
Documentation: Data types

We now have a documentation page for the libraries (https://luau-lang.org/library). It would be great to get a page that covers data types - ideally including basic commonly used operations (e.g. "this is how you index a string", "this is how you append to the table") and gotchas (ASCII vs Unicode for strings, mixed mode tables, iterating through numeric vs dictionary, 1-based indexing, etc.)

https://github.com/luau-lang/site/pull/6

repo: luau-lang/luau


text:
Screen with Color

Hi,
I add a Screen in HA and I want this Screen in a specific Text Color.
Actual I call to Services. Add_Screen and Text_Color.
That doesn't work very fine. Sometimes it work, sometimes not!
Is it possible to Add_Screen with a specific COLOR in RGB?

Hi, take a look at https://github.com/lubeda/EspHoMaTriXv2 in the 2023.9.1 branch. This is the evolution of your version, so you can expect more functionality but also the need of changing your service calls. e.g.
here you can set the color per icon:
icon_screen => {"icon_name", "text", "lifetime", "screen_time", "default_font", "r", "g", "b"}

Thank U. I try it with my new Ulanzi Clock.

authors: lubeda michisbarq

repo: lubeda/EsphoMaTrix


text:
🛑 Školský šport is down

In 26155d7, Školský šport (https://skolskysport.sk/) was down:

HTTP code: 403
Response time: 797 ms

Resolved: Školský šport is back up in faba3d1.

repo: lubosm/minedusk-uptime


text:
Custom grant required?

I'm trying to use OAuth2 to authenticate API requests and I'm unsure if a custom grant should be being used or even OAuth at all?
I would like users to create access tokens via a web portal they login to using standard Laravel authentication. They can then copy and paste these access tokens into their own application. The token would be given a TTL of say 1 year. Their applications would send these access tokens in the normal 'oauth' way via the Authorization header / Bearer. The API endpoints would be protected by the oauth middleware and somehow return the UserId / User Object of the user to the application.
I cannot seem to find a way to implement these, I would have thought it'd be pretty common use case for this type of thing? Am I missing something?
Any pointers really appreciated.
Thanks

Better would be to let users generate new client credentials. Then they can fetch access tokens from their own applications with those instead.

authors: russellgalpin vinkla


text:
How can we access the user id of the logged in user in middlewares

Hi
I have already tried Auth::user , Authorizer::getResourceOwnerId but both of them are returning the following errors:

Auth::user returns null
Authorizer::getResourceOwnerId Tried to access session data without an active access token
even though the user is logged in and has an active token.

Thanks

Did you first call the OAuthMiddleware middleware and then the OAuthUserOwnerMiddleware?

Yes I have done that.

Then you should be able to fetch the owner ID from the Authorizer::getResourceOwnerId() method.

No it's not happening. I am creating a new custom Middleware. It works in controllers.

Paste your Middleware here please.

auth = $authorizer;
    }

    public function handle($request, Closure $next)
    {
        /**
        *    Oauth token creation requires no role based access.
        */
        $requestPath = $request->path();

        if($request->is("oauth/access_token")){
            return $next($request);
        }

        $currentUserId = $this->auth->getResourceOwnerId();

        if(!$currentUserId){
            return $next($request);
        }

        if($currentUserId){
            $urls = DB::table("users")
                    ->join("user_roles", "user_roles.user_id", "=", "users.id")
                    ->join("roles_url_endpoints_mapping", "roles_url_endpoints_mapping.role_id","=", "user_roles.role_id")
                    ->join("url_endpoints", "url_endpoints.id", "=", "roles_url_endpoints_mapping.url_id")
                    ->where("users.id", "=", $currentUserId)
                    ->select("url_endpoints.url")
                    ->get();

            var_dump($urls);
        }else{
            return redirect("/");
        }

        return $next($request);
    }
}

Please add the following below and try again.
$this->authorizer->setRequest($request);

if ($this->authorizer->getResourceOwnerType() !== 'client') {
    throw new AccessDeniedException();
}

Please use the existing middlewares as reference https://github.com/lucadegasperi/oauth2-server-laravel/blob/master/src/Middleware/OAuthUserOwnerMiddleware.php

I tried but still getting the same error.

Is this thrown?
if ($this->authorizer->getResourceOwnerType() !== 'user') {
    throw new AccessDeniedException();
}
``

No. Still the same error.

Please share you error message.

NoActiveAccessTokenException in Authorizer.php line 104:
Tried to access session data without an active access token
in Authorizer.php line 104
at Authorizer->getAccessToken() in Authorizer.php line 275
at Authorizer->getResourceOwnerType() in RoleAuthenticationMiddleware.php line 30
at RoleAuthenticationMiddleware->handle(object(Request), object(Closure))
at call_user_func_array(array(object(RoleAuthenticationMiddleware), 'handle'), array(object(Request), object(Closure))) in Pipeline.php line 124
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in OAuthExceptionHandlerMiddleware.php line 36
at OAuthExceptionHandlerMiddleware->handle(object(Request), object(Closure))
at call_user_func_array(array(object(OAuthExceptionHandlerMiddleware), 'handle'), array(object(Request), object(Closure))) in Pipeline.php line 124
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in ShareErrorsFromSession.php line 49
at ShareErrorsFromSession->handle(object(Request), object(Closure))
at call_user_func_array(array(object(ShareErrorsFromSession), 'handle'), array(object(Request), object(Closure))) in Pipeline.php line 124
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in StartSession.php line 62
at StartSession->handle(object(Request), object(Closure))
at call_user_func_array(array(object(StartSession), 'handle'), array(object(Request), object(Closure))) in Pipeline.php line 124
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in AddQueuedCookiesToResponse.php line 37
at AddQueuedCookiesToResponse->handle(object(Request), object(Closure))
at call_user_func_array(array(object(AddQueuedCookiesToResponse), 'handle'), array(object(Request), object(Closure))) in Pipeline.php line 124
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in EncryptCookies.php line 59
at EncryptCookies->handle(object(Request), object(Closure))
at call_user_func_array(array(object(EncryptCookies), 'handle'), array(object(Request), object(Closure))) in Pipeline.php line 124
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in CheckForMaintenanceMode.php line 42
at CheckForMaintenanceMode->handle(object(Request), object(Closure))
at call_user_func_array(array(object(CheckForMaintenanceMode), 'handle'), array(object(Request), object(Closure))) in Pipeline.php line 124
at Pipeline->Illuminate\Pipeline{closure}(object(Request))
at call_user_func(object(Closure), object(Request)) in Pipeline.php line 103
at Pipeline->then(object(Closure)) in Kernel.php line 122
at Kernel->sendRequestThroughRouter(object(Request)) in Kernel.php line 87
at Kernel->handle(object(Request)) in index.php line 54
at require_once('/home/prashanth/ninja/ninjacrm.sales/public/index.php') in server.php line 21

This means your access token isn't valid. Please add the the middlewares in this order OAuthMiddleware , OAuthUserOwnerMiddleware and then your custom middleware.

Works like magic. Thanks a lot.

:+1:

But now i am unable to create access tokens it says that access_token is required even for accessing the url oauth/access_token.

You shouldn't add the middlewares to the oauth/access_token call. What is the error message?

{"error":"invalid_request","error_description":"The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. Check the "access token" parameter."}

I have not added the middlewares to the oauth/access_token call.

What grant are you using?

password.

What does your request look like?

Okay, lets move this conversation to #602.

voce precisa colocar um prefix na rota que está autenticando

sua rota deve ficar como esse exemplo
Route::group(['prefix'=>'api','before' => 'oauth'], function(){
});

authors: PrashanthRaghu hugoooo vinkla


text:
🛑 Site: teapot.ovh is down

In 8166f95, Site: teapot.ovh (https://teapot.ovh) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Site: teapot.ovh is back up in 8f844d1 after 11 minutes.


text:
docs: add bun install

I come from the Elysia documentation which recommends this library.
So I think it would be cool to have the bun install command in the README.

LGTM

I've moved the v3 source code to the v3 branch. You can create a new PR against the new branch if you'd like but I'll be deprecating v3 next year. See https://github.com/lucia-auth/lucia/discussions/1714

authors: Rouret jonaspm pilcrowonpaper

repo: lucia-auth/lucia


text:
🛑 Higyrus-prod is down

In 57740c8, Higyrus-prod (https://client.nasini.com.ar) was down:

HTTP code: 504
Response time: 10270 ms

Resolved: Higyrus-prod is back up in e3c0997 after 11 minutes.

repo: luciano-buono/upptime


text:
add capsules and pills, sunglasses, peace

It is my first pull, before producing other icons I would like to know if these are ok. Thank you

Hey @archistico!
Thank you for submitting an icon request, however, make sure all your icons follow our design guidelines.
Some issues include:

Invalid stroke widths (all strokes must be exactly 2px wide)
Lack of a 2px spacing between elements
Various transforms on elements (there should be none)
Inline styles (there should be none)

Some other stuff to consider in the future:

please do provide the full icon request data (use cases, similar icons) for each icon
any pull request should only contain icons that belong to a single group (e.g. it's fine to add different medical icons all at once, but I fail to see the connection between sunglasses, a peace sign and medicine tablets 🙂 )
make sure your icon has the same global attributes as all other icons and that they are correctly optimized.

Incidentally, there's already an ongoing icon request for pills.

Thank you for the directions. I'll try to make the changes and redo everything.
It is probably better if I use Inkscape instead of Affinity Designer. I see that in the export he has made me some trouble

@archistico I see you removed your changes from this PR. Are you still working on this?

No file changes, I close this for now

authors: archistico ericfennis karsa-mistmere

repo: lucide-icons/lucide

license: ISC


text:
Error When Using Accelerate

I used accelerate launch train.py.
/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py:457: FutureWarning: Passing the following arguments to `Accelerator` is deprecated and will be removed in version 1.0 of Accelerate: dict_keys(['split_batches']). Please pass an `accelerate.DataLoaderConfiguration` instead:
dataloader_config = DataLoaderConfiguration(split_batches=True)
  warnings.warn(
/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py:457: FutureWarning: Passing the following arguments to `Accelerator` is deprecated and will be removed in version 1.0 of Accelerate: dict_keys(['split_batches']). Please pass an `accelerate.DataLoaderConfiguration` instead:
dataloader_config = DataLoaderConfiguration(split_batches=True)
  warnings.warn(
atl1-1-03-012-28-0:191739:191739 [0] NCCL INFO Bootstrap : Using ib0:172.27.70.156<0>
atl1-1-03-012-28-0:191739:191739 [0] NCCL INFO NET/Plugin : Plugin load (libnccl-net.so) returned 2 : libnccl-net.so: cannot open shared object file: No such file or directory
atl1-1-03-012-28-0:191739:191739 [0] NCCL INFO NET/Plugin : No plugin found, using internal implementation
atl1-1-03-012-28-0:191739:191739 [0] NCCL INFO cudaDriverVersion 12040
NCCL version 2.18.1+cuda12.1
atl1-1-03-012-28-0:191740:191740 [0] NCCL INFO cudaDriverVersion 12040
atl1-1-03-012-28-0:191740:191740 [0] NCCL INFO Bootstrap : Using ib0:172.27.70.156<0>
atl1-1-03-012-28-0:191740:191740 [0] NCCL INFO NET/Plugin : Plugin load (libnccl-net.so) returned 2 : libnccl-net.so: cannot open shared object file: No such file or directory
atl1-1-03-012-28-0:191740:191740 [0] NCCL INFO NET/Plugin : No plugin found, using internal implementation
atl1-1-03-012-28-0:191739:191783 [0] NCCL INFO NET/IB : Using [0]mlx5_0:1/IB [RO]; OOB ib0:172.27.70.156<0>
atl1-1-03-012-28-0:191739:191783 [0] NCCL INFO Using network IB
atl1-1-03-012-28-0:191740:191784 [0] NCCL INFO NET/IB : Using [0]mlx5_0:1/IB [RO]; OOB ib0:172.27.70.156<0>
atl1-1-03-012-28-0:191740:191784 [0] NCCL INFO Using network IB

atl1-1-03-012-28-0:191740:191784 [0] init.cc:748 NCCL WARN Duplicate GPU detected : rank 1 and rank 0 both on CUDA device a000

atl1-1-03-012-28-0:191739:191783 [0] init.cc:748 NCCL WARN Duplicate GPU detected : rank 0 and rank 1 both on CUDA device a000
atl1-1-03-012-28-0:191740:191784 [0] NCCL INFO init.cc:1309 -> 5
atl1-1-03-012-28-0:191739:191783 [0] NCCL INFO init.cc:1309 -> 5
atl1-1-03-012-28-0:191740:191784 [0] NCCL INFO group.cc:64 -> 5 [Async thread]
atl1-1-03-012-28-0:191739:191783 [0] NCCL INFO group.cc:64 -> 5 [Async thread]
atl1-1-03-012-28-0:191740:191740 [0] NCCL INFO group.cc:422 -> 5
atl1-1-03-012-28-0:191739:191739 [0] NCCL INFO group.cc:422 -> 5
atl1-1-03-012-28-0:191740:191740 [0] NCCL INFO group.cc:106 -> 5
atl1-1-03-012-28-0:191739:191739 [0] NCCL INFO group.cc:106 -> 5
Traceback (most recent call last):
Traceback (most recent call last):
  File "/storage/ice1/6/1/yxu846/diffusion/denoising-diffusion-pytorch/train.py", line 16, in <module>
  File "/storage/ice1/6/1/yxu846/diffusion/denoising-diffusion-pytorch/train.py", line 16, in <module>
    trainer = Trainer(
  File "/storage/ice1/6/1/yxu846/diffusion/denoising-diffusion-pytorch/denoising_diffusion_pytorch/denoising_diffusion_pytorch.py", line 971, in __init__
    trainer = Trainer(
  File "/storage/ice1/6/1/yxu846/diffusion/denoising-diffusion-pytorch/denoising_diffusion_pytorch/denoising_diffusion_pytorch.py", line 971, in __init__
    self.model, self.opt = self.accelerator.prepare(self.model, self.opt)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1326, in prepare
    self.model, self.opt = self.accelerator.prepare(self.model, self.opt)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1326, in prepare
    result = tuple(
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1327, in <genexpr>
    result = tuple(
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1327, in <genexpr>
    self._prepare_one(obj, first_pass=True, device_placement=d) for obj, d in zip(args, device_placement)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1200, in _prepare_one
    self._prepare_one(obj, first_pass=True, device_placement=d) for obj, d in zip(args, device_placement)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1200, in _prepare_one
    return self.prepare_model(obj, device_placement=device_placement)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1450, in prepare_model
    return self.prepare_model(obj, device_placement=device_placement)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/accelerator.py", line 1450, in prepare_model
    model = torch.nn.parallel.DistributedDataParallel(
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/torch/nn/parallel/distributed.py", line 795, in __init__
    model = torch.nn.parallel.DistributedDataParallel(
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/torch/nn/parallel/distributed.py", line 795, in __init__
    _verify_param_shape_across_processes(self.process_group, parameters)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/torch/distributed/utils.py", line 265, in _verify_param_shape_across_processes
        _verify_param_shape_across_processes(self.process_group, parameters)return dist._verify_params_across_processes(process_group, tensors, logger)

  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/torch/distributed/utils.py", line 265, in _verify_param_shape_across_processes
torch.distributed.DistBackendError: NCCL error in: ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1333, invalid usage (run with NCCL_DEBUG=WARN for details), NCCL version 2.18.1
ncclInvalidUsage: This usually reflects invalid usage of NCCL library.
Last error:
Duplicate GPU detected : rank 0 and rank 1 both on CUDA device a000
    return dist._verify_params_across_processes(process_group, tensors, logger)
torch.distributed.DistBackendError: NCCL error in: ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1333, invalid usage (run with NCCL_DEBUG=WARN for details), NCCL version 2.18.1
ncclInvalidUsage: This usually reflects invalid usage of NCCL library.
Last error:
Duplicate GPU detected : rank 1 and rank 0 both on CUDA device a000
[2024-10-07 11:29:17,757] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 191739 closing signal SIGTERM
[2024-10-07 11:29:17,871] torch.distributed.elastic.multiprocessing.api: [ERROR] failed (exitcode: 1) local_rank: 1 (pid: 191740) of binary: /home/hice1/yxu846/.conda/envs/dog/bin/python
Traceback (most recent call last):
  File "/home/hice1/yxu846/.conda/envs/dog/bin/accelerate", line 8, in <module>
    sys.exit(main())
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/commands/accelerate_cli.py", line 48, in main
    args.func(args)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/commands/launch.py", line 1165, in launch_command
    multi_gpu_launcher(args)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/accelerate/commands/launch.py", line 799, in multi_gpu_launcher
    distrib_run.run(args)
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/torch/distributed/run.py", line 797, in run
    elastic_launch(
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/torch/distributed/launcher/api.py", line 134, in __call__
    return launch_agent(self._config, self._entrypoint, list(args))
  File "/home/hice1/yxu846/.conda/envs/dog/lib/python3.9/site-packages/torch/distributed/launcher/api.py", line 264, in launch_agent
    raise ChildFailedError(
torch.distributed.elastic.multiprocessing.errors.ChildFailedError:
============================================================
train.py FAILED
------------------------------------------------------------
Failures:
  <NO_OTHER_FAILURES>
------------------------------------------------------------
Root Cause (first observed failure):
[0]:
  time      : 2024-10-07_11:29:17
  host      : atl1-1-03-012-28-0.pace.gatech.edu
  rank      : 1 (local_rank: 1)
  exitcode  : 1 (pid: 191740)
  error_file: <N/A>
  traceback : To enable traceback see: https://pytorch.org/docs/stable/elastic/errors.html
============================================================

@ycformal could you try downgrading accelerate to a version that works? let me know which one and i'll just pin the version for now

The problem here is I only applied one GPU on my cluster. After applying two, it works. However, before that, I downgraded the torch version to 2.1.2+cu121, installed nccl, and disabled all optimizations on accelerate config. I don't know which of them work. Using torch 2.4 results an error when saving the model. The nccl python package is automatically installed when running pip install torch.
In summary, the following operations work for me:
Install torch 2.1.2
Install the nvidia-nccl package via pip and install nccl on the nvidia website
Ensure there are multiple GPUs
Disable all optimizations when configuring accelerate
Some ablation studies are needed to get the necessary environment condition.

@ycformal what was the warning for 2.4?

@ycformal what was the warning / error for 2.4?

It's not recorded.. I just heard somewhere that nccl has some problems with torch 2.4 and followed the advice to downgrade torch to 2.1.2.

ah got it

authors: lucidrains ycformal

repo: lucidrains/denoising-diffusion-pytorch


text:
bind: Address already in use

try a simple script and the program warns bind: Address already in use on stdout.
from pytg import Telegram
tg = Telegram(telegram="./tg/bin/telegram-cli",
              pubkey_file="./tg/tg-server.pub")

receiver = tg.receiver
sender = tg.sender

sender.send_photo("xxx", "./yyy.jpg")

Does the program correctly close the socket every time when exits?

Also, notice simple script like above prints out "terminating currently sending request" twice when exits.

Eh, I am still fighting with closing all sockets in the correct order.
The problem is, the CLI should terminate last, after all the sockets opened by python are closed.
The current situation is:
Whey your python script terminates, the CLI thread get closed by python automatically, already closing the used port. The Sender and the Receiver still have the port open, which will result in locking it up, until the underlying timeout from the OS finally closes it.
Now the duplicating termination is because you can either start the Sender and/or Receiver by yourself or included in pytg.Telegram, and must be shut down in both cases.
That currently results in shutting down from the Telegram CLI part  and afterwards from the Sender part twice (or Receiver, not quite sure, without the ability to look into it).
This is the currently best way I found working.
If somebody finds a better way, let me know.
After my vacations I will have a look by myself, too.

What I forgot:
The bind error comes from the CLI subprocess, the telegram-cli. This means there is already that port used.
This can sometimes really be a still running telegram-cli, check that too.

Did that help a bit?

that does not help.

which of the above did you try?

Yeah, Anyway, https://github.com/vysheng/tg/pull/606 looks like it could resolve that.

#22

I still have this issue. It happens when socket is already open and it tries to open another socket while last socket is still open and bind: Address already in use error shows up and a bit later AssertionError: CLI Process died error rises and i just should kill the process to make it run again.

authors: luckydonald marklrh vhdmsm

repo: luckydonald/pytg


text:
Restyle user app front-end

Forms should be as simple and clean as possible

Potentially style to match The Point (social network) site

repo: lucy-marko/centrepoint


text:
Some fixes

Two commits:

Automatic restarts fo the service:

make sure ZooKeeper is enabled => so it is started upon host reboots
make sure ZooKeeper is automatically restarted upon failure (but not on successful shutdowns)

Small enhancement:

Allow election leader / follower ports to be customised

Closing for now, until I know against which repos I should be doing this pull request.

repo: ludovicc/ansible-zookeeper


text:
Rate Games in feed

Features

Adds an item into the root page feed on top, before all other things, that will display 3 games at a time.
Only visible when there's a featured event on which there is currently voting.
It randomly selects 3 out of the top 30 on the smart feed. If it wasn't random there would be a big risk of it being useless since many times after a while the top 1-3 games are unplayable to the majority of participants due to requirements or other issues.
It collapses and expands like other posts in the feed.
There's a refresh that re-picks the random 3 out of the same 30 games to be shown (without fetching). Re-picking happens up to 7 times. After that it does a new fetch (you see the spinner breifly in the gif) and you have 7 new iterations of 3 random picked games.
Adds a button/link to the main page for browsing games to vote on.

To discuss

I'm not very happy with selection of SVGIcons for reshuffle and all games in the lower right. Which is also why I wrote the text next to them.
In my box, for some reason, the event won't list all games (not if I go there the normal way either), so I'm not 100% the href is correctly built from the featured.slug.
There's no text about the importance of playing and rating, but I'd prefer to keep the noise down.
If there's news, it will come below this however important the news is.
There's no separate default for small screens such as mobile

Related issues

Resolves #1644

Yea that looks like back icon not a refresh icon. Even just the Spinner might be better.
Looking on the icomoon website, they do have refresh/reload icons that we could use.

Was considering the spinner, maybe that would be better yes. Easy to swap if Mike says that's better.

It's worth mention that these should be 3 games user haven't rate yet. And also, why to limit it with top-30? Wouldn't it be more useful to make a choice completely random or at least top-100 random? It seems that games in the top of smart rating getting too much attention.

30 is just an arbitrary number. There's a limit to how many you can get from the API and I think it's not worth the added complexity to go beyond that. I leave it to Mike to tweak that number.
As for not including already rated, that's part of another issue (to not do that in general) so it will resolve when someone fixes the backend for the smart filter.
As for smart getting too much attention, I don't quite understand the point. The purpose of smart and design of ldjam is to promote and reward good community behavior. In this case, playing, rating and writing good feedback. When a game gets rewarded by people playing back those who made a serious effort, it drops down in smart rank. The exact weighting is ofc up for discussion. I think there are several issues relating to smart scores waiting for someone to tackle them.

authors: Yngwarr local-minimum zwrawr

repo: ludumdare/ludumdare


text:
Update travis CI

Done https://github.com/luisgc93/stock_reminder_bot/commit/891cf87d9331720d4ac7c55218cfaa31a69f0d45


text:
Could we add support for coq.nvim?

Hi, it would be nice if we can add support for coq.nvim. I think the function would mostly be the same, except the output item list format.

I don't use coq.nvim myself, so I will probably not implement it.
But I would be happy to merge a PR if someone does.

authors: lukas-reineke sandangel

repo: lukas-reineke/cmp-rg


text:
Patch for configuring openssl command

I installed openssl and libressl together, and I wrote patch for switching between them
New configuration keyword: OPENSSL_CMD="openssl"
patch.zip

Hello,
I'm not sure it's the best way to contribute on Github with a patch as a .zip file.
Anyway, to use LibreSSL, you don't need to add a new paramater, you can just add:
alias openssl='/usr/local/bin/openssl' in your dehydrated's config file.
Best Regards.


text:
422 error (file is too large) for GitHub sync

Hi, I'm not sure if I have too many tokens (both native Figma and custom ones), but after a while I'm not able to push the changes to our GitHub repo. The message I receive is with 422 error code and the following output in console:
{message: "client_payload is too large.",…} documentation_url: "https://docs.github.com/rest/reference/repos#create-a-repository-dispatch-event" message: "client_payload is too large."
The last json that I was able to push was with 2246 lines and 54.7 KB, which is not too much for a json file.
Not sure if there's a limit set to the plugin or a general issue (if I hide some of the styles by using "_", it continues to push the file without issues).
Thanks upfront!

Hey @alexhris
did you use the compress option?
Github does have a limit https://github.com/lukasoppermann/design-tokens/issues/67 so this could be the issue.
Can you export the tokens into a local file or does this create an issue as well?

I am assuming this is just the github limit. If not, please reopen.

Sorry, I didn't receive notifications for your messages. Compress option works for us for now, the problem is that the code updates are unreadable in the pull request. Exporting worked as well, it was only the sync of uncompressed files. Thanks.

authors: alexhris lukasoppermann

repo: lukasoppermann/design-tokens


text:
docs: add query parameters to list tags endpoint

Solves #25,
Updated the query parameters for README#list-tags, which although in the issue #25 has been mentioned as README#getTags, which doesn't exist. So I continued with the one that was prevailing in the real documentation.

The link in the issue was just outdated. This looks perfect, I'll go ahead and merge it. Thanks!

The link in the issue was just outdated. This looks perfect, I'll go ahead and merge it. Thanks!

Awesome :v

Awesome :v

authors: lukePeavey raxraj

repo: lukePeavey/quotable


text:
Subject via Razor

If I want to use a Razor template for the subject, how can I do that?

Closing old issues.

authors: bjcull tofutim

repo: lukencode/FluentEmail


text:
glogg@1.1.4: download via aria2 failed

Installation of glogg seems to be not possible currently:
Installing 'glogg' (1.1.4) [64bit]
Starting download with aria2 ...
Download: Download Results:                                                                                ond.
Download: gid   |stat|avg speed  |path/URI
Download: ======+====+===========+=======================================================
Download: 4a8a5e|ERR |       0B/s|C:/Users/foo/scoop/cache/glogg#1.1.4#https_glogg.bonnefon.org_files_glogg-v1.1.4-x86_64-setup.exe_dl.7z
Download: Status Legend:
Download: (ERR):error occurred.
Download: aria2 will resume download if the transfer is restarted.
Download: If there are any errors, then see the log file. See '-l' option in help/man page for details.

ERROR Download failed! (Error 1) An unknown error occurred
ERROR https://glogg.bonnefon.org/files/glogg-v1.1.4-x86_64-setup.exe#/dl.7z
    referer=https://glogg.bonnefon.org/files/glogg-v1.1.4-x86_64-setup.exe#/
    dir=C:\Users\foo\scoop\cache
    out=glogg#1.1.4#https_glogg.bonnefon.org_files_glogg-v1.1.4-x86_64-setup.exe_dl.7z

ERROR & 'C:\Users\foo\scoop\apps\aria2\current\aria2c.exe' --input-file='C:\Users\foo\scoop\cache\glogg.txt' --user-agent='Scoop/1.0 (+http://scoop.sh/) PowerShell/5.1 (Windows NT 10.0; Win64; x64; Desktop)' --allow-overwrite=true --auto-file-renaming=false --retry-wait=2 --split=5 --max-connection-per-server=5 --min-split-size=5M --console-log-level=warn --enable-color=false --no-conf=true --follow-metalink=true --metalink-preferred-protocol=https --min-tls-version=TLSv1.2 --stop-with-process=20364 --continue --summary-interval 0

Looks like the website is down in general: https://github.com/nickbnf/glogg/issues/289

e3a53055c85b80f7220cbae6c06811d505aff588

repo: lukesampson/scoop-extras

license: Unlicense


text:
typora: fix bin path

Fixes #3409
Apparently typora has removed the bin/ folder as of 0.9.82 (though the changelog doesn't mention it).
this PR changes the bin path to Typora.exe, the only executable that is left in the installation.

@r15ch13 ?

I did not expect it to matter on a case-insensitive system.

because it used to be the same way. Unfortunately i did a scoop cleanup since, so i can't check wether the old bin\\typora.exe did argument handling.

Just typora xx.md in console, so added in bin.

authors: MCOfficer niheaven


text:
civo: Add version 0.6.42

As this is not really that popular I didn't put on main repo, let me know if it should change.

Hey there @Ash258 could you point out what needs fix?

Should I rebase it or will you squash merge it?

/verify


text:
Support disassembly of all instructions

There are still some lesser used instructions that we do not disassemble (we do parse them though). This issue is to keep track of them:

[ ] invoke-polymorphic
[ ] invoke-polymorphic/range
[x] filled-new-array/range
[ ] invoke-custom
[ ] invoke-custom/range
[ ] const-method-handle
[ ] const-method-type
[ ] packed-switch-payload
[ ] sparse-switch-payload
[ ] fill-array-data-payload

Closing as we have removed the disassembler from the crate.

repo: lukhio/DEXParser


text:
Make the anomalous data resets use the multi method so they can be batched

@dtboctor simple change allowing an array (instead of just one at a time) of user ids to be passed through to the API to fix their anomalous past data,
DE-10392

:+1:

authors: apurvis dtboctor


text:
Does not correctly parse <!doctype html>

Hi,
Here is the template I am parsing:
+++
+++
<!doctype html>
<html>
<head>
{{~ include "head.scriban-html" ~}}
</head>
<body>
{{ $$ }}
</body>
</html>

and here is the C# code:
var layoutPage = Template.Parse(scriptLayoutText, fullLayoutPath, null, new LexerOptions()
{
        Mode = ScriptMode.FrontMatterAndContent
});

And here is the parse result:

What do you mean by parsing <!doctype html>? Scriban is working only at the text level, so it does not know anything about the text, I'm confused. What do you expect from the result?

Hi,
Thanks for the answer.
My mistake.
Please close this.
Great project by the way 👍

authors: vascofernandes xoofx

repo: lunet-io/scriban


text:
Add data apps

From https://github.com/luqmaan/awesome-transit/pull/7

:bus:

repo: luqmaan/awesome-transit


text:
Add Poseidon gadget to fcomm in the circuit

Currently we are not using Poseidon gadget to check the hash calculation is correct in the circuit. We need to fix that problem with high priority.

Agreed. Briefly, there should probably be a function called (e.g.) construct_commitment in gadgets/pointer.rs. That this function does not exist (and therefore is not used in circuit_frame.rs) is a hint that the associated constraints are missing.

authors: emmorais porcuquine

repo: lurk-lang/lurk-rs


text:
🛑 BrandTag Staging is down

In be23dc7, BrandTag Staging (https://app.staging.brandtag.io) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BrandTag Staging is back up in e7a414d.

repo: luxtagofficial/upptime


text:
Converter misses opportunity to detect identical glyphs, stores them as separate images

As the title says. I am converting ASCII and Cyrillic ranges. The letter A, for example, is present in both ranges and it is being stored twice. Interestingly, the stored images are slightly different. Same for other identical glyphs. It should not be too troublesome to detect duplicate glyphs and store one copy only.

How can we know if the ASCII A is the same as Cyrillc A? Check it on the rasterized image?

I believe font files have facilities that allow different Unicode code points to reference the same glyph. For example, you can go to https://fontdrop.info/ , load arial.ttf, scroll down to unicode 0410 (Cyrillic letter A) click on it and observe "This composite glyph is a combination of: glyph 36". If you click on the letter A from ASCII range (close to top of table), you'll see same index 36.

How many glyphs can be affected by that? I estimate it to max. 1% (but probably closer to 0.1%). What do you think?

Let's see. For the Russian alphabet, I would say 11 uppercase and 8 lowercase letters share glyphs with ASCII. That would be 15% of ASCII range.

Guys, before discussing any changes, it's worth providing clear proof that the source font really has multiple character codes mapped to the same image. If source images are different, that's the intent of the font authors, not a converter issue.

Also worth refer binary format as base. The "lvgl" one is less optimal, focused on text representation of the source. Binary is a close subset of TTF, with minor local changes about raster/compression instead of vectors.

So I looked closer at arial.ttf using fontdrop.info online tool. I can confirm that Russian letters АВЕМНОРТХаенорсух share glyphs with regular ASCII letters. That's 17 glyphs. This set could vary slightly from font to font, but I don't expect major variations. I am mostly an embedded C developer with some knowledge of JS. But I'll see if I can dive into the code and suggest patches.

So I looked closer at arial.ttf using fontdrop.info online tool. I can confirm that Russian letters АВЕМНОРТХаенорсух share glyphs with regular ASCII letters. That's 17 glyphs.

And you used the same font in convertor, when found duplicated images?

And you used the same font in convertor, when found duplicated images? And the same problem in binary format?

Just ran the converter on arial.ttf. Yes, the glyphs in question are duplicated. This time exact copies, to the last bit. I am not interested in the binary font format for my applications, so I can't confirm this behavior with it.

There is a chance we ignored deduplication to save time. But that's 100% not internal [binary] format restriction (don't remember about lvgl).

In LVGL we can also reference any bitmap_index for a glyph. See
 {.bitmap_index = 1307, .adv_w = 128, .box_w = 8, .box_h = 8, .ofs_x = 0, .ofs_y = -1},

authors: kisvegabor pavmick puzrin