text:
Nightcode-2.3.1 jar not working in Ubuntu 16.04

Hi,
This is what happens when I try to run the Nightcode-2.3.1 jar on my Ubuntu 16.04 system:
$ java -jar ./Nightcode-2.3.1.jar
Error: Could not find or load main class nightcode.core

You are most likely using OpenJDK, which doesn't include JavaFX. Please run sudo apt-get install openjfx to install that. Alternatively, you could install the deb version, which bundles the JRE so your system JRE/JDK won't matter.

Let me know if you still have issues after trying either suggestion.

The first option (openjfx) worked, thanks!
I'm getting some warning messages, hopefully nothing to worry about:
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
mar 01, 2017 11:44:39 AM javafx.fxml.FXMLLoader$ValueElement processValue
WARNING: Loading FXML document with JavaFX API of version 8.0.65 by JavaFX runtime of version 8.0.60
mar 01, 2017 11:44:43 AM javafx.fxml.FXMLLoader$ValueElement processValue
WARNING: Loading FXML document with JavaFX API of version 8.0.65 by JavaFX runtime of version 8.0.60
mar 01, 2017 11:44:43 AM javafx.fxml.FXMLLoader$ValueElement processValue

authors: martinodb oakes

repo: oakes/Nightcode

license: unlicense


text:
Specifying that Rudr implements alpha 1 of the spec

Minor change in messaging to make it clear that Rudr currently implements release 1.0.0-alpha1 of the spec.

LGTM

source: gharchive/pull-request

authors: hongchaodeng vturecek

repo: oam-dev/rudr

license: MIT

license_type: permissive

license_source: github-api


text:
[GLUTEN-3302][VL] Fix dead lock of BackendJniWrapper static loading

What changes were proposed in this pull request?
BackendJniWrapper extend JniInitialized and JniInitializer invoke BackendJniWrapper#initializeBackend static method too, it will cause dead lock on static object lock.
PR #3929 change BackendJniWrapper#createExecutionCtx usage and let BackendJniWrapper init first in some case trigger this issue. Before 3929, JniInitializer's static lock was hold by other JniWrapper initialization which extend JniInitializer, it's safe to hold BackendJniWrapper static lock.
(Fixes: #3302)

@zhztheplayer

@zhztheplayer How about this?

Very convincing, thank you very much for catching.

===== Performance report for TPCH SF2000 with Velox backend, for reference only ====

query
log/native_3305_time.csv
log/native_master_09_26_2023_dffd4a993_time.csv
difference
percentage

q1
43.67
43.11
-0.557
98.73%

q2
24.70
24.77
0.067
100.27%

q3
36.98
37.78
0.802
102.17%

q4
41.56
41.79
0.230
100.55%

q5
68.12
70.23
2.112
103.10%

q6
6.50
6.52
0.018
100.28%

q7
89.01
86.01
-2.998
96.63%

q8
83.14
79.93
-3.212
96.14%

q9
116.02
115.79
-0.225
99.81%

q10
49.53
46.51
-3.024
93.90%

q11
18.96
19.54
0.587
103.10%

q12
23.89
24.04
0.153
100.64%

q13
49.91
50.28
0.378
100.76%

q14
15.73
14.27
-1.465
90.69%

q15
29.71
27.99
-1.719
94.22%

q16
16.68
15.97
-0.714
95.72%

q17
121.42
120.66
-0.765
99.37%

q18
165.07
163.74
-1.322
99.20%

q19
13.52
12.08
-1.439
89.35%

q20
30.27
27.57
-2.696
91.09%

q21
237.32
239.19
1.874
100.79%

q22
15.34
15.34
-0.004
99.97%

total
1297.04
1283.12
-13.919
98.93%

@zhztheplayer @Yohahaha  it looks like the TPCDS test in github action is green when merging the previous patch, is it due to the scale factor too small? can we add a gate check on this?
thanks, -yuan

@zhztheplayer @Yohahaha it looks like the TPCDS test in github action is green when merging the previous patch, is it due to the scale factor too small? can we add a gate check on this?
thanks, -yuan

I found that issue in TPCDS sf1000 and can not repro every time, not sure how to add check.

It's a random issue related to JVM's class loading order which is naturally randomized. Class loading happens only once typically in one JVM process that why it's more reproduceable in cluster. UT will hardly cover the case unless we enable forked processes to run UTs.
I think adding a GHA local-cluster job could help either and we can try adding one at a good time.

authors: GlutenPerfBot Yohahaha zhouyuan zhztheplayer

repo: oap-project/gluten


text:
Fix scan format validation

What changes were proposed in this pull request?
Previously, the scan format validation does not take effect for datasource v2. This PR aligned the validation logic for both v1 and v2.
How was this patch tested?
under test

Some is duplicated with https://github.com/oap-project/gluten/pull/904

Some is duplicated with #904

This PR mainly focuses on fixing the validation logic for v2. Will remove the change to ORC and leave it for PR#904.

authors: jinchengchenghh rui-mo


text:
add Orc read support

add support for ORC reading with int RleV2

@rui-mo @zhejiangxiaomai

the corresponding gluten PR gluten orc-support

repo: oap-project/velox


text:
Fixes small bug with getting short code

What is this PR
Indigenous Studies had the incorrect matching expression for converting to short codes
Had to manually edit this to get it functioning when importing my schedule (below is the proof of this lol)

thank

repo: object-Object/mycampus-calendar-rs


text:
Unable to identify OData protocol version [New bug introduced to 4.20.0 & 4.21.0]

I've been using v4.19.0 for awhile, decided to update to 4.20.0 and now all my queries return a "Unable to identify OData protocol version" error message.
Using the client to query ProjectServer Odata API.
Query example:
https://siteserver.sharepoint.com/sites/pwa/_api/ProjectData/Projects?$filter=ProjectId eq guid'ef2a052f-5609-e511-80c8-00155d68241d'&$select=ProjectId,ProjectModifiedDate,ProjectName,ProjectWorkspaceInternalUrl,EnterpriseProjectTypeDescription,EnterpriseProjectTypeId
Please let me know if you need more information.

Hi,
This is very strange indeed. I don't see in the change log anything that could cause such major regression.
Unfortunately I don't have access to siteserver.sharepoint.com, so I have no possibility to test this. Perhaps you can trace HTTP traffic in Fiddler and send me the response? My mail address is vagif.abilov at gmail.

Hi,
Thank you very much for your prompt response. I played around with it a bit more but removing the client and few dependencies entirely and adding them again seems to have solved the issue.
Apologies for raising an issue needlessly. If I find out how to replicate the issue I'll keep you posted.
Regards,
Ali

No problem. This one really scared me. I reran all my tests, including those I ran agains Microsoft reference services (using various OData versions), and they all passed. So I hope there's nothing in the library on this matter. Otherwise let me know, I am closing the issue for now.

source: gharchive/issue

authors: cdotnet object


text:
I think the FrameLayout is enough.

I think the FrameLayout is enough,because these views are stacked.

yeah.u r right.thanks.

在实际使用中发现一个问题，没有提供返回当前StateLayout所处状态的方法，如果要获取当前StateLayout的状态只有通过反射来做了。

晚点我提交个PR

authors: lsxiao objectlife

repo: objectlife/StateLayout

license_source: bigquery


text:
Native module VectorIconsModule tried to override VectorIconsModule for the module name RNVectorIconsModule

Getting this error while trying to install NativeStarter Pro Seed

Sounds like you've integrated it twice, however I cannot provide support for NativeStarter Pro Seed, please ask them.

I have the problem did you find a solution ?

I solve the issue modifying the MainActivity.java file. Vector module was declarated several time. Just remove the import and it works.

I found my issue in MainApplication.java, it had repetitions of
import com.oblador.vectoricons.VectorIconsPackage;
import com.microsoft.codepush.react.CodePush;
and  changed
protected List getPackages() {
return Arrays.asList(
new MainReactPackage(),
new VectorIconsPackage(),
new CodePush(null, getApplicationContext(), BuildConfig.DEBUG),
new VectorIconsPackage(),
new CodePush(null, getApplicationContext(), BuildConfig.DEBUG)
);
}
TO
protected List getPackages() {
return Arrays.asList(
new MainReactPackage(),
new VectorIconsPackage(),
new CodePush(null, getApplicationContext(), BuildConfig.DEBUG),
);
}

@tichon007  In my case i had to remove duplicate imports from MainApplication.java.
Thank you so much for the heads-up.

I solve the issue modifying the MainActivity.java.

Yes, it multiply several time in MainApplication.java

I had the same problem. You can see the locations of duplicates in the screenshots below. Just remove the duplicates, and it works fine.

Yep, same here. It happens with you run react-native link react-native-vector-icons. Is something in the link script supposed to check if it has already been added?

should be reopened

@phiricharles101 Thanks! It worked :)
had
import com.facebook.react.ReactApplication;
import com.oblador.vectoricons.VectorIconsPackage;
import com.oblador.vectoricons.VectorIconsPackage;
import com.facebook.react.ReactNativeHost;
import com.facebook.react.ReactPackage;
import com.facebook.react.shell.MainReactPackage;
import com.facebook.soloader.SoLoader;
and
@Override
protected List getPackages() {
return Arrays.asList(
new MainReactPackage(),
new VectorIconsPackage(),
new VectorIconsPackage()
);
}

After React Native 0.60. You don't need to add packages in MainApplication.java, because they come up with Autolinking of packages  in this release.

After React Native 0.60. You don't need to add packages in MainApplication.java, because they come up with Autolinking of packages in this release.

@MrAhmedSaeed  .
sir,
if module not support the autolink then what should to do ?
I've 3 module which one not supported  autolink.

I am using React Native 0.61.5. By mistake I linked package manually. In solution, I unlink it manually.
Just run "react-native unlink react-native-vector-icons"
I got this solution from here https://stackoverflow.com/a/57272709

If you are on RN >= 0.60.0, then most of the packages are linked automatically.
If you have install and does linkage manually then run command "react-native unlink package_name".
And re run your project.
This is how I resolved this.

After React Native 0.60. You don't need to add packages in MainApplication.java, because they come up with Autolinking of packages in this release.

Thanks man

I solve the issue modifying the MainActivity.java file. Vector module was declarated several time. Just remove the import and it works.

authors: Inactivity05 JonasDralle MikaOY MrAhmedSaeed ShawRohit TheRealJAG amitgarg8085 dedisetiaji fahidmohammad hyorax kukokp ntomallen oblador parmeet9891 phiricharles101 sevilgenysf tichon007

repo: oblador/react-native-vector-icons


text:
AP has no internet access - wlan1 & wlan0

