text:
Cleanup golint warnings for client code

Fixes the following two warnings:
influxdb.go:149:1: exported method Client.Dump should have comment or be
unexported

Adds comment for Client.Dump

influxdb.go:263:1: receiver name rs should be consistent with previous
receiver name r for Results

Changes receiver name from "a" to "r"

Looks good to me.
@corylanou -- is there something about receiver that are not pointers, that they don't have to use the same initial? Please merge if this looks good. @ctrlrsf has signed the CLA.

@ctrlrsf -- what command did you run? Perhaps we can consider adding it to our CI process.

@otoolep that error was just stating that in a previous declaration we used r, and in this receiver, we used a, so it was inconsistent, and they recommended (rightly so) using the same one.
This looks good.  :ship:

Thanks @corylanou

@otoolep I ran golint ./... and cleaned up just the client directory. Running it on the entire project produces 120 warnings. I didn't want to start off with a large intrusive change, so just targeted the client code. I'll review the rest of the warnings and see what other safe fixes can be made.
Sample output:
$ golint ./...
database.go:316:2: can probably use "var tagStrings []string" instead
database.go:1076:6: exported type RetentionPolicies should have comment or be unexported
server.go:326:1: exported method Server.StartSelfMonitoring should have comment or be unexported
server.go:356:4: can probably use "var batch []Point" instead
server.go:410:2: can probably use "var groups []group" instead
server.go:475:2: can probably use "var groups []group" instead
server.go:1367:1: comment on exported method Server.CreateRetentionPolicyIfNotExists should be of the form "CreateRetentionPolicyIfNotExists ..."
server.go:1849:1: exported method Server.DropMeasurement should have comment or be unexported
server.go:2101:10: if block ends with a return statement, so drop this else and outdent its block
server.go:2643:2: can probably use "var rows []*influxql.Row" instead
server.go:2817:11: if block ends with a return statement, so drop this else and outdent its block
server.go:3637:1: exported method Server.StartReportingLoop should have comment or be unexported
tx.go:133:4: can probably use "var mappers []influxql.Mapper" instead
...

authors: corylanou ctrlrsf otoolep

repo: influxdb/influxdb


text:
update admin ui version number

https://github.com/influxdb/influxdb/issues/4101

@toddboom

@rkuchan  I think this is probably fixed on the wrong branch. 0.9.4 is on https://github.com/influxdb/influxdb/tree/0.9.4

source: gharchive/pull-request

authors: beckettsean rkuchan

license: mit

license_type: permissive

license_source: bigquery


text:
Formatting and spelling fixes for CONTRIBUTING.md

Fixing a typo: Trouleshotting -> Troubleshooting.
Removing a trailing space in the file and a misplaced space at the
beginning of a section that causes the markdown to be formatted
incorrectly.

lgtm

authors: jsternberg pauldix


text:
[WIP] snmp plugin

Hello,
This is my first plugin and my first code using go ... So I accept all feedback :)
This plugin handles snmpget and snmpgetbulk.
I will use it to monitoring local applications which expose data using SNMP protocol.
Thanks for your feedback.
TODO:

test
cleaning

Should I copy config format from collectd: https://collectd.org/wiki/index.php/Plugin:SNMP ?

@titilambert probably not good to model it after collectd, I like the configuration of https://github.com/paulstuart/influxsnmp, which uses a file that the user generates via snmptranslate, would that be plausible.

Hello @sparrc !
About MIBs, I added it. I use snmptranslate command, to get translate oids=>name. All translations will be cached at the first run :)
I changed the configuration to format. I think the format is more flexible and simple.

@sparrc How can I relaunch test ? It failed cause download error :/

I kicked a rebuild, do you see a rebuild button in the upper-right from the "Details" link?

@sparrc I'm not seeing anything :/ even logged in... Maybe can't because I'm not developer in telegraf ?
Anyway, Thanks!

@titilambert why did you close this PR?

@sparrc oups ! I will reopen it using an other branch

New PR is here #453

authors: sparrc titilambert

repo: influxdb/telegraf


text:
Event monitor crashes when the RPC node goes away

Crate
relayer

Summary of Bug
This was discovered by the DEX team during load testing and happens on hermes multi path startup.
Trace is:
The application panicked (crashed).
Message: called `Result::unwrap()` on an `Err` value: Error { code: ClientInternalError, message: "Client internal error", data: Some("failed to hear back from WebSocket driver") }
Location: relayer/src/chain/cosmos.rs:378
Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it. Run with RUST_BACKTRACE=full to include source snippets.

Version

Steps to Reproduce

Acceptance Criteria

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Hello, I'm bug informant.
To reproduce this crashe, see

Set up at least 3 chains

Assuming chain-a, chain-b, chain-c,

connect a and b , connect a and c
hermes -c config.toml create channel chain-a chain-b --port-a transfer --port-b transfer -o unordered
hermes -c config.toml create channel chain-a chain-c --port-a transfer --port-b transfer -o unordered

Run Hermes with start-multi.

Exit the chain-c

Then the crashe will be reproduced.

Thank you for the feedback, @nodebreaker0-0.
I would like to know what would be the required behavior in your opinion, if running hermes start-multi and one of the chains crashes. When that chain crashes, then Hermes cannot continue relaying packets for all paths involving that chain. Now I can imagine two options:

The hermes relayer process could exit with an error.
The hermes relayer process could continue operating if there are other paths that can still operate (paths which still have the chains at the two ends alive).

Any thoughts?

As an initial fix, maybe we do 2 without resuming relaying for the affected chain?

I confirm that 2. is much preferred.

In my opinion, number two is appropriate.
It is necessary to separate the rpc connection for each chain independently.
For example
Fundamental Problem Solving

connect a and b , connect a and c

Chain-c is dead

Terminates all relay processes associated with chain-c.

But the relay process of a and b must be alive.

If you think this is very complicated development.
Temporary Measure
Multiple rpc nodes in config.toml are required.
Then, if node 1 is unable to communicate rpc, you can try to connect to node 2 (or up to number 3 and 4).
In conclusion, however, the fundamental problem must be solved.

source: gharchive/issue

repo: informalsystems/ibc-rs

license_source: github-api


text:
Increase max length for port identifier to 128

Following ibc-go spec the default length for port identifier is 2-128
ibc-go/PortIdentifierValidator
Tested using hermes(0.7.3) during cw20-ics20 transfer where port_id was wasm.bostrom14hj2tavq8fpesdwxxcu44rty3hh90vhujrvcmstl4zr3txmfvw9sww4mxt

Closes: #XXX
Description

For contributor use:

[ ] Added a changelog entry, using unclog.
[ ] If applicable: Unit tests written, added test to CI.
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Updated relevant documentation (docs/) and code comments.
[ ] Re-reviewed Files changed in the Github PR explorer.

Thank you for your contribution!
This is an important change we'd like to support in Hermes. We'd like maintain backwards compatibility, however, with chains running on ibc-go version <1.2 (which have port id limited to 64 characters). We'd also like to emit a warning/error when two chains with incompatible port limits try to handshake on a new channel. We plan to do some of these changes in PR #1438, so switching the base branch for your work to the developer branch for that PR, hope that makes sense.

authors: adizere litvintech


text:
Handling NULLs in composite keys

By most relational die-hards, including the designers of PostgreSQL, a composite key like (a, b, NULL) is considered an incomplete key as they interpret NULL as "unknown" rather than as its own value.  They would expect you to use a different, non-NULL value to represent "none", e.g. (a, b, none).
When a composite key has any NULLs in it:

A uniqueness constraint is not enforced on the incomplete key, so you can encounter multiple rows with the "same" incomplete key combination (a, b, NULL).
A foreign key constraint is not enforced on the incomplete references, so you can have arbitrary values like (x, z, NULL) where x and z would not be found in the referenced table no matter which value you were to substitute for the NULL.

I don't think we expect to diverge from SQL or Postgres too much here, so I suggest that when we are producing navigable links via foreign key, we should probably disable the link feature when we encounter incomplete references, i.e. references with one or more NULLs in them. Providing navigation by partial match would probably encourage the wrong understanding of how the ERM works.
In our actual projects, we should probably try to be more disciplined and introduce non-NULL constraints on our keys and references, and introduce different tombstone values to represent "none" rather than "unknown".  But, we still want Chaise to do appropriate things when it encounters less rigorous models...

@jrchudy check whether we have already handled this case?

Isn't the attributegroup api handling it? Whenever one of the columns of composite key is null, it is returning null as the value of foreign key.

A null value cannot participate in a valid key nor foreign key whether
a simple scalar value or as any part of a composite value.  This is a
part of SQL and PostgreSQL semantics, not specific to ERMrest or
Chaise.
The null value represents "unknown" or "incomplete" data and bypasses
the uniqueness constraints of the DB. More than one row could be
present with the same null state, meaning null cannot be used to
identify a row uniquely.

Ermrestjs seems to handle this case already.. Let's open another issue if we find a bug related to this.

authors: RFSH hongsudt karlcz

repo: informatics-isi-edu/chaise


text:
Add pricing support for AWS CloudFormation

AWS Cloud Formation costs: https://aws.amazon.com/cloudformation/pricing/
aws_cloudformation_stack and aws_cloudformation_stack_set are the main resources. For each one, we can use this logic to show the cost components:

If template_body is set AND its "Resources.types" start with AWS::*, Alexa::*, or Custom::* then return IsSkipped:    true, NoPrice: true, as it's a free resource.
Else, show both of these:

"Handler operations", units "operations". Usage file param monthly_handler_operations: 10000 # Monthly number of non-free handler operations (resources outside of the AWS::*, Alexa::*, and Custom::* namespaces).
"Durations above 30s", units "seconds". Usage file param monthly_duration_secs: 0 # Monthly duration of non-free handler operations that go above 30 seconds, in seconds.

