text:
Update UK Biobank to EFO mappings

Since the last time when UKBB GWAS studies were mapped to EFO, the ontology has suffered significant changes. The most notable the dynamic imports of some other ontologies (MONDO, HP, etc.). Due to this changes, more terms are available sometimes better reflecting the GWAS trait than the original mapping. For example, the trait Bursitis (SAIGE_726_3) was mapped to frozen shoulder (EFO_1000941), when there is a bursitis term available in EFO (MONDO_0002471).
Next a subset (top20) of studies that were automatically suggested as potential improvements:
+------------+---------------------------------------------------------+---------------+----------------------------------------------------------+-------------+------------------------------------------+
|study_id    |traitName                                                |currentEfo     |currentName                                               |candidateId  |candidateName                             |
+------------+---------------------------------------------------------+---------------+----------------------------------------------------------+-------------+------------------------------------------+
|SAIGE_112   |Candidiasis                                              |EFO_1001283    |Candidiasis, Invasive                                     |MONDO_0002026|candidiasis                               |
|SAIGE_716   |Other arthropathies                                      |EFO_1000999    |joint disease                                             |HP_0003040   |Arthropathy                               |
|SAIGE_726_3 |Bursitis                                                 |EFO_1000941    |frozen shoulder                                           |MONDO_0002471|bursitis                                  |
|SAIGE_216   |Benign neoplasm of skin                                  |EFO_0004198    |skin neoplasm                                             |MONDO_0021440|benign neoplasm of skin                   |
|SAIGE_252_1 |Hyperparathyroidism                                      |EFO_0009189    |Hyperthyroidism                                           |EFO_0008506  |hyperparathyroidism                       |
|SAIGE_215   |Other benign neoplasm of connective and other soft tissue|EFO_1000541    |Soft Tissue Neoplasm                                      |MONDO_0000654|benign connective and soft tissue neoplasm|
|SAIGE_427_11|Paroxysmal supraventricular tachycardia                  |EFO_0009493    |paroxysmal tachycardia                                    |HP_0004763   |Paroxysmal supraventricular tachycardia   |
|SAIGE_313   |Pervasive developmental disorders                        |EFO_0003759    |pervasive developmental disorder - not otherwise specified|MONDO_0000594|pervasive developmental disorder          |
|SAIGE_296_22|Major depressive disorder                                |EFO_0003761    |unipolar depression                                       |MONDO_0002009|major depressive disorder                 |
|SAIGE_172   |Skin cancer                                              |EFO_0009259    |skin carcinoma                                            |MONDO_0002898|skin cancer                               |
|SAIGE_415_21|Primary pulmonary hypertension                           |Orphanet_275766|Idiopathic pulmonary arterial hypertension                |MONDO_0001999|primary pulmonary hypertension            |
|SAIGE_705_8 |Hyperhidrosis                                            |EFO_1000712    |hypohidrosis                                              |HP_0000975   |Hyperhidrosis                             |
|SAIGE_523_32|Chronic periodontitis                                    |EFO_0000649    |periodontitis                                             |EFO_0006343  |chronic periodontitis                     |
|SAIGE_510   |Other diseases of lung                                   |EFO_0000684    |respiratory system disease                                |EFO_0003818  |lung disease                              |
|SAIGE_253_3 |Diabetes insipidus                                       |HP_0000863     |Central diabetes insipidus                                |MONDO_0004782|diabetes insipidus                        |
|SAIGE_208   |Benign neoplasm of colon                                 |EFO_0001378    |multiple myeloma                                          |MONDO_0002278|benign colon neoplasm                     |
|SAIGE_481   |Influenza                                                |EFO_0001669    |null                                                      |EFO_0007328  |influenza                                 |
|SAIGE_473_1 |Chronic laryngitis                                       |MONDO_0002647  |laryngitis                                                |MONDO_0001369|chronic laryngitis                        |
|SAIGE_528_5 |Diseases of lips                                         |EFO_1001047    |mouth disease                                             |MONDO_0004748|lip disease                               |
|SAIGE_592_2 |Urethritis and urethral syndrome                         |EFO_0003878    |urethritis                                                |MONDO_0001730|urethral syndrome                         |
+------------+---------------------------------------------------------+---------------+----------------------------------------------------------+-------------+------------------------------------------+
only showing top 20 rows

I made a pass on a subset of trait-mappings from SAIGE or NEALE that could be updated.
I propose to include every row in the next spreadsheet with either the current or the alternative EFO as specified by booleans (checkbox)
https://docs.google.com/spreadsheets/d/1PotmUEirkV36dh-vpZ3GgxQg_LcOefZKbyTq0PNQ6NY/edit?usp=sharing

repo: opentargets/genetics


text:
Genetics portal no longer links to specific Platform widgets

In the Genetics Portal, clicking on the links to the Platform at the top of a page (e.g. "Is there known drug data?" "Is there mouse phenotype data?") no longer links to the specific widgets, just the target profile page.

With the new Platform UI, we don't (yet) have the ability to link to specific section on the target profile page. A previous idea that we considered is using the Platform API to determine if specific target annotation is available — if so, we would make the link active in the Genetics Portal and if there's no data available, the link would be greyed out.

Despite what I have said in the past, perhaps it's not a terrible idea to query the Platform API. The only consideration it needs to be made is to treat differently the next 3 cases:

a case in which and ENSGID is available and has available data
a case in which the ENSGID is available and has no data
a case in which the ENSGID is not available and absence or presence of data can not be evaluated

source: gharchive/issue

authors: HelenaCornu andrewhercules d0choa

license_type: permissive

license_source: github-api


text:
The EuroPMC entity recognition pipeline outputs empty files

Since late September 2023, all output files from the abstract pile is empty:
         0  2023-09-26T07:42:07Z  gs://otar025-epmc/ml02/abstract/2023_09_26/NMP_patch-25-09-2023-0.jsonl
         0  2023-09-27T07:41:44Z  gs://otar025-epmc/ml02/abstract/2023_09_27/NMP_patch-26-09-2023-0.jsonl
         0  2023-09-27T05:28:02Z  gs://otar025-epmc/ml02/abstract/2023_09_27/NMP_patch-26-09-2023-1.jsonl
         0  2023-09-28T09:38:31Z  gs://otar025-epmc/ml02/abstract/2023_09_28/NMP_patch-27-09-2023-0.jsonl
         0  2023-09-28T04:54:07Z  gs://otar025-epmc/ml02/abstract/2023_09_28/NMP_patch-27-09-2023-1.jsonl
         0  2023-09-29T08:12:30Z  gs://otar025-epmc/ml02/abstract/2023_09_29/NMP_patch-28-09-2023-0.jsonl
         0  2023-09-29T08:06:33Z  gs://otar025-epmc/ml02/abstract/2023_09_29/NMP_patch-28-09-2023-1.jsonl
         0  2023-09-29T05:35:51Z  gs://otar025-epmc/ml02/abstract/2023_09_29/NMP_patch-28-09-2023-2.jsonl
         0  2023-09-30T07:58:35Z  gs://otar025-epmc/ml02/abstract/2023_09_30/NMP_patch-29-09-2023-0.jsonl
         0  2023-09-30T06:28:55Z  gs://otar025-epmc/ml02/abstract/2023_09_30/NMP_patch-29-09-2023-1.jsonl
         0  2023-09-30T05:37:20Z  gs://otar025-epmc/ml02/abstract/2023_09_30/NMP_patch-29-09-2023-2.jsonl
         0  2023-10-01T06:24:35Z  gs://otar025-epmc/ml02/abstract/2023_10_01/NMP_patch-30-09-2023-0.jsonl
         0  2023-10-01T05:07:39Z  gs://otar025-epmc/ml02/abstract/2023_10_01/NMP_patch-30-09-2023-1.jsonl
         0  2023-10-02T06:18:34Z  gs://otar025-epmc/ml02/abstract/2023_10_02/NMP_patch-01-10-2023-0.jsonl

The progression of the pipeline is followed up on slack. However there was no indication if the jobs were failing (except checking the file contents manually). One example output is here. It says:
Successfully completed.

Resource usage summary:

CPU time : 13613.93 sec.
Max Memory : 77 MB
Average Memory : 68.19 MB
Total Requested Memory : 2048.00 MB
Delta Memory : 1971.00 MB
Max Swap : -
Max Processes : 4
Max Threads : 5
Run time : 14133 sec.
Turnaround time : 14136 sec.

This is the expected output: gs://otar025-epmc/ml02/abstract/2024_01_19/NMP_patch-18-01-2024-35.jsonl. No content:
─ gsutil cat gs://otar025-epmc/ml02/abstract/2024_01_19/NMP_patch-18-01-2024-35.jsonl

╭─

@tsantosh7 , could you please take a look? Also, please let us know if you need further details for the investigation. The full-text processing pipeline seemingly works fine.

Hi @DSuveges Just checked and indeed there are empty files. Dont know the reason for now and therefore would need investigation as the process runs without any problem.

Thank you @tsantosh7 for jumping onthe issue so quickly!

Hi @DSuveges
There was a bug in the abstract pipeline which is fixed now. I have rerun the pipeline for all the empty directories and updated the daily pipeline. All are reflected in the google storage now. Please kindly check and let me know if its ok?

Thanks @tsantosh7, the data is coming in! We can close this ticket.

repo: opentargets/issues


text:
Enable text-file compression in production version of platform-app

A benchmark of platform.opentargets.org home page using Google PageSpeed reports that the site does not pass the Core Web Vitals assessment.
Among the several suggested improvements, it's suggesting a 2.2 seconds improvement just by enabling text compression in text files (more dramatically in the javascript bundle).
Instead of generating plain text files (e.g. bundle.js), can we explore the possibility of producing a gzipped files (e.g. bundle.js.gz) in the production bundle? Possibly at build time.

Reassigning, but still not done

@mirandaio has made the compressed files available through the bundle. Now it's up-to @mbdebian to decide whether that's the best approach or relying on nginx for the compression.

I have patched our production web servers to increase efficiency when serving the web application content.

repo: opentargets/platform


text:
Create linked diseases table on drugs page

Should have the diseases and all the therapeutic areas. Get the TAs from the API response

Done in https://github.com/opentargets/platform-app/pull/80


text:
Uploading a File

Issue on page:        https://github.com/opentelekomcloud-docs/object-storage-service/blob/main/umn/source/obs_console_operation_guide/managing_objects/uploading_a_file.rst
If you are looking as a customer to find OBS uploader tool, there is no downlink link or anything else provided. This should be better described from customer point of view.

Hello tischrei! These are the tools that are supported at this moment:

OBS Browser+
obsutil
Can you please check if you're talking about any of those two tools?

I mean the link to the OBS Browser+.
I am missing a link to the application from the OBS user manual. I struggled a lot until I found it on the web UI which is not that clearly visible.

There is a section called OBS Browser Operation Guide in the User Guide, in this section we have a page https://docs.otc.t-systems.com/object-storage-service/umn/obs_browser_operation_guide/getting_started/downloading_obs_browser.html - it doesn't have the link to the application itself but it contains info about where to find it. Would it be sufficient?