I have two USB WiFi adapters. One acts as the AP and one connects to the WiFi network with internet access. In this case I'm using my homes WiFi. This is using the Raspberry Pi Model B.
I run the following command (random password - keyboard bashed for this example):
sudo create_ap wlan0 wlan1 PiFi 5y54YHJg6
I see the AP fine and connect to it on both my PC and phone (android). It connects fine but yet It has no Internet access.
Any ideas? It works fine on my laptop running Ubuntu 16.04 (using different adapters).

Check #151, probably you have the same issue.

I've read through that issue and It doesn't seem to work. I tried the network interfaces and it still didn't seem to provide internet access.

authors: Crasha oblique


text:
update multipolar neuron def

Fixes #3
That's pretty amazing, issue 3!

The text definition looks good to me.
But multipolar neuron is logically defined as neuron and ('has characteristic' some 'multipolar neuron morphology'), and multipolar neuron morphology (PATO:0070026) is defined as “a cell morphology that inheres in neurons which possess single axon and many dendrites and dendritic branches”.
Should the definition of multipolar neuron morphology in PATO be updated as well so as to avoid explicitly referring to an axon? Otherwise there would be a discrepancy between the text definition of multipolar neuron and its logical definition.

made the PR for PATO here: https://github.com/pato-ontology/pato/pull/467

authors: gouttegd shawntanzk

repo: obophenotype/cell-ontology


text:
updating in place?