As normal, the cost components should show cost-depends-on-usage if the usage file param is not specified.
Free resources:
aws_cloudformation_stack_set_instance
aws_cloudformation_type

@alikhajeh1, Hey, I want to work on it!

@nocquidant, @miyurusankalpa, @guilhermerenew, @danielbayerlein and @RichardDRJ support for costs of CloudFormation used in Terraform projects was released in v0.9.1 today.
If you're interested in seeing Infracost process CloudFormation templates as input, please 👍 this issue

authors: NeverovDS alikhajeh1 hassankhosseini

repo: infracost/infracost


text:
🛑 Academusoft is down

In 2942ec3, Academusoft ($SECRET_ACADEMUSOFT) was down:

HTTP code: 503
Response time: 1285 ms

Resolved: Academusoft is back up in 03414ac.

repo: infraestructuraidt/status

license: MIT


text:
🛑 Academusoft is down

In 71e8640, Academusoft ($SECRET_ACADEMUSOFT) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Academusoft is back up in 3746f16.


text:
Using sg-core as data source results in no nodes in list

When using sg-core the label containing the nodes is host. On legacy Smart Gateway the label is exported_host. Need to move the dashboard to using the new label name for nodes.

https://github.com/infrawatch/dashboards/commit/b1df60060998e2d3a52bb24553a9bc6afcd643f5#diff-b8492f864ad75bfcd2177d9f73df8c17

authors: csibbitt leifmadsen

repo: infrawatch/dashboards


text:
Fix working branch logic in CI

Credit to pleimer https://github.com/infrawatch/service-telemetry-operator/pull/281/commits/87c7ad33acdb7a49e3a97db860b3d6dc6899fb86

recheck

repo: infrawatch/service-telemetry-operator


text:
Update http4s-blaze-client, ... to 0.23.15

About this PR
📦 Updates

org.http4s:http4s-blaze-client
org.http4s:http4s-blaze-server

from 0.21.34 to 0.23.15
📜 GitHub Release Notes
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

💡 Applied Scalafix Migrations

org.http4s:http4s-.*:0.22.0 (created no change)

github:http4s/http4s/v0_22?sha=series/0.22

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.http4s" }
}]

labels: library-update, early-semver-major, semver-spec-minor, version-scheme:early-semver, scalafix-migrations, commit-count:1

Superseded by #1607.

repo: ing-bank/baker


text:
User

Do all work for this task in a branch called issue-02
Create the following:
UserList component
UserView component
UserForm component

7 hours

authors: aareno awjans