I saw this helpcenter page but if you are in your bucket, you don't see any link from there and that was a bit strange for me.
So a screenshot would be nice to clarify the position of the download link and that you have to go up instead staying in your own bucket. The description of "click the OBS Browser package link on the homepage of OBS Console" can be anywhere and is not clear from my point of view.

Thank you for your feedback, an internal ticket has been created.

cool thx

Now links for downloading OBS Browser+ are also available in the tool guide document: https://docs.otc.t-systems.com/object-storage-service/tool-guide/downloading_obs_browser.html

authors: dsabelni tischrei


text:
Remove unecessary imports for miners

Importing prompting is throwing errors for miners because of the angle model and it's required imports. It may be beneficial to not import all of prompting for the spec version.

@bkb2135 is this done?

Considering that everything is now centralized within the prompting package, this shouldn't be a problem anymore. Feel free to reopen the issue in case that's not the correct interpretation of the current state.

authors: bkb2135 mccrindlebrian p-ferreira

repo: opentensor/prompting

license: MIT


text:
Update index.html - add comerford

Adding my details to the pledge table

Added in https://github.com/opentffoundation/manifesto/pull/266

source: gharchive/pull-request

authors: comerford flavius-dinu

repo: opentffoundation/manifesto


text:
spi-hdlc-adapter: Improved strategy for how SPI transactions are performed

The big change in this commit is a change in the transmission strategy used. This change isn't fixing any particular bug, but these changes should improve performance.
Instead of always using a throw-away transaction to figure out the buffer sizes for the NCP, we now attempt to send any frame we have in the first transaction. If the NCP has a response that happens to fit in the size of that packet, it will be processed.
This change also adds a lot more comments better explaining the more complicated parts of the code.

Note that this change shouldn't be merged until the "work-in-progress" tag is removed. Additional testing and confirmation is required before we can merge this change.

A general question: Where and how is this used?

This is used on Linux-based platforms where the interface to the NCP is SPI. wpantund can be configured to talk to a separate process instead of a UART. spi-hdlc-adapter allows wpantund to communicate with the NCP as if it were connected via UART, even though it is physically connected via SPI.
At some point native support for the Spinel SPI protocol recommendation(which is what spi-hdlc-adapter uses) might be added to wpantund, but this solution works well enough for now and is rather convenient since it doesn't require any significant changes to wpantund. You can even tunnel such a connection across SSH.

Current coverage is 72.92% (diff: 100%)

Merging #1066 into master will decrease coverage by 0.30%

@@             master      #1066   diff @@
==========================================
  Files           127        127
  Lines         18293      18293
  Methods        2553       2553
  Messages          0          0
  Branches       2237       2237
==========================================
- Hits          13397      13341    -56
- Misses         4197       4262    +65
+ Partials        699        690     -9

Powered by Codecov. Last update f2d28b5...f298d1c

I've done testing on this and I think that it feels solid.

authors: codecov-io darconeous nibanks

repo: openthread/openthread


text:
Add arm-gcc54 to travis and -Wno-c++14-compat to CXXFLAGS.

Resolves #825.

@wbober, @LuDuda, @nibanks I think this is a cleaner solution to addressing the sized delete issue.  This avoids introducing Windows-specific preprocessor checks into core.

Current coverage is 59.32% (diff: 100%)

Merging #832 into master will decrease coverage by 13.99%

@@             master       #832   diff @@
==========================================
  Files           109         14      -95
  Lines         16306       2837   -13469
  Methods        2219        343    -1876
  Messages          0          0
  Branches       1953        351    -1602
==========================================
- Hits          11956       1683   -10273
+ Misses         3706       1021    -2685
+ Partials        644        133     -511

Powered by Codecov. Last update 117ecaf...2f87789

LGTM👍

LGTM :+1:  I have no errors during compilation using this patch.

:hand: Unfortunately this doesn't fix #826.

@wbober, gcc6 sets the default mode for C++ to -std=gnu++14.  Couple questions:

Are you OK with setting the C++ mode to an earlier version?
What features of gcc6 interest you - gcc6 is relatively bleeding edge :)

@jwhui, I see. That explains the issue :)
Ad1) Yes, I'm fine.
Ad2) None in particular. I'm simply using ArchLinux and that's the reason I have gcc6.

@wbober, thanks.  I'll update this PR to add gcc6 to travis soon.

I'm going to merge this first then submit a separate PR for gcc6.

authors: LuDuda bukepo codecov-io jwhui wbober


text:
fix: changed the staled twitter icon

Description
Replaced the old twitter icon to new twitter icon
Motivation and Context
The motive was to change the old twitter icon to new one
Screenshots (if appropriate):
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My change depends on a change in the main opentofu repository.

Side note, the mobile menu still says "Twitter"

FWIW https://github.com/opentofu/opentofu/issues/1028 is related.

Thank you for your work, this is now resolved. Closing in favor of #267

authors: Dev79844 ebel janosdebugs


text:
Module: makandra/terraform-aws-state-storage

Module Repository
makandra/terraform-aws-state-storage
DCO

[X] I sign this project's DCO

Im working on the version issue and release one

I added a version now, sorry for that hiccup

@RubenMakandra no problem, thank you for the submission!

authors: RubenMakandra ollevche

repo: opentofu/registry


text:
🛑 Search Tool (Develop) is down

In bfffe0c, Search Tool (Develop) (https://search-dev.opentorc.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Search Tool (Develop) is back up in 0ee84ab.

repo: opentorc/upptime


text:
Disable reporting spans for actuator endpoints

Hi guys,
Reposting this here.
When using Opentracing with Jaeger for Spring Cloud Gateway with actuator endpoints enabled (e.g. /actuator/health for K8s readiness probe), all calls to the actuator endpoints produce a span. Is there a way to disable this behaviour?
Config:
        <dependency>
            <groupId>io.opentracing.contrib</groupId>
            <artifactId>opentracing-spring-jaeger-cloud-starter</artifactId>
            <version>2.0.0</version>
        </dependency>

        <dependency>
            <groupId>io.opentracing.contrib</groupId>
            <artifactId>opentracing-spring-cloud-starter</artifactId>
            <version>0.3.2</version>
        </dependency>

Cheers,
Marius

I think this should not happen, the helthcheck probes should not be traced.
@ask4gilles could you please comment on this one? It will also transfer it to web repository.

authors: mariusgiger pavolloffay

repo: opentracing-contrib/java-spring-cloud

license_source: bigquery


text:
Simple layer on top of ByteBuffer for BINARY format.

Provide a simple layout to let users get/set the used ByteBuffer,
as well as hint them about the ByteBuffer length in the case
of injection (as opposed as the current approach, where they
need to pass a large-enough ByteBuffer when calling Tracer.inject()).
Observe this is merely a thin layer on top of ByteBuffer, but with the hint for letting the users know the required length of the buffer used by inject().

Coverage increased (+0.3%) to 81.796% when pulling 3dd5a6114c855a2652dc99822782d1da36c73020 on carlosalberto:binary_format_proposal_simple into 4c5dfb5010daf32901c57fbc74b3728d603148a8 on opentracing:v0.32.0.

The code was updated to show the suggested improvements @yurishkuro Let me know ;)

@yurishkuro Good point (on the injectionBuffer instead of injectBuffer) ;)
Updated.

@yurishkuro My impression is that nobody has been really using this API so far - still, I think it would be nice to ask on Gitter (at least), in case anybody was (if that's the case, we should definitely deprecate what we have now, etc).

I believe this interface puts

more work on on instrumenters side, since it now has to handle the lifecycle of a ByteBuffer and an additionnal method to implement.
more work on the tracer implementers with an aditionnal method setInjectionBufferLength to use. Also, it does not have the hand on the kind of buffer being created.
does not solve the concerns of @raphw

The previous interface from @yurishkuro did solve the first 2 items.
What do you think ?

@felixbarny Oh, if Instana is using BINARY, then we definitely add a new format and deprecate the current one.
On @raphw and his feedback, I'd suggest reading, for historical context:

#99 as the initial need for users to be able to not pass a large enough ByteBuffer instance for Tracer.inject().
#223, as the original PR where we tried to have a simple streaming API, similar to what Go does/has at this moment (and which was later reverted).
#253 which is the Issue referencing all the effort and iteration and considerations (including this PR and #252 . This can be important as @raphw mentioned that at some moment (in #252):

the more I think of it, I believe that it would actually be the easiest to extract a TextMap and push it into the stream depending on the underlying binary protocol. Until there is an actual use case, maybe it makes sense to table the binary extraction?

I had previously in the same thread mentioned the advantages and disadvantages of what the options we had at hand - which leads us to have this simple approach (which I mentioned later on as well):

definitely we need a simple, working approach for now (needed, for example, for instrumenting Cassandra on the server side). @raphw needs a more advanced, streaming-based approach that we could add later on, definitely, once we hit that need ;)

I'd urge you to read that to understand the full picture, so the situation is clear, and why we will go with this very PR for the time being. Else, let us know on your take (either for this PR still, or a future streaming based API ;) )

@hypnoce Hey, setInjectionBufferLength() serves for users asking to have a variable-size ByteBuffer approach (see for example #99).
As the other questions (will write my answers here, but it sounds we should put them in the docs as well ;) )

more work on on instrumenters side, since it now has to handle the lifecycle of a ByteBuffer and an additionnal method to implement.

Related to the previous point - and users dont have to handle the lifecycle of a ByteBuffer - we simply provide a default adapter for users to want to have a new ByteBuffer created for simple calls (maybe for MockTracer). In a real world scenario, the user would have a ByteBuffer pool and have a Binary implementation like this (snippet):
class CustomBinary implements Binary
{
  public void setInjectionBufferLength(int length)
  {
    this.buffer = CustomByteBufferPool.getWithLength(length);
  }
  public ByteBuffer injectionBuffer()
  {
    return this.buffer;
  }
}

more work on the tracer implementers with an aditionnal method setInjectionBufferLength

Implementing an extra method is less work than implementing, for users, a full OutputStream or InputStream that has been described in #243, for example :) Also, it serves a specific purpose (and for Tracer.extract(), it should be straightforward to use our adapter (which means: no need to write a class for it):
Byte buffer = ...;
SpanContext ctx = tracer.extract(BinaryAdapters.extractionCarrier(buffer));

For the third point, see my answer to @felixbarny on why we decided to have that approach (streaming) as a separate, potential new FORMAT for the future.

The previous interface from @yurishkuro did solve the first 2 items.

Which one?  #252? I think that's a fine API too, but this is simpler and would work just fine for simpler cases.

Glad to see interest in this picking up! I'm pinging more people to make them aware of this thread.
In the meantime, I would strongly suggest moving to tests and runnable code examples for illustrating various scenarios/points-of-concern. The ability for english/prose to move these discussions forwards becomes very limited once we get down into the weeds.