If we want to update the marks in place in the DOM rather than throw them away and create a new one on each tick (in the context of the time animations, and later interactions), we can pass the previous node as part of the context (as in the patch below), and use join rather than append.
(And then, why not go further and always pass a g element, on any call to render — that is, independently of whether it's a previously rendered node or a new one just created with create("svg:g", context)? The mark would still be free to ignore it and return something else, of course.)
diff --git a/src/marks/dot.js b/src/marks/dot.js
index e4140b55..3442267f 100644
--- a/src/marks/dot.js
+++ b/src/marks/dot.js
@@ -1,4 +1,4 @@
-import {path, symbolCircle} from "d3";
+import {path, select, symbolCircle} from "d3";
 import {create} from "../context.js";
 import {positive} from "../defined.js";
 import {identity, maybeFrameAnchor, maybeNumberChannel, maybeTuple} from "../options.js";
@@ -55,13 +55,12 @@ export class Dot extends Mark {
     const {x: X, y: Y, r: R, rotate: A, symbol: S} = channels;
     const [cx, cy] = applyFrameAnchor(this, dimensions);
     const circle = this.symbol === symbolCircle;
-    return create("svg:g", context)
+    return (context.node ? select(context.node) : create("svg:g", context)
         .call(applyIndirectStyles, this, scales, dimensions)
-        .call(applyTransform, this, scales)
-        .call(g => g.selectAll()
+        .call(applyTransform, this, scales))
+        .call(g => g.selectAll(circle ? "circle" : "path")
           .data(index, i => i)
-          .enter()
-          .append(circle ? "circle" : "path")
+          .join(circle ? "circle" : "path")
             .call(applyDirectStyles, this)
             .call(circle
               ? selection => {
diff --git a/src/plot.js b/src/plot.js
index 51864c40..6a9ec847 100644
--- a/src/plot.js
+++ b/src/plot.js
@@ -376,7 +376,7 @@ export function plot(options = {}) {
           }
           const ifacet = [...facet.filter(i => T[i] < time1), ...(currentTime < time1) ? Ii : [], ...facet.filter(i => T[i] >= time1)];
           const index = mark.timeFilter(ifacet, T, currentTime);
-          timeNode = mark.render(index, scales, interp, dimensions, context);
+          timeNode = mark.render(index, scales, interp, dimensions, {...context, node: timeMark.node});
         } else {
           // here typically t = 0;
           const index = mark.timeFilter(facet, T, currentTime);

I think we need this not only for performance, but to allow users to click on the chart—currently if you click on a mark while it's updating, the event does not bubble up and reach the chart (probably because the svg element you clicked has been withdrawn from the DOM and replaced with a new one).

(To reconsider in light of the new render transform.)

See, e.g. https://observablehq.com/@fil/plot-animate-a-bar-chart/2

Another experiment here https://observablehq.com/@observablehq/plot-bar-chart-transitions

repo: observablehq/plot

license: ISC


text:
Permalink to graphs

OCaml speed had this very useful feature where the user can make the selection on the UI, get a permalink that can be shared with other users. This turned out to be very useful to share insights rather than shared pdfs of graphs around. Can we support such as feature in sandmark nightly? If streamlit has such a feature, then it would be easy enough to extend that. Related https://discuss.streamlit.io/t/how-to-give-an-input-option-for-url/7414/9.

It would be nice to be able to share links to the whole results page, too.

Closed in #108

authors: gadmm kayceesrk punchagan

repo: ocaml-bench/sandmark-nightly


text:
Split opam-0install and opam-0install-cudf

opam-0install and opam-0install-cudf are both separated project and do not interact with each other.
Adding opam-0install-cudf to this repository (https://github.com/ocaml-opam/opam-0install-solver/pull/11) made sense at the time because the codebase was a copy/replace from opam-0install and i wanted to keep the changes in sync.
Nowadays, while the code hasn't change that much, i feel like they're both different enough, and can even impede each other (e.g. there is no CI because of https://github.com/ocurrent/ocaml-ci/issues/257).
Thus i propose to split this repository into two:

opam-0install would move to the ocurrent org (i feel that it makes sense, but feel free to propose something else)
opam-0install-cudf would move to ocaml-opam/opam-0install-cudf

@talex5 what do you think?

Splitting seems fine, but I don't see why this one needs to move. It uses opam-format package metadata from opam-repository and is used in other opam-related tools (e.g. opam2nix), but it has nothing in particular to do with OCurrent, so I think it's better to keep it here.

It uses opam-format package metadata from opam-repository and is used in other opam-related tools (e.g. opam2nix), but it has nothing in particular to do with OCurrent, so I think it's better to keep it here.

fair enough, my reasoning came from the fact i thought opam-0install was mostly only used for ocaml-ci, i didn't know about other users such as opam2nix.
I'll open a PR and set that up soon


text:
Lint before pinning to avoid editor spinning

Also, add a CHANGES file. We should release after this is merged.

I think the CI failure is transient/has been fixed in opam-repository but I don't seem to have the ability to restart the failed build. Could someone kick it, please?

repo: ocaml/ocaml-travisci-skeleton


text:
docs: Automated Changelog Update for v5.0.0-beta6

copilot:all
Automated changes by create-pull-request GitHub action

🤖 Generated by lychee action
Summary

Status
Count

🔍 Total
1258

✅ Successful
378

⏳ Timeouts
0

🔀 Redirected
0

👻 Excluded
879

❓ Unknown
0

🚫 Errors
0

Full action output
Full Github Actions output


text:
[Bug]: The custom environment name can be consistent with the default environment name

ODC version
odc424
OB version

What happened?

What did you expect to happen?
Unavailable and consistent with built-in environment name
How can we reproduce it (as minimally and precisely as possible)?
Create a custom environment named Development
Anything else we need to know?
No response
Cloud
No response

pass

repo: oceanbase/odc


text:
[Bug]: Search box dropdown database page crashes

ODC version
odc430
OB version

What happened?
https://github.com/oceanbase/odc/assets/143492234/06825943-4ff8-4ac6-b8bf-fc5a960e6131
What did you expect to happen?
Page does not crash
How can we reproduce it (as minimally and precisely as possible)?

Anything else we need to know?
No response

Fixed In Commit 32f81a2f7dfcb38dcd3bd242fdb2260c878217a9
------
畅晚
Wed May 29 09:54:15 2024 +0800

pass


text:
fix(data-transfer): only inject sys tenant config when it's configured in datasource

What type of PR is this?
type-bug

What this PR does / why we need it:
There are some issues,  such as #1030 and #1158 , are caused by the sys tenant configs.
On the one hand, due to the fact that after OceanBase4.x, ob-loader-dump no longer relies on the account and password of sys tenants. On the other hand, this configuration has security issues.
Therefore, we prohibit users from filling in the sys tenant account password when initiating transfer tasks.
Which issue(s) this PR fixes:

Fixes #1030 and #1158

also fix #237


text:
fix(security): read-write "id" field may lead to overstep

Task Description
Read-write "id" field may lead to overstep
Solution Description
Make id field in DTO objects readonly
Passed Regressions
manually
Upgrade Compatibility
Compatible
Other Information

Release Note

LGTM

LGTM

the title may use :  security: balbla, for automatic changelog generation

the title may use : security: balbla, for automatic changelog generation

get!

authors: PeachThinking smallsheeeep yhilmare yizhouxw


text:
Restore profile header

It refers to this

Seems like bseides Sales metric header stats values are correct. I'll come back on this once we have #970 restored.

authors: AnaLoznianu claudiaHash

repo: oceanprotocol/market


text:
ionic and ng2-translate

an error occurred when trying to implement ng2-translate with ionic2 - reason missmuch of angular version.
the error:
TypeScript error: C:/code/.../node_modules/ng2-translate/ng2-translate.d.ts(1,10): Error TS2305: Module "C:/code/../node_modules/@angular/core/index"
has no exported member 'ModuleWithProviders'
please provice in your md file how to get an older version of you module
tnx

Ionic 2 is still on angular 2 RC4, and ng2-translate requires RC5 (with the new ng modules).
You should fix the version of ng2-translate to 2.2.2 until you can upgrade angular

Perfect right! :dancers:

I'll add a note to the readme tomorrow :)

I just added an example folder with an ionic 2 example, hope this helps !

authors: guysan ocombe yuriwally

license: mit


text:
Proposal: improve 404 page or redirect -dev versions after release

I've been working with colleagues on mapping detection findings, which was a part of the 1.1.0 release.  Before release, this version was listed under 1.1.0-dev, and so our discussions often involved linking to the OCSF server with a version reference like so:
https://schema.ocsf.io/1.1.0-dev/classes/detection_finding?extensions=
As this was the only way to see the new detection finding class.  Now that 1.1.0 is released, the link above just goes to a basic 404 page.

I wonder if there's a better experience to provide here?  Ideas:

Simple: improve the basic 404 page so there are at least links back to OCSF schema proper.
More complicated: on release of a -dev version, would it make sense if /1.1.0-dev redirected to /1.1.0?

This 404 page is coming from Nginx, not the OCSF Server app. Different schema versions are literally handled by independent instances of the OCSF Server running on the same machine, fronted by Nginx.
Fixing is probably be possible with some additional Nginx configuration. Hopefully... because if that doesn't work, the only solution is a significant change to the OCSF Server allowing it to handle multiple schema versions itself.

I'm not familiar with that part of the app yet -- is the nginx configuration part of this repository or is it somewhere else?  I tried searching for it but no luck.

authors: alanisaac rmouritzen-splunk

repo: ocsf/ocsf-server


text:
robotJs Unable to fire click event on chrome browser.

robotJs Unable to fire click event on chrome browser.
mouseClick is not firing any event on chrome browser. I'm running a javascript code from the cmd and trying to click on a chrome tab. This event gets fired on every other application (even firefox) but the chrome.
Expected Behavior
mouseClick method is supposed to click on the chrome tab to bring it to forefront.
Current Behavior
click event not firing up at all when it is supposed to happen on chrome browser. No error either in the console.

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

RobotJS version:
Node.js version:
npm version:
Operating System:

This issue has been closed because it has been inactive for > 240 days.
You may reopen this issue if it has been closed in error.

repo: octalmage/robotjs


text:
🛑 Ahora+ (rrhh.octubre.org.ar) is down

In fc9ef35, Ahora+ (rrhh.octubre.org.ar) (https://rrhh.octubre.org.ar/api/health) was down:

HTTP code: 503
Response time: 890 ms

Resolved: Ahora+ (rrhh.octubre.org.ar) is back up in 5c6314d.

repo: octubre-softlab/octubre-upptime


text:
🛑 ISSA (issa.edificarseguros.com.ar) is down

In 4b57b07, ISSA (issa.edificarseguros.com.ar) (https://issa.edificarseguros.com.ar/api/health) was down:

HTTP code: 503
Response time: 1175 ms

Resolved: ISSA (issa.edificarseguros.com.ar) is back up in d07929b.


text:
🛑 GUAU (guau.umet.edu.ar) is down

In e0baa8f, GUAU (guau.umet.edu.ar) (https://guau.umet.edu.ar/api/health) was down:

HTTP code: 503
Response time: 844 ms

Resolved: GUAU (guau.umet.edu.ar) is back up in 3e64797.


text:
Can not remove placed blocks

For some reasons placed blocks can not be removed.

Solved in e51282e0f09a1be01757e2fcb2ae5de0e8dab85d


text:
more words for 'storage'

	cproj   :: proc(z: complex_double) -> complex_double ---
	cprojf  :: proc(z: complex_float) -> complex_float ---
	creal   :: proc(z: complex_double) -> double ---
	crealf  :: proc(z: complex_float) -> float ---

seems these 4 ids for type names are not highlited.

Which "ids"?

authors: CudaText-addons gingerBill

repo: odin-lang/sublime-odin


text:
Syncing or Downloading Reduced Size Images: Services

Allows functionality to do a full sync while downloading reduced size images, or just downloading all attachments while getting the images reduced size.
Involves:
-UI modification
-logic for determining whether an image is reduced size and we want to overwrite that with a full size image.
Depends on https://github.com/odk-x/services/pull/219 and https://github.com/odk-x/androidlibrary/pull/217 to work.
@wbrunette

@wbrunette
I'm storing the previous sync state as properties, and this is working now.

repo: odk-x/services


text:
[WIP] feat : add external http sensor at optimus

https://github.com/odpf/optimus/issues/138

Pull Request Test Coverage Report for Build 1854401221

20 of 38 (52.63%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 71.746%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

store/local/job_spec_adapter.go
8
12
66.67%

api/handler/v1beta1/adapter.go
12
26
46.15%

Totals

Change from base Build 1839481496:
-0.1%

Covered Lines:
5160

Relevant Lines:
7192

💛  - Coveralls

authors: coveralls siddhanta-rath

repo: odpf/optimus


text:
[BUG] 3 Broken links on "running kubernetes" page

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
https://egeria.odpi.org/open-metadata-resources/open-metadata-tutorials/lab-infrastructure-guide/running-kubernetes.html
shows 404 on all three links e.g.
https://odpi.github.io/egeria-charts/site/intro/k8s/
Expected Behavior
Links to work
Steps To Reproduce
Navigate to https://odpi.github.io/egeria-charts/site/intro/k8s/
Access any of three hyperlinks
Environment
- Egeria:
- OS:
- Java:
- Browser (for UI issues):
- Additional connectors and integration:

Any Further Information?
No response

Hi, Thanks...
We are in the process of migrating our docs over to a new repo, as well as adding some new content. Apologies for the current breakage.
The new location starts from https://odpi.github.io/egeria-docs/guides/admin/kubernetes/intro/
I'll update those links to avoid confusion - at some point we'll remove all the content

I've added a PR to direct the links to the new location
I'd be very welcome for your feedback on the new docs also - so please do raise any issues accordingly, ask questions, submit improvements etc. We'll be continuing that (for k8s) in https://github.com/odpi/egeria-docs

repo: odpi/egeria


text:
[BUG] Exception in IGC proxy caused by iterators

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Pagination params are not properly managed by RepositoryFindRelationshipsIterator, causing exceptions in igc-proxy. Judging by the similarities, it is possible that all iterators have this issue
2022-02-22 15:31:33.609 DEBUG 55140 --- [io-9445-exec-10] o.o.e.c.i.i.r.m.r.RelationshipMapping    : addSingleMappedRelationship - adding relationship: ff247351-5a8f-4fcc-b6f2-0713e422c36e:data_file_record@b1c497ce.54bd3a08.c6hn1i9sq.bukfo4j.i3u8dd.g2acraes43blt0nb71avudata_file_field@b1c497ce.60641b50.c6hn1i9sq.bukj51s.ve15al.mk89o65falg24f018ob1g
Tue Feb 22 15:31:33 EET 2022 igc-proxy Exception OMRS-AUDIT-9014 The Open Metadata Repository Service has generated an unexpected java.lang.IllegalArgumentException exception during method getRelationshipsForEntity.  The message was fromIndex(1000) > toIndex(2)
Tue Feb 22 15:31:33 EET 2022 igc-proxy Exception OMRS-AUDIT-9014 Supplementary information: log record id ac20880f-5adf-4de1-a484-bd856b156586 java.lang.IllegalArgumentException returned message of fromIndex(1000) > toIndex(2) and stacktrace of
java.lang.IllegalArgumentException: fromIndex(1000) > toIndex(2)
at java.base/java.util.AbstractList.subListRangeCheck(AbstractList.java:509)
at java.base/java.util.ArrayList.subList(ArrayList.java:1138)
at org.odpi.egeria.connectors.ibm.igc.repositoryconnector.mapping.entities.EntityMapping.getMappedRelationships(EntityMapping.java:961)
at org.odpi.egeria.connectors.ibm.igc.repositoryconnector.IGCOMRSMetadataCollection.getRelationshipsForEntity(IGCOMRSMetadataCollection.java:893)
at org.odpi.openmetadata.repositoryservices.localrepository.repositoryconnector.LocalOMRSMetadataCollection.getRelationshipsForEntity(LocalOMRSMetadataCollection.java:1997)
at org.odpi.openmetadata.repositoryservices.rest.server.OMRSRepositoryRESTServices.getRelationshipsForEntity(OMRSRepositoryRESTServices.java:2147)
at org.odpi.openmetadata.repositoryservices.rest.server.spring.LocalRepositoryServicesResource.getRelationshipsForEntity(LocalRepositoryServicesResource.java:782)
at jdk.internal.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1067)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:963)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:681)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
Expected Behavior
Proper pagination params are sent to igc-proxy
Steps To Reproduce
Search for an entity that involves igc-proxy in fetching it
Environment
- Egeria:
- OS:
- Java:
- Browser (for UI issues):
- Additional connectors and integration:

Any Further Information?
No response

Fixed in igc-connector https://github.com/odpi/egeria-connector-ibm-information-server/pull/679


text:
🛑 fromagerieamstutz.ch is down

In 802c637, fromagerieamstutz.ch (https://www.fromagerieamstutz.ch) was down:

HTTP code: 0
Response time: 0 ms

Resolved: fromagerieamstutz.ch is back up in 13b6748.

repo: odqo/upptime


text:
🛑 urbamonde.org is down

In 17bdd17, urbamonde.org (https://www.urbamonde.org) was down:

HTTP code: 429
Response time: 638 ms

Resolved: urbamonde.org is back up in 4f95954.


text:
🛑 urbamonde.org is down

In eb4abb3, urbamonde.org (https://www.urbamonde.org) was down:

HTTP code: 429
Response time: 577 ms

Resolved: urbamonde.org is back up in f7c34f2.


text:
🛑 Ipsilon-Dev is down

In 177b898, Ipsilon-Dev (https://ipsilon-dev.sgu.ru) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ipsilon-Dev is back up in 94e2eee.

repo: oec-ssu/status


text:
Merging type and @type in one array

Affected TD
{
"td": {
"id": "9d35b43b-7416-431d-a046-6e098c012cf9",
"geo:location": {
"geo:lat": "48.1516",
"geo:long": "17.1674"
},
"adapterId": "evchargers-01",
"securityDefinitions": {
"nosec_sc": {
"scheme": "nosec"
}
},
"description": "Service returning EV_chargers for given location",
"properties": {
"getChargersForLocation": {
"type": "number",
"@type": "adp:AmbientTemperature",
"readOnly": true,
"description": "Chargers ",
"forms": [
{
"op": "readproperty",
"href": "http://adapter:4000/api/v1/chargers"
}
],
"title": "getChargersForLocation"
}
},
"title": "EV_chargers",
"@context": [
"https://www.w3.org/2019/wot/td/v1",
{
"adp": "https://auroral.iot.linkeddata.es/def/adapters#",
"om": "http://www.ontology-of-units-of-measure.org/resource/om-2/",
"geo": "http://www.w3.org/2003/01/geo/wgs84_pos#"
},
"https://www.w3.org/2022/wot/discovery"
],
"security": [
"nosec_sc"
],
"@type": [
"adp:Device"
]
}
}

Solved after talking with @xdraho11

repo: oeg-upm/wot-hive


text:
Google Places as Remote Url

Any idea's how to approach this for a remote url data completer?
https://maps.googleapis.com/maps/api/geocode/json?address=:query
i tried, this.dataService = completerService.remote(this.googleGeoCode, 'results.formatted_address', 'results.formatted_address'); without any luck.

@kodeine, thanks for reporting.
This is a duplicate of issue #22

authors: kodeine oferh


text:
mismatched types error on armv7

Hi,
There's been a breakage affecting arm platforms recently (and x86 android too) and while some of the crates have already been fixed it seems the problem won't be fixed in a top-down manner. You will probably have to look into this:
Compiling users v0.4.3
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:280:40: 280:41 error: mismatched types:
 expected `*const u8`,
    found `*const i8`
(expected u8,
    found i8) [E0308]
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:280     from_utf8_unchecked(CStr::from_ptr(p).to_bytes()).to_string()
                                                                                ^
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:280:40: 280:41 help: run `rustc --explain E0308` to see a detailed explanation
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:365:61: 365:89 error: mismatched types:
 expected `*const i8`,
    found `*const u8`
(expected i8,
    found u8) [E0308]
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:365                 let user = unsafe { passwd_to_user(getpwnam(username_c.unwrap().as_ptr())) };
                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:365:61: 365:89 help: run `rustc --explain E0308` to see a detailed explanation
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:418:62: 418:92 error: mismatched types:
 expected `*const i8`,
    found `*const u8`
(expected i8,
    found u8) [E0308]
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:418                 let user = unsafe { struct_to_group(getgrnam(group_name_c.unwrap().as_ptr())) };
                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/odroid/.cargo/registry/src/github.com-48ad6e4054423464/users-0.4.3/src/lib.rs:418:62: 418:92 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to 3 previous errors

The alternative to doing casts is a switch to std::os::raw where applicable. What's the plan for this crate?

Hi,
I just made a load of changes, including removing some casts (which I think I originally wrote when I didn't know what I was doing). Try now?

It does compile on nightly - I can't tell from memory if it was 1.5 or nightly that didn't.

This crate doesn't use any unstable features anymore, so if it compiles now it should compile everywhere (I hope!)

No, that's not what I meant - the ARM issue bites differently before and after 1.6. The details are in the link.

I've found my old comment so it seems the issue was not about 1.5 but rather >= 1.6.
It doesn't help much building exa though, cause the root cause is still there and other crates, like number_prefix stop the show.

Sorry, I meant locale crate.

Ha, see what I mean? Before that debacle Rust used to be a cross-platform language but now you'd have to be thinking about stuff like this beforehand:
 Compiling users v0.4.4
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:326:35: 326:44 error: mismatched types:
 expected `*const i8`,
    found `*const u8`
(expected i8,
    found u8) [E0308]
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:326         members.push(from_raw_buf(*username));
                                                                                ^~~~~~~~~
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:326:35: 326:44 help: run `rustc --explain E0308` to see a detailed explanation
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:365:61: 365:89 error: mismatched types:
 expected `*const u8`,
    found `*const i8`
(expected u8,
    found i8) [E0308]
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:365                 let user = unsafe { passwd_to_user(getpwnam(username_c.unwrap().as_ptr())) };
                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:365:61: 365:89 help: run `rustc --explain E0308` to see a detailed explanation
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:418:62: 418:92 error: mismatched types:
 expected `*const u8`,
    found `*const i8`
(expected u8,
    found i8) [E0308]
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:418                 let user = unsafe { struct_to_group(getgrnam(group_name_c.unwrap().as_ptr())) };
                                                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/.cargo-1.5/registry/src/github.com-48ad6e4054423464/users-0.4.4/src/lib.rs:418:62: 418:92 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to 3 previous errors
Build failed, waiting for other jobs to finish...
Could not compile `users`.

This happens on Rust 1.5 which previously was OK.

Rust 1.5 is probably irrelevant by now, closing.

authors: ogham petevine

repo: ogham/rust-users


text:
Feedback from UG set-up

Alright, so here is all of my feedback from your awesome move-to-brain-brew set-up for UG. Sorry if this is a bit raw and disorganised. 😅

builder_files - I know the naming of this folder is not tied to Brain Brew, but I feel like scripts would be a better name. The way I see it, the YAML files in this folder are "scripts" that define "tasks".

brain_brew_config.yaml - very minor, but what would you think of calling this file brain-brew.config.yaml?

I come from a web front-end background, and that's how config files are usually named (e.g. webpack.config.js, postcss.config.js, etc.)
The Python package is called brain-brew, so I think this should be consistent (also I'm more of a kebab-case than snake_case kind of guy 😄).
All that being said, I'm not familiar with Python naming conventions, so I could be way off.

generate syntax - in the YAML builder files (scripts?), I find the generate syntax a bit confusing, as it encompasses both read and write operations (sometimes both in the same task, with save_to_file).
I feel like having separate, independent read (i.e. parsing a file/folder) and write (i.e. writing to a file/folder) tasks would make things a lot clearer. Here is how I see it:

In a read operation, you describe:

the file/folder name of the resource you want to parse,
its type (i.e. CSV, CrowdAnki JSON, YAML deck part, etc.),
the "deck parts" you want to parse from it, to which you give unique names (following a naming convention of sorts).

In a write operation, you describe:

the destination file/folder of the resource you want to write,
its type,
the named deck parts declared in the script's read tasks and how they are to be used in the destination resource.

This is a huge simplification of the problem, but do you see where I'm getting at?

Deck parts is what you call the various pieces of a deck's metadata, right? Would you be able to write down a list somewhere of all the deck parts that you have defined/identified, just so we're clear?

Perhaps it's your plan, but I feel like some of the deck parts could be split up even more so they could live in separate files like in AnkiDM -- I liked how templates and the deck's description lived in HTML files, the styles in a CSS file, etc.

Thanks for the feedback, let me take these in the order that makes most sense to me:
Structural changes

brain_brew_config.yaml - very minor, but what would you think of calling this file brain-brew.config.yaml?

The global config file will soon be fully removed, I hope. It is no longer useful, in my eyes, and I wish for everything that it does to be configurable in the builder files yaml files that define the tasks of how stuff is made 😏 So the media super-folder will soon be definable per task, so different decks can even use replacement media 👍

Perhaps it's your plan, but I feel like some of the deck parts could be split up even more so they could live in separate files like in AnkiDM -- I liked how templates and the deck's description lived in HTML files, the styles in a CSS file, etc.

That's the plan, indeed! I would like to have css and html be their own files too, but I'd like that to be optional, not necessary. The current issue is that I don't know how I should structure the files after this, while trying to maintain the ability to merge to and from crowdanki 🤔 the templates are either used or not, no worries there, but the for the css I think having a bunch of separate css files which can be combined together would be best. This way an extended deck can add just one css part to get some new functionality in their new card, or can overwrite just a specific part in order to change some functionality. All the while they keep the most recent changes in the main repo, with the minimum changes propagating out into them (and less work for us 😅 )
Just spit balling ideas, lemme know if anyone has a better suggestion 😁👍
Names of stuff

builder_files - I know the naming of this folder is not tied to Brain Brew, but I feel like scripts would be a better name. The way I see it, the YAML files in this folder are "scripts" that define "tasks".

In the sense of what I call things in the code I've pretty much been winging it on the names, just picking whatever makes sense in my head. Absolutely nothing in the system needs to be called that, and can be changed to whatever makes more sense 👍 A "Builder" made sense to me as it 'builds' the stuff, but yes I can also see a "script" also works 👍 I'll have a think about it, and would like to hear what others think.
However the other way to look at this is: what do we call the folder in the UG repo? Call it literally whatever you want 😁 as long as you run it in the command line or point to it in the script, s'all good. Same with every folder in any repo that uses UG. The global_config can even be renamed, as long as you run brain brew with -g name_of_config 👍

generate syntax - in the YAML builder files (scripts?), I find the generate syntax a bit confusing, as it encompasses both read and write operations (sometimes both in the same task, with save_to_file).

Same goes with these! The term "Generate" just makes sense to me, as it makes those things, however this one is entirely superfluous. generate csv as a top level key in the Yaml matches the CsvGenerate task in the code only because the key matches the regex .*csv.* 😄 Same goes for generate crowdanki or make me a crowd anki pls as it matches .*crowd[\s_-]*?anki.* which you can find here in the code. My intention here is to have these keys be flexible in that users can put whatever makes sense but still have it match an actual transform task. So something like english csv may make sense in this case, and would still work! 😁 I just did not want to limit users to a specific key set, which may change in the future, and that others may not like whatever naming convention is/was used, like Generate_Csv_Collections 😅 this way, you are free to do it yourself, as long as it matches only 1 of the tasks!
Deck Parts are the only special one right now, as the name is a top level task and it also matches each of the other types in it's children (their X_from_source type, such as notes_from_crowdanki). So these are all equivalent:
generate deck parts:
   from csv:
      ...
   csvs:
      ...
   country_csv:
      ...

and the top level again does not need the term generate, though it is what the task does, it makes deck parts. The second reason deck parts are special is that they do not save as a file by default, and are merely held in memory so that other files can be made with them. One can save them to memory if they wish, but it is optional.

I feel like having separate, independent read (i.e. parsing a file/folder) and write (i.e. writing to a file/folder) tasks would make things a lot clearer.

It's a little more complicated than that, as a task does not simply read or write, usually both are done as it is more of a transform of one data into another, each time. Csv <-> Deck Parts <-> Crowd Anki. The only step that is just a read is reading a Deck Part from the local Yaml representation, as in
generate deck parts:
   from deck part:
      ...

So I chose for everything to be a generation task, you make a deck part, you make a csv, you make a crowd anki (and more to come) and that is the entirety of the top level key definitions. Also the 'read' tasks, which make the non deck part file tasks have no concept of the files in the system used previously. Only Deck Parts is a working list that is kept in memory, and can be referenced in other tasks. That's how I designed the system to be reliant on Deck Parts, as I want each source type to be entirely independent of the others.

Deck parts is what you call the various pieces of a deck's metadata, right? Would you be able to write down a list somewhere of all the deck parts that you have defined/identified, just so we're clear?

The Deck Parts to me are: Notes, Note Models, Headers, and Media. I go into detail on these here https://github.com/ohare93/brain-brew/issues/4#issuecomment-644975261
I would like to remove Headers entirely as a requirement, but that will take some more work in CrowdAnki in order to get to there. I believe you agree with me on that goal 😅 For the time being they are a necessary evil.
One can ofc break down Note Models into further smaller components, such as Templates and Fields, but I think they are related enough to be a part of the same general thing, even if they end up being stored in separate files. I hope to add in a filter for these two fields into Brain Brew soon, in the form of a whitelist or blacklist, so that one can choose to only use the Fields and Templates that you want (when doing a transform in either direction, that is). This will hopefully also be an option in CrowdAnki itself, which may remove the requirement of generating an Extended deck in the first place 🤔 😁 the user simply gets the option in CrowdAnki to include them or not (and I am sure we can set the default to be without the extra two templates).

but the for the css I think having a bunch of separate css files which can be combined together would be best

Totally! The blurring of the flags could live in its own file, for instance.

However the other way to look at this is: what do we call the folder in the UG repo?

I like scripts because it's very generic and quite a common name, but I also like .brain-brew, which is the complete opposite. Tooling folders like the latter seem to be becoming a convention of sorts, and they have the merit to be clear.

generate csv as a top level key in the Yaml matches the CsvGenerate task in the code only because the key matches the regex .csv.

Riiiight, I get it now! Pretty cool, actually. 🙂
A part of me can't help but wonder, though, whether it wouldn't be safer and clearer to know exactly which transformer is run. I'm thinking that if transformers were to become more specific or cross-purpose, regexes could become confusing or run into conflicts. A clearer identification would also:

make it a lot easier to find the transformer's source code and documentation;
avoid relying on people writing good, meaningful task names.

In my opinion, you could get the best of both worlds with something like:
- Task name that can be anything
  transformer: my_transformer
  # ... (rest of config)

I also wonder whether the deck-part-parsing "sub-tasks" (e.g. - from csv:) couldn't just be top-level tasks in their own right, with their own, purpose-built transformers -- something like:
- Parse note model from YAML
  transformer: note_model_from_yaml
  part_id: ug
  # ...

- Parse English notes from CSVs
  transformer: notes_from_csv
  part_id: english
  # ...

- Parse German notes from CSVs
  transformer: notes_from_csv
  part_id: german
  # ...

# etc., then the "output" tasks:

- Generate CrowdAnki JSON
  transformer: all_deck_parts_to_crowdanki
  output_folder: build/Ultimate Geography
  note_model: ug
  notes: english
  # ...

We could then come up with a naming convention for the transformers, like:

<deck_part_type>_from_<format> for deck parts parsers;
<deck_part|"all_deck_parts">_to_<format> for generators that take deck parts and output files.

The example above packs a lot of suggestions. I've probably over-simplified things since I don't have a full picture of all the use cases you're trying to cover, but do you see where I'm getting at? I should probably justify a bit more where the above syntax came from... 😅
Basically, in my opinion, what I'm suggesting would clear up a number of confusions, and notably the following:

- from csv:
  notes:
    # ...

The notes object adds a level of nesting, and is most often used on its own. By having dedicated transformers to parse each type of deck part from each file format that can store them, the whole thing can be declared in a single line, with zero extra level of nesting: transformer: notes_from_csv.

- generate deck parts:
  - from deck parts:
    #...

Some deck parts (note models and headers) can be stored in YAML files, but they end up as deck parts in Brain Brew's runtime memory as well. I had a lot of trouble getting my head around this because of these two lines.
The verb "generate" for a task that puts something in memory feels wrong (see item below about save_to_file).
from deck parts doesn't convey anything about the file format.

notes:
  name: english

The way deck parts are identified in memory through name is not very explicit in my opinion. That's why, in my example, I suggest using a key called part_id -- it's clear that it's an identifier that is meant to be used later on, and it also clarifies what the output of the transformer is (i.e. a deck part in memory).

save_to_file: src/deck_parts/notes/english.yaml

I'm back to what I was saying about a task/transformer doing both read and write operations. In my opinion, a transformer should only do one and be named accordingly: notes_from_csv already parses notes from CSV files; it shouldn't also write to a file (c.f. single-responsibility principle). Why not have dedicated transformers take care of writing each type of deck part to YAML?
- Save notes to YAML
  transformer: notes_to_yaml
  output_file: build/english.yaml
  notes: english

Wow, that was a lot, sorry. 😄 I hope there's something in there that makes sense! 😅

I haven't fully digested @axelboc's suggestions, but some partially thought-out, randomly-ordered (sorry!) responses.
Before diving in, none of the issues are IMO "breaking" and bikeshedding syntax should probably be relatively low in priority, at the moment. (Even though in the long run, getting syntax right is important.)

generate csv as a top level key in the Yaml matches the CsvGenerate task in the code only because the key matches the regex .csv.

I agree with @axelboc and also prefer unambiguous task names (for instance, it makes it easier to grep the source code for references :)). OTOH flexible names are indeed cool and neat, so perhaps there could be a "canonical" name, while also allowing matching by regex?

It's a little more complicated than that, as a task does not simply read or write, usually both are done as it is more of a transform of one data into another, each time.

Is this for example when you're writing a set of fields/columns to a CSV, which also contains other fields/columns which aren't being modified? (As would presumably be the case when converting a single language CrowdAnki deck to CSV.)

save_to_file

I admit that I like this key, even though it mixes reading and writing (and is "impure"/results in "side effects"), as it's a neat way of caching the intermediate data (the "deck part").
I don't think that it should really be used "in production", since IMO there should only be a single source of truth, but I imagine that it might be extremely valuable for quick debugging.

The way deck parts are identified in memory through name is not very explicit in my opinion. That's why, in my example, I suggest using a key called part_id

I found name as the name of the "id" to be OK. part_id or even just id would have also been OK.
Perhaps, for clarity, there could be an (unenforced) convention on identifier names (just like there is for variable names in some programming languages)? For instance ALL_CAPS or _underscore_prefixed or suffixed_? I'm not sure if it's worth it, though.
(Off-the-cuff-thought: As a far more disruptive suggestion, we could have the name as the top-level, e.g.
- Ultimate Geography:
  - from deck parts:
      note_models:
        - file: src/deck_parts/note_models/Ultimate Geography.yaml

according to the idea that what we're doing is defining "Ultimate Geography" for later use. ("Ultimate Geography = ..."). Obviously, there'd need to be a way of disambiguating between identifiers and writing-to-end-files transformations.
Aaah, but this wouldn't work in the case of CrowdAnki → CSV transformations, since we'd need the equivalent of (model_name, notes_name, headers_name) = ..., which wouldn't work with YAML.)

Sorry for the late reply, I have been rather busy. Will become a dad in the next month or so, so plenty to do! :grin: :tada:

I like scripts because it's very generic and quite a common name, but I also like .brain-brew, which is the complete opposite. Tooling folders like the latter seem to be becoming a convention of sorts, and they have the merit to be clear.

How about a recipe? :wink: this Brain-Brew after all! :grin: Though I would say the files should still be .yaml so that code editors can give highlighting and autocomplete for yaml specific keys :+1:

The way deck parts are identified in memory through name is not very explicit in my opinion. That's why, in my example, I suggest using a key called part_id -- it's clear that it's an identifier that is meant to be used later on, and it also clarifies what the output of the transformer is (i.e. a deck part in memory).

Good suggestion, I shall adopt this immediately :+1:

I'm back to what I was saying about a task/transformer doing both read and write operations. In my opinion, a transformer should only do one and be named accordingly: notes_from_csv already parses notes from CSV files; it shouldn't also write to a file (c.f. single-responsibility principle). Why not have dedicated transformers take care of writing each type of deck part to YAML?

- Save notes to YAML
  transformer: notes_to_yaml
  output_file: build/english.yaml
  notes: english

I get what you're saying, but this comes with a few downsides. First of all, the first line here would not be valid, as the rest is a dictionary, so this would either have to be made into an explicit comment key, or just a yaml comment itself. Which we can already do, I guess :sweat_smile: Secondly, having transformer be a key inline with the rest of the keys complicated type prediction when running prechecks to see if all the expected keys are present. It is still possible to do so with this structure, but it is more difficult, I believe. Also, it creates wasted lines of repetition, in my opinion, where a nested format would be simpler. For instance, the following:
- generate deck parts:
  - from deck parts:
      note_models:
        - name: Ultimate Geography
          file: src/deck_parts/note_models/Ultimate Geography.yaml
        - name: Ultimate Geography Combined Fields
          file: src/deck_parts/note_models/Ultimate Geography Combined Fields.yaml

would turn into
- generate deck parts:
  - from deck parts:
    - transformer: note_model
      name: Ultimate Geography
      file: src/deck_parts/note_models/Ultimate Geography.yaml
    - transformer: note_model
      name: Ultimate Geography Combined Fields
      file: src/deck_parts/note_models/Ultimate Geography Combined Fields.yaml

and the extra lines would only compound as more parts / transformers are used :sweat: This also would not work for tasks which take lists. I will keep the nesting as it is for now, but ofc anyone can point out something I missed :grin:

The verb "generate" for a task that puts something in memory feels wrong

Hmm :thinking: I get that. Do you have a better suggestion? create_deck_parts, build_deck_parts?

Edit: actually it seems that save_to_file is also used for the "final" writing-to-file, for instance in source_from_anki.yaml, which feels slightly weird.

I understand your confusion about this key. The exact same result could be achieved by having a separate write deck parts key which takes a list of part_ids and their write location, and then writes those to disk. Though I just felt that this was rather clunky, as all deck parts are immutable so their content will never change due to being used by other tasks. So writing them at the end of the process is unnecessary, though I agree would perhaps add clarity when reading the task list itself.
I will not change this behaviour at the moment, but anyone else can feel free to implement a write deck parts top level task :+1: which should be quite easy.

I agree with @axelboc and also prefer unambiguous task names (for instance, it makes it easier to grep the source code for references :)). OTOH flexible names are indeed cool and neat, so perhaps there could be a "canonical" name, while also allowing matching by regex?

Hmm, you both have swayed me. This is indeed an incredibly unimportant feature, that I have already spent too much time on, compared to the other large tasks that still exist. Standard expected keys will suffice. However I will leave the implementation using Regex for now, so that improvements can be made here in the future.

Changes made! See my PR for all the nitty gritty details: https://github.com/ohare93/brain-brew/pull/13 I just went with my best judgement from out conversation, but nothing is permanent :+1:
I have updated the Move-To-Brain-Brew branch of UG to reflect these changes :+1: Which you can find here https://github.com/ohare93/anki-ultimate-geography/commit/ab83d80f5c57e6caf81896b12f21e03fc46861cf
Remember to run pipenv install again, to update to the latest version of Brain Brew!

Sorry for the late reply, I have been rather busy. Will become a dad in the next month or so, so plenty to do! 😁 🎉

Wow, congrats!! 👶 🍼

How about a recipe? 😉 this Brain-Brew after all! 😁

Love it! 😁

First of all, the first line here would not be valid, as the rest is a dictionary [...]

Right, silly me, the syntax I had in mind was more like that of GitLab CI:
Save notes to YAML:
  transformer: notes_to_yaml
  output_file: build/english.yaml
  notes: english

Does dropping the top-level array syntax pose a challenge? I'm not all that familiar with the inner-workings of YAML (as you may have guessed 😄), so perhaps the array provides better ordering guarantees?

Secondly, having transformer be a key inline with the rest of the keys complicated type prediction when running prechecks to see if all the expected keys are present. It is still possible to do so with this structure, but it is more difficult, I believe.

Makes sense, I get you. Anyway, as you said, it doesn't matter if the transformer name is the top-level key since it's easy to add a comment above it! https://tenor.com/view/smart-so-sosmart-gif-15534259

Also, it creates wasted lines of repetition, in my opinion, where a nested format would be simpler.

I slightly disagree on this one: I think that repetition can make things clearer if it's the right kind of repetition. Repeating the transformer, in my opinion, is a good thing because it makes identifying all the transformations that take place easier. If this leads to config repetitions across multiple tasks, then this could be addressed specifically (i.e. by providing a syntax to share config between tasks at the top-level, for instance).
That being said, allowing multiple tasks to be defined as an array under the same transformer is conceptually sound, so this is more of a philosophical discussion. 😄

Changes made!

Awesome! part_id really makes things clearer, and build_deck_parts has a lot less of a file-writing vibe. 💯

Looking back at the updated build_deck_parts syntax, I still think this should be flattened or rethought somehow 🤔:
- build_deck_parts:
  - from_deck_parts:
    note_models: ...
    headers: ...
  - from_csvs:
    notes: ...

(I think) I fully understand the syntax now, so I'm happy to work with it for the time being. However, I do feel like the from_ keys interfere with readability. To me, a couple of more readable alternatives could be:

- build_deck_parts > - note_model > - from_deck_parts,
- build_deck_parts > - note_model_from_deck_parts,
- build_note_model > - from_deck_parts,
- build_note_model_from_deck_parts.

If I'm not mistaken, currently, a build_deck_parts "sub-transformer" (like from_deck_parts) can potentially handle multiple types of deck parts. The alternatives I suggest would basically require splitting the sub-transformers so that one sub-transformer can build only one type of deck part from one source format. Is this right, and if so, is this something you would consider doing in the long term?
Note that you could still nest multiple tasks under the same transformer if you wanted:
- build_deck_parts:
  - note_model_from_deck_parts:
    - part_id: Ultimate Geography
      file: src/deck_parts/note_models/Ultimate Geography.yaml
    - part_id: Ultimate Geography Combined Fields
      file: src/deck_parts/note_models/Ultimate Geography Combined Fields.yaml

That being said, allowing multiple tasks to be defined as an array under the same transformer is conceptually sound, so this is more of a philosophical discussion. smile

:laughing: I get your point about certain types of repetition though, that makes sense. Let's file this away as a bridge to cross after a bunch of bigger breaking changes fundamentally change the structure of the whole program again :sweat_smile:

Looking back at the updated build_deck_parts syntax, I still think this should be flattened or rethought somehow thinking:

:man_shrugging: not much difference in the end result here. Why do you prefer this flattened structure in this instance though? :thinking:
- build_deck_parts:
  - from_deck_parts:
      note_models:
        - part_id: Ultimate Geography
          file: src/deck_parts/note_models/Ultimate Geography.yaml
      headers:
        - part_id: default header
          file: src/deck_parts/headers/default.yaml

I made it the way it currently is as I had (have?) the expectation that a user will only ever perform 1 instance of reading all the deck parts, at the start of the Recipe. "Why split it up into multiple, if they'll just group them all together anyways?" was my thought :thinking: One can always make multiple from_deck_part tasks, each with a subset of the deck parts, though I cannot foresee a use case for that :thinking:
Anyways not explicitly against this change, but it will be low priority without further convincing :sweat_smile:

Fair enough 😅
Regarding from_deck_parts > note_models and the like, it's not so much about the flattening per se, but about the cognitive simplicity of one transformer having one input and one output (i.e. one deck part, not multiple deck parts). The flattening is something that can be gained from this simplicity.
Moreover, if you take the names of the deck part transformers on their own (from_deck_parts, from_csvs, etc.), they give me no information as to which deck part they are able to build. They are too generic and vague. Can from_csvs build note_models? Smaller, atomic transformers called note_model_from_deck_parts, or note_from_csvs, would be self-descriptive.
Side note, I'd recommend at least renaming from_deck_parts to from_yaml_deck_parts to convey the source format. Someone may want to store raw deck parts in another format one day. 🤷♂
Regarding build_deck_parts, I get that this is a way to group deck part building tasks, but I don't really get the benefit of that. If anything, I see two downsides:

It looks like a transformer in its own right, but it's not... not really anyway. The real transformers are from_csvs, etc., right? I feel like having transformers at different nesting levels in the recipe file increases the cognitive complexity.
You mention that users would group all deck part building tasks at the top of the recipe, but what's the harm in interleaving them with generate tasks? Someone may want to have a recipe that builds a deck part, then does something with it, then builds another deck part and does something else with it. I don't know, I feel like it's just an unnecessary constraint.

I hope my reasoning makes more sense, but no worries if I didn't manage to convince you 😉. Thank you for taking the time to chat about this! 🍻

You mention that users would group all deck part building tasks at the top of the recipe, but what's the harm in interleaving them with generate tasks? Someone may want to have a recipe that builds a deck part, then does something with it, then builds another deck part and does something else with it. I don't know, I feel like it's just an unnecessary constraint.

That is my expectation, yes. But as I said earlier, there is no limitation here. Someone can use multiple build_deck_parts tasks, or multiple from_deck_parts.

Side note, I'd recommend at least renaming from_deck_parts to from_yaml_deck_parts to convey the source format. Someone may want to store raw deck parts in another format one day. man_shrugging

Not a bad idea :+1:

Regarding from_deck_parts > note_models and the like, it's not so much about the flattening per se, but about the cognitive simplicity of one transformer having one input and one output (i.e. one deck part, not multiple deck parts).

But the same is not true about other transformers, like deck_parts from_crowdanki:
- build_deck_parts:
  - from_crowd_anki:
      folder: brain_brew_build/Ultimate Geography/
      notes:
        part_id: standard notes
        sort_order: [Country]
        save_to_file: src/deck_parts/notes/english.yaml
      note_models:
        - part_id: Ultimate Geography
          save_to_file: src/deck_parts/note_models/Ultimate Geography.yaml
      headers:
        part_id: default
        save_to_file: src/deck_parts/headers/default.yaml
      media:
        from_notes: true
        from_note_models: true

One can create Notes, multiple NoteModels, Headers, and Media. Would you also suggest breaking this up into multiple? :slightly_frowning_face:
Hmm, I thought I would be more against this, but looking back on my reasoning I am seeing some misalignment.
My main reason was to limit repetition which could lead to mistakes, but with Yaml Anchors that can be mitigated. Further weight behind your argument is that my actual code is written in this atomic structure that you are advocating for. Before my rewrite there was a lot more interdependencies between the different components, and the final one remaining (Notes need to know the names of the Note Models) can be fixed with no worries.

I think that smaller, atomic transformers called note_model_from_deck_parts, or note_from_csvs, would be self-descriptive.

God damn it, you've convinced me :sweat_smile: :laughing: I will work on this immediately. Better to get this stuff nailed down while nobody is using the program! :smile:

Further thought: perhaps each top level step should be explicitly named by the user :thinking: rather than it being a list. This would help with the end goal of allowing others to more easily replace one specific part of the Recipe. Rather than splitting up the steps into multiple files which is annoying and not as easily readable, or replacing a specific numbered step which would be prone to errors.
This could also just be optional, for repos such as UG which will actually use it, and the rest can use just a standard list.
Thoughts? :grin: This is the time for these high level design discussions, while everything is young and easily changed :laughing:

Just catching up with this. Awesome! 🍻 Glad to hear also that your code is already suited to making this change, I was worried it'd be too much work.

Further thought: perhaps each top level step should be explicitly named by the user 🤔 rather than it being a list.

Could you just please clarify what you mean with a quick example, to make sure I understand?

I'm back to it :muscle: Atomisation complete :+1:

Build parts are now much more atomic
Media files are read in groups, and can change for each export.

It is also possible to combine or subtract media groups before exporting them

Yamale is now used to validate Yaml

See pull https://github.com/ohare93/brain-brew/pull/14 for the code changes.
I have also updated the Move to Brain Brew branch of UG https://github.com/ohare93/anki-ultimate-geography/commit/903b21e0c2d0a4c6cd107dcdfca9458aad9a570d Here'ss an example of a difference:
Old
- build_deck_parts:
  - from_crowd_anki:
      folder: brain_brew_build/Ultimate Geography/
      notes:
        part_id: standard notes
        sort_order: [Country]
        save_to_file: src/deck_parts/notes/english.yaml
      note_models:
        - part_id: Ultimate Geography
          save_to_file: src/deck_parts/note_models/Ultimate Geography.yaml
      headers:
        part_id: default
        save_to_file: src/deck_parts/headers/default.yaml
      media:
        from_notes: true
        from_note_models: true

New
- build_parts:
  - notes_from_crowd_anki:
      source: brain_brew_build/Ultimate Geography/
      part_id: standard notes
      sort_order: [Country]
      save_to_file: src/deck_parts/notes/english.yaml
  - note_models_from_crowd_anki:
    - source: brain_brew_build/Ultimate Geography/
      part_id: Ultimate Geography
      save_to_file: src/deck_parts/note_models/Ultimate Geography.yaml
  - headers_from_crowd_anki:
    - source: brain_brew_build/Ultimate Geography/
      part_id: default
      save_to_file: src/deck_parts/headers/default.yaml
  - media_group_from_crowd_anki:
    - source: brain_brew_build/Ultimate Geography/
      part_id: all_anki_media
  - save_media_group_to_folder:
      parts: [all_anki_media]
      folder: src/deck_parts/media
      clear_folder: false

I will release this new version tomorrow so others can try it, so only local installs will work until then, fyi :+1: Anyways, glad to be back! :grin: I will not work on the NoteModel parts being separate files :tada:

That definitely looks cleaner!
I hope you're a happy dad now, though I'm also glad that you're still finding time to work on this! :)

Note Model is now separated :partying_face: CSS and Templates live in their own files, and Fields are done through Yaml. Again, see the latest in move_to_brain_brew for the details.
Just have some fixes to do to allow easy generation of the extended deck (is currently working, but requires duplication of Note generation step :angry:) then I'll release the latest and give y'all a proper update in the move_to_brain_brew branch :+1:

Great work!! It's looking really good. 💯

I guess this issue is resolved! :grin:

I guess this issue is resolved! :grin:

authors: aplaice axelboc ohare93

license: Unlicense


text:
🛑 Reportes is down

In d6b2850, Reportes (https://repository.ohelit.co/jasperserver/login.html) was down:

HTTP code: 502
Response time: 613 ms

Resolved: Reportes is back up in 8d4f2bb.

repo: ohelitco/status


text:
🛑 Reportes is down

In 48333d8, Reportes (https://repository.ohelit.co/jasperserver/login.html) was down:

HTTP code: 502
Response time: 575 ms

Resolved: Reportes is back up in 9a65b03.


text:
feat: Miss Counter Multiplier

Description

Add the number of assets missed to the miss counter instead of 1 each time.
Account for the increased number of misses when calculating the validVoteRate to determine if a validator should be slashed.

closes: [#42]

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] added appropriate labels to the PR
[ ] targeted the correct branch
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@e498431). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #48   +/-   ##
=======================================
  Coverage        ?   15.40%
=======================================
  Files           ?       27
  Lines           ?     8405
  Branches        ?        0
=======================================
  Hits            ?     1295
  Misses          ?     7079
  Partials        ?       31

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@zarazan is this ready to merge? looks like there's an issue with code cov but it's just not uploading

authors: adamewozniak codecov-commenter zarazan

repo: ojo-network/ojo


text:
'textDocument/codeAction' not support?

Hi, in README, the supported LSP functions are:
callHierarchy/incomingCalls
callHierarchy/outgoingCalls
textDocument/declaration
textDocument/definition
textDocument/documentSymbol
textDocument/implementation
textDocument/references
textDocument/typeDefinition
workspace/symbol
So textDocument/codeAction not support?

No it doesn't sorry. Implementing support for Code Actions is not trivial as the other methods unfortunately. See also this issue for why I chose not to support them and alternatives.

repo: ojroques/nvim-lspfuzzy


text:
Metadata editors should include JsonSchema validation?

Overview
If you open/import invalid metadata it should show errors and an "invalid" status in the header. Think if we need validation after editing or HTML inputs validation is enough

@romicolman
@pdelboca
This one is basically is not applicable to the current state of the app. It was for cases when you edit e.g. Table Schema as a separate file which is not possible now

repo: okfn/opendataeditor


text:
Update README.md

Include GoSquared example (after properly testing it) and fixed a typo

Thanks! It will be a couple of days before we can release a new version but we'll take try for this week.

Thanks for the PR! Tested it with new GoSquared account - interesting service, what turned you on to them ?

Excellent! Actually I met the CEO, James Gill in a 'London Technology Week' event, James Gill. After talking to him about the plans and roadmap for GoSquared, I became really interested.
I use it in a small size production Meteor application, and it works fantastic. I would say it integrates better than Google Analytics or KISSMetrics, that is the ones I have tested. Specially for social integration.

authors: aldofunes deanius pauldowman

repo: okgrow/analytics


text:
Update Documentation for Spread Syntax Option

Hey there! Ran into this issue following the given documentation and the option to use the default export of the library in my resolver map using the spread operator. The problem is that if you do that, your GraphQL server will complain at you for having three missing scalar types: UnsignedInt, UnsignedFloat and RegularExpression. These need to be added to the list of scalars that need to be added to the schema because the documentation isn't clear on this. Here's an updated list you can just copy over into the docs:
scalar DateTime

scalar NonPositiveInt

scalar PositiveInt

scalar NonNegativeInt

scalar UnsignedInt

scalar NegativeInt

scalar NonPositiveFloat

scalar PositiveFloat

scalar NonNegativeFloat

scalar UnsignedFloat

scalar NegativeFloat

scalar EmailAddress

scalar URL

scalar PhoneNumber

scalar PostalCode

scalar RegularExpression

Additionally, I'd like to suggest a process for making this simpler: in my own project I have all of my definitions in separate .gql files, which I then export from a index.js file, which looks something like this:
export { default as DateTime } from "./dateTime.gql"
// ... other exports ...

I then import this single index in my schema.js file where I use it like so:
import { makeExecutableSchema } from "graphql-tools"
import OKGGraphQLScalars from '@okgrow/graphql-scalars'
import * as types from "./types"
import * as enums from "./types/enums"
import * as inputs from "./types/inputs"
import * as interfaces from "./types/interfaces"
import * as scalars from "./types/scalars"
import * as unions from "./types/unions"
import * as resolvers from "./resolvers"

export const schema = makeExecutableSchema({
  typeDefs: [
    ...Object.values(types),
    ...Object.values(enums),
    ...Object.values(inputs),
    ...Object.values(interfaces),
    ...Object.values(scalars),
    ...Object.values(unions)
  ],
  resolvers: { ...OKGGraphQLScalars, ...resolvers }
})

This helps to keep my schema modular and easy to manage. While this may be overkill to make individual files for each scalar definition, you could still do something similar where you export a single OKGScalarDefinitions file as a named export that people can use in a similar fashion as I have above. That way they can quickly add all of the custom scalars to their schema in one place in only three lines of code, and updates to this package such as adding new scalars/resolvers will stay in sync, whereas right now any additions will break servers where the spread technique is used.

Fixed in v0.4.2

authors: Saeris ccuilla

repo: okgrow/graphql-scalars


text:
build.gradle 中的react-native 版本号和package.json 不匹配

可能会导致问题：screenPhysicalPixels.width 。
screenPhysicalPixels 为 undefine。

@qiuchengw  我已经更新至最新，你再试试~~

authors: okoala qiuchengw

repo: okoala/RNStarter


text:
Avoid --no-verify (allow ignoring specific tasks)

Original title: Avoid --no-verify/introduce LINT_STAGED=0
I've determined that using --no-verify is an anti-pattern - ideally we avoid ever using it. It's basically a giant global kill switch.
Ideally we have individual switches for everything.
At any point in time when making pre-commit checks stricter, we may need to temporarily bypass specific checks, but may should avoid completely disabling all git commit hooks/checks. (I'm using a commit-msg hook to add "Suggested reviewers" to all commits)
Also, imagine just your tsc pre-commit check is failing, in the middle of rebasing, and the type error is fixed in a future commit.
My ideal solution will allow me to specifically disable my type-check pre-commit check.
It would also be useful to be able to disable all lint-staged checks, and still let anything and everything else run normally. This way my commit-msg hook still runs and adds "Suggested reviewers" to the commit message.
(Aside: just realized if a user is running git commit in a real terminal, we could just prompt them, ask if they want to ignore this specific issue this one time).

FWIW here's my lint-staged config:
  "lint-staged": {
    "*.@(ts|tsx|js|jsx|mjs|cjs)": [
      "yarn lint:fix:pre-commit",
      "run-p --print-label --continue-on-error test:update-snapshots type-check --"
    ],
    "!*.@(ts|tsx|js|jsx|mjs|cjs)": [
      "prettier --write --ignore-unknown"
    ]
  },

This problem could be addressed inside of lint-staged.
If we ignore the fact that run-p is calling type-check, in theory lint-staged could create some mechanism to allow me to ignore this entire command. Maybe we'd need users to label them like so:
  "lint-staged": {
    "*.@(ts|tsx|js|jsx|mjs|cjs)": [
      ESLINT_AUTOFIX: "yarn lint:fix:pre-commit",
      SNAPSHOTS_TYPE_CHECK: "run-p --print-label --continue-on-error test:update-snapshots type-check --"
    ],
    "!*.@(ts|tsx|js|jsx|mjs|cjs)": [
      FORMAT: "prettier --write --ignore-unknown"
    ]
  },

Then, you can already intuit ways to disable each of these checks I labeled. Maybe LINT_STAGED_SKIP='ESLINT_AUTOFIX' git commit.
In my very specific case, I'd need some alternative to run-p, some way to tell lint-staged that I want tasks to run in parallel: https://github.com/okonet/lint-staged/issues/934#issuecomment-1001862009

Supporting LINT_STAGED=0 would be a minor version bump.
The "parallel" style syntax could be supported without a major version bump, but it would probably be easier (development/coding wise) to just create an experimental fork/branch that DROPS support for the current Array<string> based task spec.
I think it's even possible I implement a silly little "labeled-parallel-lint-staged-config-wrapper" npm package, and you do something like:
// .lintstagedrc.js
module.exports = require('parallel-labeled-lint-staged-config-transform')({
   "*.@(ts|tsx|js|jsx|mjs|cjs)": [
     { ESLINT_AUTOFIX: "yarn lint:fix:pre-commit" },
     {
       SNAPSHOTS: "test:update-snapshots",
       TYPE_CHECK: "type-check"
      }
   ],
})

I'm not sure if it could properly implement the ability to individually disable/skip/ignore tasks. It could easily translate things into some sort of run-p task1 task2 string

I'm wondering what's missing for you to implement everything you want using our JS config syntax?

The main thing that's missing is some sort of labels or names for tasks. How would I tell lint staged to bypass type-check?

You could use an env variable for that and read it in the config.

A better example to work off of, how could I tell lint-staged to skip my lint:fix:pre-commit script? Upon failure, it could print out some generated thing:

Ignore this task failure with LINT_STAGED_SKIP='*.js lint:fix:pre-commit' git commit. I'm not sure how to generate+parse this LINT_STAGED_SKIP, but I think it's the wrong approach.

Maybe labeling tasks will have many more benefits, but I'm not sure.

Oh, duh, use an env variable to customize the config before I pass it to lint-staged. I think the config wrapper will work just fine!
(The config wrapper will read some env var and then wholly omit tasks you want to skip. Lint-staged has no idea the task exists.

But we must consider, should this wrapper really be a different package?

When specific git hook checks are disabled, those flags can be added to the commit message. This would then ultimately translate to this "tdd-like" pattern:

Create new check, or make an existing one stricter. Now you can't commit normally. You run something like: SKIP_TYPE_CHECK=1 git commit. Inside the git prepare commit msg hook, it will include something like "Committed with: SKIP_TYPE_CHECK"
Next commit, you should probably fix the new type errors

When you go to push, a rebase --exec can be run to verify each commit has passing checks. This process would have the somewhat involved duty of parsing commit messages for a "Committed with: SKIP_*" message.
Multiple "SKIP_THIS=1 SKIP_THAT=1 git commit" flags would not be supported. Error message would recommend creating smaller simpler commits.

repo: okonet/lint-staged


text:
Automated Workflow Installation/Update

This PR is part of an automated maintenance operation. It aims to add or update workflows in the repository to enhance automation and ensure consistency across operations.

Summary by CodeRabbit

New Features

Implemented a GitHub Actions workflow to automatically add new issues to the project board upon creation.

size-limit report 📦

Path
Size

target/wasm32-unknown-unknown/release/okp4_objectarium.wasm
430.75 KB (0%)

target/wasm32-unknown-unknown/release/okp4_law_stone.wasm
645.26 KB (0%)

target/wasm32-unknown-unknown/release/okp4_cognitarium.wasm
824.92 KB (0%)


text:
feat(dataverse): implements dataverse query

Implements the Dataverse query to be able to retrieve name and cognitarium contract address.

Summary by CodeRabbit

New Features

Enhanced data retrieval capabilities to include Dataverse data.
Added triplestore_address in DataverseResponse for improved data structuring.

Documentation

Updated documentation to reflect new triplestore_address property and its significance.
Clarified the representation of validated addresses in the system.

Tests

Implemented tests to ensure the reliability of new dataverse data retrieval functionalities.

size-limit report 📦

Path
Size

target/wasm32-unknown-unknown/release/okp4_objectarium.wasm
440.47 KB (0%)

target/wasm32-unknown-unknown/release/okp4_law_stone.wasm
654.01 KB (0%)

target/wasm32-unknown-unknown/release/okp4_cognitarium.wasm
833.65 KB (0%)

target/wasm32-unknown-unknown/release/okp4_dataverse.wasm
670.78 KB (+0.27% 🔺)

:tada: This PR is included in version 4.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: amimart bot-anik


text:
⚖ Register Validator: Thor

Network Choice
nemeton-1
Who are you?
i like testnets when they are on gentx stage hope i will be choosen!
gentx
{"body":{"messages":[{"@type":"/cosmos.staking.v1beta1.MsgCreateValidator","description":{"moniker":"Thor","identity":"","website":"","security_contact":"thorthegod05@gmail.com","details":""},"commission":{"rate":"0.050000000000000000","max_rate":"0.200000000000000000","max_change_rate":"0.010000000000000000"},"min_self_delegation":"1","delegator_address":"okp413wyynhujjktcrn6vw88xn03wnyvysrrfjq2z02","validator_address":"okp4valoper13wyynhujjktcrn6vw88xn03wnyvysrrf886t3t","pubkey":{"@type":"/cosmos.crypto.ed25519.PubKey","key":"Xmv3TEkC30wBRPWhUHm+PsjUaq/eEaE58PGQxUoooyE="},"value":{"denom":"uknow","amount":"10000000000"}}],"memo":"cf4e4330fa83d0cec0ddb03cabc48fcd7ce461bf@137.184.168.203:26656","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[{"public_key":{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A+MmoW+kHoKO1WAkwdbPzs3gE8DYjfnX9AnY3WkKcnLh"},"mode_info":{"single":{"mode":"SIGN_MODE_DIRECT"}},"sequence":"0"}],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""},"tip":null},"signatures":["J/mgY2GbOLepeHvMUG+dsYRGVvusGkS9E1DJ49AV6XguXXhU1LusqfGTi+cFIdCLwgqaZIRq2EmaZfLUdVUopQ=="]}

😉 Here is the corresponding PR: https://github.com/okp4/networks/pull/522


text:
Specify root directory for garden

As a user that would like to manage my digital garden in my main Obsidian vault and keep all my published notes in a separate subdirectory, I would like to be able to manually configure a root directory for the garden. For example, my vault structure is:

Resources

Garden

Note in Digital Garden.md

The same structure shows up in the filetree on the published site. I would like to be able to specify the location of the filesystem in my vault, like:
Root Directory: Resources/Garden
Then the filetree in the sidebar of the published site would show:

Note in Digital Garden.md

in the root, and any subdirectories under Garden would then appear as subdirectories in the filetree.

@oleeskild Would it be possible to implement this as setting the Filetree root directory? It would really be nice to have the filetree start from a specified directory instead of the vault root.

That's exactly what I'm looking for here.

I'm also looking for something like this.

While setting things up and messing around I discovered that you can just use ´dg-path´ in the frontmatter as a slight workaround.
It's a bit more work whenever you create a note since now you're gonna have to write dg-path: File.md in each note.
Then if you decide to make subdirectories inside the Garden directory (or whatever you name it), you'd have to write Subdirectory/File.md.
It's not as nice as having a global setting as the author mention, but it does the job until it's added (if ever).

I had the same issue, so I added a fix to the path rewrite that allows rewriting a folder to a blank path.
now you can do a path rewrite
/garden:/ and it should work like above!

I had the same issue, so I added a fix to the path rewrite that allows rewriting a folder to a blank path.
now you can do a path rewrite
/garden:/ and it should work like above!

I don't know if I'm doing something wrong but I add this in the Path Rewrie Rules:

Then I have the Home note, which I expect to be by itself, like this (using the dg-path in the notes themselves):

But it still looks like this:

@Rinnray I think I typoed the message above, checked my own and I have garden: as my setting, and it seems to work fine.
I added this preview box under the rewrite rules so you can test them:
with slash before:

without slash before:

So try garden: and see if it works! I'll add a ticket to remove slashes before rules too, as that sounds like a bug!

So try garden: and see if it works!

Yep! That seem to have worked! ^^

authors: Rinnray julesvirallinen ludwikc timjore

repo: oleeskild/obsidian-digital-garden


text:
Health Check

Hi there!
Is there a smart way to check if there is currently a connection to the defined Kafka cluster?
Want to provide a health check endpoint which exposes if there is a connection or not.
Thanks and Cheers!

Does myProducer.client.heartBeatRequest() show when there is no connection in the rejection handler?

There is no health check for a SimpleConsumer or Producer. client.heartBeatRequest() is for GroupConsumers only. With producers you can send small messages to some topic that no one listens to.

Thanks!
Works so far :)

authors: felixheck oleksiyk

repo: oleksiyk/kafka


text:
Config common steps folder instead of all steps [Question]

I want to configure predefined steps folder path  as line no 13 instead of line no 14 to 16

I feel,  it's really not developer friendly to update build.yml file  for each re-usable step configuration.

Hello! Thanks for raising the ticket.
This mechanism was not intended to be used for local steps with relative paths. If you follow the README, for external steps, you need to specify the package name. That was made for users to be intentional when they share (provide external step) or import (use existing step) anything from another package via bdd_options config.
It might be annoying to add common steps at the beginning of the project, but soon the list becomes stable as the majority of the steps will be feature-specific. If that's not true for your project and you expect the majority of steps to be shared between features, consider specifying the stepFolderName instead.
How many common steps that are private for the package do you expect to have in your project?

@olexale
My usecase :
I am writing the bdd test cases per screen, not per feature
Lets say I have 30 screens. I am creating 30 .feature files and 30 folders for each
For each screen I have below steps
Wip.....

As per this doc, it is configuration for step folder name right,  not for re-usable steps config.

stepFolderName will not only change the name, it may also make all feature files inside the package use a single directory, so you will get the steps reusability you requested. Inside this folder, you may create subfolders to prevent it from becoming a mess.
If that solution is not acceptable, my question is the same: how many common steps that are private for the package do you expect to have in your project?
So far it looks like you have two common steps (which I believe should be combined into a single one). That sounds not that bad if you had to write a single line in the config.

@olexale  i get it now,  Thanks.
For my project mostly 5 to 6 common steps. not more than this.

authors: olexale venkata-reddy-dev


text:
Inform the user if permission has already been granted

As of now, when a user chooses to obtain authentication in the main menu, an authentication URL is generated regardless of whether there already is a stored token and whether that token is still valid. The program should first check to see whether a token is stored and whether it is still valid before going ahead and generate a new authentication URL.

Done.

repo: olivertwistor/todo-list-tools


text:
Add default voice setting and apply to chat

A new tab is added to settings and the end-user can select one's favorite voice now.
Please see the screenshot.

Testing done:

Select Default in voice settings -> click the speaker icon -> ✔
Select Rocko (English (United States)) in voice settings -> click the speaker icon -> ✔

BTW, I reuse the speaker icon on the tab. It would be good if one could help to create a new icon.

Amazing stuff, Thanks for the PR! I fixed and refactored some code, please try it out and let me know if it works as intended on your end!

Amazing stuff, Thanks for the PR! I fixed and refactored some code, please try it out and let me know if it works as intended on your end!

Thanks for the review and refactoring! Everything works as expected.

Good to hear! everything LGTM, Thanks!

authors: tjbck yeahdongcn

repo: ollama-webui/ollama-webui


text:
OLLAMA_MAX_QUEUE is invalid

What is the issue?
It seems that OLLAMA_MAX_QUEUE is not taking effect. My environment is Windows 11, and I have set OLLAMA_NUM_PARALLEL=1,
set OLLAMA_MAX_QUEUE=1, but excessive requests are still queuing up instead of returning an error.
OS
Windows
GPU
Nvidia
CPU
Intel
Ollama version
0.3.14

This is a side effect of the way the scheduler is implemented.  The queue depth relates to processing incoming requests that need to be scheduled.  If you make requests for different models, then it would have the behavior you're looking for.  Multiple requests to the same model pass through the scheduler quickly since the model is already loaded, and get to the underlying runner and queue up on the parallelism semaphore.  Currently this layer of the system does not use a fixed depth queue.  Adjusting that implementation to use a queue and respect the max queue depth does seem like a good enhancement to make.

repo: ollama/ollama


text:
How do I replace my own data for training?

Hello, I was recently reading and studying your article and downloaded your code for testing, I would like to ask if it is possible to train time series in .tif format data? (Sentinel-1 data) How can I do this? Thank you very much!

Hi, thanks for your interest in the code. This depends on how the data has been processed. Which software have you used to process your data? Do you have a single .tif file that contains a series of Sentinel-1 coherence images that are all coregistered to the same grid? If so, the most straightforward approach would be to open the .tif file in python, write it as a numpy array, then use the code as stated in the documentation. You could also make a small modification to the code in order to load a .tif file rather than a .npy file, which would save you having to duplicate the data.
If the Sentinel-1 data are in separate .tif files that aren't registered to the same grid, then this is less straightforward. You first need to resample everything so that each pixel corresponds to the same geographic region on the ground.
Using gdal is probably the best way to interact with .tif files in python. See: https://www.geeksforgeeks.org/opening-tif-file-using-gdal-in-python/

I'm not sure if my presentation is clear, so I wanted to add to it. My main confusion with the code at the moment is focused on how my tif dataset has to be used in the code to reflect this feature of the training of the time series?
Thanks a lot!

The training data should be a 3 dimensional matrix with dimensions (space, space, number of time steps). So if you have 100 coherence pairs, then for your data the training data would have the dimensions (5000, 3000, 100). In the code we refer to the spatial dimensions as the shape and the temporal dimension as the length. So in the dataset.json file you would put "shape": [5000, 3000] and "length": 100. You can see that the test_dataset.npy file has dimensions (100, 100, 10), so the shape is (100, 100) and the length is 10.
In order to use the data that you have, you need to take each coherence image and stack it into a single file, with the stacking in time along the third axis. The data is then loaded into the code here: https://github.com/olliestephenson/dpm-rnn-public/blob/bc4247fd7126eac66dd07c50149a62be72a316ec/coherence_timeseries.py#L30, so you could also rewrite the code here in order to be able to load multiple separate images.

repo: olliestephenson/dpm-rnn-public


text:
🛑 MediaNet is down

In 0e57f12, MediaNet (https://medianet-pa.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MediaNet is back up in 4dcc306.

repo: olmloa/upptime