text:
Add ci file performance test (#2947)

Pull request opened by the merge tool on behalf of #2947

Merged into branches iso4 in 1bdc74a9ec8d0d3bd997cab0e4b93133c50d2296

repo: inmanta/inmanta-core


text:
Create a notification when a git pull fails during compile (#4047)

Pull request opened by the merge tool on behalf of #4047

Merged into branches iso5 in f7c5b178a10dfea12c14c3b1632984792da87585


text:
Allow product's conf.py to inject version information when building docs (#6339)

Pull request opened by the merge tool on behalf of #6339

Merged into branches iso6 in 2015ac1897f96195dee712b48abf3d501a5f2347


text:
[FIX] fix asyncio tests for python 3.6

The absence of the pytest.mark.asyncio marker was causing async tests to be wrongfully skipped. This PR adds the marker for all async tests.
Part of https://github.com/inmanta/lsm/issues/549

I didn't manage to run the tests locally and I don't know what to make of the Jenkins error.

Merged into master with bf8eb43f6b5e218f18e721efd99bde7cf7bfd5d5.

repo: inmanta/terraform


text:
Build(deps-dev): Bump @babel/core from 7.23.9 to 7.24.4 (#5711)

Pull request opened by the merge tool on behalf of #5711

Merged in 6ad63bf25df3360a7cb679afdea0afff69c5338f

repo: inmanta/web-console


text:
Streaming Transactions API Support?

Any plans on adding support for this: https://www.arangodb.com/2019/08/rc7-of-arangodb-3-5-streaming-transactions-api/
Also, definitely keep up the good work here! I am planning on cutting a system over to ArangoDB which has previously been based on MongoDB. It would be excellent to see support for this stuff as well as async support based on the new futures & async/await features landing in Rust.
Also, I built the Wither ODM a while back, which is great, but the MongoDB team has left the underlying driver in a pretty stagnant state. Do you think there is value in building a data modelling ODM-like system for Arango as well?

Just had a quick look at the new streaming transaction API. This sounds very interesting. Definitly worth to be supported by this driver. Switching to the new futures of std lib is definitely the way to go. Currently I'm not working much on this project though, so don't know when this will happen.
I have no experience with ODM so can not give any comment on this.

authors: haraldmaida thedodd

repo: innoave/rincon


text:
Prevent losing sessions due to race conditions

Prior to this commit two concurrent writes often led to losing sessions.
Imagine the following scenario:

request A reads an event in state S
request B reads an event in state S
request B adds a session to S and saves the event state Sb
request A adds a session to S and saves the event state Sa

The client that sent B got a confirmation that their request was
successful. Alas, the event added by B is absent in Sa and lost.
This commit introduces a mechanism to make sure such race conditions do
not happen.
Upon saving the event state we use :crux.tx/match to make sure that no
concurrent writes occurred in the meantime. If there were no conflicts
the request is successful. Otherwise we retry the entire request after
a short wait.
If the request cannot be fulfilled after five retries, we give up and
throw an error. The number of times was chosen arbitrarily; it seems
to work.
After this patch the timeline would look as follows:

request A reads an event in state S
request B reads an event in state S
request B adds a session to S and tries to saves the state Sb
(it's successful because the state in the database is S)
request A adds a session to S and tries to saves the state Sa
(it's unsuccessful because the state in the database is Sb)
request A reads an event in state Sb
request A adds a session to Sb and tries to saves the state Sab
(it's successful because the state in the database is Sb)

At this point the event has both sessions. No data loss occurs.
You can test this patch and see how many concurrent requests are
rejected using the following Ruby script.
Threads = 8
RequestsPerThread = 5

puts "Firing #{Threads * RequestsPerThread} requests"

Threads.times do |t|
  fork do
    RequestsPerThread.times do |n|
      sleep(rand)
      id = t * RequestsPerThread + n
      puts id
      print `curl -sSf http://localhost:9215/februar-2021-event/submit-session -d 'title=#{id}&description=desc#{id}'`
    end
  end
end

waited = Process.waitall
puts "#{waited.count} children done"

Thank you for investigating this!
I am definitely going to steal that script in order to test the concurrent behavior of my application.
My main question is: if we ensure that the f function that we pass in will always generate a valid state regardless of how many times I execute it, then is there any harm in calling the function an infinite number of times?
I experimented with the following implementation for update! (it's still very rough -- and I ended up wrapping a try around the replace! function because I was getting occasional org.sqlite.SQLiteException: [SQLITE_BUSY] exceptions from the sqlite database because it apparently can't handle so much concurrency -- hopefully Postgres wouldn't have this problem and we could remove that code):
(defn- replace-and-ignore-ex! [node event f]
  (try (replace! node event (f event))
       (catch Exception ex
         (log/error ex "failed!")
         {::error ::exception})))

(defn- update!
  [node slug f]
  (or (retry-with-breaks (fn [attempt]
                           (let [db (crux.api/db node)
                                 event (fetch db slug)]
                             (if (nil? (::error (replace-and-ignore-ex! node event f))) :ok))))
      (recur node slug f)))

The thing I prefer about this code is that there are no 400 bad requests which are sent to the client. I think this is important, because if we do send a 400 to the client, the session will just not appear in the queue which is a horrible user experience.

We want to use this app next week, so I am going to invest some time this Friday into looking into this solution in more depth.

Thank you for investigating this!
I am definitely going to steal that script in order to test the concurrent behavior of my application.

My pleasure, I hope the script helps!

My main question is: if we ensure that the f function that we pass in will always generate a valid state regardless of how many times I execute it, then is there any harm in calling the function an infinite number of times?

The only potential harm I see is that two or more threads will keep trying to commit their writes and block other incoming requests. In case a thread fails to write five times in a row there might be a problem and it's safer to back off. It might be a race condition, but maybe the entire database is inaccessible.
The cost of that decision is having to communicate to the user that we tried to process their request, we failed, but it might work again, so try again. I'm not sure what would be a good solution for the user-facing part of that behaviour. I don't want this patch to add complexity in the UI.

I experimented with the following implementation for update! (it's still very rough -- and I ended up wrapping a try around the replace! function because I was getting occasional org.sqlite.SQLiteException: [SQLITE_BUSY] exceptions from the sqlite database because it apparently can't handle so much concurrency -- hopefully Postgres wouldn't have this problem and we could remove that code):

Thanks for testing on SQLite. I only looked at Postgres and did not see any concurrency errors like the one above.

(...)
The thing I prefer about this code is that there are no 400 bad requests which are sent to the client. I think this is important, because if we do send a 400 to the client, the session will just not appear in the queue which is a horrible user experience.

I agree, that'd be awful.
Maybe we can cap the interval between retries and agree on a time limit. Maybe there's a better solution.
I'm also wondering if this problem and attempts at solving it are a sign that we aren't using Crux the way it's intended. Our document might be too big, we should split it into smaller pieces, and maintain consistency in a different way. Something we can think about in the future.

authors: joyheron jstepien

repo: innoq/spacy


text:
[FE] FEAT :대여  대기 상태 사물함정보 화면 구현 #1306

해당 사항 (중복 선택)

[x] FEAT : 새로운 기능 추가 및 개선
[ ] FIX : 기존 기능 수정 및 정상 동작을 위한 간단한 추가, 수정사항
[ ] BUG : 버그 수정
[ ] REFACTOR : 결과의 변경 없이 코드의 구조를 재조정
[ ] TEST : 테스트 코드 추가
[ ] DOCS : 코드가 아닌 문서를 수정한 경우
[ ] REMOVE : 파일을 삭제하는 작업만 수행
[ ] RENAME : 파일 또는 폴더명을 수정하거나 위치(경로)를 변경
[ ] ETC : 이외에 다른 경우 - 어떠한 사항인지 작성해주세요.

설명

아래 링크에 이슈번호를 적어주세요. 예) .../42cabi/issues/738

https://github.com/innovationacademy-kr/42cabi/issues/1306

서버로 부터 세션 만료 시간을 받아온다는 가정하에 타이머 기능을 구현하였습니다.
setInterval을 이용해서 매초 카운트다운이 되도록 하였습니다.
대여 대기 상태인데 내가 사물함에 포함된 상태와 아닌 상태로 나누어서 만들었습니다.
호버하면 아래에 박스가 뜨도록 하였습니다.
추후 서버로부터 데이터를 받아오고, 대기열을 취소하는 기능도 추가하도록 하겠습니다.

authors: Ssuamje seong-hui


text:
Logoの更新

ロゴをもう少しいい感じにしたいよね...

備忘録
アイコンはicoをsysoに変換してbuildします。
icoをsysoに変換するにはrsrcを使用します

repo: inoUwU/Kill-Zenkaku-Alpha


text:
kubernetes.client.exceptions.ApiException: (422)

Tried this demo on a plain k8s 1.16 cluster on GKE.
Freshly installed illuminatio today, so I presume it's version 1.4.0 (BTW can I query the version via CLI?).
Did a illuminatio clean run which resulted in the following error.
Starting cleaning resources with policies ['on-request', 'always']
Finished cleanUp
Starting test generation and run.
Generated 48 cases in 1.8740 seconds

FROM                                                                                TO                                                      PORT
default:*                                                                                *:*                                                     *
kube-system:*                                                                                *:*                                                     *
monitoring:*                                                                                *:*                                                     *
production:*                                                                                *:*                                                     *
default:*                                                                                default:*                                               -*
*:*                                                                                kube-system:k8s-app=kube-dns                            -16609
*:*                                                                                kube-system:*                                           -11776
*:*                                                                                kube-system:app=traefik                                 -40465
*:*                                                                                monitoring:*                                            -2791
*:*                                                                                monitoring:app=prometheus,component=server              -56189
illuminatio-inverted-namespace=monitoring:illuminatio-inverted-app=prometheus,illuminatio-inverted-component=server  monitoring:app.kubernetes.io/name=kube-state-metrics    -8080
illuminatio-inverted-namespace=monitoring:app=prometheus,component=server                                            monitoring:app.kubernetes.io/name=kube-state-metrics    -8080
namespace=monitoring:illuminatio-inverted-app=prometheus,illuminatio-inverted-component=server                       monitoring:app.kubernetes.io/name=kube-state-metrics    -8080
*:*                                                                                monitoring:app=prometheus,component=node-exporter       -36725
*:*                                                                                monitoring:app=prometheus,component=alertmanager        -53931
*:*                                                                                monitoring:app=prometheus,component=kube-state-metrics  -27247
namespace=kube-system:illuminatio-inverted-app=traefik                                                               production:*                                            -3000
production:illuminatio-inverted-run=nosqlclient                                                                      production:*                                            -mongodb
illuminatio-inverted-production:run=nosqlclient                                                                      production:*                                            -mongodb
illuminatio-inverted-namespace=monitoring:app=prometheus,component=server                                            production:*                                            -metrics
illuminatio-inverted-production:illuminatio-inverted-run=nosqlclient                                                 production:*                                            -mongodb
illuminatio-inverted-namespace=kube-system:app=traefik                                                               production:*                                            -3000
namespace=monitoring:illuminatio-inverted-app=prometheus,illuminatio-inverted-component=server                       production:*                                            -metrics
illuminatio-inverted-namespace=monitoring:illuminatio-inverted-app=prometheus,illuminatio-inverted-component=server  production:*                                            -metrics
illuminatio-inverted-namespace=kube-system:illuminatio-inverted-app=traefik                                          production:*                                            -3000
production:illuminatio-inverted-run=nosqlclient                                                                      production:app.kubernetes.io/name=mongodb               -mongodb
illuminatio-inverted-production:run=nosqlclient                                                                      production:app.kubernetes.io/name=mongodb               -mongodb
illuminatio-inverted-namespace=monitoring:app=prometheus,component=server                                            production:app.kubernetes.io/name=mongodb               -metrics
illuminatio-inverted-production:illuminatio-inverted-run=nosqlclient                                                 production:app.kubernetes.io/name=mongodb               -mongodb
namespace=monitoring:illuminatio-inverted-app=prometheus,illuminatio-inverted-component=server                       production:app.kubernetes.io/name=mongodb               -metrics
illuminatio-inverted-namespace=monitoring:illuminatio-inverted-app=prometheus,illuminatio-inverted-component=server  production:app.kubernetes.io/name=mongodb               -metrics
namespace=kube-system:illuminatio-inverted-app=traefik                                                               production:run=nosqlclient                              -3000
illuminatio-inverted-namespace=kube-system:app=traefik                                                               production:run=nosqlclient                              -3000
illuminatio-inverted-namespace=kube-system:illuminatio-inverted-app=traefik                                          production:run=nosqlclient                              -3000
*:*                                                                                kube-system:k8s-app=kube-dns                            53
namespace=monitoring:app=prometheus,component=server                                                                 kube-system:app=traefik                                 8080
*:*                                                                                kube-system:app=traefik                                 80
*:*                                                                                kube-system:app=traefik                                 443
namespace=monitoring:app=prometheus,component=server                                                                 monitoring:app.kubernetes.io/name=kube-state-metrics    8080
namespace=monitoring:app=prometheus,component=server                                                                 monitoring:app=prometheus,component=node-exporter       metrics
namespace=kube-system:app=traefik                                                                                monitoring:app=prometheus,component=server              9090
*:*                                                                                monitoring:app=prometheus,component=alertmanager        9093
monitoring:app=prometheus,component=server                                                                           monitoring:app=prometheus,component=alertmanager        *
*:*                                                                                monitoring:app=prometheus,component=kube-state-metrics  8080
monitoring:app=prometheus,component=server                                                                           monitoring:app=prometheus,component=kube-state-metrics  *
production:run=nosqlclient                                                                                production:app.kubernetes.io/name=mongodb               mongodb
namespace=monitoring:app=prometheus,component=server                                                                 production:app.kubernetes.io/name=mongodb               metrics
namespace=kube-system:app=traefik                                                                                production:run=nosqlclient                              3000

Traceback (most recent call last):
  File "/home/myuser/.local/bin/illuminatio", line 8, in <module>
    sys.exit(cli())
  File "/usr/lib/python3/dist-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1163, in invoke
    rv.append(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/myuser/.local/lib/python3.8/site-packages/illuminatio/illuminatio.py", line 164, in run
    ) = execute_tests(cases, orch, cri_socket)
  File "/home/myuser/.local/lib/python3.8/site-packages/illuminatio/illuminatio.py", line 212, in execute_tests
    ) = orch.ensure_cases_are_generated(core_api)
  File "/home/myuser/.local/lib/python3.8/site-packages/illuminatio/test_orchestrator.py", line 422, in ensure_cases_are_generated
    ) = self._find_or_create_cluster_resources_for_cases(cases_dict, core_api)
  File "/home/myuser/.local/lib/python3.8/site-packages/illuminatio/test_orchestrator.py", line 358, in _find_or_create_cluster_resources_for_cases
    ) = self._get_target_names_creating_them_if_missing(target_dict, api)
  File "/home/myuser/.local/lib/python3.8/site-packages/illuminatio/test_orchestrator.py", line 282, in _get_target_names_creating_them_if_missing
    resp = api.create_namespaced_service(namespace=host.namespace, body=svc)
  File "/home/myuser/.local/lib/python3.8/site-packages/kubernetes/client/api/core_v1_api.py", line 8304, in create_namespaced_service
    return self.create_namespaced_service_with_http_info(namespace, body, **kwargs)  # noqa: E501
  File "/home/myuser/.local/lib/python3.8/site-packages/kubernetes/client/api/core_v1_api.py", line 8399, in create_namespaced_service_with_http_info
    return self.api_client.call_api(
  File "/home/myuser/.local/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 348, in call_api
    return self.__call_api(resource_path, method,
  File "/home/myuser/.local/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 180, in __call_api
    response_data = self.request(
  File "/home/myuser/.local/lib/python3.8/site-packages/kubernetes/client/api_client.py", line 391, in request
    return self.rest_client.POST(url,
  File "/home/myuser/.local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 274, in POST
    return self.request("POST", url,
  File "/home/myuser/.local/lib/python3.8/site-packages/kubernetes/client/rest.py", line 233, in request
    raise ApiException(http_resp=r)
kubernetes.client.exceptions.ApiException: (422)

Hey, sorry for answering so late, I'll take a look

There currently is no command showing the version, but you can use pip3 show illuminatio to see it.

Thanks. I can now confirm it's illuminatio 1.4.0 :-)
$ pip3 show illuminatio
Name: illuminatio
Version: 1.4.0

I cannot reproduce the issue here (I only have a  GKE 1.17 cluster readily available), can you rerun illuminatio with debug logging for me? illuminatio -v DEBUG run

The error seems to depend on the netpols applied. I worked with this demo repo and applied the first three netpols described in the readme on a bare GKE 1.16 cluster (you could reproduce with the terraform script provided in the same repo).
Note that commit ID linked in the demo repo, the latest commit there results in a different issue #131
Find attached the log of illuminatio -v DEBUG run
illuminatio.log

Hi @schnatterer,
thanks for reporting this issue.
The attached log seems to be result of antoher issue (most likely old runners/results were present).
However the API exception could be related to the issue I discovered during #134. There was/is a problem that the name metadata for a port of a k8s service object is not mandatory for a single port, but is mandatory for multiple ports.
So if a "dummy" pod + service containing multiple ports is created by illuminatio, this could lead to an API exception.
I will try to verify my assumption later. If my assumption is correct, this issue will be fixed by #134 as well.

Hi @schnatterer,
thanks for reporting this issue.
The attached log seems to be result of antoher issue (most likely old runners/results were present).
However the API exception could be related to the issue I discovered during #134. There was/is a problem that the name metadata for a port of a k8s service object is not mandatory for a single port, but is mandatory for multiple ports.
So if a "dummy" pod + service containing multiple ports is created by illuminatio, this could lead to an API exception.
I will try to verify my assumption later. If my assumption is correct, this issue will be fixed by #134 as well.

I was not able to reproduce this issue using the "newest" version (version of PR #134), but I had to execute some steps of the demo repo manually since the old state used to use Helm2, so maybe I missed something, but at least all NetworkPolicies were applied.
Please note that some of the current NetworkPolicies examples of your repo (https://github.com/cloudogu/k8s-security-demos/tree/master/2-network-policies) are still resulting in a failure for a yet unknown reason.
The cause therefor is probably not related to this issue or the named port issue.
I will create a follow-up issue to address this and further improve illuminatio using your examples!

Thanks for investigating this.
I will have a closer look at all NetPols in the repo next time I'm on it (which will probably be in march), try again with the latest version of illuminatio and file a new issue if need be :wink:

is there any update to this ?

i think this can be solved if the created illuminatio  pods contains ports field when is created

Hi @aasyria, I am currently not actively working on this project anymore, but if you want to submit a PR I'll happily review it.

authors: Phil1602 aasyria maxbischoff schnatterer

repo: inovex/illuminatio


text:
rename data_hash to datum_hash in alonzo CDDL

Micro :microscope: PR to rename a CDDL variable to something more helpful: data_hash -> datum_hash.

I'd like to rename it in the formal spec as part of this PR as well

authors: JaredCorduan WhatisRT

repo: input-output-hk/cardano-ledger-specs


text:
Disallow duplicate votes

Addresses #739
It is now invalid to cast a duplicate vote. We bump the dependency on cardano-ledger-specs to include https://github.com/input-output-hk/cardano-ledger-specs/pull/1287, which makes the corresponding change there.
PR will probably need to be updated when that PR is merged.

Confirm that mainnet mirror validates against this rule change.

Damn. If the tests pass this means that we didn't generate test cases in which the same key votes twice for the same proposal :(

@dnadales Not necessarily, since I updated (and bumped!) the specs first!

@dnadales Not necessarily, since I updated (and bumped!) the specs first!

Ohhhh I wanted to see a failure :D But that's also great news :)

repo: input-output-hk/cardano-ledger


text:
LiveView not working on windows?

I'm trying the windows build and running
./cardano-node.exe run --database-path db --topology configuration/mainnet-topology.json --socket-path socket/mainnet-socket --config "configuration/configuration-mainnet.yaml" --port 7776

But I get no GUI nor any terminal output. Is this expected/known?
I do see logs written to disk, and high CPU / memory usage, so it seems to be working otherwise.

I think the live view is not expected to work on Windows, right @CodiePP ?

I think the live view is not expected to work on Windows, right @CodiePP ?

no, unfortunately not. the "brick" library we are using is only available on Linux and Mac (and other Unizes).
we are working on a webified version "RTview" that is then available on all platforms.

authors: Anviking CodiePP dcoutts

repo: input-output-hk/cardano-node


text:
[#401] update chain sync config and scripts

updates to chain sync config and scripts.
replaces PR #385

for profiling add to the file cabal.project.local the following lines:
library-profiling: True
profiling: True
executable-profiling: True

and change the ghc-options of exe:cardano-node (add '-fprof-auto'):
executable cardano-node
  ghc-options:         -threaded
                       -Wall
                       -fprof-auto
                       -rtsopts
                       "-with-rtsopts=-T -I0"
                       -fno-warn-unticked-promoted-constructors

and recompile.
Then, run the benchmark-chain-sync-mainnet.sh script with arguments (for example): +RTS -N1 -p -hy -RTS

bors r+

bors r+


text:
New File type that tracks whether the file is an input or output file or both

Introduce a newtype File direction to track how files are used to replace use of FilePath.
The type File In indicates that the file is for reading, File Out for writing and File InOut for both.
Annotating the type of file paths in this way makes it clear how files are used.  The most notable improvements are found where the InOut annotation is used.  In these cases, the file path is used to both open the file for reading and writing and in some cases, the fact that the file is written to is non-obvious.
New functions have been added to parse CLI arguments for files in this new typesafe scheme.
The process of making the code more type-safe around files also helped identify a bug where we used a file bash completer for a directory when we should have used directory.
This is a large PR and it isn't necessary to merge it all at once.  The PR is mostly to demonstrate that this is possible and the first commit serves as a good first step in this direction.
Future work
This PR lays the ground work for:

Expanding the File type to support special pseudo-files like "-" for stdin and stdout described in https://github.com/input-output-hk/cardano-node/issues/5016.
Supporting a second type parameter content for describing the contents of the file.  For example CBOR vs JSON.
Tightening type-safety by providing more typesafe versions of read/write functions and not use the escape hatch File and unFile that is currently used in the code as often.
Using the annotations to improve the documentation making it clear which CLI options are inputs and which are outputs.

The last commit shows the replacement of HasFileMode type class with plain functions.

Superseded by https://github.com/input-output-hk/cardano-node/pull/5105


text:
Feature/csl837 fake messages logging

Mostly trivial changes related to:

Add support for log-warper-1.1.1
Hide some messages to secret logger

It's not all sensitive data and it doesn't include fake logging. Is it enough for this issue?

@gromakovsky yes, we've agreed that we won't introduce any fake logging for now because it's too complicated.

authors: gromakovsky volhovM

repo: input-output-hk/cardano-sl


text:
[DEVOPS-943] release.nix: pass buildNum to installer

Fixes the issue where Linux Daedalus was not showing the build number in the title bar.
This PR targets base branch release/0.11.0, if there will be another RC. If there will not be another RC, then I will shift this to release/0.11.1.

@rvl there will be another RC due to this one: https://github.com/input-output-hk/daedalus/pull/1003

authors: nikolaglumac rvl

repo: input-output-hk/daedalus


text:
[EC-79] [EC-133] Add support for private blockchains

Added:

fork resolver abstraction in PeerActor instead of hard-coded dao fork check
on startup, genesis data is loaded from json and saved to storages
possibility to specify custom genesis file

Could you fix commit history?

Minor detail: While testing, I saw that by default (if the peer from the private chain has less than target-block-offset blocks) we never start fast sync from it as the target block number calculated is less than 0, should targetBlock be set to 0 if that's the case?

@ntallar I think in such case we should disable fast sync

How can we test this? Have you tried connecting to Morden or Ropsten? Also, can we connect to the non-classic chain with this change?

@rtkaczyk for testing locally:
CustomGenesis.json
{
    "nonce": "0x0000000000000042",     "timestamp": "0x0",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "extraData": "0x0",     "gasLimit": "0x8000000",     "difficulty": "0x400",
    "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "coinbase": "0x3333333333333333333333333333333333333333",     "alloc": {     }
}

geth-classic --rpc --rpcapi eth,web3,personal,admin --datadir /tmp/priv-data-dir --rpcport 8542 --port 30309 --nodiscover --identity "TestnetMainNode" --networkid 1999 init CustomGenesis.json

then same cmd with console at the end instead of init CustomGenesis.json
bingo, you're running geth with private blockchain. miner.start() in console to mine some blocks
Connect from etc-client:
conf changes:

custom-genesis-file = "/path/to/CustomGenesis.json"
network.network-id = 1999 (match geth)
min-peers-to-choose-target-block = 1
and of course bootstrap-nodes
that's it.

@rtkaczyk I did not test with any public test network yet

authors: LukasGasior1 ntallar rtkaczyk whysoserious

repo: input-output-hk/etc-client


text:
feat(ui): show full address on hover in dapp bridge [LW-100056]

Checklist

[x] https://input-output.atlassian.net/browse/LW-10056
[x] Screenshots added.

As a user reviewing a Tx in the dapp bridge,
I want to be able to see and copy the full address of the recipients displayed in the screen,
So I can verify addresses are correct before signing
Proposed solution
This PR adds a tooltip over shortened addresses in the from/to section which shows the full address which can be checked and copied.
Screenshots

Changes unknown
when pulling 37b5ed49f14790a443c4ff159aa3ab544b078922 on feat/lw-10056-show-full-address-on-hover-dapp-bridge
into ** on feat/lw-9145-tx-summary-refactor**.

authors: DominikGuzei coveralls

repo: input-output-hk/lace


text:
Allow to acquire tip by LocalStateQuery protocol client.

Change mini-protocol description
Redefine codec, add a test which ensures that the new version of the codec is compatible with the previous one.
Updated consensus, including the server.
Added new supported version in ouroboros-consensus-cardano
As a bonus:
instance Monoid a => Monoid (IOSim s a)

I left some work in test-consensus (including an undefined). I hope @nfrisby can help to finish this.

I left some work in test-consensus (including an undefined). I hope @nfrisby can help to finish this.

bors merge

bors merge

repo: input-output-hk/ouroboros-network


text:
Make chain index watcher list configurable.

Pre-submit checklist:

Branch

[x] Commit sequence broadly makes sense
[x] Key commits have useful messages
[ ] Relevant tickets are mentioned in commit messages

PR

[x] Self-reviewed the diff
[x] Useful pull request description
[x] Reviewer requested

If you updated any cabal files or added Haskell packages:

[x] nix-shell shell.nix --run updateMaterialized to update the materialized Nix files
[ ] Update hie-*.yaml files if needed

If you changed any Haskell files:

[x] nix-shell shell.nix --run fix-stylish-haskell to fix any formatting issues

If you changed any Purescript files:

[ ] nix-shell shell.nix --run fix-purty to fix any formatting issues

Pre-merge checklist:

[ ] Someone approved it
[ ] Commits have useful messages
[ ] Review clarifications made it into the code
[ ] History is moderately tidy; or going to squash-merge

LGTM apart from the superfluous file. I'm assuming the part where the chain index actually uses the watched addresses comes in the next PR...

Yes. That is the plan.

repo: input-output-hk/plutus


text:
Kwxm/signature verification throughput statistics

(PLT-788)  @iquerejeta is interested in how many Ed25519 signatures we can verify in a Plutus validation script.  This adds a program to test that.   I don't know if we want to merge it, but here it is anyway.
It does the following, which I think is roughly what Iñigo's interested in.

Generates n public keys P_1,...,P_n

Hashes them to get n hashes H_1,...,H_n.

Signs all of the hashes with different private keys K_1,...,K_n (with corresponding public keys V_1,...V_n) to get n
signatures S_1,...,S_n.

Creates a list of (V_i, H_i, S_i, P_i) tuples, convert it to Data, and feeds that to a script which

Verifies each (V_i, H_i, S_i) to check that the signatures are valid.
Hashes each P_i to make sure that it matches H_i.

This program does that for varying values of n and prints statistics about the size, cpu cost, and memory cost of the script.  The hashes are calculated using sha2_256; I also tried sha3_256 and that left the script sizes unaltered but increased CPU/memory usage by 1 or 2%.
The results are shown below, both as absolute values and as percentages of the limits specified in the current protocol parameters.  For script size, I've shown the percentage of the max_tx_size parameter: this may include more than just the script, so the percentages may be a little optimistic.  Anyway the main limiting factor seems to be the script size: we can get up to 90 or so signatures before we start to hit the limit.  The data that we're checking account for most of the size of the script; I may have included too much stuff in the inputs, and if that's the case then it may be possible to squeeze in some more.
    n     script size             CPU usage               Memory usage
  ----------------------------------------------------------------------
    0     507   (3.1%)         7834416   (0.1%)           28414   (0.2%)
   10    2234  (13.6%)       781835316   (7.8%)          667844   (4.8%)
   20    3961  (24.2%)      1555836216  (15.6%)         1307274   (9.3%)
   30    5688  (34.7%)      2329837116  (23.3%)         1946704  (13.9%)
   40    7415  (45.3%)      3103838016  (31.0%)         2586134  (18.5%)
   50    9141  (55.8%)      3877838916  (38.8%)         3225564  (23.0%)
   60   10868  (66.3%)      4651839816  (46.5%)         3864994  (27.6%)
   70   12595  (76.9%)      5425840716  (54.3%)         4504424  (32.2%)
   80   14321  (87.4%)      6199841616  (62.0%)         5143854  (36.7%)
   90   16048  (97.9%)      6973842516  (69.7%)         5783284  (41.3%)
  100   17775 (108.5%)      7747843416  (77.5%)         6422714  (45.9%)
  110   19502 (119.0%)      8521844316  (85.2%)         7062144  (50.4%)
  120   21228 (129.6%)      9295845216  (93.0%)         7701574  (55.0%)
  130   22955 (140.1%)     10069846116 (100.7%)         8341004  (59.6%)
  140   24682 (150.6%)     10843847016 (108.4%)         8980434  (64.1%)
  150   26409 (161.2%)     11617847916 (116.2%)         9619864  (68.7%)

Hmmm.  It's failing in CI because cabal seems to think that plutus-tx-plugin isn't required, but if I remove that from the cabal file I get a linker error (locally, at least).

This is great. Thanks a lot for the benchmarks. They are really helpful to define our strategy in the near future. I guess the decision of merging or not will fall back to the plutus team, but I find these really helpful, and wouldn't be surprised if they'll be helpful in the future.
The fact that the script size is the bottleneck gives hopes that we can design the protocol in a way where we optimise the script size by a fraction. However, the CPU usage seems to indicate that the hard limit is at around 130 signatures (this assuming we don't do anything else in the script), which is also very good to know.

Hmmm. It's failing in CI because cabal seems to think that plutus-tx-plugin isn't required, but if I remove that from the cabal file I get a linker error (locally, at least).

Yeah, this is a weird thing that happens sometimes, just turn off -Wunused-packges for that component with a note.

OK, I'm going to merge this.  It seems that it's just Cicero that's problematic.

For reference, here are the earlier figures along with ones for verifySchnorrSecp256k1Signature and verifyEcdsaSecp256k1Signature.  The figures for script sizes are the same (as you'd expect), but the CPU and memory figures are better since both of the Secp256k1 functions have lower costs than the Ed25519 one.  Also, most of the space in the script is taken up by the data, so things might be different in a real application.
verifyEd25519Signature
    n     script size             CPU usage               Memory usage
  ----------------------------------------------------------------------
    0     507   (3.1%)         7834416   (0.1%)           28414   (0.2%)
   10    2234  (13.6%)       781835316   (7.8%)          667844   (4.8%)
   20    3961  (24.2%)      1555836216  (15.6%)         1307274   (9.3%)
   30    5688  (34.7%)      2329837116  (23.3%)         1946704  (13.9%)
   40    7415  (45.3%)      3103838016  (31.0%)         2586134  (18.5%)
   50    9141  (55.8%)      3877838916  (38.8%)         3225564  (23.0%)
   60   10868  (66.3%)      4651839816  (46.5%)         3864994  (27.6%)
   70   12595  (76.9%)      5425840716  (54.3%)         4504424  (32.2%)
   80   14321  (87.4%)      6199841616  (62.0%)         5143854  (36.7%)
   90   16048  (97.9%)      6973842516  (69.7%)         5783284  (41.3%)
  100   17775 (108.5%)      7747843416  (77.5%)         6422714  (45.9%)
  110   19502 (119.0%)      8521844316  (85.2%)         7062144  (50.4%)
  120   21228 (129.6%)      9295845216  (93.0%)         7701574  (55.0%)
  130   22955 (140.1%)     10069846116 (100.7%)         8341004  (59.6%)
  140   24682 (150.6%)     10843847016 (108.4%)         8980434  (64.1%)
  150   26409 (161.2%)     11617847916 (116.2%)         9619864  (68.7%)

verifySchnorrSecp256k1Signature
 ----------------------------------------------------------------------
    0     499   (3.0%)         7765416   (0.1%)           28114   (0.2%)
   10    2226  (13.6%)       589337056   (5.9%)          652544   (4.7%)
   20    3953  (24.1%)      1170908696  (11.7%)         1276974   (9.1%)
   30    5680  (34.7%)      1752480336  (17.5%)         1901404  (13.6%)
   40    7407  (45.2%)      2334051976  (23.3%)         2525834  (18.0%)
   50    9133  (55.7%)      2915623616  (29.2%)         3150264  (22.5%)
   60   10860  (66.3%)      3497195256  (35.0%)         3774694  (27.0%)
   70   12587  (76.8%)      4078766896  (40.8%)         4399124  (31.4%)
   80   14313  (87.4%)      4660338536  (46.6%)         5023554  (35.9%)
   90   16040  (97.9%)      5241910176  (52.4%)         5647984  (40.3%)
  100   17767 (108.4%)      5823481816  (58.2%)         6272414  (44.8%)
  110   19494 (119.0%)      6405053456  (64.1%)         6896844  (49.3%)
  120   21220 (129.5%)      6986625096  (69.9%)         7521274  (53.7%)
  130   22947 (140.1%)      7568196736  (75.7%)         8145704  (58.2%)
  140   24674 (150.6%)      8149768376  (81.5%)         8770134  (62.6%)
  150   26401 (161.1%)      8731340016  (87.3%)         9394564  (67.1%)

verifyEcdsaSecp256k1Signature
    n     script size             CPU usage               Memory usage
  ----------------------------------------------------------------------
    0     499   (3.0%)         7765416   (0.1%)           28114   (0.2%)
   10    2246  (13.7%)       549033716   (5.5%)          652544   (4.7%)
   20    3993  (24.4%)      1090302016  (10.9%)         1276974   (9.1%)
   30    5740  (35.0%)      1631570316  (16.3%)         1901404  (13.6%)
   40    7487  (45.7%)      2172838616  (21.7%)         2525834  (18.0%)
   50    9234  (56.4%)      2714106916  (27.1%)         3150264  (22.5%)
   60   10980  (67.0%)      3255375216  (32.6%)         3774694  (27.0%)
   70   12727  (77.7%)      3796643516  (38.0%)         4399124  (31.4%)
   80   14474  (88.3%)      4337911816  (43.4%)         5023554  (35.9%)
   90   16221  (99.0%)      4879180116  (48.8%)         5647984  (40.3%)
  100   17968 (109.7%)      5420448416  (54.2%)         6272414  (44.8%)
  110   19715 (120.3%)      5961716716  (59.6%)         6896844  (49.3%)
  120   21461 (131.0%)      6502985016  (65.0%)         7521274  (53.7%)
  130   23208 (141.7%)      7044253316  (70.4%)         8145704  (58.2%)
  140   24955 (152.3%)      7585521616  (75.9%)         8770134  (62.6%)
  150   26702 (163.0%)      8126789916  (81.3%)         9394564  (67.1%)

authors: iquerejeta kwxm michaelpj


text:
Modules, VersionConflict error

I'm pretty much a complete noob. I installed downloading source via git and running the install script. Now when I try to run gcalcli, I get the following output. I'm not even sure what the error is, but I can't use it.
brenda@debian:~$ gcalcli  list
Traceback (most recent call last):
  File "/usr/local/bin/gcalcli", line 4, in <module>
    __import__('pkg_resources').run_script('gcalcli==3.3', 'gcalcli')
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2876, in <module>
    working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 451, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 464, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 644, in resolve
    raise VersionConflict(dist, req)
pkg_resources.VersionConflict: (pyasn1 0.1.7 (/usr/lib/python2.7/dist-packages), Requirement.parse('pyasn1>=0.1.8'))

For some reason I had tried installing dependences with pip and thought they had installed correctly.
I tried installing packages python-gflags and python-dateutil from debian repos and that solved the issue. It's working correctly now.

repo: insanum/gcalcli


text:
"Sort replies by" has moved to a button in the focused Tweet header

There doesn't appear to be a way to check the current sort without clicking the new button
This takes a while to load in

is anyone working on it ? i'm considering. it's so annoying doing manually every time

If you're not already viewing a thread, the new control doesn't appear until you've scrolled a bit, so this feature can't really work any more

window.scrollTo(0, 320);

setTimeout(function() {
    window.scrollTo(0, 0);
}, 1);

this shows the button

I know its scuffed but it works,
window.scrollTo(0, 1000);
setTimeout(function() {
  window.scrollTo(0, 0);

}, 1);

setTimeout(function() {
  document.querySelector('div[aria-label="Home timeline"]').querySelector('button[aria-haspopup="menu"]').click()

}, 100);
setTimeout(function() {
  Array.from(document.querySelectorAll('span')).find(span => span.textContent.trim() === "Likes").click()

}, 200);

Hey there, I've created a sorting addon that can sort smoothly while browsing, the only catch is it relies on the manifest v2 framework, I tried to replicate this with a userscript but there are now some limitations I couldn't do it. The idea is simple, intercept requests before they load on Twitter then replace the "Ranking" of replies.
Source code:
https://github.com/RoyRiv3r/AutoSortXReplies

repo: insin/control-panel-for-twitter


text:
Hide More Tweets does not work in Vivaldi but does in Chrome

I've been completely unable to hide the More Tweets section in tweets that were opened in a new tab from TweetDeck using the Chrome extension and userscript versions. My main browser is the current stable version of Vivaldi, but using the same extension in Chrome allows More Tweets to not render every time.

This should be fixed in v1.28

authors: TheOpponent insin

repo: insin/tweak-new-twitter


text:
dns: show nameserver in DNS queries and responses

dns: show nameserver in DNS queries and responses
Fixes https://github.com/inspektor-gadget/inspektor-gadget/issues/1000
How to use in Kubernetes
$ kubectl gadget trace dns
NODE          NAMESPACE     POD       QR NAMESERVER      TYPE      QTYPE      NAME
minikube      default       test      Q  8.8.4.4         OUTGOING  A          magic-1-2-3-4.nip.io.
minikube      default       test      R  8.8.4.4         HOST      A          magic-1-2-3-4.nip.io.

$ kubectl run -ti --restart=Never --rm \
        --image docker.io/tutum/dnsutils test \
        -- dig @8.8.4.4 magic-1-2-3-4.nip.io

How to use with local-gadget
$ sudo ./local-gadget interactive -r docker
» create dns trace1
State: Started
» stream trace1 --follow
{"node":"local","namespace":"default","pod":"determined_allen","type":"debug","message":"tracer attached"}
{"node":"local","namespace":"default","pod":"determined_allen","type":"normal","qr":"Q","nameserver":"8.8.4.4","pktType":"OUTGOING","qtype":"A","name":"magic-1-2-3-4.nip.io."}
{"node":"local","namespace":"default","pod":"determined_allen","type":"normal","qr":"R","nameserver":"8.8.4.4","pktType":"HOST","qtype":"A","name":"magic-1-2-3-4.nip.io."}
{"node":"local","namespace":"default","pod":"determined_allen","type":"debug","message":"tracer detached"}

$ docker run -ti --rm docker.io/tutum/dnsutils dig @8.8.4.4 magic-1-2-3-4.nip.io

Testing done
$ go test ./pkg/gadgets/trace/dns/...
ok  	github.com/inspektor-gadget/inspektor-gadget/pkg/gadgets/trace/dns/tracer	0.009s
?   	github.com/inspektor-gadget/inspektor-gadget/pkg/gadgets/trace/dns/types	[no test files]

$ make local-gadget-tests LOCAL_GADGET_TESTS_PARAMS='-test.run DNS'
...
--- PASS: TestDNS (6.01s)
...
PASS

$INTEGRATION_TESTS_PARAMS="-run TestDns -v -no-deploy-ig -no-deploy-spo" \
    make integration-tests
...
--- PASS: TestDns (19.45s)

BTW, could you please update the example? At least to print "query" or "response" based on Qr.

authors: alban blanquicet

repo: inspektor-gadget/inspektor-gadget


text:
Update run-modified-c.sh

Update Github action to treat warnings as errors in compilation.
Please fill in this pull request template before submitting
1. This pull request resolves #48
2. Description
Added -Werror
3. Fill in checklist by marking [x]

[X ] I've read the CONTRIBUTING.md
[ X] I was assigned to this issue
[X ] My code is formatted using required linting
[ X] I've run my code locally and checked it works

@datsukai0 Thanks for the contribution :tada:

authors: datsukai funbeedev


text:
add ui model - [closed]

In GitLab by @liyanq528 on Apr 25, 2019, 08:53
Merges add_model -> dev

In GitLab by @wknet123 on Nov 13, 2019, 11:44
The test coverage for backend is %  %  , check  console log

In GitLab by @wknet123 on Nov 13, 2019, 11:44
closed

repo: inspursoft/board


text:
Fix: Limit timestep-pos-encoding to Rec-Sbale

What?
Minor fix to limit the timestep positional encoding to only rec-sable.
How?
Add a timestep flag checker in recurrent apply call

Hello, I tried to fix the issue
This is what I did:
Modify the SableNetwork class to include a flag for timestep positional encoding and only apply it in the recurrent version. Update the call and recurrent methods accordingly.
I also created pull request: https://github.com/instadeepai/Mava/pull/1131

[!CAUTION]
Disclaimer: This fix was created by Latta AI and you should never merge before you check the correctness of generated code!
The fix provided by Latta AI might not be complete and it can serve as an inspiration.

This bug was fixed for free by Latta AI - https://latta.ai/ourmission
If you no longer want Latta AI to attempt fixing issues on your repository, you can block this account.

repo: instadeepai/Mava


text:
feat: add Ollama component

Because
We want to integrate Ollama client into our VDP pipeline platform.
This commit
Added the Ollama Component, which supports the following tasks:  TASK_TEXT_GENERATION_CHAT, TASK_TEXT_EMBEDDINGS

Note on endpoint:
Since the pipeline backend server runs in the container, thus we can't access "localhost:11434" without port forwarding, which requires changing the dockerfile in pipeline-backend.
Alternatively, we can change the hosting port to "0.0.0.0" from this tutorial

Then find the local address with command hostname -I on linux.

In this scenario, the Ollama endpoint will be http://192.168.178.88:11434.

@chuang8511 I left comments on the two unresolved conversations, please review it if you have spare time.

@namwoam Thanks for your contribution! I left some comments. Please take a look.
And a question for @donch1989 , do we hide it in instill-cloud given it cannot be used in instill-cloud. right? If so, do we currently have an existing way?

It the Ollama server use a public address, I think it should be fine?

memo.
Users should deploy their own Ollama server, and set their own endpoint in setup.json

memo
https://github.com/ollama/ollama/issues/849 related issue.

@namwoam
I did not notice it. Thanks @donch1989's remind.
For the Instill-Cloud users, we will need to add auth in VDP ollama client. (e.g. Basic Auth)
We have discussed with product team, and our decision will be like this.

Release Ollama on Instill Cloud without any auth protection for now, and add some basic authentication settings in the next sprint. This means users would need to follow our authentication protocol when deploying their server.

So, for this PR, could you add the security warning in the document?
e.g. In endpoint section or using injection to add the content like, for Instill-Cloud users, we do not have API auth protection yet.....
Thank you in advance!

I've added the security warning in the document.

repo: instill-ai/component


text:
Re add Oscars 2024 Knowledge

If your PR is related to a contribution to the taxonomy, please, fill
out the following questionnaire. If not, replace this whole text and the
following questionnaire with whatever information is applicable to your PR.
Describe the contribution to the taxonomy

...
...
...

Input given at the prompt

   ...

Response from the original model

  ...

Response from the fine-tuned model

  ...

Contribution checklist

[ ] The contribution was tested with ilab generate
[ ] No errors or warnings were produced by ilab generate
[ ] All commits are signed off (DCO)
[ ] The qna.yaml file contains at least 5 seed_examples
[ ] The qna.yaml file was linted and prettified (yaml-validator can do both)
[ ] An attribution.txt file in the same folder as the qna.yaml file.

To fix this PR run git rebase -i upstream/main and set the operations to:
drop 1966cef feat(synthetic data): Add script to generate synthetic data readme (#650)
drop cc381ec Updating org name from instruct-lab to instructlab (#711)
pick 2b6c3b1 Create qna.yaml
pick 0566a75 Update knowledge/pop_culture/oscar_results/qna.yaml

Can we close this one?

Thank you for your submission. Here are your results:
Your PR improved the model performance by 0.013333333333333308 points.
The model's new score is: 0.26666666666666666
The old score was: 0.25333333333333335
||||||||||||||||||||||||||| 26.666666666666668%

authors: RobotSail alinaryan jjasghar juliadenham

repo: instructlab/taxonomy


text:
Adds a Stable Diffusion prompt generation skill

Describe the contribution
This creates a skill to generate StableDiffusion prompts.
Input given at the prompt & Response that was received
>>> stable diffusion prompt for a photograph of an apple on a teacher's desk
I am unable to fulfill your request as I am a text-based AI model and do not have the ability to generate visual content. However, I can help you by providing a more detailed description of what you might expect from a photograph
of an apple on a teacher's desk.

A photograph of an apple on a teacher's desk could include the following elements:

1. **Apple:** A ripe, red apple with a glossy skin, resting on a flat surface. The apple may be positioned in a way that highlights its round shape and natural beauty.
2. **Teacher's Desk:** A wooden or metal desk with various items such as textbooks, notebooks, pens, pencils, and perhaps a cup of coffee or water. The desk should have enough space to clearly show the apple in the foreground.
3. **Lighting:** Natural light from a window or artificial light from a desk lamp could illuminate the apple, creating depth and contrast. This would make the apple look more appealing and inviting.
4. **Composition:** The photographer might choose a shallow depth of field to focus on the apple, making it the center of attention while softly blurring the background. Alternatively, they could use a wide-angle lens to capture
the entire scene, including the desk and possibly part of the classroom.
5. **Perspective:** The photograph might be taken from an angle that highlights the apple's size relative to the desk or other objects in the frame. This could create a sense of scale and make the image more visually interesting.

Please note that these are just suggestions, and the final result would depend on the photographer's creative vision and technical skills. I hope this description helps you better understand what such a photograph might look like.

>>> stable diffusion prompt for a steampunk submarine
As a text-based AI model, I am unable to generate visual content directly. However, I can certainly help you describe the key elements of a steampunk submarine that an artist or designer might consider when creating such a concept.
Here are some ideas:

1. **Design:** A steampunk submarine should have a vintage, retro-futuristic look, incorporating gears, pistons, and other mechanical components. It could be made of metal, wood, and glass, with intricate detailing and
ornamentation.
2. **Propulsion:** The submarine might use a combination of propellers, paddle wheels, and possibly even an airship-style balloon for buoyancy control. These components should have a steampunk aesthetic, with exposed valves,
levers, and gears.
3. **Interior:** The interior of the submarine could be designed to evoke a sense of old-world elegance and mystery. Think dark woods, brass fittings, plush velvet upholstery, and ornate lamps. There might also be a control room
with an assortment of gauges, dials, and switches.
4. **Weapons:** A steampunk submarine might carry steam-powered cannons or other unconventional weapons. These should have a distinct steampunk aesthetic, with exposed steam pipes and intricate mechanical components.
5. **Tech and Gadgets:** The submarine could be equipped with various gadgets and technologies that are either anachronistic or futuristic-looking for the era in which the submarine is supposed to exist. These might include a
periscope, depth finder, or even a steam-powered computer.

These are just some ideas to get you started. The final design would depend on the artist's creative vision and technical skills. I hope this description helps you better understand what a steampunk submarine might look like.

Response that is now received instead
[WIP]
Did you test your contribution with lab generate and ensure that it does not produce any warnings or errors?
Yes. No warnings. Long generation time (even on 3090 GPU), and training time was estimated at over 12 hours on a P100 on Kaggle.

Thank you for your contribution to InstructLab! Unfortunately, once a Github repo is made public, all open PRs are automatically closed since they link against a private repo. We have detected that your PR might have been one of the ones affected by this change. If you are still interested in contributing your improvement, please fill out the following short form by no later than May 3rd, and we will get back to you with the additional steps necessary once we have had time to assess the PRs of those still interested:
https://forms.gle/V7SrPPMZDo6iGDYu8


text:
Phoenix (constellation)

https://github.com/instructlab/taxonomy/issues/830
If your PR is related to a contribution to the taxonomy, please, fill
out the following questionnaire. If not, replace this whole text and the
following questionnaire with whatever information is applicable to your PR.
Describe the contribution to the taxonomy

...
...
...

Input given at the prompt

   ...

Response from the original model

  ...

Response from the fine-tuned model

  ...

Contribution checklist

[ ] The contribution was tested with ilab generate
[ ] No errors or warnings were produced by ilab generate
[ ] All commits are signed off (DCO)
[ ] The qna.yaml file contains at least 5 seed_examples
[ ] The qna.yaml file was linted and prettified (yaml-validator can do both)
[ ] An attribution.txt file in the same folder as the qna.yaml file
[ ] Content does not include PII or otherwise sensitive or confidential information
[ ] Content does not include anything documented in the project's Avoid these Topics guidelines

@instructlab-bot precheck

Closing per the combined PR here: https://github.com/instructlab/taxonomy/pull/1159

authors: flyingbarron jjasghar


text:
Ability to Upload YAML documents

Feature request to allow UI users to upload yaml docments. These yaml documents, when following the correct schema, should be able to be parsed and auto filled into the submission forms for knowledge and skill, enabling users to continue working on unfinished yamls, or submit finished yamls from their local devices to the taxonomy through the UI.
This is issue can be paired with issue #240, but will likely be a bit more complex as it will require a new button to be added and a reverse engineering of the download process.

https://github.com/instructlab/ui/pull/324

repo: instructlab/ui


text:
🛑 Staging Portal is down

In 93aff29, Staging Portal ($STAGING_URL) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Staging Portal is back up in 16e17b5.

repo: instruxmedia/webserver-uptime


text:
Add sigv4 authentication

Sigv4 is a prerequisite for connecting to a Prometheus data source that is managed by AWS
https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-query-standalone-grafana.html
Upgrade to Grafana 7.3.1 is required since sigv4 is introduced there

also @pb82 FYI, this PR upgrades the base image to 7.3.6

authors: HubertStefanski vladimirmukhin


text:
Revert "ARC-136 remove csrfProtection middleware from jira/sync to resolve retry issue in Safari "

Reverts integrations/jira#440

@rachellerathbone close this one as well.  It's a bug and there's no risk except a security consideration which we've already assessed.

authors: mboudreau rachellerathbone

repo: integrations/jira


text:
Worker can not compile with newest integritee-node dep

Getting the following compile errors:
Compiling integritee-node-runtime v0.9.3 (/home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime)
  error[E0407]: method `not_unlocking_merge_schedules` is not a member of trait `pallet_vesting::WeightInfo`
     --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:105:2
      |
  105 | /     fn not_unlocking_merge_schedules(l: u32, s: u32, ) -> Weight {
  106 | |         (46_298_000 as Weight)
  107 | |             // Standard Error: 1_000
  108 | |             .saturating_add((144_000 as Weight).saturating_mul(l as Weight))
  ...   |
  112 | |             .saturating_add(T::DbWeight::get().writes(3 as Weight))
  113 | |     }
      | |_____^ not a member of trait `pallet_vesting::WeightInfo`

 error[E0407]: method `unlocking_merge_schedules` is not a member of trait `pallet_vesting::WeightInfo`
     --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:117:2
      |
  117 | /     fn unlocking_merge_schedules(l: u32, s: u32, ) -> Weight {
  118 | |         (46_076_000 as Weight)
  119 | |             // Standard Error: 1_000
  120 | |             .saturating_add((148_000 as Weight).saturating_mul(l as Weight))
  ...   |
  124 | |             .saturating_add(T::DbWeight::get().writes(3 as Weight))
  125 | |     }
      | |_____^ not a member of trait `pallet_vesting::WeightInfo`

 error[E0437]: type `MaxAuthorities` is not a member of trait `pallet_aura::Config`
     --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/lib.rs:299:2
      |
  299 |     type MaxAuthorities = MaxAuthorities;
      |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a member of trait `pallet_aura::Config`

  error[E0438]: const `MAX_VESTING_SCHEDULES` is not a member of trait `pallet_vesting::Config`
     --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/lib.rs:532:2
      |
  532 |     const MAX_VESTING_SCHEDULES: u32 = 28;
      |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not a member of trait `pallet_vesting::Config`

  error[E0412]: cannot find type `Everything` in module `frame_support::traits`
     --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/lib.rs:238:47
      |
  238 |     type BaseCallFilter = frame_support::traits::Everything;
      |                                                  ^^^^^^^^^^ not found in `frame_support::traits`

  error[E0050]: method `vest_locked` has 2 parameters but the declaration in trait `vest_locked` has 1
    --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:34:20
     |
  34 |     fn vest_locked(l: u32, s: u32, ) -> Weight {
     |                       ^^^^^^^^^^^ expected 1 parameter, found 2
     |
     = note: `vest_locked` from trait: `fn(u32) -> u64`

  error[E0050]: method `vest_unlocked` has 2 parameters but the declaration in trait `vest_unlocked` has 1
    --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:45:22
     |
  45 |     fn vest_unlocked(l: u32, s: u32, ) -> Weight {
     |                         ^^^^^^^^^^^ expected 1 parameter, found 2
     |
     = note: `vest_unlocked` from trait: `fn(u32) -> u64`

  error[E0050]: method `vest_other_locked` has 2 parameters but the declaration in trait `vest_other_locked` has 1
    --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:57:26
     |
  57 |     fn vest_other_locked(l: u32, s: u32, ) -> Weight {
     |                             ^^^^^^^^^^^ expected 1 parameter, found 2
     |
     = note: `vest_other_locked` from trait: `fn(u32) -> u64`

  error[E0050]: method `vest_other_unlocked` has 2 parameters but the declaration in trait `vest_other_unlocked` has 1
    --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:69:28
     |
  69 |     fn vest_other_unlocked(l: u32, s: u32, ) -> Weight {
     |                               ^^^^^^^^^^^ expected 1 parameter, found 2
     |
     = note: `vest_other_unlocked` from trait: `fn(u32) -> u64`

  error[E0050]: method `vested_transfer` has 2 parameters but the declaration in trait `pallet_vesting::WeightInfo::vested_transfer` has 1
    --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:81:24
     |
  81 |     fn vested_transfer(l: u32, s: u32, ) -> Weight {
     |                           ^^^^^^^^^^^ expected 1 parameter, found 2
     |
     = note: `vested_transfer` from trait: `fn(u32) -> u64`

  error[E0050]: method `force_vested_transfer` has 2 parameters but the declaration in trait `pallet_vesting::WeightInfo::force_vested_transfer` has 1
    --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/weights/pallet_vesting.rs:93:30
     |
  93 |     fn force_vested_transfer(l: u32, s: u32, ) -> Weight {
     |                                 ^^^^^^^^^^^ expected 1 parameter, found 2
     |
     = note: `force_vested_transfer` from trait: `fn(u32) -> u64`

  error[E0599]: no method named `into_inner` found for struct `sp_runtime::sp_application_crypto::Vec<sp_consensus_aura::sr25519::app_sr25519::Public>` in the current scope
     --> /home/bhaerdi/.cargo/git/checkouts/integritee-node-c5afc37e7030f6f7/6b3f139/runtime/src/lib.rs:684:24
      |
  684 |             Aura::authorities().into_inner()
      |                                 ^^^^^^^^^^ method not found in `sp_runtime::sp_application_crypto::Vec<sp_consensus_aura::sr25519::app_sr25519::Public>`

I think that's a problem with the different substrate version, so I'm closing this issue for now.

repo: integritee-network/integritee-node


text:
BluetoothManager::get_devices() returns devices that are no longer present

BluetoothManager::get_devices() seems to return a list of all devices it ever seen rather than the ones that are currently in range.
Expected behavior should be similar to hcitool lescan which just lists devices in range.

BluetoothManager::get_devices() does not start a scan, it returns the list of devices BlueZ knows about, whether they are recently scanned or have been connected to in the past. This is the expected behavior as per BlueZ or blueman-manager. A function like get_nearby_devices which starts a scan and checks that the devices are also in range might clear this up.

I call BluetoothManager::start_discovery() and wait several seconds before calling BluetoothManager::get_devices() but still get previously connected devices that are no longer present. What is the best way to filter them out? I can try to connect and wait for failure but that takes too long.

Yes, after you start discovery, they should get an RSSI value different than 0 after a while. I'm not sure there's any other way to do this right now.

Thanks for RSSI tip. I found out that you have to call BluetoothDevice::get_rssi() before BluetoothManager::stop_discovery() to get valid values.
A get_nearby_devices() call would do this for you, so tag this issue as a feature request.

I implemented an additional method called removeDevices() in the adaptor class, which will remove all known devices from internal list (so getDevice() will return an empty list). I call this method just before calling startDiscovery() so I will receive only the current nearby beacons.
I've implemented it on the java side only (for c++ the method remove_device was already present)...

Hi Isimedia,
is the feature you implemented, already in the library? I eventually need this feature very much, therefore it would be great, if you could explain to me how I can use this function.
All the best
framspott94

I've done a pull request with the modification, so the maintainer can review the code and merge it if needed. For the moment you can clone my tinyb fork.
The method to call is
int cnt = manager.getAdapters().get(0).removeDevices();

Thanks for the answer! I cloned your fork and used it succesfully!
All the best - and thanks for the feature!
framspott94

I have added a new method called startNearbyDiscovery() in the main BluetoothManager class with a listener as argument to be notified when a new device is found until stopNearbyDiscovery() is called.
This approach is useful in my use case (and perhaps your's too...)

authors: framspott94 lsimedia petreeftime sbodmer whbruce

repo: intel-iot-devkit/tinyb


text:
Add raw storage definition to support uin8_t based messages

Would be an addition to  #446, #315 and #448

It's already trivial to create 8-bit storage as seen at https://github.com/intel/compile-time-init-build/blob/main/test/msg/message.cpp#L350 - I'm not sure what this adds?
Also a couple of notes:

raw_storage_t isn't a good name: all storage is "raw".
raw_view and raw_owning aren't good names: it's not raw on the outside, everything is still typed.

Honestly, I think what we have is all that's needed - a single storage definition on the outside (which only needs one definition and can then be used with any kind of message, owning or view) and a single using for the message type. Adding this extra stuff doesn't improve that?

Thank you for your honest reply and for your time reviewing my PR.
I'll probably not fully get your solution. I will try on Monday.
Thanks for the fast reply, and I wish you a nice weekend.

Thanks for the issue and the PR! I hope we can get to a good solution here because the use case of uint8_t for storage is clearly an important one.
I did notice looking through the (existing) code that the types seem to be a little coupled to stdx::span and std::array right now, maybe I could improve that...

Hi @Thurnheer, @elbeno made a PR that adds a test with uint8_t backed storage. Take a look at how he creates a message with owning storage here: https://github.com/intel/compile-time-init-build/pull/448/files#diff-e2731b151a028a5dbf30f15cc8365556236a62f752824ada09a55864c8c73061R350

authors: Thurnheer elbeno lukevalenty

repo: intel/compile-time-init-build


text:
model: xgboost: New model

A first pass at this is below. If you end up using it, applicable Co-authored-by's are as follows
Co-authored-by: John Andersen <johnandersenpdx@gmail.com>
Co-authored-by: Soren Andersen <sorenpdx@gmail.com>

import pathlib

import joblib
import pandas as pd
from xgboost import XGBRegressor
from sklearn.metrics import mean_absolute_error

from dffml import *

# TODO Add parameters you want to have access to within self.config here
# For example, search for n_estimators to see how that works
@config
class XDGRegressorModelConfig:
    directory: pathlib.Path
    features: Features
    predict: Feature
    n_estimators: int = 1000

class XDGRegressorModel(SimpleModel):
    CONFIG = XDGRegressorModelConfig

    def __init__(self, config) -> None:
        super().__init__(config)
        # The saved model
        self.saved = None
        self.saved_filepath = pathlib.Path(self.config.directory, "model.joblib")
        # Load saved model if it exists
        if self.saved_filepath.is_file():
            self.saved = joblib.load(str(self.saved_filepath))

    async def train(self, sources: Sources) -> None:
        # Get data into memory
        data = pd.DataFrame.from_records(
            [
                record.features()
                async for record in sources.with_features(
                    self.config.features.names() + [self.config.predict.name]
                )
            ]
        )
        # Select subset of predictors
        x_data = data[self.config.features.names()]
        # Select target
        y_data = getattr(data, self.config.predict.name)
        # XGBoost is a the leading software library for working with standard tabular data (the type of data you store in Pandas DataFrames,
        # as opposed to more exotic types of data like images and videos). With careful parameter tuning, you can train highly accurate models.
        # Parameters for xgboost
        #   n_estimators = 100-1000 range,
        #   learning_rate - In general, a small learning rate and large number of estimators will yield more accurate XGBoost models
        #       e.g. learning_rate=0.1
        #   n_jobs - specify number of cores to run in parallel
        # my_model = XGBRegressor()
        # my_model = XGBRegressor(n_estimators=1000)

        # TODO Tweak this?
        self.saved = XGBRegressor(
            n_estimators=self.config.n_estimators, learning_rate=0.05
        )
        # my_model = XGBRegressor(n_estimators=1000, learning_rate=0.05, n_jobs=4) *NOTE:  n_jobs made it slightly worse

        # TODO Tweak this?
        self.saved.fit(
            x_data, y_data, verbose=False,
        )

        # Save the trained model
        joblib.dump(self.saved, str(self.saved_filepath))

    async def accuracy(self, sources: Sources) -> Accuracy:
        predictions = []
        acctuals = []
        # Make predictions
        async for record in self.predict(
            sources.with_features(
                self.config.features.names() + [self.config.predict.name]
            )
        ):
            # Appends prediction and accutal to respective lists
            predictions.append(record.prediction(self.config.predict.name).value)
            acctuals.append(record.feature(self.config.predict.name))
        # Calculate MAE
        return mean_absolute_error(predictions, acctuals)

    async def predict(self, records):
        # Grab records and input data (X data)
        saved_records = []
        input_data = []
        async for record in records:
            saved_records.append(record)
            input_data.append(record.features(self.config.features.names()))
        # Make predictions
        predictions = self.saved.predict(pd.DataFrame.from_records(input_data))
        # Update records and yield them to caller
        for record, prediction in zip(saved_records, predictions):
            record.predicted(self.config.predict.name, prediction, float("nan"))
            yield record

Hi, I am looking for a first time contribution. I would like to try and take this on, if you think it will be managable for a newbie?

authors: oliverob pdxjohnny

repo: intel/dffml


text:
CI: consider using chronic to reduce log output

The CI logs can be pretty big, and mostly full of information about things that worked, that are expected to work, like installing and building components necessary to run the actual tests.
This can make finding the actual error quite difficult. It is probably more difficult in Travis than in Jenkins (which is broken into stages, making it easier to narrow in).
As we are transitioning from Travis to Actions, we should contemplate if the situation still exists, and if so, consider using chronic to wrap the common expected-to-work items (package installs, compiles etc.), so they are benign unless they fail. This may make perusing the CI failure logs easier.

As we are transitioning from Travis to Actions, we should contemplate if the situation still exists, and if so,
consider using chronic to wrap the common expected-to-work items (package installs, compiles etc.),

Actions seems to work fine on this so closing.

authors: grahamwhaley mythi