I would also like to suggest that there may be no "universal" binary solution that would satisfy every case effectively. In Java for example, we may want one solution for situations that require a ByteBuffer, and a separate solution for streaming, rather than a single solution. If a single underlying solution can be made efficient, with higher-level utilities being employed to make it ergonomic for various scenarios, that would be great. But if that seems too difficult, consider that we could instead have several separate solutions.

@carlosalberto Thanks for your answer !

In a real world scenario, the user would have a ByteBuffer pool and have a Binary implementation like this

Each middleware instrumenter would have an implementation of a ByteBuffer pool instead of the tracer implementation to handle it. Therefore, since a single JVM may host different middlewares but a single tracer implementation, you may endup using many ByteBuffer pools with variable degrees of stability.
As a middleware instrumenter, I would rather have the tracer to handle the pooling instead of me and the others since we will endup in many ways of implementing the same behavior. Hope you see the point here :).

Implementing an extra method is less work than implementing, for users, a full OutputStream or InputStream

Totally agree

Hey, setInjectionBufferLength() serves for users asking to have a variable-size ByteBuffer approach

Indeed, when the ByteBuffer is supplied by the instrumenter, then we need such method. When the BB is supplied by the tracer, then I believe this method disappears.

Which one? #252? I think that's a fine API too, but this is simpler and would work just fine for simpler cases.

Exactly. In what aspect do you think the new proposed one is simpler ?
In the end, I would emphasise that java.nio package is not asynchronous IO. It's New-IO and therefore does not enforce asynchronicity. Therefore, exposing ByteBuffer makes total sense in case of blocking IO.
Thanks for your great work !

Hey @hypnoce, thanks for the message.

In what aspect do you think the new proposed one is simpler ?

I think this one is barely a thin layer on top of the current approach (a bare ByeBuffer object). Also, the other implementation you mentioned could become the future BINARY_STREAM one if/when needed (or else @raphw approach of working with actual Java IO streams). This would keep them separated.

As a middleware instrumenter, I would rather have the tracer to handle the pooling instead of me and the others since we will endup in many ways of implementing the same behavior.

Not sure Tracer implementation is the best place to put this, and not sure they would love it ;) To me it sounds we should provide some ByteBuffer pool in some opentracing-contrib repo in the near future, so other instrumentations could use it. This way you could import such pool and do:
import io.opentracing.contrib.BinaryPool;

// returns an object providing a ByteBuffer in the pool, based on a given length.
Binary binary = binaryPool.getInstance();

// Do the actual injection.
tracer.inject(ctx, Format.BINARY, binary);

// Use the result (provided by the pool)
ByteBuffer buffer = binary.injectionBuffer();
buffer.rewind();
request.setPayload(buffer);

This way, we provide a safe place to start - and later people can use their own implementation if they need to. Thing this would work for you? Let us know ;)

Hey @CodingFabian I've got a question for you ;)
Is Instana is using the current BINARY format?  Let us know, as we are moving towards a new API (more or less soon ;) ). Depending on your needs, we could keep the current one (as Deprecated) and create this mentioned new format under a new field (BINARY_LAYER or similar ;) )
Thanks in advance!

well some of our implementations support it, not sure if any user uses it.
there are actually many open issues with the binary format, so I am not sure.

@carlosalberto thanks for your answer
I understand the rationales and a default Binary implementation could be created in the contrib section.
I'm still not really confortable with the setInjectionLength(int length) method. It is very coupled with injectionBuffer().
Maye I would rather replace it y an overloading of injectionBuffer() :
public interface Binary {

    ByteBuffer injectionBuffer();

    ByteBuffer injectionBuffer(int length);

    ByteBuffer extractionBuffer();
}

I beleive it makes the Binary interface easier to understand just by reading the methods. Also, It does not impose some ordering constraints on the calls.
What do you think ?

@hypnoce
Hey! So I had previously played with such approach (injectionBuffer(int length)), but abandoned it as the user couldn't easily/clearly retrieve the underlying buffer (what should happen if the user calls it again? clear the existing buffer? create a new one? what if another length is passed? etc). Having a simple getter for the underlying buffer was specially helpful for BinaryAdapters.injectionBuffer(), as it simply created a buffer on demand ;)

ByteBuffer injectionBuffer();
ByteBuffer injectionBuffer(int length);

IHMO this is confusing - one of them is used for creation, and another one as a getter, but with the same name... I'd rather stick with (as mentioned):

ByteBuffer injectionBuffer(int length);
ByteBuffer extractionBuffer();

And the user could access the underlying buffer depending on the actual implementation they have (CustomBinary.buffer() or similar).
In this case we could remove the BinaryAdapters.injectionBuffer() overload in favor of a simple one wrapping a buffer, injectionBuffer(ByteBuffer), throwing an exception in case the remaining bytes are not enough for the requested length (of course, the users could either provide their own implementation of Binary, or they could use the pool we will be creating soon under contrib ;) )
I'm fine with this slight change - let me know what you think about this one.
cc @yurishkuro ;)

@CodingFabian Hey, thanks for the answer :)
So I'd personally prefer to break the BINARY format here - but, if you think it's better (for you and your users) to add this new iteration under a new field, and simply deprecate the current one, let us know ;)

as long its documented, I would guess the few users using it would find the doc.

@carlosalberto
This change looks nice to me :)
Do you think it's a good thing to document thrown exceptions or it's implementation dependant ?
Thanks !

There's still room to change this once it's merged into the release candidate branch. But I would like to get feedback from @felixbarny and @raphw before doing so, to make sure their concerns have been addressed. Maybe a call in CET time would be quicker?

I am currently on vacation and cannot follow this up but my concerns are the same as I initially mentioned. The current API would require to manage byte buffer pools both by the tracer and the user of a tracer. Also, the buffers must be sized by the required bytes for the trace information what makes reuse difficult.

Hey @raphw

The current API would require to manage byte buffer pools both by the tracer and the user of a tracer. Also, the buffers must be sized by the required bytes for the trace information what makes reuse difficult.

The current API (which simply uses a ByteBuffer) is not much better than PR. Also, few applications simply require this (like Cassandra on the server side, which receives/gets a ByteBuffer as a binary payload).
But as Ted mentioned, I think it would be nice to have an actual call to talk about a binary, stream based, more complex format (separated, such as BINARY_STREAM) - whenever you are back from holidays, that is ;)

@hypnoce Hey, I have updated the PR to remove setInjectionBufferLength(). Let me know ;)

Hey @carlosalberto the changes look good to me. Thanks !

Hey @raphw @felixbarny before going ahead and merge this PR, we would like do cover this issue/PR up in the next Cross-Language group call on July 13th (next week).
Observe the initial plan is to have this as the simple way to do binary propagation, but we would like to get some feedback (part of that is to work on some more advanced BINARY_STREAMING format). Let me know if you can make it to the call ;)

So I think we will be merging this onto the v0.32.0 branch next week.
@raphw if you are still around, would be nice to schedule a Cross-Language call to talk about a more advanced BINARY_STREAM format (which most of us can't properly design/test as we are not experts in the area 😞 ) If not, I will create an Issue, to have it a reminder of this potential format.
@CodingFabian Final take on whether we could replace the existing BINARY format with this one, or should we add it as a new one, to not break code? ;)

@carlosalberto i am fine with breaking as we did not implement this anyway. Thats my vendor perspective.
My user perspective is that this is still probably not usable.

Hey @CodingFabian thanks for the answer.

i am fine with breaking as we did not implement this anyway
My user perspective is that this is still probably not usable

You mean the current or this proposed one? ;)

Hey all,
Trying to get revive this PR - so essentially this approach is simply enough, yet handles an important case (telling the user in advance the required size of the buffer).
In addition, I'd like to address that while prototyping Cassandra server side support, I saw the payload is received as a straight ByteBuffer (https://github.com/carlosalberto/java-cassandra-server/), and while prototyping Hadoop integration (https://github.com/carlosalberto/hadoop/tree/ot_initial_integration), I realized that in such case it may be helpful (on top of Protocol Buffers).
The arguments in favor we had before were: keeping it as a simply, yet more realistic approach to the one we have now; and against it, probably the need of a more advanced format (which could be addressed by a 'streaming' one in the future).
Thoughts?

Hey all,
I'd like to merge this PR by tomorrow, in order to include it in an incoming RC - so feel free to provide any feedback in case you think it needs tuning or shouldn't be merged even ;)
(And my understanding, upon re-reading the conversation, is that it's fine to break Instana' BINARY tracer support ;) )

Merged this PR - feel free to open an issue if you feel something needs tuning (I will be putting an eye on that, and will update accordingly)
Thanks all for your feedback!

authors: CodingFabian carlosalberto coveralls hypnoce raphw tedsuo

repo: opentracing/opentracing-java


text:
🛑 [CN] OpenUPM Website Docs is down

