Electron apps syncing simple db between each other

I'm a bit confused what I need to do here to have several electron apps communicate with each other, and syncing a simple key-value db.
Essentially any app could add or modify the contents of the DB over a local network.
I've created a local DB in one of the apps using orbit-db and ipfs, but I'm not sure how to connect two.
In the getting started guide in the replication section (https://github.com/orbitdb/orbit-db/blob/master/GUIDE.md#replicating-a-database) there seem to be an assumtion, that there's a "master" DB, which is replicated by the second DB, which is not what I want.
Essentially these apps would need to automatically discover each other, and just sync automatically, without having a "master" that all others replicate.
Another thing that confused me is this the "ipfs daemon" (https://github.com/orbitdb/orbit-db#module-with-ipfs-daemon) which seems to be recommended for electron apps, but I'm not sure what the difference is between this and my first approach which just using the ipfs module.
I'm sure I just need to do my research, I just feel like I don't know where to look. 😅

Hey, @ZeeCoder! I believe I understand that you want each app to contain one or more orbitdbs, and simply make those available to other electron apps on the same system. Is this correct?
To start our troubleshooting, let's ensure that each of the nodes are connected to one another. OrbitDB requires this. You can do this by trying the following steps:
Let's assume your IPFS variable is simply ipfs.

running something like ipfs.id().then(console.log) and noting the multiaddr of the node. something like /ip4/<IP_ADDRESS>/tcp/[####]/Qm....
Copying that value into the "Bootstrap" field of the IPFS config object in your electron app's JS
Then, you should be able tp run ipfs.swarm.peers() inside each app and see an array of peers, the ids of which should match your app's id.
Copy this process for each app, in each app until all apps are "bootstrapped" with all the others.
Run your tests again.

As to your question about the ipfs daemon - if you're using js-ipfs inside of a node app, the default behavior is that the app "is its own" daemon while it's running.

Thanks for the fast answer @aphelionz !
I would want the apps to essentially operate on the same DB, and sync each others' changes.
So if app1 adds the following: { username: "some user" };
Then app2 would receive that automatically, and should be able to amend it, which app1 would receive.
On syncing
So I don't need the db1.address then at all?
Is this how it would look like essentially?
const ipfsOptions = {
    EXPERIMENTAL: {
        pubsub: true,
    }
};

// Create IPFS instance
const ipfs = new IPFS(ipfsOptions);

// Assuming that I got `app2Address` from app2 somehow, which I got by running `ipfs.id()`
ipfs.bootstrap.add(app2Address)

ipfs.on('ready', async () => {
    // Create OrbitDB instance
    const orbitdb = new OrbitDB(ipfs);
    const db = await orbitdb.docs("db", { write: ['*'] });
    await db.load();

    // Now whatever I do with db, it's replicated in app2's db (?)
});

Then app2's code would look essentially the same?
Can I add nodes like this as I'm discovering them on the network?
So if I start app3 and app4, do I just add their addresses the same way runtime to ipfs, and will those apps start syncing?
About the daemon:
Technically electron is a node environment, and it seemed to work just as is 🤔

ooh, so it doesn't sync automatically? :(
So what does this mean then, isn't this possible?

OrbitDB uses IPFS as its data storage and IPFS Pubsub to automatically sync databases with peers

Anyway, can I run my idea so far through you, just to see if I really get this:
I'd make the apps start their local DB first, with something like the following:
const ipfsOptions = {
    EXPERIMENTAL: {
        pubsub: true,
    }
};

// Create IPFS instance
const ipfs = new IPFS(ipfsOptions);

// I'm intentionally not adding remote ipfs ids here to bootstrap, as I'll discover them later

ipfs.on('ready', async () => {
    // Create OrbitDB instance
    const orbitdb = new OrbitDB(ipfs);
    const db = await orbitdb.docs("db", { write: ['*'] });

    // This is basically polling at this point from all other nodes, which
    // I kinda wanted to avoid as I thought orbit-db would do this
    // automatically when new data is created in a node. 🤷♂
    const tick = async () => {
        await db.load();
        await delay(1000);
        tick()
    }

    tick()
});

// Here I'd expose this app's ID using `ipfs.id()`, with either websockets or a
// simple express server over a fixed port, so that I can discover apps on a local network

// ...imagine express server code here exposing ipfs.id()...

// Here I'd imagine yet another loop, that discovers other apps over the
// aformentioned port, and gets their ipfs ID:

const discover = async () => {
  const ipfsIds = findIpfsIdsOverTheLocalNetwork();
  ipfsIds.map(id => ipfs.bootstrap.add(id));
  await delay(1000);
  discover()
}

discover()

All the above are kinda pseudo-code ish, but you get the idea.
What I still don't get though, is why I need a genesis db here? Technically all apps have their own local DB, and the whole Idea of being P2P is not to have a central app.
Otherwise I'd just make one app the master with an exposed REST api or something. 🤔

Somebody, somewhere, has to write the first entry into the CRDT and "start" the database.
I'm curious to see how far you got based on our conversation. Maybe try out the psuedo-code and then report back? You can also be artful about how you call load, it doesn't need to be polling.

Also, a clarification: pubsub handles the data transfer on the IPFS later and load() brings those contents into memory to be queried.

I don't want to start working on this until I know the project fits my needs. 😅
For example having a "master" app sounds the exact opposite of a system that claims to be a
< distributed, peer-to-peer database.
Automatic syncing was the other thing that made me think this project might be a good fit, but I'm not so sure anymore.
I'll probably look around a bit more to see if there's something that's actually distributed peer-to-peer, and automatically syncing between nodes, as I don't want to deal with these "low-level" details if possible. 😅

There's a distinction between "master" / "central" and the term I used, which is "genesis."
If I start a git repository and you eventually clone it, we both have a copy of the database locally, can perform operations on it, and have certain assurances that when we decide to sync up (which can be done at any time, at any interval), functions run on our data will yield the same outputs. The fact that I started it is just a consequence of the fact that somebody had to make the first commit.
In the case of orbitdb, this DOES happen automatically via pubsub as you suggest, on the IPFS layer. It seems like you mostly don't like the fact you have to periodically call db.load to get the database into memory to work with, which is a valid critique and we can perhaps look at keeping a certain amount of data in memory at all times.

There's an electron implementation of orbit chat here, for reference: https://github.com/orbitdb/orbit-electron

The way I imagined is less like a git repo (which has to have an initial commit, as all other commits then reference another commit before them) and more like array of objects getting merged together.
If you think of the databases as array of object, then each peer would just add new objects to their local array as they come in from other peers.
In this scenario there's no need for a "genesis" array.
That's sort of how I thought this would work.
The part I don't really get is not just why we need a "genesis" DB, but how it gets created?
Like here: https://github.com/orbitdb/orbit-db/issues/498#issuecomment-437631309
If I start 3 apps, which one creates such a "genesis" table?
What happens if after I started them, one app is not connected to the network, and while the first two starts syncing with each other (let's say app1 created a "genesis" db somehow) would app 3 create a genesis db of its own, as it might assume there are no other nodes?
What happens then when it does connect to the network? Would it somehow conflict with app1 and 2, instead of the three apps nicely fetching new data from each other to get synced?

I have so many questions and I'm not sure where to look for answers tbh. 😅

We'll get there! Let me type up detailed responses tomorrow and get back to you.

Sorry for being so pushy about this @aphelionz btw, I really do appreciate your help! 🙌

Let's start with just a basic walkthrough of what each line is and does in the following example:
// start with dependencies
const IPFS = require("ipfs");
const OrbitDB = require("orbit-db")

const ipfsOptions = {
  repo: "./orbitdb/ipfs",
  EXPERIMENTAL: {
    pubsub: true,
  }
}

// create a js-ipfs repo with default config
var ipfs = new IPFS();

// Once IPFS is ready, create a new orbitdb instance by passing ipfs
ipfs.on("ready", async() => {
  const orbitdb = new OrbitDB(ipfs);
}

At this point, in your local file system, you'll have some folders - the ipfs repo and an orbitdb-managed folder with the same name as your IPFS node's ID.
$ ls ./orbitdb
ipfs                                           # IPFS repo
Qmacc8APadGneFifUsAfh9mNuARHQTgGHKb41eHP1SxmGD # OrbitDB metadata (keystore, etc)

Back in our javascript we can make a database:
ipfs.on("ready", async() => {
  const orbitdb = new OrbitDB(ipfs);
  const log = await orbitdb.log("/testdb")
}

and back on the filesystem:
$ ls orbitdb/
ipfs
Qmacc8APadGneFifUsAfh9mNuARHQTgGHKb41eHP1SxmGD  QmeFHiAqnaKe4HgJ4WJcRDJ1gSyPqCwyrYvv8f6d3HHp9u

# So what's in there? A folder with the name of your db
$ ls orbitdb/QmeFHiAqnaKe4HgJ4WJcRDJ1gSyPqCwyrYvv8f6d3HHp9u/
testdb

$ ls -alh orbitdb/QmeFHiAqnaKe4HgJ4WJcRDJ1gSyPqCwyrYvv8f6d3HHp9u/testdb/
total 24K
drwxrwxr-x 2 mark mark 4.0K Nov 12 22:15 .
drwxrwxr-x 3 mark mark 4.0K Nov 12 22:15 ..
-rw-rw-r-- 1 mark mark  284 Nov 12 22:15 000003.log
-rw-rw-r-- 1 mark mark   16 Nov 12 22:15 CURRENT
-rw-r--r-- 1 mark mark    0 Nov 12 22:15 LOCK
-rw-rw-r-- 1 mark mark   57 Nov 12 22:15 LOG
-rw-rw-r-- 1 mark mark   50 Nov 12 22:15 MANIFEST-000002

I can break down what each of these files are, but the gist of what I'm getting at is this: Each node / app / peer is going to have a database structure like this - they can connect via the orbit address generated from database creation:
I guess all of this is tantamount to git init, to stay with the analogy. This answers one of your questions:

If I start 3 apps, which one creates such a "genesis" table?

They all do, and to address

If you think of the databases as array of object, then each peer would just add new objects to their local array as they come in from other peers.

 Technically they're arrays of ipfs-log objects. Each one DOES independently act on its own copy of the database.
But What About Merging?
You asked a few questions here:

What happens if after I started them, one app is not connected to the network, and while the first two starts syncing with each other (let's say app1 created a "genesis" db somehow) would app 3 create a genesis db of its own, as it might assume there are no other nodes?

What happens then when it does connect to the network? Would it somehow conflict with app1 and 2, instead of the three apps nicely fetching new data from each other to get synced?

All of these problems are solved by using CRDTs and so-called "Lamport Clocks." You can read up on them and I can provide the journal articles if you want, but essentially all the timestamps in an orbitdb are "vector" timestamps, meaning they are sorted not only by a regular timestamp but also the ID of the node contributing the entry.
So, when it comes time to merge (again handled by IPFS pubsub) then you can get the state of the database using a pure function across a unique and consistent set of values from all peers acting on the DB.

Closing this for now and directing people to the new OrbitDB Field Manual. Feel free to open issues and PRs there if you have more questions or if things don't make sense!

I understand that the genesis database can be created first and then accessed directly by using the address in the three apps. However, I have another problem: after each data change ({ pin:true }) is it OK to take data directly from IPFS(Every app's ipfs daemon is always online!)? Even if a new 'app100' comes in, it only has the address of the database.can it replicate the database?I tryed in
const create = require('ipfs-http-client')
const OrbitDB = require('orbit-db')
function sleep(ms) {
    return new Promise((resolve) => {
        setTimeout(resolve, ms);
    });
}

async function listenPublicDatabase(orbitdb, address) {
    const publicDatabase2 = await orbitdb.open(address)
    console.log('in ipfs2, opened')
    publicDatabase2.events.on('replicated', () => {
        console.log("db1 ed time:", publicDatabase2.all)
    })
    await publicDatabase2.load()
    console.log('in ipfs2, loaded')
    console.log('pub2', publicDatabase2.all)
}
async function main() {
    const ipfs1 = create("http://localhost:50001")
    const ipfs2 = create("http://localhost:50002")
    const orbitdb1 = await OrbitDB.createInstance(ipfs1, { directory: './orbitdb1' })
    const orbitdb2 = await OrbitDB.createInstance(ipfs2, { directory: './orbitdb2' })
    // create a database on ipfs1
    // const publicDatabase1 = await orbitdb1.keyvalue("NetDisk-PublicDatabase1", {
    //     // Give write access to everyone
    //     accessController: {
    //         write: ['*']
    //     }
    // });
    // console.log(publicDatabase1.address.toString())
    const publicDatabase1 = await orbitdb1.open('/orbitdb/zdpuAzEJHgs9ksvYSiGwTG68LRfLJ2N29bC5C6NMxW79KpbKf/NetDisk-PublicDatabase1')
    await publicDatabase1.load()
    console.log('pub1', publicDatabase1.all)
    await publicDatabase1.put("time", '1-249', { pin: true })
    console.log('start to wait')
    await sleep(15000);
    console.log('end to wait')
    console.log('pub1', publicDatabase1.all)
    // await publicDatabase1.close();      // **************
    // await orbitdb1.disconnect()           // **************
    await sleep(15000);
    // try to access the database on ipfs2,but get empty,so go to listen on replicated
    listenPublicDatabase(orbitdb2, publicDatabase1.address.toString())
    // update the database ,see if replicate works
    // await publicDatabase1.put("time", new Date().toString(), { pin: true })
}
main()

In the tag line(with ******************), the result of comments it or not is different. That is, when orbitdb2 has older data, orbitdb1 updates the data (it has been pinned, and in ipfs node bootstrap has been added between nodes. In order to ensure that I even run ipfs swarm connect ***, then orbitdb1 node goes offline, Ipfs1 is still online) but it can't be obtained through ipfs2 (I even executed ipfs get zdpuazejhgs9ksvysigwtg68lrflj2n29bc5c6nmxw79kpbkf in command line). It can only be obtained through the orbitdb node by replicating. Do I need an orbitdb node to run all the time to receive the changes of someone who may be offline?

my problem is a more complicated version of issue 460
I separated ipfs and orbitdb.
issue 460
all the ipfs node is always online.
orbitdb1 comes online, loads the db, does some operations and updates the values of the database and goes offline(ipfs1 is still online orbitdb1 is disconnected). orbitdb2 comes online, loads the database, and starts reading the entries. Does the entries contain the ones made by orbitdb1?
here is the cmd output
pub1 { time: 'new Date().toString()' }   //  read the old value in orbitdb1:'new Date().toString()'
start to wait // wait 15000 ms
end to wait
pub1 { time: 'Sat May 15 2021 18:01:22 GMT+0800 (中国标准时间)' }  // update value(pin:true) in orbitdb1 and sleep 15000 ms
in ipfs2, opened // orbitdb2 online and open("/orbitdb/...../......")
in ipfs2, loaded // orbigdb2.load()
pub2 { time: 'new Date().toString()' } // orbitdb2 get the unchanged value

Uou need at least one  other orbit db instance to be online for the exchange heads process. After it's replicated any changes then the secind instance should be able to load the db fro.m its local cache


firstDayOfWeek: 1 在选择日期范围时不起效果

ElementUI version
1.1.3
OS/Browers version
macOS/Chrome 55
Vue version
2.1.8

http://jsfiddle.net/6y48qg8c/

当type="daterange"时

I'm new in Vue and impressed of ElementUI - great work!

I use a date-picker with firstDayOfWeek: 1 and experience the correct dates shown in input field, but the blue marks in popup window itself is not aware of it. When I click on start date, the next day is marked blue - similar issue with end date. This mark behavior feels strange and there is a mismatch now between text in input field and the blue marked date range in popup.
Is there a chance to improve this fix to a full awareness of firstDayOfWeek.


Improve testing on Travis (add more sample font families to increase code testing coverage)

I think the CI should exercise more of the code, ideally there should be at least one font testing each check.

Travis does run fontbakery on a single test font: Cousine-Bold
We could add a second one such as Mada, perhaps.
Also, we could run a family (Cousine-.ttf and/or Mada.ttf) instead of a single font, in order to cover the cross-family checks as well.

@khaledhosny anything else to do here?

Not exactly the kind of testing I had in mind, I was thinking more of units tests, also it seems that all it checks for is that the script does not crash not if there are any regressions.

@graphicore has architected this and @felipesanches has been filling it out, so I'm closing this


Intermittent truncation of calls when using targets BED input

Erik;
Thanks so much for the work and the most recent updates. Those fixed the issues with target regions and min_entropy (#165) but unfortunately did not resolve the underlying issue with loss in sensitivity that I saw with the latest versions. Sorry, I was hoping the previous test case would sort everything out.
I dug into the issue more with the latest head (v0.9.21-18: c15a283) and it looks like there is a problem with some regions causing FreeBayes to halt calling, truncating the output when you have multi-region target BED files. I put together a small test example demonstrating the problem:
https://s3.amazonaws.com/chapmanb/fb/freebayes_truncated.tar.gz
(as before, this has a little shell script that shows the problem with included data, and only needs a pointer to a local copy of the GRCh37 reference)
The problematic region, 1:41905-41945 in regions-missing.bed, results in FreeBayes stopping calling for the remaining intervals in the targets file. There are no obvious errors even with debug turned on. This truncating causes sections to get lost, since I'm using BED files of multiple regions, leading to the loss in sensitivity.
I don't yet understand the conditions that cause FreeBayes to stop calling. It happens on ~1/3 of our targets file so is relatively common but not universal. Hopefully the test case provides more of a clue for you.
The last version that validated well was 0.9.21-7 (https://github.com/ekg/freebayes/commit/7dd41dbc8c789d5a82288bbafc983ad525f04061) and I've tested on 0.9.21-13 (https://github.com/ekg/freebayes/commit/c5efe19a4eb40ce6c1f6ef82c67bb766d319c0f6) and later which all show this symptom.
Happy to provide any more details that would be helpful. Thanks again.

@chapmanb I'm going to work on this now. Sorry for the continued difficulties.
As a (very passable) workaround you can run freebayes over the list of targets using the same pattern seen in freebayes-parallel. The result will be correct behavior and faster runtime. I'm sorry for the difficulty with using BED targets, but this is simply not a way that I've run the method since the first few months of development. I'd either run whole-genome and then filter down, or run using GNU parallel over the list of targets.

I'll chime in here, at least in supporting the use of BED targets.  For RAD sequencing with de novo loci, the reference ends up being thousands of short fragments (200 bp) each of which is generally an entire target.  Generally, we loading dozens to hundreds of bam files into FreeBayes, so there is some startup overhead involved.  With the targets option, it becomes a bit cumbersome because it basically has to call an instance of FB for each RAD fragment.  I found that it was more efficient to break up the reference using 50-100 BED target chunks and use this for GNU-parallel.  I'd guess that this would be the same for RNA/transcriptomics as well.
As always, we all appreciate your work on freebayes!

I've see similar behavior to what Brad describes.

Could anyone else test this out? The git HEAD has been passing @chapmanb 's test for some time, but I forgot to refer to this issue in the commit.

Erik;
Thanks much for the heads up. Apologies for missing that you'd fixed this. I updated to the latest and ran validation tests for 0.9.21-26 (the latest git HEAD) versus 0.9.21-7, which we're using in bcbio. The latest runs cleanly, does not have this problem, and has similar sensitivity and precision to the 0.9.21-7. Here is a validation on hg19 and hg38 of the two versions:
http://imgur.com/a/GXR5O
Thanks much for fixing this. It's great to be back tracking the latest version.

Hi Brad, thanks for double-checking this! I have a question about the
results--- what's going on with indels and hg38 vs hg19? Why is the FN rate
so much lower for all the callers?
On Tue, Oct 27, 2015 at 9:25 AM, Brad Chapman<EMAIL_ADDRESS>wrote:

Erik;
Thanks much for the heads up. Apologies for missing that you'd fixed this.
I updated to the latest and ran validation tests for 0.9.21-26 (the latest
git HEAD) versus 0.9.21-7, which we're using in bcbio. The latest runs
cleanly, does not have this problem, and has similar sensitivity and
precision to the 0.9.21-7. Here is a validation on hg19 and hg38 of the two
versions:
http://imgur.com/a/GXR5O
Thanks much for fixing this. It's great to be back tracking the latest
version.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/freebayes/issues/173#issuecomment-151426713.

Erik;
I'm not sure -- it might be an issue with the truth sets. The hg38 truth sets, both lifted over Genome in a Bottle and the natively generated Illumina Platinum Genomes, have more indels detected (good) but not as high a percentage validate (bad). I'm enthused by the extra detection capability but hopefully we can refine the truth sets to figure out what is going on as folks get more into 38 work. There is more background in the post here: http://bcb.io/2015/09/17/hg38-validation/


[EC-253] Removed use of BlockchainStorages outside Blockchain

Description
Reduced the passing of BlockchainStorages as a parameter and the construction of BlockchainImpl through out the codebase, so as to work just with Blockchain whenever possible.

@ntallar do you think we could also address this:
class GenesisDataLoader(
    dataSource: DataSource,
    blockchain: Blockchain,
    pruningMode: PruningMode,
    blockchainConfig: BlockchainConfig,
    dbConfig: DbConfig)

Could be a separate task...

@rtkaczyk I agree that we should remove that use of DataSource from GenesisDataLoader (probably the using something like InMemorySimpleMapProxy would help). However I also prefer creating a separate task for looking into that, will create one now :+1:


Knockout custom functions

Added support for Knockout custom functions (http://knockoutjs.com/documentation/fn.html) when using no implicit any.

knockout/knockout.d.ts
to authors(@borisyankov @Igorbek @moonpyk). could you review this PR?
:+1: or :-1:?
check list

[ ] pass the Travic-CI test?

Good to me


schema export via reactive driver and fix for bug #113

This supersedes #112.

Alright, folks, so shall I merge this one?

Silence indicates consent.

No, it doesn't

Maybe if you put a deadline. Anyway, it looks good, feel free to merge it

Pushed manually.

This has broken CI because it depends on core 5.5.0-SNAPSHOT. I'll create a new PR that does a clone+build of core 5.5.0-SNAPSHOT so we can still have CI coverage until the next version of core is released.
Aside from that, it looks like the user has to do 2 things to enable this:

register the no-op connection provider
Set the custom generation target

Can we make it so these steps happen automatically and the user gets the RX-based schema creation out of the box?

This has broken CI because it depends on core 5.5.0-SNAPSHOT. I'll create a new PR that does a clone+build of core 5.5.0-SNAPSHOT so we can still have CI coverage until the next version of core is released.

The new ORM release will be ready shortly, before the end of the day. We decided to do an exception for this time and merge the PRs even if they refer to an unreleased version.
It's OK if you test it locally.

Can we make it so these steps happen automatically

Yes, I was already working on that, and I just pushed the result.

Yes, I was already working on that, and I just pushed the result.

Excuse me: I have pushed part 1 but not yet part 2.

@gavinking Any idea about this error? https://github.com/hibernate/hibernate-reactive/pull/122/checks#step:4:151

@gavinking Any idea about this error? https://github.com/hibernate/hibernate-reactive/pull/122/checks#step:4:151

I imagine you're referring to the test failure I fixed here.

Yes, it's working now, thanks
On Mon, May 18, 2020 at 6:56 PM Gavin King<EMAIL_ADDRESS>wrote:

@gavinking https://github.com/gavinking Any idea about this error?
https://github.com/hibernate/hibernate-reactive/pull/122/checks#step:4:151
I imagine you're referring to the test failure I fixed here
https://github.com/hibernate/hibernate-reactive/commit/4e8b51adc43dcc5251946205047ff9e6c8290e27
.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hibernate/hibernate-reactive/pull/118#issuecomment-630342924,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEIQ5K7RBPSAW4HVJKWHT3RSFZFVANCNFSM4NC7JVYQ
.


Brew still using API with HOMEBREW_NO_INSTALL_FROM_API=1

brew doctor output
Your system is ready to brew.

Verification

[X] My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
[X] I ran brew update twice and am still able to reproduce my issue.
[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output
HOMEBREW_VERSION: 4.0.18-85-g16b2a14
ORIGIN: https://github.com/Homebrew/brew
HEAD: 16b2a14c9408140b04828462b660d30056421fdb
Last commit: 20 hours ago
Core tap origin: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 419d9c8d85ef0724403bdb705432f0fd211b4587
Core tap last commit: 82 minutes ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_EDITOR: code --wait
HOMEBREW_GITHUB_API_TOKEN: set
HOMEBREW_MAKE_JOBS: 8
HOMEBREW_NO_AUTO_UPDATE: set
HOMEBREW_NO_INSTALL_FROM_API: set
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 14.0.3 build 1403
Git: 2.40.1 => /opt/homebrew/bin/git
Curl: 7.88.1 => /usr/bin/curl
macOS: 13.4-arm64
CLT: <IP_ADDRESS>.1.1679647830
Xcode: N/A
Rosetta 2: false

What were you trying to do (and why)?
sudo brew services start sudo-touchid
What happened (include all command output)?
Error: Need to download https://formulae.brew.sh/api/formula.jws.json but cannot as root! Run brew update without sudo first then try again.
What did you expect to happen?
Successful service start. With HOMEBREW_NO_INSTALL_FROM_API=1 set, I do not expect homebrew to still depend on the API to start a service.
Step-by-step reproduction instructions (by running brew commands)
1. export HOMEBREW_NO_INSTALL_FROM_API=1
2. brew install artginzburg/tap/sudo-touchid
3. sudo brew services start sudo-touchid
>> Error: Need to download https://formulae.brew.sh/api/formula.jws.json but cannot as root! Run `brew update` without `sudo` first then try again.
4. brew update
5. sudo brew services start sudo-touchid
>> Error: Need to download https://formulae.brew.sh/api/formula.jws.json but cannot as root! Run `brew update` without `sudo` first then try again.

Thoughts, @apainintheneck?

sudo brew services start sudo-touchid

sudo doesn't pass through environment variables by default. Use sudo -E or sudo HOMEBREW_NO_INSTALL_FROM_API=1


.asf.yaml:  Enable Issues in the apps/ repository.

Do we really want two issue trackers? Splitting the project management board across two repos seems even more of an issue. What about the testing repo will it also have an issue tracker? I would be much more in favor of having a notice in the description that they should file issues against the os project.

Yes, most definitely.  I do NOT want security violations against crappy little applications in apps/ being reported against the OS.  The is a disservice to the years of effort that have but put into it.  A badly done afternoon's work develop a bad application MUST not reflect on the core OS.  We cannot have that.
It is very important (at least to me) that we separate the issues base upon what they are reported against.

We will also need to eventually enable issues in incubator-nuttx-testing and incubator-nuttx-website too.

I would have liked to just have a single issue tracker and just attach labels for OS/arm OS/net Website etc... But looks like we are not doing that. What about the project feature can we at least have one of those? I cannot imagine being able to use that effectively in 5 different places. You can link issues from different repos to a single project board.

I really, really, really dislike that idea.  I do not want apps/ issues in the OS.  That is a really repulsive concept to me and I have to resist that idea with all means available to me.

The PPMC as a whole should discuss this and come to some consensus on it. I suggest you start a thread on the mailing list.

There already is a thread.  But is never came to a consensus.  Some wanted to use Jira, some wanted to use Github issues.
I don't really care, but I don't want all issues reported against the OS.  That is wrong.  Especially after this BS discussion about security in a pre-Apache code release.  I do not want those reports associated with the core OS.  I am really not comfortable with that at all.

"There already is a thread."  There were the threads called "Bug Tracking" started on January 3 and again as "Issue Reporting" sometime before January 9

I'm aware of those threads. Why is action being taken if consensus hasn't been reached? Consensus sometimes can be hard and takes time, but I don't think there's a huge rush here. How many app issues have been raised to date in the main repo? I'd also suggest the PPMC focus on dealing with security issues as per the documented process.

Let's keep everything as it is now so that no application issues are reported against the OS in the mean time.
I am not the right person to deal with the security nonsense.  I don't have sufficient patience for that.


Require global settings to be defined before tests and keywords using them

Currently we support data like this so that the created test gets the setup and the template defined after the test itself:
*** Test Cases ***
Example
    arg1    arg2

*** Settings ***
Test Setup       Setup Keyword
Test Template    Template Keyword

This syntax causes two problems:

It is not possible to change the value of the global test and keyword related settings. There has, for example, been several requests to to allow using different test templates in a single file with a syntax like this:*** Settings ***
Test Template    Something

# The following tests use the template specified above
*** Test Cases ***
T1
    arg1.1    arg1.2
T2
    arg2.1    arg2.2

# Change the template it and use it with the forthcoming tests
*** Settings ***
Test Template    New

*** Test Cases ***
T3
    arg3.1    arg3.2   arg3.3

It makes implementing parsers a lot harder. Parsers typically go through data line-by-line, but in our case the parser needs to process the whole file to find possible Test Template or it won't be able to handle test cases properly. Robot's own parser obviously handles that, but this syntax makes it a lot harder to implement custom parsers, for example, for syntax highlighting purposes or to implement a faster C/Rust/Go based parser for Robot itself.

The main benefit of allowing settings to be defined after tests and keywords using them is that it allows "hiding" the Setting section at the end of the file. That can be useful when tests are shown to non-technical people, but scrolling to the right place in the file or using code folding in an IDE ought to be good enough alternatives. Notice also that even after this change we'd allow suite related settings as well as imports to be defined after tests and keywords.
What do others think about this? Do you consider the benefits explained above higher than problems? The change is backwards incompatible, so it could only be done in a major release and would require a deprecation period. Please use :+1: / :-1: reactions to indicate how you feel about this and write a comment if you have something more to say.

I find significance of order of the settings section (or any other section) in the file to be very counter-intuitive, so I am objecting this change.. To me the use case of having different templates in a single file is not really strong enough for such a significant change.

The main motivation of this proposed change is making parsing simpler. Currently when a parser sees something like
*** Test Cases ***
Example
    Something    here

in the beginning of a file, it doesn't know should Something and here be tokenized as a keyword an its arguments or are both of them arguments to a template keyword specified later. This requires the parser to go through the date twice which adds complexity. Robot's own Python based parser obviously handles this, but there are pretty good reasons to implement new parsers for Robot's syntax:

Syntax highlighters, like the one here on GitHub, need a parser. Various syntax highlighters have a parser for Robot Framework, but I don't think any of them handles all syntax properly. For example,Tree-sitter is a popular parser generator) that actually has a parser for Robot, but I don't think it handles templates.
Also editors and IDEs need parsers to properly support different languages. This isn't so relevant anymore when LSP is getting so popular and we have a great LSP server that uses Robot's own parser, but I'm pretty sure there are IDEs that would benefit. My understanding is that some editors use the aforementioned Tree-sitter. A Javascript based parser would be cool in a browser.
Robot's own parsing could be made significantly faster by implementing the parser (most importantly tokenizer) in C, Rust or Go. Not needing to support to support templates after tests would simplify creating them.

@pekkaklarck, what do you mean by

Notice also that even after this change we'd allow suite related settings as well as imports to be defined after tests and keywords.

@gohierf, the proposed change wouldn't affect how
*** Test Cases ***
Example
    Some keyword

*** Settings ***
Documentation    Doc for the suite.
Library          SomeLibrary

works. Only test and keyword related settings would need to be set before tests and keywords using them.

We discussed this and some other possible syntax changes at the end of the RF 7.2 planning session today. Participants in general agreed that this change makes sense, but because various people have expressed concerns we decided to not make any decision about this. Most importantly, there won't be any deprecation warning in RF 7.2 related to this.


List of all new lua console commands / functions?

Not sure where to ask since there's no discussion tab, so asking this here.
The old console command format doesn't work here anymore - So what are the new commands? And if there is a list, show us it?

It's all in the wiki.


RecursionError: maximum recursion depth exceeded while calling a Python object

  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 420, in __torch_function__
    return lazy_forward(func, shape_impl, *args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 420, in __torch_function__
    return lazy_forward(func, shape_impl, *args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 420, in __torch_function__
    return lazy_forward(func, shape_impl, *args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 420, in __torch_function__
    return lazy_forward(func, shape_impl, *args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 420, in __torch_function__
    return lazy_forward(func, shape_impl, *args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 420, in __torch_function__
    return lazy_forward(func, shape_impl, *args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 420, in __torch_function__
    return lazy_forward(func, shape_impl, *args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 572, in lazy_forward
    return func(*args, **kwargs)
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 408, in __torch_function__
    if not builtins.all(
  File "/opt/conda/lib/python3.8/site-packages/koila/tensors.py", line 409, in <genexpr>
    issubclass(typ, (LazyTensor, Tensor, int, float, bool)) for typ in types
  File "/opt/conda/lib/python3.8/abc.py", line 102, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
RecursionError: maximum recursion depth exceeded while calling a Python object

Hi, thanks for this great bug report. I've not tested this code in evaluation mode.
This bug happens because torch.* functions will call __torch_function__ when evaluating LazyTensor, and because LazyTensor is designed to evaluate eagerly in evaluation mode, it causes an recursion error.
I don't think the fix in #4 is ideal, however, because the code should evaluate eagerly in evaluation mode (where OOM almost never happens because the graph does not need to be saved). So the 'correct' fix would be to run every arg and kwarg before passing them to torch.* functions.
Will fix it when I can, but as of right now, I'm going to close #4 .


Make login password field a hidden text field

Description
We can't have a text field that shows the password like that lol please hide the password text like most apps do with the big dots instead of characters
Screenshots

Files
login.js

solved by my recent push straight 2 master


Make TypedLambda less newline sensitive

Fixes https://github.com/Azure/bicep/issues/12913.
Microsoft Reviewers: Open in CodeFlow

Just realized that Anthony created https://github.com/Azure/bicep/pull/13043 which should be a better fix.


[IDEA] Key rebinding tool

Please read conditions below carefully, and don't delete this part. Invalid issues will be closed.

No apps related to piracy or intellectual property infringement is allowed.
We can't guarantee if the app will be developed by anyone.
We encourage you to develop the app by yourself. This would be a great contribution to webOS homebrew community.

[x] I understand conditions above
[ ] (Optional) I'd like to develop this app by myself

Issue content starts below this line

This should be achievable by injecting into lginput2 and replacing lginput_uinput_send_button. Option to switch keys around, or execute a specific command / launch specific app would be great.
Update: lginput2 only handles magic remotes

Magic Remote (mrcu)

lginput2 → lginput_uinput_send_button

IR Remote (via micom)

webOS 3.x-4.x → RELEASE/tvservice → MICOM_UINPUT_WriteEvent
webOS 5.x+ → micomservice → _MicomHandler_Write_KeyEvent

I would love something like this! I've bought a replacement magic remote for my 55" LG G9 but the Disney+, Google and Alexa buttons don't seem to work :(

https://github.com/Simon34545/lginputhook implements this.


Add interface to check balance of specific accounts in MockedBlockchain

This would be very useful for testing any contract that moves Near

MockedBlockchain doesn't keep track of account balances, the balance is based on the VMContext.
So this should be part of integration tests


fix(motion): add video to motion overview

Closes #1738
Adds in a video to Guidelines/Motion

@jillianhowarth should be fine once we get it on the main website, I'm guessing the Vercel preview is not one of the allowed domains.
Is the positioning on the page correct?


Exception in thread "main" java.lang.RuntimeException: File '/gpfs/data/SSH003_R1.fastq.gz' was specified multiple times.

My starting command:
perl FLT3_ITD_ext.pl -f1 /gpfs/data/SSH003_R1.fastq.gz -f2 /gpfs/data/SSH003_R2.fastq.gz -o /gpfs/data/ -g hg38
Samtools version 1.9
Bedtools version 2.26.0
bwa version 0.7.15
I encounter the error in the title after the main perl scrip runs the following command.
Executing jgi.BBDuk [-Xmx2g, in1=/gpfs/data/SSH003_R1.fastq.gz, in2=/gpfs/data/SSH003_R2.fastq.gz, out1=/gpfs/data/SSH003_R1.fastq.gz, out2=/gpfs/data/SSH003_R2.fastq.gz, literal=AGATCGGAAGAGCACACGTCTGAACTCCAGTCAC,AGATCGGAAGAGCGTCGTGTAGGGAAAGAGTGT, ktrim=r, k=23, hdist=1, mink=11, hdist=1, ordered=t, ignorebadquality]
As you can see the out1 and out2 file names are the same as the in1 and in2 file names for some reason.
Starting on line 1634 in the main perl script this is where the declaration of the these variables is made. I am not super familiar with perl so I am not entirely sure if this is the issue. It looks like they are set to $fastq1 and $fastq2
if( $adapter ) {
my $trimfq1 = $fastq1; $trimfq1 =~ s/.R1.fastq/.trimmed.R1.fastq/;
my $trimfq2 = $fastq2; $trimfq2 =~ s/.R2.fastq/.trimmed.R2.fastq/;
if(
system( sprintf( "%s -Xmx2g in1=%s in2=%s out1=%s out2=%s literal='AGATCGGAAGAGCACACGTCTGAACTCCAGTCAC,AGATCGGAAGAGCGTCGTGTAGGGAAAGAGTGT' ktrim=r k=23 hdist=1 mink=11 hdist=1 ordered=t ignorebadquality", $trimcmd, $fastq1, $fastq2, $trimfq1, $trimfq2 ) ) ||
system( sprintf( "mv %s %s", $trimfq1, $fastq1 ) ) ||
system( sprintf( "mv %s %s", $trimfq2, $fastq2 ) ) ) {
die "Failed to trim adapters. Exiting...\n";
}
}
Any ideas on how to fix this issue?

I was able to fix this by renaming the files with a period in place of the underscore


Multiple VirtualServices define the same host

This ERROR should not be present.
ERROR: The VirtualServices bookinfo, httpbin in namespace(s) default, default define the same host, *. A host name can be defined by only one VirtualService. Consider updating the VirtualService(s) to have unique hostnames.

Although both my bookinfo and httpbin VS use '*' they are attached to different Gateways.  I have placed the Gateways on different ports.  It should not be a problem to have the same hostname if the gateways are different.
The message wording is difficult to parse.  Perhaps replace with something like
ERROR: The VirtualServices bookinfo.default and httpbin.default use the same host, "*". A host name can be used by only one VirtualService. Consider updating the VirtualService(s) to have unique hostnames or use different Gateways.

It might be useful to give the errors istio-vet codes like VS001 so that in the future we can look them up.

Thanks @esnible for filing this. I really appreciate your help in exercising these paths and filing issues as you find them.

Fixed by https://github.com/aspenmesh/istio-vet/pull/53 from @BLaurenB


Change deployment mode from environments/tenants

is it possible to change de deployment mode and tenantID depending on the environments/tenants?
because we would like to have develop, test and prod environments that means we have to keep track of three different files.
sort of the feature request (https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/33150376-remove-tenantid-from-custom-policies)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bdca08d8-4a1d-f11c-9e3e-6627ea0f18bc
Version Independent ID: 6bb42537-50b2-2af1-fdf7-86b76ed9afe6
Content: Troubleshoot custom policies with Application Insights - Azure AD B2C
Content Source: articles/active-directory-b2c/troubleshoot-with-application-insights.md
Service: active-directory
Sub-service: b2c
GitHub Login: @msmimart
Microsoft Alias: mimart

Did you try the VS code extension for Azure AD B2C. The policy settings feature allows you to manage the values of your Azure AD B2C environments.

@yoelhor Thank you for responding
@84618315 Were you able to look into the previous response.

yes, thx it was helpfull


Merge two config maps into one that defines control switches and user defined injections

This pull requests aims to merge User Defined Injections (UDI) ConfigMap into the control switches ConfigMap.
In result, there will be only one map to provided by the user. From the code perspective I refactored code by moving out from webhook.go all functions related to UDI into separate package called custominjections. This way, there is a clear information about package responsibility.
Fixes https://github.com/k8snetworkplumbingwg/network-resources-injector/issues/61

@zshi-redhat Could you review?

In the cmd/webhook/main.go, there is this piece of code:
202                 case <-time.After(30 * time.Second):
203                         cm, err := clientset.CoreV1().ConfigMaps(namespace).Get(
204                                 context.Background(), controlSwitchesConfigMap, metav1.GetOptions{})
205                         if err != nil {
206                                 glog.Warningf("Error within control switches map %s", err.Error())
207                                 if !errors.IsNotFound(err) {
208                                         glog.Info("Map with runtime configuration not available using default / CLI settings")
209                                 }
210                         }
211                         // has to be called each time because we need to restore default config when map is empty
212                         controlSwitches.ProcessControlSwitchesConfigMap(cm)
213                         userInjections.SetUserDefinedInjections(cm)
214                 }

Could we use the following:
                        cm, err := clientset.CoreV1().ConfigMaps(namespace).Get(
                                context.Background(), controlSwitchesConfigMap, metav1.GetOptions{})
                        if err != nil {
                                if !errors.IsNotFound(err) {
                                        glog.Warningf("Error getting control switches configmap %s", err.Error())
                                }
                                continue
                        }
                        // has to be called each time because we need to restore default config when map is empty
                        controlSwitches.ProcessControlSwitchesConfigMap(cm)
                        userInjections.SetUserDefinedInjections(cm)
                }

So that it won't print a Warningf message every 30 seconds and the processing of controlSwitch configmap would be skipped, when there is no controlSwitch configmap defined.
Also could you merge the three commits into one?
Thank you!

In the cmd/webhook/main.go, there is this piece of code:
202                 case <-time.After(30 * time.Second):
203                         cm, err := clientset.CoreV1().ConfigMaps(namespace).Get(
204                                 context.Background(), controlSwitchesConfigMap, metav1.GetOptions{})
205                         if err != nil {
206                                 glog.Warningf("Error within control switches map %s", err.Error())
207                                 if !errors.IsNotFound(err) {
208                                         glog.Info("Map with runtime configuration not available using default / CLI settings")
209                                 }
210                         }
211                         // has to be called each time because we need to restore default config when map is empty
212                         controlSwitches.ProcessControlSwitchesConfigMap(cm)
213                         userInjections.SetUserDefinedInjections(cm)
214                 }

Could we use the following:
                case <-time.After(30 * time.Second):
                        cm, err := clientset.CoreV1().ConfigMaps(namespace).Get(
                                context.Background(), controlSwitchesConfigMap, metav1.GetOptions{})
                        if err != nil {
                                if !errors.IsNotFound(err) {
                                        glog.Warningf("Error getting control switches configmap %s", err.Error())
                                }
                                continue
                        }
                        // has to be called each time because we need to restore default config when map is empty
                        controlSwitches.ProcessControlSwitchesConfigMap(cm)
                        userInjections.SetUserDefinedInjections(cm)
                }

So that it won't print a Warningf message every 30 seconds and the processing of controlSwitch configmap would be skipped, when there is no controlSwitch configmap defined.
Also could you merge the three commits into one?
Thank you!

I have removed the log that was polluting the events log. But please notice that I did not add continue'in case where there  error. According to what we agree within issue description, in case when there is no config map or it is invalid - NRI should restore default values.
I squashed also all commits into one, but could you explain me why I should do it? I thought that it is possible to squash commits when merge is done from my fork to npwg repo directly by gihub.

I have removed the log that was polluting the events log. But please notice that I did not add continue'in case where there error. According to what we agree within issue description, in case when there is no config map or it is invalid - NRI should restore default values.

In case there is no configmap - yes, I think it should re-initialize the settings.
In case the configmap is invalid - yes, NRI should restore default values (how do we define invalid, does it mean the data of configmap is not in right format, but configmap itself is retrievable by NRI?).
I think there is a third condition:
In case the NRI fails to get the configmap due to a temporary api unaccessibility, the settings will be re-initialized until the next api call success. I assume we would want to avoid the temporary change on the settings.

I squashed also all commits into one, but could you explain me why I should do it? I thought that it is possible to squash commits when merge is done from my fork to npwg repo directly by gihub.

Yes, you're right, the squash can be done in merge action, I will do that next time.

In case there is no configmap - yes, I think it should re-initialize the settings. In case the configmap is invalid - yes, NRI should restore default values (how do we define invalid, does it mean the data of configmap is not in right format, but configmap itself is retrievable by NRI?).
I think there is a third condition: In case the NRI fails to get the configmap due to a temporary api unaccessibility, the settings will be re-initialized until the next api call success. I assume we would want to avoid the temporary change on the settings.

Done.

@Eoghan1232 would you want to take another look since there has been some update since your last approve?

@Eoghan1232 would you want to take another look since there has been some update since your last approve?

Yes, I will review once more.


Write task with external deployments and artifacts loaded

I'm trying to write a buidler task but when my task is executed I try to get bre.deployments.all(); but it's empty.
My builder.config.ts has a bunch of external configs.
I'm not sure if this was supposed to work though.

Hi @tuler for the task to have the deployments available,
either the deployment json files have to exist in the corresponding deployments folder (in which case you get already deployed contract)
or the task has to call the deploy task. (bre.run("deploy"))

I'm talking about bringing external deployments from npm packages.
Should they already be available at bre.deployments.all()?

yes, these should be available (like for the deployments folder) assuming you are on the equivalent network
If this does not work, I would need more details, ideally a reproducible repo to figure out the problem

I just tested it again, and it works fine!
Sorry for the noise.


dawn-v4.2.0<EMAIL_ADDRESS>

api error => { message: 'transaction declares authority '{"actor":"eosio.token","permission":"active"}', but does not have signatures for it under a provided delay of 0 ms',
file: 'authorization_manager.cpp',
line_number: 405,

I have the exact same problem, still trying to figure out

Same. Was about to post this.
My code looks like this
var EOS = require('eosjs');
var i = Math.round(+new Date());
let initaPrivate = "5J7dLLEWRuK7ws5Jb7GcVJRFMJR4vFzL2bWp6mHvhx6GyAiiuz2";
let initaPublic = "EOS6RZNJvzvLUKhMF8dee4zgCKgU4Y5nYvVdHJApE51vFjYLKapdi";
let keyProvider = initaPrivate;
let eos = EOS.Localnet({ keyProvider });
let res = eos.transaction(
    {
        actions: [
            {
                account: 'eosio.token',
                name: 'transfer' ,
                authorization: [{ actor: 'eosio.token', permission: 'active' }],
                data: { from:'alice', to:'olivier', quantity:'50.0000 EOS', memo:' ['+i+']' }
            }
        ]
    },
    { broadcast: true });

Has anyone figured it out?

add chainId into Localnet options

@yepp4you  Thanks. Can you give me more detail information?
options = {broadcast: true,sign: true,initial_chain_id: "0000000000000000000000000000000000000000000000000000000000000000"}
But it does not work

https://github.com/EOSIO/eosjs/issues/118

options = {broadcast: true,sign: true,chainld: "b686f7d31bd96218d73a080b4bfac00abd34fe13725139cd4bd55fd2435c40db"}
chainld? But it does not work for me<EMAIL_ADDRESS>eos: dawn-v4.2.0

After added the chainId fixed the problem
let config = {
            chainId: "706a7ddd808de9fc2b8879904f3b392256c83104c1d544b38302cc07d9fca477",
            keyProvider: [privateKeys],
            broadcast: true,
            sign: true,
        }

let eos = Eos.Localnet(config)

@lihao6485  It works. Thanks

I'm getting this error when I do that:
api error => { message: 'transaction has expired, expiration is 2018-05-28T11:21:02 and pending block time is 2018-05-28T12:46:34.000',
  file: 'controller.cpp',
  line_number: 1380,
  method: 'validate_expiration' }

Has anyone got this before?

@Olivierlu1  you eos version and eosjs version? Also the action detail

Increase expireInSeconds
https://github.com/EOSIO/eosjs#configuration

@yankunsam I am using dawnv4.2.0 with 13.0.0 for eosjs.
@jcalfee I changed my config to:
let config = {
    chainId: '706a7ddd808de9fc2b8879904f3b392256c83104c1d544b38302cc07d9fca477',
    keyProvider: initaPrivate,
    broadcast: true,
    sign: true,
    expireInSeconds: 60
};

But it still doesn't work.

Actually, I was able to resolve the error by configuring my nodeos. However, I still get my initial error of:  api error => { message: 'transaction declares authority '{"actor":"eosio.token","permission":"active"}', but does not have signatures for it under a provided delay of 0 ms',
My whole program is simple and looks like this:
var EOS = require('eosjs');
var i = Math.round(+new Date());
let initaPrivate = "5J7dLLEWRuK7ws5Jb7GcVJRFMJR4vFzL2bWp6mHvhx6GyAiiuz2";
let initaPublic = "EOS6RZNJvzvLUKhMF8dee4zgCKgU4Y5nYvVdHJApE51vFjYLKapdi";
let keyProvider = initaPrivate;
let config = {
    chainId: '706a7ddd808de9fc2b8879904f3b392256c83104c1d544b38302cc07d9fca477',
    keyProvider: initaPrivate,
    broadcast: true,
    sign: true,
    expireInSeconds: 60,
};
let eos = EOS.Localnet(config);
let res = eos.transaction(
    {
        actions: [
            {
                account: 'eosio.token',
                name: 'transfer' ,
                authorization: [{ actor: 'eosio.token', permission: 'active' }],
                data: { from:'alice', to:'olivier', quantity:'50.0000 EOS', memo:' ['+i+']' },
            }
        ]

    },
    { broadcast: true });

@Olivierlu1  great 👍

not great! It doesn't work

@Olivierlu1 a transfer "from" alice needs an authorization from "alice" not "eosio.token" .. So change to: authorization: [{ actor: 'alice, permission: 'active' }],.


chore: increases version

@homu r+

:pushpin: Commit 64ebaeb has been approved by kbknapp

:hourglass: Testing commit 64ebaeb with merge 37006c3...

:sunny: Test successful - status


Sanitize basePath

The basePath argument to SimplaPaths.observe() is confusing - intuitively you specify a leading slash, like /base/path, but that results in the following //base/path which is invalid. Likewise I was just guessing whether I should include a trailing slash or not, if I had it would have resulted in /base/path//sid which is also invalid.
I think the fix for this is for observe() just to sanitize whatever it gets in basePath (within limits), particular in regard to leading and trailing slashes.

As an aside - paths like //path/to/content should warn, not error in console. Common for eg: dynamically defined SIDs (eg: headings on simpla.io) to have momentary missing parts of a path.

Yeah perhaps it would make more sense if we treated paths as normal file paths in terms of what we'll accept and automatically figure out? e.g. We know that //foo == /foo but foo != /foo and /foo//bar == /foo/bar and maybe /foo/bar/ == /foo/bar? In which case we should map out exactly how we're normalize it - or just follow a standard e.g. Something like node's normalize method.

I think a general solution to this is dangerous and would easily result in incorrect behavior. Just the input to observe should be normalized because the argument is ambiguous. See comments on other issue re throwing vs warning on invalid paths.

If we just update the docs so that the default value is actually '' (given that's what it should be, not /) - would the confusion still be there? An example of then using it would be:
Simpla.observe(document.querySelector('about-page'), '/about');

Actually I just realised, this might just be a bug, I may have misread your initial comment - you did:
Simpla.observe(element, '/base/path');

which failed? That should have passed, that's a bug. If that did succeed, would that less confusion?

Yes that failed, resulted in double leading slash. In any case don't see what the default value has to do with it (and surely that should be /, otherwise it'd fail if not defined no?).
That's intuitive enough, requiring a leading slash, as per normal paths, but the end of it is a little less clear, because you could define / or /base, which aren't consistent. Or can you not define /? That's confusing.

So you can't give it /, but you can give it /base. It's probably easier if you think of it as a prefix. So for whatever path is on an element, add the prefix: ${prefix}/foo/bar. If you give it /: //foo/bar, if you give it '': /foo/bar, /base: /base/foo/bar
Anyway, I get what you mean about it being confusing. Personally, I still think normalizing across the board would probably make more sense. So you could do Simpla.get('//foo/bar') and it would accept it no worries, like you would if you were dealing with file paths - makes it much easier to GROK, what do you think?

I vote hard no on normalizing across the board for the reasons I mentioned above - /foo/bar and /{temporarily-undefined}/foo/bar are very different paths, and it's very possible that it would fetch completely unrelated data that would either a) result in hella cryptic errors/bugs, or b) give you nasty FOUC. I'd prefer the current behavior (throwing) to that.
I don't see the problem with sanitizing the basePath argument here though? What's the issue with making it less of a PITA to guess by just checking what we were given? There's no ambiguity or edge cases with this - if someone gives it /foo/bar/ they obviously mean it to become /foo/bar/baz, not /foo/bar//baz. Same as /, that should obviously become /foo/bar, not //foo/bar. That last one in particular is a big gotcha for no reason. To be explicit in a function call it makes sense to give basePath something, and that something should be /, not '' (to be consistent with paths everywhere else). It's just really confusing, and requires users to understand the internals of what this function is doing.

FWIW I think that the user should check something's undefined before handing it to the element - otherwise I would expect it to get the wrong value. But, erroring is also OK IMO - so happy to stick with that.
As for that, yeah I definitely would like to normalize, I'm just worried it'll be inconsistent elsewhere. But, I've just realised I've been thinking of it wrong: this is actually the only place where you give a path and it will be joined with another path else i.e. all other times you're dealing with a path it's a full one, and then at other times it's just sid and gid which aren't allowed / in them.
Given that, yup happy to sanitize base path.

This is actually the only place where you give a path and it will be joined with another path else i.e. all other times you're dealing with a path it's a full one, and then at other times it's just sid and gid which aren't allowed / in them

Yes, exactly. This isn't the same thing as defining a path in elements or get or whatever, it's a totally separate argument, and therefore can play by different rules.

and

FWIW I think that the user should check something's undefined before handing it to the element - otherwise I would expect it to get the wrong value

Yeah that's fair enough - but yeah, I'd rather it blow up explicitly (or warn explicitly, but that's neither here nor there ;-) in that case rather than do the javascript thing of trying to make everyone happy and breaking in much weirder ways


Implement builtin0-4

Currently only added to satisfy imports, actually properly implement it. Needed: sample rego.

Tracking https://github.com/open-policy-agent/npm-opa-wasm/issues/7

Tracking https://github.com/open-policy-agent/opa/issues/3083

Tracking https://github.com/open-policy-agent/opa/issues/3083

@christophwille, I played around this weekend and was able to copy what the NPM SDK is doing for automated tests. Should I open a PR?
I've made it so you can basically copy the exact same YAML test files into a directory in this repo, and NUnit should pick them up and display them as separate tests. I was able to get NUnit to run the tests, but discovery is not working for those tests in VS Code Intellisense, but it does work in the Test Explorer and using dotnet test.
I also implemented a few builtin calls as an example (regex, sprintf). I think that the way it's set up now, to implement new builtins wouldn't require changes to the core OpaPolicy class. An example workflow for contributing a new builtin would be:

Copy the corresponding test from open-policy-agent/opa.
Implement a normal C# static function in a Builtins class (with normal type signatures, etc.).
Annotate your function name with [OpaBuiltin(<name of builtin>)].
Run the tests to see if they pass.
Update the capabilities.json file to include the new function.

I know this is a lot of code and changes, so I'm OK if you don't want to pull them in or review them. I just had fun trying it out!

I haven't thought about implementation details for builtins, but I had lambdas in mind initially (not really having thought about alternatives or ramifications of certain choices).

Yeah, I didn't think too deeply about it either. I think my main goal was to centralize the value lookups and type casting from OPA/WASM so that the methods had normal type signatures (and could be tested independently). At first, I tried registering Func in a Dictionary, but the type signatures became to unwieldy for me to unravel. Someone with more experience might have a different way of going about it.
I'm not sure of the performance impact of using reflection either. I cached the attribute lookup into a static Dictionary, but that's the optimization I made (and I don't even know if that would make a real difference with the JIT). There's also some extra boxing happening between JSON deserialization, and then type-casting to call the builtin implementation method. I haven't benchmarked the builtin calls at all either.

I'll have a look at your code wrt builtins later this week.

Sounds good. Let me know if opening a PR would make it easier for you to review.

What would be helpful is a couple simple regos to use for unit tests in the inner loop to prototype a few approaches.

Dumping ground for my notes:
The docs: https://www.openpolicyagent.org/docs/latest/wasm/#built-in-functions
The JS impl: https://github.com/open-policy-agent/npm-opa-wasm/blob/7f3b0e0f088222aab279f255b95b8b3919a81a3a/src/opa.js#L97
iinuwa commit: https://github.com/iinuwa/dotnet-opa-wasm/commit/d8435d1e65fc44c41dce1198ecd133ad8382b079
I see the following requirements:

the caller of this library will define the built-in functions, yes, we might supply a couple "default ones", but in general this will be a per-policy thing.
given that it is a per-policy thing, willy-nilly collecting "everything we find" (by whatever means, eg attribute) isn't a good approach

A couple personal guesstimates:

passing arg1.. arg3 as json strings should be enough. I'd expect most devs to pass a JSON obj as arg1 anyways.

My preference then would be for the built-ins to be an optional argument to eg the ctor. Or a .WithBuiltin composable call.
policy.WithBuiltin(...).WithBuiltin();
additionally we could considers an .WithBuiltins(...) call that takes a hashtable of sorts. Preference: Action

@srenatus is there any more docs on the architectural intentions of wasm builtins other than https://www.openpolicyagent.org/docs/latest/wasm/#built-in-functions ? Thanks. Especially useful would be the "intended use case" eg are builtins a library feature or a per-policy custom feature? The JS code looks like "hard-coded and library-provided" whereas the wasm docs seem to suggest that any policy can come with any custom builtin requirement.

The set of SDK-provided built-ins that a module needs depends on the rego code. So, if your policy only makes use of natively-implemented functions (the "✅" rows here), then it will not need any of the SDK-provided built-in functions. Also, the builtins will only be required if the policy evaluation actually takes a path that requires the built-in, e.g.
package foo

allow {
  input.x == "bar"
  http.send({...})
}

would never call the built-in if input.x wasn't bar.
When compiling a policy to wasm, there's a capabilities file that defines the set of available builtins. When you do opa build -t wasm, it'll use the capabilities of the opa binary you're using. You could, for example, have a capabilities file that only declares the natively-implemented built-ins, and if you used that for compiling your wasm module, you'd have some assurance: the opa build command would fail if the rego policy used a built-in not in the capabilities file.
Similarly, you could maintain a capabilities file that covers the natively-implemented functions PLUS the ones implemented in this specific SDK -- it could then be used for compiling rego to wasm meant for the use with this SDK, and you'd know at build time that it's going to work in the end.
To make life colourful, your capabilities file used with opa build could declare built-in functions that opa doesn't know at all, but you could provide them in your SDK. Anything you could come up with, really.
The short answer is

any policy can come with any custom builtin requirement

but you can control it using the capabilities feature.

Thanks for the detailed answer! Regarding the "SDK-dependent" piece re:functions more generally: Is there a page / md somewhere on the common features SDKs are supposed to support? Like "at the minimum an SDK must support a, b, c..." or "a full-on SDK must additionally provide the following x, y, z".

I'd like to harken back to the capabilities file... scenario "one additional custom function whatever.func". What is the easiest way to tell opa build that I want "all the stuff that OPA comes with + my custom func". Because I only see --capabilities taking one file. And copy/pasting the default file to append one custom single capability seems a lot of work (esp. when OPA revs, I'd need to keep my copy updated with the new "defaults")

There is no simpler way right now. But I suppose the addition of a single function could be automated, via a clever opa eval or jq call 🤔

Is there a page / md somewhere on the common features SDKs are supposed to support? ...
Nope there's no such guidance, I'm afraid.

Maybe in place of this, repositories of rego files (example) could be scraped and parsed to see which builtins are called the most to determine the implementation priority. I would imagine that http.send, and SDK-dependent regex builtins would be pretty high on the list.

And copy/pasting the default file to append one custom single capability seems a lot of work (esp. when OPA revs, I'd need to keep my copy updated with the new "defaults")

I totally agree; it was a pain to do that in the patch that I made. That would also keep you locked into the latest version of OPA. (Otherwise users may naively write and build policies based on functions that the SDK doesn't provide.)
Off-topic for this repo, but maybe a feature could be added to opa build to create a new --add-capabilities flag that can be specified multiple times with different JSON files. Its behavior could be:

to add new capabilities on top of the provided ones, in other words, the non-SDK-dependent builtins would be retained
and to merge the given files by:

producing union of the allow_net arrays
merging builtins by builtins.name, failing if there are any builtins that are specified twice.

Then the SDK authors could just write the capabilities that they explicitly provide, and SDK users could append to that with their own custom functions.
Until then, maybe maintaining a capabilities.json file with instructions to copy the default capabilties from the open-policy-agent/opa repo and merge the SDK capabilities using jq as srenatus mentioned would be better. More work for the user, but more maintainable.

Here's a shell script that can merge capabilities files, optionally overwriting builtins that are defined more than once.
It's written in sh, so it'd require Git Bash/Cygwin/WSL to run on Windows, but I can port it to PowerShell Core if that's more desirable.

merge-capabilities.sh
#!/usr/bin/env sh

HELP="A utility to merge Open Policy Agent capabilites.json files.

Usage:
    $0 [--allow-duplicate-builtins] <FILE>...

Options:
    --allow-duplicate-builtins
            Allows builtin functions to be defined multiple times. The last
            definition specified, based on the order of the <FILE> parameters,
            will be included in the output.
    -h, --help
           Print this help.

Arguments:
    <FILE>...
      File(s) to merge. Use a dash ('-') to read from standard input.

Examples:
    # Add custom policies to delivered policies
    $0 capabilities-v0.34.0.json capabilities-custom.json

    # Add a remote host definition
    echo '{\"allow_net\": [\"example.com\"]}' | $0 capabilities-v0.34.0.json -

You can find the delivered capabilities files for each OPA version online[0].

See the capabilities documentation[1] for more information.

[0]: https://github.com/open-policy-agent/opa/tree/main/capabilities
[1]: https://www.openpolicyagent.org/docs/latest/deployments/#capabilities
"

for arg in $@; do
  if [ "--help" = "$arg" ] || [ "-h" = "$arg" ]; then
    echo "$HELP"
    exit 0
  fi
done

if [ -p /dev/stdin ]; then
  read STDIN
  STDIN=$(echo -n $STDIN | jq '$default * .' --argjson default '{ "allow_net": [],"builtins": [] }')
fi

FILES=$@
DUPLICATED_BUILTINS=$(echo -n "$STDIN" | jq -s -r '
  [ .[].builtins | .[] ]
  | group_by(.name)
  | map(select(length > 1))
  | map((.[0].name))
  | join(" ,")
  ' $FILES)

if [ ! -z "$DUPLICATED_BUILTINS" ]; then
  echo "Duplicated builtins defined: $DUPLICATED_BUILTINS"
  echo "Exiting."
  exit 1
fi

echo -n "$STDIN" | jq -s '
  {
    allow_net: [
      .[]
      | .allow_net[]
    ] | unique,

    builtins:
      [ .[].builtins | .[]]
      | group_by(.name)
      | map(.[-1])
  }' $FILES


Updates to the standard Terms of Service - Winter 2019

This update to the Terms of Service include a number of changes for compliance purposes and clarifications, including changes to the following sections:

Account Requirements
Acceptable Use
Private Repositories
Additional Terms for GitHub Pages and Learning Lab
GitHub Learning Lab

Thank you all for your comments and feedback! As stated in our blog post, the comment period ends today. I am closing this pull request for internal review of any remaining comments. We will commit final clarifications or edits when we merge this pull request next Friday, April 19. At that time, the updated version of this policy will be effective.


bug: processNextHandler is null (React)

Bug Report
Ionic version:
[x] 5.0.7
Current behavior:
When using ev.detail.register(prio, (processNextHandler) => {}), processNextHandler is null.
Expected behavior:
processNextHandler should be a function calling the next handler
Steps to reproduce:
Follow the docs to set up a handler.
Related code:
  document.addEventListener('ionBackButton', ((ev: BackButtonEvent) => {
    ev.detail.register(0, (processNextHandler: Function) => {
      processNextHandler();
    });
  }) as EventListener);

Other information:
My current workaround is:
  document.addEventListener('ionBackButton', ((ev: BackButtonEvent) => {
    ev.detail.register(0, () => {
      if (history.length === 1) {
        Plugins.App.exitApp();
      } else {
        history.goBack();
      }
    });
  }) as EventListener);

Ionic info:
Ionic:

   Ionic CLI       : 6.5.0 (/usr/lib/node_modules/@ionic/cli)
   Ionic Framework : @ionic/react 5.0.7

Capacitor:

   Capacitor CLI   : 2.0.1
   @capacitor/core : 2.0.1

Utility:

   cordova-res : not installed
   native-run  : not installed

System:

   NodeJS : v14.3.0 (/usr/bin/node)
   npm    : 6.14.5
   OS     : Linux 5.6

Thanks for the issue. This feature shipped in Ionic React 5.1.0, so you will need to update to the latest version of Ionic React in order to use it.


Consider adding pydocstyle linter to our automated checkers

Consistency and formality in docstrings are useful. Pydocstyle is used in many projects to allow maintainers to define their rules and provide automated feedback to developers about compliance. We should consider using it.
http://www.pydocstyle.org/en/stable/

LOL.  Running pydocstyle on ARMI yields 3204 linting errors in 281 files:

27 x (D100) Missing docstring in public module
92 x (D101) Missing docstring in public class
445 x (D102) Missing docstring in public method
62 x (D103) Missing docstring in public function
24 x (D104) Missing docstring in public package
206 x (D105) Missing docstring in magic method
1 x (D106) Missing docstring in public nested class
201 x (D107) Missing docstring in init
211 x (D200) One-line docstring should fit on one line with quotes
1 x (D201) No blank lines allowed before function docstring
82 x (D202) No blank lines allowed after function docstring
9 x (D204) 1 blank line required after class docstring
271 x (D205) 1 blank line required between summary line and description
1 x (D208) Docstring is over-indented
18 x (D209) Multi-line docstring closing quotes should be on a separate line
2 x (D210) No whitespaces allowed surrounding docstring text
1 x (D300) Use “””triple double quotes”””
6 x (D301) Use r””” if any backslashes in a docstring
841 x (D400) First line should end with a period
550 x (D401) First line should be in imperative mood
7 x (D402) First line should not be the function’s “signature”
131 x (D403) First word of the first line should be properly capitalized
15 x (D412) No blank lines allowed between a section header and its content


Detected the true Columntypes when initializing Column or Table

Is your feature request related to a problem?
Based on bug #315
Desired solution
Designing a new function that detectes the Columntype based on the Safe-DS column types. The function is called when a new Column or table is initialized.
Type hierarchy:

Anything

RealNumber

Integer

Boolean
String

Possible alternatives (optional)
No response
Screenshots (optional)
No response
Additional Context (optional)
No response

See #127

:tada: This issue has been resolved in version 0.15.0 :tada:
The release is available on:

v0.15.0
GitHub release

Your semantic-release bot :package::rocket:


Demo program usage problems

Thank you so much for your code! This was my first C++ development on Zynq and freeRTOS and lwIP.
Could you please provide two new demos:
1 On Zynq, the data from the host computer is received using UDP and parsed into numbers (double, small-endian storage).
2 Using the "producer-consumer" model, the data generated by Zynq signal processing is sent to the host computer through TCP. Among them, the signal processing module is the producer, and the TCP sending module is the consumer.

Hi!
Honestly, I do not plan to work on the demons you suggested because things like this are currently not needed in my projects. 😃
Re: 1
Have you tried ChatGPT? At my request, ChatGPT produced the attached UDP lwip socket data receiving demo.
I did not test it, but at first glance, the code looks correct.
Re: 2
Well, this you can basically do using the content of this repository. You can write any binary data from CPU memory to the FileViaSocket using the method ostream::write.
You just have to modify file_via_socket.py to do what you need with the received data, not just writing it to a file.
//UDP lwip socket data receiving demo

#include "lwip/opt.h"
#include "lwip/sys.h"
#include "lwip/sockets.h"
#include "lwip/netdb.h"
#include <string.h>
#include <stdio.h>

#define RECV_PORT 12345
#define BUFFER_SIZE 1024

void receive_task(void *arg)
{
    int sockfd;
    struct sockaddr_in recv_addr;
    char buffer[BUFFER_SIZE];
    int len;
    struct sockaddr_in sender_addr;
    socklen_t sender_addr_len = sizeof(sender_addr);

    // Create a socket
    sockfd = lwip_socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd < 0) {
        printf("Socket creation failed.\n");
        return;
    }

    // Prepare the sockaddr_in structure
    memset(&recv_addr, 0, sizeof(recv_addr));
    recv_addr.sin_family = AF_INET;
    recv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    recv_addr.sin_port = htons(RECV_PORT);

    // Bind the socket to the address and port
    if (lwip_bind(sockfd, (struct sockaddr *)&recv_addr, sizeof(recv_addr)) < 0) {
        printf("Socket bind failed.\n");
        lwip_close(sockfd);
        return;
    }

    printf("Listening for incoming packets on port %d...\n", RECV_PORT);

    while (1) {
        // Receive data from the socket
        len = lwip_recvfrom(sockfd, buffer, BUFFER_SIZE - 1, 0,
                            (struct sockaddr *)&sender_addr, &sender_addr_len);
        if (len < 0) {
            printf("Receive failed.\n");
            continue;
        }

        // Null-terminate the received data
        buffer[len] = '\0';

        // Print the received data
        printf("Received packet from %s:%d\n", inet_ntoa(sender_addr.sin_addr), ntohs(sender_addr.sin_port));
        printf("Data: %s\n", buffer);
    }

    // Close the socket (never reached in this example)
    lwip_close(sockfd);
}

int main(void)
{
    // Initialize the lwIP stack (assumes initialization code is provided elsewhere)
    lwip_init();

    // Create a task to receive data
    sys_thread_new("receive_task", receive_task, NULL, DEFAULT_THREAD_STACKSIZE, DEFAULT_THREAD_PRIO);

    // ...

    return 0;
}