In f36b428, [CN] OpenUPM Website Docs (https://openupm.cn/docs/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Docs is back up in f179273.

repo: openupm/upptime


text:
Move screenshots to S3

[x] Set up an S3 bucket with a reasonable name.
[x] Move the screenshot files.
[x] Update every place where we generate the screenshot URLs to call them from S3 instead.
[x] Delete files from EC2
[x] Update the screenshot-generation script to use s3tools to move those images onto S3 after generating them.
[ ] Start generating thumbnails of the screenshots, rather than just the enormous versions, since mod_pagespeed can't automatically generate thumbnails of images being called from a remote server.

It looks like mod_pagespeed can now optimize remote content.

I just fiddled with it for 10 minutes and couldn't get it working.

repo: openva/richmondsunlight

license: mit


text:
Which version of CVAT will add point cloud tool?

I saw this requirement is in the Backlog page, but don't know which version of CVAT will add it, in addition when will 1.1-realease will be finished?
Thanks,

Hi, thx for the questions.

1.1 has been released: https://github.com/openvinotoolkit/cvat/releases/tag/v1.1.0
We do not have a strict roadmap, what's more backlog means that our team is not planning to do the feature in foreseeable future. Maybe somebody from the community will help with the feature,

authors: SaihholdChiu bsekachev

repo: openvinotoolkit/cvat


text:
add notebook for llm chat

CVS-116313

mpt-7b requires einops:

mpt-7b requires einops:

@apaniukov , thanks updated

I was unable to compile the 3B model on GPU (A750), getting
RuntimeError: Exception from [C:\Jenkins\workspace\private-ci\ie\build-windows-vs2019](file:///C:/Jenkins/workspace/private-ci/ie/build-windows-vs2019)@3\b\repos\openvino\src\inference\src\core.cpp:117:
Check 'itr->second == desc' failed at [C:\Jenkins\workspace\private-ci\ie\build-windows-vs2019](file:///C:/Jenkins/workspace/private-ci/ie/build-windows-vs2019)@3\b\repos\openvino\src\plugins\intel_gpu\src\graph\topology.cpp:15:
[GPU] Different primitive with id 'gather:/gpt_neox/Gather_1' exists already

using todays optimum and optimum-intel 1.10.1 releases.
Can you validate that GPU compilation and inference is working?

I was unable to compile the 3B model on GPU (A750), getting
RuntimeError: Exception from [C:\Jenkins\workspace\private-ci\ie\build-windows-vs2019](file:///C:/Jenkins/workspace/private-ci/ie/build-windows-vs2019)@3\b\repos\openvino\src\inference\src\core.cpp:117:
Check 'itr->second == desc' failed at [C:\Jenkins\workspace\private-ci\ie\build-windows-vs2019](file:///C:/Jenkins/workspace/private-ci/ie/build-windows-vs2019)@3\b\repos\openvino\src\plugins\intel_gpu\src\graph\topology.cpp:15:
[GPU] Different primitive with id 'gather:/gpt_neox/Gather_1' exists already

using todays optimum and optimum-intel 1.10.1 releases. Can you validate that GPU compilation and inference is working?

The Red Pajama 3B model is running on my Arc A770 GPU. It uses about 11GB of GPU memory. The A750 may not have enough memory to load the FP16 model.

The Red Pajama 3B model is running on my Arc A770 GPU. It uses about 11GB of GPU memory.

That's a good insight. I never expect the OV conversion to be as bad. Since GPU forces FP16 which would normally fit a 3B model on a 8GB GPU (at least on cuda). This notebook specifies that you need 64GB ram for the conversion (for the 7B models? 32GB isn't enough for the 3B either and it fills up) but you also need 20GB storage even though if the model.bin is 5.8GB.
Apart from successfully compiling the model on GPU, is the performance any good? I did manage to compile and run the 240-notebook with the dolly2 3B but the performance was horrible.

Intel Xeon Server E3 (Supermicro)
64GB RAM
Red Pajama - Works
Llama2 - Failed (Crashes after query)
Intel Xeon Processor Cascade Lake (Amazon EC2)
128 GB RAM
Red Pajama - Works
Llama2 - Runs however results into error  (Uses around 110 GB RAM)
Error - Expecting value: line 1 column 1 (char 0)

The Red Pajama 3B model is running on my Arc A770 GPU. It uses about 11GB of GPU memory.

That's a good insight. I never expect the OV conversion to be as bad. Since GPU forces FP16 which would normally fit a 3B model on a 8GB GPU (at least on cuda). This notebook specifies that you need 64GB ram for the conversion (for the 7B models? 32GB isn't enough for the 3B either and it fills up) but you also need 20GB storage even though if the model.bin is 5.8GB.
Apart from successfully compiling the model on GPU, is the performance any good? I did manage to compile and run the 240-notebook with the dolly2 3B but the performance was horrible.

The performance of LLM models will be better with 2023.1. GPU perf for me was ok but CPU was much better. We will have the 2023.1 pre release on PyPI (hopefully) before the end of July.

Expecting value: line 1 column 1 (char 0)
@vagheshp this error does have relation to model, it says that you have wrong proxy settings and connection with interface was lost.

Regarding memory issue, do you have already converted model to IR or conversion happens in the same process, I think it maybe the reason of large memory consumption if optimum does not free some memory after model conversion?

Regarding memory issue, do you have already converted model to IR or conversion happens in the same process, I think it maybe the reason of large memory consumption if optimum does not free some memory after model conversion?

Optimum uses a TempDir for the ONNX export in between source. And looking at the ram usage during conversion it looks like ram is freed when that cell is done executing. However it seems like the openvino IR .bin file is twice as large as the pytroch model.bin - so I suspect it's saved to fp32 for some reason - could be those HINTS and it seems like the openvino documentation has improved with 2023.0 so I will maybe raise a new issue on that observation.

Optimum uses a TempDir for the ONNX export in between

yes, but after that it reads onnx directly to openvino that leads to additional optimization run on runtime side during reading, so the second run when you already have serialized IR using save_pretrained should requires less memory. Could you please check this hypotisis?

@vagheshp this error does have relation to model, it says that you have wrong proxy settings and connection with interface was lost.

Thanks @eaidova. Let me try on open network.
I am running the conversion in the same process.

@vagheshp this error does have relation to model, it says that you have wrong proxy settings and connection with interface was lost.

Thanks @eaidova. Let me try on open network.
I am running the conversion in the same process.

I am able to run the chat window on the second try with the llama2 model in the open network.
For the first try, optimum was not freeing the memory so when I query it crashes my jupyter kernel. However, on second try, I was able to run the chat box and query with proper response.
One thing I noticed is the memory usage is very high, It is almost using 127GB on my second try.

Intel Xeon Server E3 (Supermicro) 64GB RAM Red Pajama - Works Llama2 - Failed (Crashes after query)
Intel Xeon Processor Cascade Lake (Amazon EC2) 128 GB RAM Red Pajama - Works Llama2 - Runs however results into error (Uses around 110 GB RAM) Error - Expecting value: line 1 column 1 (char 0)

Also, got the crash on the first run with my xeon setup.

@vagheshp this error does have relation to model, it says that you have wrong proxy settings and connection with interface was lost.

Thanks @eaidova. Let me try on open network.
I am running the conversion in the same process.

I am able to run the chat window on the second try with the llama2 model in the open network. For the first try, optimum was not freeing the memory so when I query it crashes my jupyter kernel. However, on second try, I was able to run the chat box and query with proper response.
One thing I noticed is the memory usage is very high, It is almost using 127GB on my second try.

We need open network to make it works?

authors: Vipitis apaniukov eaidova raymondlo84 ryanloney vagheshp


text:
ovnkube: Don't default logging to a file.

If there is no logging file specified in config or
via command line, then don't default to the file
"/var/log/ovn-kubernetes.log". We need a way to log to stderr.
Signed-off-by: Gurucharan Shetty guru@ovn.org

@dcbw Any other ideas? I guess, now we don't log for CNI too.

@shettyg I've actually got a PR that reworks the default handling based on @alinbalutoiu suggestions, I didn't expect the config PR to get merged already.  So if you don't mind, I'll cherry-pick your commit to my new PR and fix it up for the new changes?

Sure thing. I will close this.

authors: dcbw shettyg

repo: openvswitch/ovn-kubernetes


text:
Fix parser for ovn-nbctl show command output

Since openvswitch v2.6.0 output format of ovn-nbctl show has
changed. Any occurrences of "lswitch" have been replaced with "switch",
and occurrences of "lport" have replaced with just "port". Adapt to
the changes.
Ideally we shouldn't be doing output scraping if output format is
free-form but instead ask for machine readable output like JSON or
CSV.

@hzhou8 out of curiosity, do you need ovn-scale-test to work with openvswitch <= 2.6.0?

@jsitnicki it seems not much value to support <= 2.6 since OVN was immature back at that time.

@hzhou8 I've addressed your comments, can you please give it another look?

Opened issue #153.

LGTM. Thanks @jsitnicki !

repo: openvswitch/ovn-scale-test


text:
On-demand columns fetching

This pull request adds support for fetching on-demand columns from non-monitored data.

Please see my review at: http://openvswitch.org/pipermail/dev/2016-May/071155.html

authors: blp sebastian-arguello

repo: openvswitch/ovs


text:
Add openwhisk-es6-action sample

See: https://github.com/ddragosd/openwhisk-es6-action .
This repo shows how to write actions in ES6 standard and includes a setup for unit testing with code coverage.

Very cool!

authors: ddragosd jthomas

repo: openwhisk/awesome-openwhisk


text:
set force_insert=False on the second super().save inside BaseX509 (fi…

…xes #5)
If using Cert.objects.create() Django uses force_insert=True.
The second call of save() inside baseX509 will fail, because
a PK is created on the first save and it's called again with force_insert=True

Hello Federico,
thanks for your work - sorry about the commit message. I have rebased my branch and updated the commit message.
I also saw the strange error - but local with my 2.7.9 the test did not fail. (the isort is easy to change, but I would like to have my PR clean)

@hggh thanks for helping out.
I fixed the isort issue but I can't replicate the test failure we're getting on travis, are you able to replicate that?

I also can not replicate the error from travis. I have tested it with my local Python 2.7.9 and with 3.5.3, I don't get that error.

Not me either. I guess we'll find out in the near future :-/

authors: hggh nemesisdesign


text:
Changes enhance the code's robustness, usability, and maintainability while ensuring it can handle more complex data structures effectively. #297

Checklist

[x] I have read the OpenWISP Contributing Guidelines.
[x] I have manually tested the changes proposed in this pull request.
[x] I have written new test cases for new code and/or updated existing tests for changes to existing code.
[x] I have updated the documentation.

Reference to Existing Issue
Closes #297.
Please open a new issue if there isn't an existing issue yet.
Description of Changes

Error Handling:
Replaced console.error with throw new Error(...) for better error management.

Input Validation:
Added a validateNodes method to ensure input data is valid before processing.

Performance Optimization:
Used a Set in arrayDeduplication for tracking duplicates instead of an array.

Support for Nested Properties:
Enhanced arrayDeduplication to handle nested properties using dot notation via getValueByPath.

Custom Key Generation:
Allowed users to provide a custom key generation function in arrayDeduplication.

Documentation Improvements:
Updated JSDoc comments for clarity and added examples where appropriate.

Screenshot
Please include any relevant screenshots.
Screenshot
Please include any relevant screenshots.

@nemesifier please review this pr and the changes i have enhanced code robustness to handle heavy data effectively


text:
kernel/scheduler: cleanups, optional debug vars

This PR adds a configuration to enable scheduler debug variables SCHEDULER_DEBUG_ENABLE (current and peak tasks). Disabling it will save a couple of bytes in memory.
This PR also adds geters for those variables to avoid reading them through scheduler_dbg_t
numTasksCur and numTasksMax are removed from scheduler_vars_t since there was no use of them.

@fjmolinas, looks good, thanks!

Thanks for the reivew!

authors: TimothyClaeys fjmolinas

repo: openwsn-berkeley/openwsn-fw


text:
Update nvidia driver on host image to 530

Update the nvidia driver to 530 in image_setup.sh
Update the create_templates.sh to use the new images

I decided to also update the CPU images just for consistency

Here is the procedure for the update:

Update and rollout the host image with the newer driver. The backward compatibility should allow us to still run CUDA 11 in docker images.
Update the NVIDIA CUDA/Vulkan common drivers to v530 in the docker image: https://github.com/openxla/iree/pull/13912

Progress toward #13830. Tested only updating CUDA in docker to 12 and it didn't work: https://github.com/openxla/iree/actions/runs/5151975373/attempts/1
runner-env: testing

Actually I just noticed that this adds a TEST_FILE to the top directory by accident?

Actually I just noticed that this adds a TEST_FILE to the top directory by accident?

Ah yes, it was used to trigger the CI. Revert in https://github.com/openxla/iree/pull/13940

authors: antiagainst pzread

repo: openxla/iree


text:
[CPU] Re-enable performance tracking of non-DT path

Not sure why benchmarks on the non-DT path were disabled. This PR is bringing them back.

Yes, this should work and it's similar to do with aarch64

authors: dcaballe pzread


text:
Move CrossReplicaSum from StableHLO to CHLO.

Part 1 of Many

Create a copy of stablehlo.cross-replica-sum in CHLO, including changes in .td and .cc files.

CrossReplicaSum is a special case of AllReduce where the reduction is a summation operation.
It is therefore decomposable to AllReduce. We intend to move the op to CHLO and lower it to AllReduce.

From a compatibility perspective, Migration Change. We will need to keep both Ops around, unless we figure out a way to use a generic Operation * for upgrade pass, before verifiers are run. I'll be investigating this in the near future.
(M0)

Current state, no impact.

(M1)

Verifier (pre-downgrade) blocks serialization of stablehlo.cross-replica-sum
chlo.cross_replica_sum => [downgrade] => stablehlo.cross-replica-sum (remove after forward compatibility window)
stablehlo.cross-replica-sum => [upgrade] => chlo.cross_replica_sum

(M2)

No impact.

(M3)

Remove upgrade pass, delete stablehlo.cross-replica-sum

Closing this pull request for now as discussed in https://github.com/openxla/stablehlo/issues/3#issuecomment-1263057416. Will revisit once we pick up the associated ticket again.

authors: GleasonK burmako subhankarshah

repo: openxla/stablehlo


text:
Makes end-to-end benchmarks more realistic

Chat with @wu-sheng made me realize our end-to-end benchmarks were not
that realistic, on account of using a noop reporter. Most people use
AsyncReporter and eventhough that code lives outside Brave, it is a
very important factor in latency which should be included.
For example, here's with 1KiB message size (to avoid GC thrash in JMH)
Benchmark                                           Mode  Cnt    Score    Error  Units
EndToEndBenchmarks.server_get                       avgt   15  159.013 ±  9.592  us/op
EndToEndBenchmarks.traced128Server_get              avgt   15  223.974 ± 14.517  us/op
EndToEndBenchmarks.traced128Server_get_resumeTrace  avgt   15  226.344 ±  9.706  us/op
EndToEndBenchmarks.tracedServer_get                 avgt   15  220.218 ±  6.028  us/op
EndToEndBenchmarks.tracedServer_get_resumeTrace     avgt   15  218.240 ±  2.942  us/op
EndToEndBenchmarks.tracedawsServer_get              avgt   15  218.895 ±  6.939  us/op
EndToEndBenchmarks.tracedawsServer_get_resumeTrace  avgt   15  219.882 ± 12.913  us/op
EndToEndBenchmarks.unsampledServer_get              avgt   15  166.991 ±  2.342  us/op

Overhead without the async reporter is usually up to 30us. The above
shows significant opportunity to reduce overhead there. FWIW, it is
mainly due to encoding spans on the calling thread. There are other
ways to accomplish the goal of memory-bounding now that the data
structures are simpler (in zipkin v2).

https://github.com/openzipkin/zipkin-reporter-java/issues/81 for the follow-up work

repo: openzipkin/brave


text:
[WIP] add multi-arch support to Travis CI

Work in progress.
A test run of Travis CI, illustrating the multi-arch support there.

Thanks for trying with this - currently our docker build pipeline is a bit complicated, we build images on Quay and sync to Docker Hub using Travis. So changing the arch here won't actually affect the images that are built.
We are currently migrating our build from Quay to be directly on Docker Hub, and I think after that we can look into trying with multiple architectures. The build itself would be very simple since Zipkin is pure Java, we'd just need to copy into a different base image and that could happen even on normal amd64 hosts.

authors: anuraaga vielmetti

repo: openzipkin/docker-zipkin


text:
release.sh: Retry docker push to dockerhub

Pushing to dockerhub occasionally fails due to various intermittent problems (see https://travis-ci.org/openzipkin/docker-zipkin/builds/87597647 for an example). This change automates the retry we used to do manually.

Just logged this: https://github.com/docker/docker/issues/17506
Maybe we can delete this one day :)
In the mean time :shipit:

authors: abesto adriancole


text:
UI doesn't resolve durations properly

Hi!
For some reason a request repeated to the same endpoint twice for the same trace, makes the UI render the durations improperly.
Check out this section (2 completely different requests, having same traceid, shot to the same endpoint):
{
    "traceId": "caa9948bef618715",
    "name": "http:/present/order",
    "id": "c7d6f8f1f0be2d7f",
    "parentId": "c47bbb8a2ea2334a",
    "timestamp": 1465236501361000,
    "duration": 28000,
    "annotations": [],
    "binaryAnnotations": [
      {
        "key": "http.status_code",
        "value": "500",
        "endpoint": {
          "serviceName": "presenting",
          "ipv4": "10.69.252.94",
          "port": 9991
        }
      },
      {
        "key": "lc",
        "value": "unknown",
        "endpoint": {
          "serviceName": "presenting",
          "ipv4": "10.69.252.94",
          "port": 9991
        }
      }
    ]
  },
  {
    "traceId": "caa9948bef618715",
    "name": "http:/present/order",
    "id": "23ca77c6a15733bd",
    "parentId": "1c57dfdea6d8f7e8",
    "timestamp": 1465236636507000,
    "duration": 23000,
    "annotations": [],
    "binaryAnnotations": [
      {
        "key": "http.status_code",
        "value": "500",
        "endpoint": {
          "serviceName": "presenting",
          "ipv4": "10.69.252.94",
          "port": 9991
        }
      },
      {
        "key": "lc",
        "value": "unknown",
        "endpoint": {
          "serviceName": "presenting",
          "ipv4": "10.69.252.94",
          "port": 9991
        }
      }
    ]
  }

JSON:
bad_duration.txt
SCREEN:

I'm not quite sure I get what the error is... what would the expected output look like?

Twice the graph. As you can see the last couple of spans don't have a
duration set. For some spans the duration of negative whereas in the json
it's not.

So it should look more or less like this:

In the initial picture you can see 16 spans. Actually those are 2 x 8 spans. However the second 8 spans have their durations completely ignored.

And when I click at one of the spans (I've clicked it on another computer so it won't have much to do with the attached JSON) I get such entries:

It seems that the issue was with the initial sent span. Let's close it for now

authors: eirslett marcingrzejszczak

repo: openzipkin/zipkin


text:
hessian protocol not support？

How to integrate Hession protocols in my projects？

ps please update this issue while you progress!

but actually this issue should be in brave, not zipkin

@lukylent can you please open an issue in Brave instead? https://github.com/openzipkin/brave/issues

authors: adriancole lukylent shakuzen


text:
Can't build on/for alpine linux on v1.1.0

Trying to build a ziti-tunneler for alpine linux and getting an issue.
env:
Linux buildkitsandbox 5.15.0-94-generic #104-Ubuntu SMP Tue Jan 9 15:25:40 UTC 2024 x86_64 GNU/Linux
PRETTY_NAME="Alpine Linux v3.20"
ninja version: 1.9
gcc version 13.3.0 (GCC)

Build instructions for cmake:
git --git-dir=/ziti-tunnel-sdk-c/.git --work-tree=/ziti-tunnel-sdk-c checkout v1.1.0

cmake -DDISABLE_LIBSYSTEMD_FEATURE=ON -DCMAKE_C_COMPILER=/toolchain/bin/gcc -DCMAKE_CXX_COMPILER=/toolchain/bin/g++ -DCMAKE_MAKE_PROGRAM=/usr/bin/ninja -DCMAKE_BUILD_TYPE=Release --preset ci-linux-x64 -S /ziti-tunnel-sdk-c -B /ziti-tunnel-sdk-c/build

cmake --build /ziti-tunnel-sdk-c/build # errors here

Part of the cmake --build log that causes an issue:
[153/176] Building C object _deps/tlsuv-build/CMakeFiles/tlsuv.dir/Debug/src/compression.c.o
1.941 ninja: job failed: /toolchain/bin/gcc -DSODIUM_STATIC -DZITI_BRANCH=HEAD -DZITI_COMMIT=g9fa5162 -DZITI_LOG_MODULE=\"ziti-sdk\" -DZITI_VERSION=1.0.7 -DCMAKE_INTDIR=\"Debug\" -I/ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-src/library/../includes -I/ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-src/library/../inc_internal -I/ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-src/library/proto -I/ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-build/include -I/ziti-tunnel-sdk-c/build/_deps/tlsuv-src/src -I/ziti-tunnel-sdk-c/build/_deps/tlsuv-src/include -I/ziti-tunnel-sdk-c/build/_deps/tlsuv-src/deps/uv_link_t/include -isystem /ziti-tunnel-sdk-c/build/vcpkg_installed/x64-linux/include -isystem /ziti-tunnel-sdk-c/build/vcpkg_installed/x64-linux/include/json-c -isystem /ziti-tunnel-sdk-c/build/vcpkg_installed/x64-linux/lib/pkgconfig/../../include -g -std=gnu11 -fPIC -g -pthread -MD -MT _deps/ziti-sdk-c-build/library/CMakeFiles/ziti.dir/Debug/internal_model.c.o -MF _deps/ziti-sdk-c-build/library/CMakeFiles/ziti.dir/Debug/internal_model.c.o.d -o _deps/ziti-sdk-c-build/library/CMakeFiles/ziti.dir/Debug/internal_model.c.o -c /ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-src/library/internal_model.c
1.941 In file included from /ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-src/library/../inc_internal/internal_model.h:19,
1.941                  from /ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-src/library/internal_model.c:16:
1.941 /ziti-tunnel-sdk-c/build/_deps/ziti-sdk-c-src/library/../inc_internal/internal_model.h:52:4: error: field 'expires' has incomplete type
1.941    52 | XX(expires, timestamp, none, expiresAt, __VA_ARGS__) \

Out of ideas atm on how to remedy this problem.
Any push to the direction would be helpful!

Hi and thanks for the report. Some changes to one of our dependencies happened to rely on struct timeval being defined. I made the relevant fix in the dependency project. Once that change is merged and released I'll make another PR in this project to use the updated dependency. Stand by.

Wow, thats fast.
Going to check the build in a few hours against v1.1.2.
Thanks!!

Hooray! It works as expected. Build is working fine now.
Closing the issue!

authors: nenkoru scareything

repo: openziti/ziti-tunnel-sdk-c


text:
(feature): Add a minimal client library for fetching catalog contents

Description

Adds a minimal client library to facilitate fetching a Catalogs contents from the catalogd HTTP server
Adds unit tests for this minimal client library

Motivation

Resolves #117

If the intent of the library is to be used externally what do you think of creating a sub module for it?

authors: everettraven fgiloux

repo: operator-framework/catalogd


text:
upstream-community-operators tackle-operator (0.0.2)

Signed-off-by: mrizzi mrizzi@redhat.com
Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[x] Did you create a ci.yaml file according to the update instructions?
[x] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[x] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Submit operators to both upstream-community-operators and community-operators at once
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/merge possible

authors: framework-automation mrizzi

repo: operator-framework/community-operators


text:
Introduce the joelanford/kuberpak provisioner

Migrate the github.com/joelanford/kuberpak provisioner which is responsible for provisioning the "registry+v1" OLM bundle format.
Introduce the ./provisioner/kuberpak directory and copy over Joe's implementation almost 1:1. I separated out the individual changes I needed to make to the kuberpak repository so we can have a clear audit of what we needed to change over time.

1.64554769110278e+09	ERROR	controller-runtime.test-env	unable to start the controlplane	{"tries": 1, "error": "fork/exec /usr/local/kubebuilder/bin/etcd: no such file or directory"}
sigs.k8s.io/controller-runtime/pkg/envtest.(*Environment).startControlPlane
	/home/runner/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.11.0/pkg/envtest/server.go:330
sigs.k8s.io/controller-runtime/pkg/envtest.(*Environment).Start

I need to fix the envtest installation as the c-r dependency was bumped in this PR.
/hold

repo: operator-framework/rukpak


text:
feat(frontend): any as spdk params for nvme controller

This is needed if any other bridge needs to pass its own parameters as a part of nvmf_subsystem_add_listener call.
For example https://github.com/opiproject/opi-intel-bridge/pull/398

I want to avoid use of any let's discuss

We already use any with virtio-blk transport, and I want to be consistent. However, let's consider alternatives:

return map[string]any instead of NvmfSubsystemAddListenerParams

embed map[string]any into NvmfSubsystemAddListenerParams is not supported by the language

embed any into struct. Does not work. We do not get a flatten json structure with an interface.
move rpc call into transport instead of returning params struct.

What is your suggestions/ideas?

I remember we already discussed option to move rpc call into transport instead of returning params struct...
WDYT ?

I remember we already discussed option to move rpc call into transport instead of returning params struct...
WDYT ?

It is the third option in my list above 😄

move rpc call into transport instead of returning params struct.

In general, I agree that we can proceed that way

Closing. The calls to spdk will be moved into the transports

authors: artek-koltun glimchb

repo: opiproject/opi-spdk-bridge


text:
[Bug] Wifi is broken in 20.1

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues and I'm convinced that mine is new.
Describe the bug
When assigning a f.e. run0_wlan1 to the wan interface, the interface type switches to cable, so your not able to to change the wifi settings again until you completely remove the wan interface, and reassign it.
WPA Settings seems to be ignored:
When creating a wifi ap interface, with enabled WPA(2) settings, the provided network is still 'Open' further its only possible to join open networks as a client.
Used wlan: Ralink USB Wlan-stick with  RT5370 chipset (works well when configuring in commandline)
To Reproduce WAN interface problems
Steps to reproduce the behavior:

Attach wlan stick and create a wlan device under "Interfaces -> Wireless -> Devices"
Assign the created wlan device to wan, and enter wlan settings
hit save
See error

Expected behavior
Wan interface connects to wifi, and settings can be changed later
Screenshots
(will upload later today)
Relevant log files
No logs found
To Reproduce missing WPA settings
Steps to reproduce the behavior:

Attach wlan stick and create a wlan device under "Interfaces -> Wireless -> Devices"
Assign the created wlan device to opt1
change wlan settings to ap
enable wpa2 and enter a passphrase
hit save & apply
See error

Expected behavior
There should be a new wifi which is wpa2 secured
Screenshots
(will upload later today)
Environment
Software version used and hardware type if relevant.
e.g.:
OPNsense 20.1 (armv7, OpenSSL).
ARM Cortex-A9 r4p1
&
OPNsense 20.1 (aarch64, OpenSSL).
ARM Cortex-A53
Ralink WiFi Dongle RT5370 Chipsatz
All the best,
René

This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository,
please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

authors: AdSchellevis DarkSunOne

repo: opnsense/core


text:
[net/freeradius] Add attribute enabled check in config files

Fix for issue #878

I got this when installing your repo:
Sep 30 07:51:57 OPNsense configd.py: [8c031ed8-fc46-4cd0-94b5-f712b6490956] Inline action failed with OPNsense/Freeradius OPNsense/Freeradius/dictionary 'user_list' is undefined at Traceback (most recent call last):   File "/usr/local/opnsense/service/modules/processhandler.py", line 509, in execute     return ph_inline_actions.execute(self, inline_act_parameters)   File "/usr/local/opnsense/service/modules/ph_inline_actions.py", line 51, in execute     filenames = tmpl.generate(parameters)   File "/usr/local/opnsense/service/modules/template.py", line 332, in generate     raise render_exception Exception: OPNsense/Freeradius OPNsense/Freeradius/dictionary 'user_list' is undefined
Please check on your side ...

@mimugmail Thanks, fixed

@fichtner this can be merged now ..

Merged, thanks!

authors: fichtner mimugmail reza-ebrahimi

repo: opnsense/plugins


text:
Add info to the wiki about how to find the commit which caused an issue.

@prafulbbandre has written a document called "Finding Bad Commits with the help of Git Blame and Git Bisect". This is very useful info that we can provide contributors, and we should probably add it to the wiki as a guide.
We should do the following:

[ ] Transfer the content to the Coding Guidelines > Debugging section in the wiki sidebar, in a new page called "How to find the commit which introduced a bug".
[ ] Link to this content from our general bug-fixing issue template.

Hey Sean,
I plan to add a line here linking the issue to the Google Doc you mentioned. Additionally, I wanted to ask if you would like the document to be converted into a separate page following the wiki guidelines? I am a bit confused about what you mean by "Link to this content from our general bug-fixing issue template."

@seanlip can I work on this or is @prafulbbandre working on it?

@satvshr You can work on this if you like. I'm assigning you, when can you make a PR?

Sorry for not mentioning that, is the 2nd of Jan alright?

@seanlip Sorry for not mentioning that, is the 2nd of Jan alright?

Never mind I am already finished with the article, could you please tell me how I can add a link to the general bug-fixing issue template as mentioned in checkpoint 2?

@satvshr You'll need to edit this file that I pointed you to earlier: https://github.com/oppia/oppia/blob/develop/.github/ISSUE_TEMPLATE/1_bug_report_form.yml (the placeholder text in the last field).
This involves making a PR to the oppia/oppia repository. So, completing this issue fully would entail two PRs, one to this repo and one to oppia/oppia.

@satvshr You'll need to edit this file that I pointed you to earlier: https://github.com/oppia/oppia/blob/develop/.github/ISSUE_TEMPLATE/1_bug_report_form.yml (the placeholder text in the last field).
This involves making a PR to the oppia/oppia repository. So, completing this issue fully would entail two PRs, one to this repo and one to oppia/oppia.

I can only do that once my pr is merged and a link to the article is created, so I will wait until that's done.

@satvshr Yes and perhaps drop any stuff in the note there that's redundant with your article.

@satvshr Yes and perhaps drop any stuff in the note there that's redundant with your article.
How is this @seanlip?
Before addressing the bug, follow these steps: Use git bisect to identify the PR causing the issue (refer to https://github.com/oppia/oppia/wiki/How-to-find-the-commit-which-introduced-a-bug). If the bug occurred before commit c7db0fe, use the Python setup for git bisect (only back to commit 9a334e9. For commits beyond that, use the Docker setup. If you identify the PR, comment on the issue with a link to it. If it happened before commit 9a334e9, mention that. Consider using git blame along with git bisect for more detailed insights during the investigation.

I'd just say:
Before addressing the bug, please identify which PR caused the issue (you can follow the steps [here](https://github.com/oppia/oppia/wiki/How-to-find-the-commit-which-introduced-a-bug)). If you identify the PR, comment on the issue with a link to it. If not, mention the commit hash of the oldest commit you looked at (and the month and year it was made in).

I'd just say:
Before addressing the bug, please identify which PR caused the issue (you can follow the steps [here](https://github.com/oppia/oppia/wiki/How-to-find-the-commit-which-introduced-a-bug)). If you identify the PR, comment on the issue with a link to it. If not, mention the commit hash of the oldest commit you saw the bug on (and the month and year it was made in).

The template being used now makes no sense but I felt there was a reason for that, this sounds way better and simpler. Thanks!

@satvshr I was trying to find your new page just now but I had trouble doing that, and then realized it's not in the wiki sidebar. Could you please add it there too, with all the other debugging wiki pages? Thanks.

@satvshr This looks like it's fully addressed. Thanks! I'm closing it as completed :)

authors: satvshr seanlip

repo: oppia/oppia-web-developer-docs


text:
Update User feedback reporting UI on Web project description

These are the changes to the User feedback reporting UI on Web project.

@SanjaySajuJacob could you update your branch with the new changes?

authors: SanjaySajuJacob aasiffaizal


text:
Windows task wont delete if delayed

If you have a scheduled task, and you attempt to delete it with ':delayed' it will never be deleted.
Example
  windows_task 'foobar' do
    user "example.com\\bob"
    command  "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -noprofile -noexit -executionpolicy Bypass -File c:\foo.ps1 '"
    action [:create,:run]
    notifies :end, 'windows_task[foobar]', :delayed  #TODO This strangely never gets deleted
    notifies :delete, 'windows_task[foobar]', :delayed #TODO This strangely never gets deleted
    run_level :highest
    force true
  end

Same behavior happens if you send the 'notify' from another resource.
  file 'c:\foo' do
    action :create
	notifies :end, 'windows_task[foobar]', :delayed
    notifies :delete, 'windows_task[foobar]', :delayed
  end

Work around,
Dont' specify :delayed, and make a resource at the end of the cookbook that sends the notify.
Windows 2012 R2
Chef 12.4.1

Better workaround is to make the delete as part of the action.
    action [:create,:run,:delete]

Hi, my response is late but I hope this helps someone out.
If the windows_task resource task_name attribute is not specified then the task_name is defaulted to the resource name. Therefore in your example windows_task 'foobar' is the name of the resource and also the task_name.
In load_current_resource the task_name is changed (see below)
pathed_task_name = @new_resource.task_name[0, 1] == '\\' ? @new_resource.task_name : @new_resource.task_name.prepend('\\')
The @new_resource.task_name.prepend('\') is adding two slashes to the @resource.task_name. Normally in Ruby when the underlying object is changed a method is marked with a bang to signify warning, it's not obvious but prepend appears to change the underlying object.
When the windows_task LWRP has finished executing if there were any actions the Chef::Runner will try and locate the resource in the resource queue to establish whether it should also action any notifications. My belief is that the name of the resource has changed and now includes two backslashes (\), the resource cannot be found in the resource queue, which is why the notifications are failing.
Can you try your code specifying the task_name and making it different from the resource name, e.g
windows_task 'install_foobar' do     task_name 'foobar'     user "example.com\\bob"     command  "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -noprofile -noexit -executionpolicy Bypass -File c:\foo.ps1 '"     action [:create,:run]     notifies :end, 'windows_task[install_foobar]', :delayed     notifies :delete, 'windows_task[install_foobar]', :delayed     run_level :highest     force true   end

Thanks for the response. I see now that the reason this happens is because the resource name is not the same as the task name.
So basically the following will fail to send notifications
windows_task 'chef ad-join' do
  user 'SYSTEM'
  command 'chef-client'
  notifies :create, 'file[c:/notifytest.txt]', :immediately #Not working
  action :create
end

Where as this will work properly
windows_task 'chef ad-join' do
  task_name 'foobar'
  user 'SYSTEM'
  command 'chef-client'
  notifies :create, 'file[c:/notifytest.txt]', :immediately #Not working
  action :create
end

I still think a change needs to be made to the cookbook since this is an easy trap to fall into (It bit me twice). The task_name parameter needs to be made mandatory.

Thanks for confirming. It's a bug in the windows_taks resource, the resource name gets changed in load_current_resource hence why Chef::Runner can't locate resources in the notification queue. I can't make any fixes at the moment as we don't have a CLA.
The error is to do with the use of the prepend method, this changes the underlying object, e.g
x = 'hello'
y = x.prepend('\')
x #=> \hello
y #=> \hello

If i'm understanding correctly, String.prepend in ruby creates another object. So the solution might be to change this line:
 pathed_task_name = @new_resource.task_name[0, 1] == '\\' ? @new_resource.task_name : @new_resource.task_name.prepend('\\')

to something like this?
if @new_resource.task_name[0, 1] == '\\' do
  @new_resource.task_name
else
  new_name = "\\#{@new_resource.task_name}"
  @new_resource.task_name = new_name
end

This is just a stab in the dark. I'll need to do more testing. I do have an CLA so if this works, i'll open a pull request.

wow. You'd think prepend should be prepend!.

:+1:  Manually verified against edee5a7 confirmed working

authors: chrisgit mwrock spuder

repo: opscode-cookbooks/windows


text:
Image upload feature

There was a problem with the image fields, I made some updates to use the image fields.

Hi @ahmetbedir!
Thanks for the PR! It's greatly appreciated. :) I only have some things to bring out - this currently hardcodes the public disk for the files.
I think we should use the corresponding Field's configured disk.
I think the easiest way to do is is to:

Find the Field the file corresponds to
Use a PHP "hack" to make storeFile un-protected and accessible (or add a Macro to Field that will proxy the method)
Call the field's ->storeFile($request, $requestAttribute) method that will handle storing the file
The storeFile method will return the value we need to store

I can try to implement this myself. :)

Hey! Did you test this?

Hey! Did you test this?

I tested it again. Uploading and previewing images does not appear to be a problem either. But the image deletion is not working correctly now. The DELETE request results in a 404 because Nova cannot find the relevant field. Consider creating a unique attribute name Example: "user_details---avatar---0" when there is no field with that name, the result will be 404. We probably won't be solving this with the existing Image component. Because we will need to override the following findFieldByAttribute method in the FieldDestroyController@handle method. You can see the part where it gives the 404 error in the code block below. I will deal with this issue at a later date.
public function handle(NovaRequest $request)
{
    $resource = $request->findResourceOrFail();

    $resource->authorizeToUpdate($request);

    $field = $resource->updateFields($request)
                ->whereInstanceOf(Downloadable::class)
                ->findFieldByAttribute($request->field, function () {
                    abort(404);
                });

    DeleteField::forRequest(
        $request, $field, $resource->resource
    )->save();

    Nova::actionEvent()->forResourceUpdate(
        $request->user(), $resource->resource
    )->save();
}

authors: Tarpsvo ahmetbedir

repo: optimistdigital/nova-simple-repeatable


text:
move submodules from subdir 'tools' to the root of the repo

Currently, there is a single submodule out of subdir tools. My proposal in this PR is to move the tool submodules out from the subdir to the root of the repo. At the same time, tools-setup.txt is renamed to setup.sh, and the content is modified for users to execute it directly. The README is updated accordingly.

ping @coolbreeze413

repo: optimuslogic/pygmy-dev


text:
fix: enable management plugin for OCI Bastion service session to work

Signed-off-by: Srinivasa Nikhil Kota srinivasa.nikhil.kota@oracle.com

Thanks for the fix. Can you please sign your commit before we can merge?

Hey, The commit is already signed-off right. Is there something else that needs to be done ?


text:
chart not find  checkDBLockStatus.sh

location: docker-images/blob/master/OracleDatabase/SingleInstance/helm-charts/oracle-db/templates/deployment.yaml
checkDBLockStatus.sh not find

deployment.yaml:
 readinessProbe:
        exec:
          command: [ "/bin/sh", "-c", "$ORACLE_BASE/checkDBLockStatus.sh" ]
        initialDelaySeconds: 20
        periodSeconds: 40
        timeoutSeconds: 20

@pandihao The oracle DB image from container-registry.oracle.com should have this script included

@yunus-qureshi I thought the Oracle DB image on Container Registry now used the Dockerfiles in this repo. Is that not the case? If not, we need that to be called out far more explicitly.

authors: Djelibeybi pandihao yunus-qureshi

repo: oracle/docker-images


text:
Fault Tolerance 3.0

[ ] Fault Tolerance 3.0 support
[ ] Documentation
[ ] Samples
[ ] Guides

MicroProfile 4.0 support epic: #2636

Changes in FT 3.0:

[ ] Lifecycle of circuit breakers
[ ] Changes related to Jakarta EE dependencies
[ ] @Asynchronous test related to security/naming context
[ ] Changes to metrics and scopes

Changes in FT 3.0:

[ ] Lifecycle of circuit breakers
[ ] Changes related to Jakarta EE dependencies
[ ] @Asynchronous test related to security/naming context
[ ] Changes to metrics and scopes

PR #2680

PR #2680

repo: oracle/helidon


text:
Helidon jar doesn't contain Automatic-Module-Name in MANIFEST.MF

Environment Details

Helidon Version: 2.5.1
Helidon SE
JDK version: JDK17
OS: N/A
Docker version (if applicable): N/A

Problem Description
Within Helidon jar like such:
https://repo1.maven.org/maven2/io/helidon/integrations/graal/helidon-graal-native-image-extension/2.5.1/helidon-graal-native-image-extension-2.5.1.jar
there is no presence of Automatic-Module-Name  property/attribute within MANIFEST.MF file. Current file is like such:
Manifest-Version: 1.0
Created-By: Apache Maven 3.6.3
Built-By: jenkins
Build-Jdk: 11.0.12
Implementation-Title: Helidon Integrations Graal Native Image Extension
Implementation-Version: 2.5.1
Implementation-Vendor-Id: io.helidon.integrations.graal
Implementation-Vendor: Oracle Corporation
Implementation-URL: https://helidon.io
Scm-Revision: df66d863cd0274bd899120d2d4e81aabaef64612

Such leads to an exception
Caused by: java.lang.IllegalArgumentException: helidon.graal.native.image.extension: Invalid module name: 'native' is not a Java identifier

when used within Java modules.
Exception in this case is due to this list of Keywords:
https://docs.oracle.com/javase/specs/jls/se7/html/jls-3.html#jls-3.9
where native  is one of them.
Temporary workaround: rename file to let say helidon-graal-native1-image-extension-2.5.1.jar
Long term fix: introduce Automatic-Module-Name attribute into MANIFEST.MF
Steps to reproduce

Download https://repo1.maven.org/maven2/io/helidon/integrations/graal/helidon-graal-native-image-extension/2.5.1/helidon-graal-native-image-extension-2.5.1.jar into some folder
Navigate to that folder and invoke such command:

java -p . --list-modules

You should see such exception:

Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for ./helidon-graal-native-image-extension-2.5.1.jar
Caused by: java.lang.IllegalArgumentException: helidon.graal.native.image.extension: Invalid module name: 'native' is not a Java identifier

Initial explanation could be quite simple - some Maven dependency graph (which in most cases taken as granted before digging into side effects) brings such dependency into same area, which later used for java invocation. And while it may not be even used/needed for java runtime in case of invocation via produced Jar and not  native image path later - just presence of such jar impacts Java modules resolution.
Of course you may argue that then some Maven profiles/etc. conditional logic should be in place to mitigate that. But if such jar would be pretending good Java module citizen - that would save at least time skipping it automatically even if it present in some folder and not used.


text:
Added get_lldp_neighbors_detail

Added lldp neighbors detail (usefull for netbox lookups)

thnaks for the nice PR, i'm merging it

authors: ArthurHlt zarya

repo: orange-cloudfoundry/napalm-cumulus


text:
Remove and seperate LP

LPをRepositoryから削除します。

@gaishimo
LGTM

authors: gaishimo gavinzhou


text:
Implement Delete in the oci store content implementation

Signed-off-by: viovanov vlad@aserto.com

Thanks @shizhMSFT!
Do you know when this will make it into a v1 release?

Thanks @shizhMSFT! Do you know when this will make it into a v1 release?

I think it will happen very soon. We just need a ceremony :D

anything we can do to help for the ceremony @shizhMSFT?
maybe send some cake over? :)

authors: shizhMSFT viovanov

repo: oras-project/oras-go


text:
Add support for “Update a database” endpoint

Notion added the PATCH /database/{database_id} endpoint in Aug. 2021.
Changelog entry: https://developers.notion.com/changelog/update-existing-databases-with-patch-v1databases
API Documentation: https://developers.notion.com/reference/update-a-database

It was already there, but undocumented—added docs in 0bc36cb

repo: orbit-love/notion-ruby-client


text:
source.js:17 Uncaught Error: already resolved

source.js:17 Uncaught Error: already resolved
at Function.i.resolve (source.js:17)
at index.js:10
at reduce.js:10
at drain.js:20
at async-map.js:28
at map.js:19
at async-map.js:28
at f (index.js:84)
at c (index.js:68)
at s (index.js:29)
at i (async-map.js:27)
at map.js:11
at i (async-map.js:27)
at i (drain.js:16)
at drain.js:29
at async-map.js:39
when call saveSnapshot() ,got the above error

@mccoysc Did you figure out what happened? :)

authors: RichardLitt mccoysc

repo: orbitdb/orbit-db-store


text:
Всем привет Я отправил на обмен 340 хрп.денег нету хрп.нету.

Всем привет Я отправил на обмен 340 хрп.денег нету хрп.нету.

GD5AZ7Y4LP7Y34O5UU5CJBJLPS4RYMW2JJTXQHEPEVOOPUFHOA75H6Y7

GD5AZ7Y4LP7Y34O5UU5CJBJLPS4RYMW2JJTXQHEPEVOOPUFHOA75H6Y7

repo: orbitlens/stellar-expert-explorer


text:
Dynamic memory allocation (releasing after use)

I have a very big docker project running.
When I stop working on it, I usually just stop the containers in OrbStack to free up memory (16g pain).
So with Version 0.11.3 (1648) stopping the (all) containers does not free up memory in the "Virtual Machine Service". When I stop the process in Activity Monitor and  re-start the container runtime within OrbStack, the VMS is back at 575m.
I'm not sure if it was like this all the time since I have always just stopped the containers without explicitly checking the memory usage, but it feels like this has been freed up in earlier versions because I never ran into memory issues with stopped containers - but I might just not have been noticing it before.
Steps to reproduce the behavior:

Go to Activity Montor and look up "Virtual Machine Service". Should be quite high depending on the running containers
Stop all running containers
Go to Activity Montor and look up "Virtual Machine Service". Should still be ~ equal to first check
Stop the "Virtual Machine Service" process
Open OrbStack and Click the "Start" Button under "Containers"
Go to Activity Montor and look up "Virtual Machine Service". Should still be way less

Expected behavior
Stopping the containers should free up memory in VMS
Logs
vmgr.log
Info report
OrbStack info:
  Version: 0.11.3 (110300)
  Commit: f953c63b1cbfe3c2988c97e0b42680600cf0e060 (v0.11.3)

System info:
  macOS: 13.3.1 (22E261)
  CPU: arm64, 10 cores
  CPU model: Apple M1 Pro

It's always been this way. Memory is used on demand, but once it's been used, it can't be freed without restarting OrbStack.
Dynamic memory allocation has always been a planned feature, but there's a macOS bug that makes it impossible to do in a production-ready way. More details + prototype: https://twitter.com/kdrag0n/status/1645645284721184768
I chatted with Apple last week and they're working on it, but there's still no fix as of now (even on macOS Sonoma Developer Beta 1).
My suggestions for now:

Try lowering the memory limit. We have an advanced memory management setup that allows most workloads to run with less memory than usual.
If the memory usage isn't causing performance issues for you, then don't worry about it. macOS has transparent memory compression that handles pressure quite well.

@kdrag0n Is there an update to Apple ticket FB11996689 regarding this?

No news from Apple.

@kdrag0n Any update to Apple ticket FB11996689 wrt this?

repo: orbstack/orbstack


text:
Restrict write to AI For Orcas CosmosDB

https://aifororcasdetections.azurewebsites.net/index.html

Code deployed and functionality verified.

authors: micowan prakruti

repo: orcasound/aifororcas-livesystem


text:
Edit and link to the Orcasound vessel research portfolio

This is optional, but another way to get exposure beyond Github could be to revise this (dated) page on Orcasound's Wordpress site -- https://www.orcasound.net/portfolio/salish-sea-vessel-research/
We can create an account for you if you'd like to update the page.

@tsuize Do you want me to set up a Wordpress account so you can help me edit the vessel-research page?
Or would you rather I draft a section and ask you for feedback on it?

repo: orcasound/orca-eye-aye


text:
[WIP] Improv/react router

Description
Apply react-router to replace window.orchest.loadView.
With current loadView mechanism, we have following limitations:

if a sub component has a reload-current-page behavior, we cannot extract this sub component (i.e. circular dependency, parent imports child and child imports parent, because child needs to reload parent using loadView). This is blocking us from breaking big components to small ones.
unable to have an overview of all the pages in the app and their corresponding route. This indirectly leads to an inconsistent usage of querystring and props.
rely fully on queryArgs to initialize the component, while queryArgs is not always consistent amongst all components.

Usually, we would like to refactor in small parts, but two routing mechanisms co-exist in one app will more-likely introduce more bugs and unexpected behaviors. So, this PR will inevitably be a big bang.
Major changes:

Make use of react-router-dom library as much as possible and reduce the amount of custom implementation regarding routing
Make paths more semantic and configurable (see routingConfig.tx), so we don't create path based on component names.
Make use of the route parameters to replace queryArgs. Most components are self-content by getting important data from the path (e.g. projectId). Thus, we could reduce the need to call BE in order to get data.
Create one-off useCustomRoute hook to collect all route parameters, that is, we no longer need to check the parent, nor the caller of loadView to figure out what's been passed in.

To-Do:

[ ]  regression testing
[ ] update Cypress tests

Checklist

[ ] I have manually tested the application to make sure the changes don’t cause any downstream issues, which includes making sure ./orchest status --ext is not reporting failures when Orchest is running.

Great cleanup!

while queryArgs is not always consistent amongst all components.

Do you have an example of this kind of inconsistency?

I give a second look and realize why I had this impression (for the record, the usage of queryArgs is consistent, my apologies) 🙂
props.project_uuid and props.queryArgs.project_uuid both appear in the codebase, and it takes some time to understand that props.queryArgs is passed from loadView and should only be used in "view" components. However, this pattern is rather hidden and it's hard to hold when more contributors join forces.

authors: iannbing ricklamers

repo: orchest/orchest


text:
Баг у абстракции скрина

Describe the bug
Неправильный мердж массива. Попадает ключ, который не должен быть. Из-за этого рушится DI у экшена кнопки.
Например если вызывать дебаггер у экшена кнопки, получим такую картину:
dd($model); // В данном случае, $model - это просто первый аргумент метода. Вместо модели, получим значение из ключа q, т.е. URI
To Reproduce
Шаги:

Создать скрин, кнопку с экшеном.
Попробовать нажать на кнопку.

Expected behavior
Ожидалось мерджа без лишних параметров в абстрактном классе Screen, чтобы подхватилась модель в экшене.
На момент написания ишью, не грузились скриншоты.
Подробности в телеграм: @tyominomi
Desktop (please complete the following information):

OS: Manjaro Linux

Server (please complete the following information):

Platfrom Version: 10.23.0
Laravel Version: 8.63.0
PHP Version:  8.0.11

Additional context
В конечном итоге эта проблема решается очень легко. Но изза того что большинство методов Screen приватные, я не могу корректно наследовать методы, остается просто копировать, что не имеет смысла.

@tabuna Вот скриншот примерного решения.
https://i.imgur.com/rAd2xM3.png

Please submit your issues in English.

authors: astersnake windx-foobar

repo: orchidsoftware/platform


text:
Update catalyst and dont error if taxjar not configured

Taxjar would throw error if not configured even if it wasn't being used

Hold on merging this in. Need to update to accomodate for another PR that was merged in and am also seeing some issues with Catalyst that we'll need to remedy before merging

repo: ordercloud-api/headstart


text:
Use as_array at step 21

step 21で as_array が使われていたところが、こちらでは使われていなかったので書籍の説明と合うように書き換えました。

ありがとうございます！


text:
[FEATURE Load external language files automatically

Referring to this page: https://cookieconsent.orestbida.com/advanced/language-configuration.html
As far as I can see that, languages have to be defined manual.
But, could it be made to load all defined language files automatically by the script - so nobody must "fiddle around" with the init script?
For example: the backend of the sued system generates x language files (in json format of course).
Assume we have en, it, de, fr
Now the script scan this subfolder and add them automatically.
If a new language is added, this new file is also (the translations) added.
Same goes for when a language file is deleted - that language is not valid anymore.
Guess that could be a nice feature.

Unfortunately this is not possible since javascript does not have access to the file system (for security reasons).
The scan must be done server side, afterwards you can pass all the defined languages to the frontend.

Okay, many thx.
If I would be better in javascript, I should know this also - but you can learn every day 👍
But what I have seen (after playing around now with v3), could the path for language files be one lower than the base and init scripts.
Say:

cookieconsent

cookieconsent.css

cookieconsent.umd.js

cookieconsent-ini.js

language

en.json

de.json

Means then, the path is fixed, and the possible configuration errors (mispelling the path) can be avoided.

Why are you asking me for help with my device info and making illegal changes to my personal identifiable information??
1

On Nov 20, 2022, at 11:42 AM, OSWorX @.***> wrote:
Okay, many thx.
If I would be better in javascript, I should know this also - but you can learn every day 👍
But what I have seen (after playing around now with v3), could the path for language files be one lower than the base and init scripts.
Say:
cookieconsent
cookieconsent.css
cookieconsent.umd.js
cookieconsent-ini.js
language
en.json
de.json
Means then, the path is fixed, and the possible configuration errors (mispelling the path) can be avoided.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Mhm, I'm not sure I understand what the issue is.
You can specify any path for the translation files:
en: './en.json'
it: '../assets/translations/it.json'

Okay, I do it through the management console the user will have in his CMS.

authors: Realme121 orestbida osworx

repo: orestbida/cookieconsent


text:
Passive Event Handlers

Could you please explain why do we need passive handlers for 'scroll' and 'mousewheel' ?

'scroll' handlers can't prevent scrolling, so why should we mark them passive ?
'mousewheel' is not used anywhere in react-list, what problem is it solving (noop handler) ?

See #58, #98, #129

authors: DrGor caseywebdev

repo: orgsync/react-list


text:
Logger.v,Logger.d,Logger.json not work?

formatStrategy = PrettyFormatStrategy.newBuilder()
	.showThreadInfo(true)
	.methodOffset(2)
	.methodCount(2)
	.tag("MyTag")
	.build();
Logger.addLogAdapter(new AndroidLogAdapter(formatStrategy));

Logger.v("my v message with MyTag");
Logger.i("my i message with MyTag");
Logger.d("my d message with MyTag");
Logger.w("my log message with my tag");

In the sample project,I add Logger.v , Logger.i  and Logger.d, but just Logger.i and Logger.w work.
version :
'com.orhanobut:logger:2.1.1'

same problem ,I run the sample ,Logger.d  without any log in logcat window

I get same problem , Logger.d without any log in logcat window

Did you init ?
or all do, you can see the lib is right, other lib also include Logger. or maybe device limit,
you can try   simulator or other devices.
发自网易邮箱大师
On 11/22/2017 10:53，zhujunnotifications@github.com wrote：
I get same problem , Logger.d without any log in logcat window
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

same problem,logger.json() does't work

是不是没在 application 的oncreate方法里加   Logger.addLogAdapter(AndroidLogAdapter(PrettyFormatStrategy.newBuilder().tag("xxxxx").build()))

It may be that your mobile phone, such as Huawei mobile phone, prohibits the output of the background log, that is, it does not display Debug, Verbose level log in logcat. You need to enter into the project mode to allow output of these logs.
If you are using a Huawei mobile phone, you can enter ##2846579## in the phone software(or  enter ()()2846579()()= in the Calculator software if you are using a Huawei pad) to enter the project mode, then: Background Settings - Background Debug - LOG Settings - select the "AP Log" checkbox

As others explained, it seems it's related to device. Unfortunately I can't do much about this from Logger point of view. I'd be happy though if someone wants to contribute to README with a FAQ section that explains this issue and potential solution.

This indeed is device problem. On my Xperia device, even using the native Log.d, it doesn't work, only work when I use Log.e or Log.i

Closing this one since can't do anything about this unfortunately.

authors: EiChinn REBOOTERS anderscheow behindeye bzn1120 hacket hueyra orhanobut xinyangmaojian

repo: orhanobut/logger


text:
Catch and log ORecordDuplicatedException

Don't throw an exception if an edge can't be created because one already exists - log it, skip edge creation and continue the import.
I can understand if this should be a setting in the json rather than uniform.

In Vertex Transformer we have:
skipDuplicates:{optional:true,description:'Vertices with duplicate keys are skipped', default:false}

We could apply the same also to edges.

Unfortunately this PR changes the default setting, so I can't merge it. However I've created an issue for that: https://github.com/orientechnologies/orientdb-etl/issues/79

authors: bmcgavin lvca

repo: orientechnologies/orientdb-etl