Documenting the process

Thought it might be an idea to document the process that has been done so far.
1. Screen discussions
Screen discussions: We met virtually and all jammed on figma. This was done over a few calls where we looked at the individual screenstates of the current GUI and discussed various aspects of that. Some comments were made around certain features, as well as whether to move certain features to different screens and so forth.
Figma file
2. Created an initial design document
Christoph created an initial planning document, outlining the possible steps we  could take as well as things we would have to think about during the design process.
Planning document
3. Created user stories
Christoph created some initial user stories where he tried to think about the different user groups and how these groups would use the gui. He created 4 different user stories.

As a user, I want to…
As a casual user, I want to…
As an experienced user, I sometimes want to….
As a developer, I want to…
The document with the user stories can be found here

Within the design document some initial sections were created which might exist within the interface.
4. Grouped user stories
Mo then grouped the user stories under the various categories (mentioned above). The purpose of this was to see which user story fitted under which area of the interface design. With a goal possibly being of when the initial designs are iterated we can go back and look at if the user stories are fulfilled by the design itself.
Figma file
We also thought about prioritizing the user stories and will be thinking more about that as well.
We also thought about interviewing the devs to ask them about what user stories they would like included.
5. Collaboration guidelines
Christoph had an idea on how to collaborate on the design process, that can be found here
https://github.com/BitcoinDesign/Bitcoin-Core-App/discussions/23

Initial direction
After having a call with the devs yesterday, we discussed two things:
1) Minimum viable product
A minimum viable product (MVP). This would ensure that the build process is starting with some core fundamentals and then moving into the complexity as we move forward.
To build a MVP, I asked the question which part of the userflow could we best focus on. The devs mentioned in this initial phase it would be good to focus on:
Onboarding -> Create wallet -> Send and Receive
2) Menu layout options
Primarily there are 2 options to layout the menu, a horizontal menu layout as well as a vertical menu layout.
Christoph created some design ideas around both and we had a small discussion around which menu options would be available.
While both menu layouts have their strengths and weaknesses, at this stage all ideas are still being explored. We also discussed the layouts and the strengths and drawbacks of each layout.

Block clock design
Christoph has come up with some variations of the block clock which he has shared on Youtube for some feedback.
During the onboarding process the block clock is introduced showing the blocktime. There is a circular display indicating the clock and there are 2 variations of this. One variation has the blocks as individual units and the other variation has the clock as a continuous circle.
Link here to the video walkthrough
User flow
Mo created a user flow  and we jointly worked within this flow yesterday exploring it and expanding it mostly within the send section.
Link to userflow

We discussed issue #158
This issue addresses a cleanup of the available screens. From that discussion is was decided on to focus a bit more on:
Connection Screen settings
At the moment within this screenstate there are two settings:

Database cache size
Script verification threads
There has been a discussion around possibly moving these to detailed/advanced settings.
MASTER

PR

Init Error message
This is essentially an error during the initialization phase. We had a discussion around re-designing this screenstate and at the moment have  some rough modal designs.

Proxy Screen + Disabled screen settings
We did an initial design exploration around this screen today with the idea of presenting some ideas to the devs on the next call.
How to contribute page
Christoph has worked on the how to contribute page and has added alot more content to it. Suggestions to the content can be added here.

During the last 2 calls; one of which was with the devs and the 2nd was a design focused call. We discussed the following:
Design documentation
We discussed the design documentation website which is live. The goal of this documentation is for new  design contributors to have an overview of the project as well as the design principles as well as how design decisions were made. This is fully open for contributors and feedback.
Storage screen
There are currently 3 screens focused on storage, there is an idea to perhaps remove the 3rd screen.
Multisig signing screens
We reviewed the multi sign signing screens which were designed by Gene

Create wallet: Regular wallet
Some initial designs were created and an initial user flow for the create wallet flow. This is still in its very early stages and many further iterations will be made based on the feedback from the devs as well as some technical considerations which we will research.

Create wallet: Regular wallet: User flow

During the last 2 calls we:
Roadmap
Christoph created a roadmap to track all the things within the gui that are being worked on at the moment.
This is a nice easy tool to use when there are multiple people working at the same time and keeps for easy clear collaboration
Blockclock
We decided now at the initial stages it would be best to go for the design of the blockclock that is the easiest to implement for the devs
Storage location settings
There are some duplicates in some of the settings. It will be worked on in the future as to how to work with these.
Clickable prototype
It was discussed to create a clickable prototype two parts of the userflows which have been designed; onboarding as well as the create wallet flow.
Blockclock
Shashwat has created an initail iteration of how the block clock could show up in the gui.
Focus states
Some design decisions were made around the focus states. The designers agreed that:
Design decisions:

The Focus outline would be in purple

There would be an offset with the outline. Filled and outlined buttons would have an offset, free buttons the outline would be inset.

List items:
Hover: Orange light 1
Active: Orange light 2

Error messages would show a red outline as well as red text under the input box with a warning icon.

Our last 2 calls were very good, quick summary below:
Designers documentation
We discussed cross linking the design documentation with the developers documentation. We looked at the information architecture of the designers website. Below a quick look at the possible information architecture of the website.

Onboarding & Create wallet
We focused on the user flows for both onboarding as well as creating a wallet. During our second call we looked at the user flow of both and got some valuable input from the devs.
With the creating wallet flow we also looked more at the userflows for creating:

A regular wallet
A view only wallet
A multisig wallet

Blockclock

The Blockclock is further along in development.
Shavaan needs to figure out a workaround with regards to displaying the segments
Suggestion from Christoph is to use the gradient approach

User expectations
We had a discussion around how to manage user expectations during the onboarding and create wallet process.
Two things that affect the initial user exp are

The internet bandwidth it takes to sync to the network
The amount of hard drive space it uses on the users pc

We also discussed 2 things that a user could do during the IBD, at the moment there are only 2 things a user can do;

Seeing how much of history is downloaded
Seeing who you are connected to

Do we need to educate users about 1) That the initial download might slow down their pc. 2) There are some there tasks they can do (read the whitepaper) while waiting for the initialization process to continue.
Create wallet flow
We spoke about the create wallet flow which was further worked on by Micheal. We all commented on this flow idea and found it good as an initial iteration. The design can be seen below.

We also looked at the copy on the screenstates themselves as well as the copy on the labels and agreed that the copy itself needs a good thorough look to adjust it for consistency and understanding. Having good copy is going to be essential to the users exp of the gui.
Peers window
We also discussed whether in the future it might be relevant to create a screen for a peers. The purpose of this screen would be so that users can

Add more peers
See how many peers the currently have

Block clock implementation
Shavaan has coded the block clock which now very closely resembles the original block clock design made by Christoph. The now coded design shows the different fractions of how the clock is broken up/fragmented.
Onboarding flow
Christoph worked further on the onboarding flow and we would say it is about 90% finished now.  Some items that are still being discussed are:

Do we want to make it optional in the beginning to allow a user to skip the encrypt wallet part until they make a first transaction? Or do we want to design it in a way that the encrypt wallet is highly suggested but allow an option to skip it.

Copy: With regards to terminology used we will during the process of looking at the designs also ensure that the copy amongts all the screenstates are related and connected. So for example using the word passphrase on one screen should then be used across the other screenstates as well to maintain consistency,
Dashboard time:
This is another concept we discussed as to how that time with syncing with the network will be shown on the interface.
Top navigation

Create wallet flow

# Some additional designs/iterations have been made to the create wallet flow as well:

The create password section has been refined further which is now different to the previous design mentioned in previouos updates.
Screen designs have also been added in for unsupported wallets as well as confirmation screens when imported wallets are recognized.
Confirmation screen that wallet has been created

Yesterday's call was focused on the Storage screen states.
Storage settings screen

Storage space: Try a design with a slider and see how the different variations look

Storage location:

Default directory (this is different for every operating system, will be stored in a folder)
Custom directory (This is a custom location that they save)
Will we need to show a file picker window?  That would be the file picker from your computer

Does this happen as soon as they click? The file picker will automatically pop up. (the devs will try to code it so that it automatically opens the file picker on the persons computer)

Copy on the screen of Storage location screen:

Main heading is: Storage location
2 sub-options below would then read Default Directory and Custom Directory

Look at the option to change this to Default and Custom
Storage amount screen
This screen is allowing the user to decide on how much data they want to store
Choices:

Reduce storage (uses 1GB) - Pruned (Reduce storage)
Store all data (uses 440GB) - Full archival node (Store all data)

Added in some text to the design that with Store all data (they support the network) and with reduce storage (they are using it as a regular wallet)

Main topic is preparing for the first release of V1
There is a plan to have a soft launch of V1, create awareness that this is happening and spread some awareness via various channels that we are looking for feedback on V1.
Main tasks to be done:

Website

There might be some limitations wrt the model of android phones which V1 will run on. Maybe mention something about the android version that it can work on.

Collect feedback

Airtable, Github, Twitter

Testing will be done on

Desktop windows
Desktop mac
Android
Linux

Media plan

If you are  using the QT Gui you cannot replace it, it is very simple, it is not running a node. The mission of this app is to get people to run a full node.
Channels where we will do the announcements and ask for feedback:

Community call on November 30th we can do a soft release there through the community

Twitter:

Jarol long form blog post

December 9th - have the app out there
Coding to do:

Block clock

Some initial usability tests were done on V1.
Usability testing V1

During the call with the devs  we discussed the following:
Block clock
The block clock is further in development and the initial view for the clock has been developed as well as the pause screen.
Scroll view
This has now been fixed. The devs have come up with 2 different options. This is the automatic re-sizing that happens when the GUI is viewed on mobile.
Scroll View Github
Re-usable Settings
Re-usable settings Github
To do: Test 193 on android
Github
Proxy Settings Screen
The proxy settings screen would be for someone who wants to use these settings. However it might be an option to include this in V1.
Peer window
The original peer window contains alot of different information. This screen has now been simplified to contain just a few headings.

Christoph created a new view with buttons selection options, where the data can be sorted on Version, IP, Network and Ping

Might be an idea to add in sorting data by direction. Default sorting is by age of connection.
To do: Test out the peers window in the current version of the GUI.

Design file cleanup
Main design file has been cleaned up.
Peers screens
Peers screens have also been added and some different screen variations has been created.
Block clock progress

Block clock connecting to network this seems to be stuck atm and provides no clear feedback, it is currently showing that it is stuck on 0%
Switch out logo
Connecting circle
Peer indicator moving pattern
Peer indicator tool tip( Requires hit box change)
Fade out/in when changing state
Theme color switches (uses color variables)
Estimated time number formatting
Time estimation (confidence level showing an estimate)
Minimum visual indicator of percentage display

5 dots is the connectivity
The color of the circles is showing how much of data has been downloaded (small dots at the bottom, if user clicks on that then it will show connectivity to peers, will show in red if there is a peer connection problem)
[Block Clock interactive states](https://stupefied-jones-dd209f.netlify.app/)]

User feedback/UX Research
Use both avenues to collect user feedback as it might hep to inform the design more (First have to wait for block clock to be integration to be further implemented)

Usability tests
Feedback form

Naming of the downloads:
[gui-qml/src/qml at main · bitcoin-core/gui-qml](https://github.com/bitcoin-core/gui-qml/tree/main/src/qml)
The devs can instead build a separate binary and rename that something a bit easier.
Options handling
Test option 3 and provide feedback

21 December call notes:
During this call mainly the input fields were discussed as well as the blockclock.

Testing guide: Jarol will start to put together a testing guide
The Gui is frozen on testnet at the moment, the screen should indicate in someway that they are on testnet. People would need to know that they cannot get onto the mainnet.

Input fields:

Automatic validation
Error states for input fields to make UI designs
The input fields are pre-populated

Good practices of Input fields:

Error states
Maximum input numbers (minimum numbers and max numbers)
Feedback: The user needs to be informed when the info they have provided is incorrect
Back-end code: Technically it should have a pre-cleanup that does not allow certain data to enter the system

Blockclock

The clock will start at zero and as a block is mined then the clock will add on a part/section to the clock, a bar.
The clock has a timer which is for updating the tip…the next rectangle point being shown on the clock

[Link](https://github.com/bitcoin-core/gui-qml/pull/148](https://github.com/bitcoin-core/gui-qml/pull/148) to download blockclock

Tasks

[ ] Peer screen: Make the selection criteria horizontally scrollable instead of 2 layers one after the other.

[ ] Error states and behavior to the design system

Add to the design documentation, if you go into a setting screen and you tap a field and you type in text. If you enter 10 billion. If it goes beyond the max value value that we allow. does it show an error message?
Add these to the design system. The logic only exists in code, but adding in the logic about these error states into the design documentation as well

[ ] Peer screen (copy)

Release planning

[ ] 1. Come up with a proposal on how we can organize the release

[ ] Create a UX Research plan
3 circles of research

Initial audience (the initial circle ore of people who are initially active) (week 1)

2nd circle (bitcoin design community)

3rd larger community

[ ] Mo to test this version with a focus on error states:

[[DO NOT MERGE] Review current state by jarolrod · Pull Request #267 · bitcoin-core/gui-qml (github.com)](https://github.com/bitcoin-core/gui-qml/pull/267)

To do:

[ ] Ideate on application release notes

[ ] Open up a PR for the spelling of the file name to change it from insecure to unsecure.

[ ] Graph toggle: There is a graph that collects network data and you want to see a graph, the app needs to have collected the application. An option is to only start capturing the data from when you start using the graph.

Toggle: By default do not always collect this history. (Start with 24 hours)
UX Research
A question was asked; what would the devs like to know once it's launched and what would  we like t know from the design perspective?
Devs questions: What are they interested in knowing

The developers are interested in technical issues such as crashing or freezing
What feeling do they get when they run it? Is it too scary for them?
Do they feel confident, I can run a full node and it doesn’t feel like jumping in the deep end?
Mission: Did you run a node before? Will this make you likely to run a node in the future?

Design questions: What is interesting to learn more about from the design side of things?

Do they find it useful?
What device are they using?
How do they manage the initial block download?
Is the download process clear?
How many people stumble on the download process?
How does it fit into peoples lives
Do they see themselves letting it run?
Does the block clock make sense to them?
Do they find the block clock interesting and useful

Will use the above to create a list of questions which will inform the research questions we as first time testers.

UX Research: Milestone 1
Why?

We wanted to test out milestone 1 with a smaller audience before testing it on a wider circle.
We wanted to understand how the installation process was experienced by people
We wanted to understand the Initial general impressions as well as impressions of the block clock

How?
We hosted a call within the bitcoin design community. During this call one of the Bitcoin Core developers were present as well as the Christoph and Mo. Two people tested milestone 1 on Macs.
Link to call
Image shared

Post that was shared:
Tomorrow 13 April at 14:00 UTC we are going to be having a super fun UX Research call. We will be doing some live testing of Bitcoin Core App. It's going to be really hands on. We will onboard ourselves and walk through the interface together. The only prep before the call is to install it on your device of choice.
:arrow_right: Check out the Github link where you'll find the latest download links. The team have been working away to bring this new design to the ecosystem and we are really keen to see how you the community experience it.
Where was the post shared?:

Bitcoin Design Community Slack
BDK Discord
Fedimint Discord

What we discovered?
Installation process

Installation process errors if there is a previously installed version of Bitcoin Core.
Onboarding userflow is skipped if there was a previous version installed.
-Mac user might need guidance on finding the signing path during the installation process

Syncing screen:

When the app fails to sync we could provide feedback that the app is failing to sync

Block clock:

When clicking the block clock it pauses, it may require feedback in the hover state to provide guidance that when clicked the clock pauses.

Settings screen:

Users were a bit surprised to find the peers/network traffic in the settings screen.

Repository:
A repository has been created where all of the user feedback can live and be captured from milestone 1
Why?

An open public place where all builders can look at the live raw feedback from UX research that was conducted.
A hub where all UX research insights can live
An insight into the main friction areas in the user flow

How?
A public repository was created in Github.
Link to repository

Quick update after the last call. During the last call Christoph suggested a more structured way of working towards the future milestones.
What are our goals?

Easier to maintain - new framework
Android - billions more people can use it
Design foundation & maintenance
Better feedback loops
In the conversation of self-custody

V1 Screens

In addition to the screens which are already designed, V2 will have additional screens added to the user flow. The additonal screens are highlighted with a star in the below diagram and figma document.
V2 QT Parity Screens

Version release plan
Link to document

Christoph has further bucketed the design process into mini buckets:
V2 Parity Mini buckets:

Navigation restructure
Wallet import
Wallet creation
Activity and balance
Receive
Send
Other

Navigation explorations
The navigation is being built out atm.

Development needs atm:

A Design top bar state for when app is built without wallet features.

App can also be built without:

Port Mapping, NATPNP, UPNO - disappear of disable

Clickable prototype navigation
Jakub created a clickable prototype in Figma for the navigation explorations.
Widget design explorations
Christoph has done some widget design explorations here.

Project Management
Christoph has also created a repo for project management which covers milestones and a roadmap.

UX Research
We will be kicking off a research initiative which is in the process of being developed. The goals of the research initiative are to;

Understand the personas using Bitcoin Core
Understand the jobs that the interface needs to do to meet the needs of these personas
Understand the parts of the UI that are being used more heavily than others
Understand their struggles and hopes of people when using the GUI
Understand what frustrates or makes people happy when using the GUI

So far a research plan has been created and together we are reaching consensus on what would be the best approach.

Mapping UX Research done on Bitcoin Core
Mapped out the current research initiative as well as past research initiatives that have been done on core. The purpose of doing this was to:

Visually see how all the past and present research initiatives are connected to each other.
Pool all documents  from current and previous research together in one place.

Ideate on what is missing in the current research plan and improve it.
Link to mapping
By clicking on the individual squares they then open up links to files and documents associated with that topic.

Visual of mapping

Research project plan
Github project board

Dev update

Working towards 1.1 polish milestone
Reworking a few things for a better technical foundation moving forward

UX Research update

Mo and Jakub gathered 20 interviews with Core users
Also interested in talking to developers to learn about their needs
Gui could have a dev mode
Idea is interview developers and understand their needs so that there is a separate environment that is developed for them
We now have a developer options screen, the console is also a developer option tool

Wallet import
Michael presenting import wallet flow work
Figma file
File figma: Wallet Import 1.3
Import wallet screen

No seed or descriptor import option - file import is enough
Multiple imports require multiple flow walkthroughs
Descriptor import as a possible additional feature in the future
Any extra permissions needed for picking files? Johnny and Jarol to discuss
Add text input for single address or xpub
Drag and drop on mobile?
Is view-only an import function or a create wallet function?
Wallets that are not supported: What are the criteria of a wallet that won’t be able to be imported?
Wallet update: If a BDB state is imported then its state would need to be updated (Need to design Wallet update error screen)

View only and Multisig designs will be worked on later
Since we are focused on this user flow right now, we’ll try to cover future feature additions as well and not just the first implementation.

Wallet import flow update
(Figma)

Designs for view only, multikey, single key
What about fringe case if your node is not properly set up?
Ask dev input
Node only option, so also include an option to not import a wallet
Add in info about the type of wallet that was imported, for example this is a ⅔ wallet.
Add in the option to edit the wallet name (this would better be in settings, to keep this userflow as short as possible)

Node runner/Wallet user flows

In the future having 2 separate paths for the node runner and then for the person who would use it for wallet functionality

Research update
(ChatGPT summary, raw transcript, Figjam)

Research is still being worked on, it is being bucketed so that the main areas/insights are clear
Goal would be to move the insights into a place where people can just search and all tags around a particular work will be pulled up
To do: Present it in a report and present it in a searchable database

Top nav bar update
(Figma)

Added in a state but did not have time to work on the wallet selector
Will be merged into the main file

To open up milestone 4 wallet creation

Dev updates
Build Artifacts
There has been a re-introduction of the build artifacts. . Designers can now grab the binaries and build the wallet to test it. Basically download and install the application. It automatically builds based on the current master file. This will allow many people to test on android.
Proxy & Data entry picker
Data directory picker is finished.
Proxy, you can set the proxy on the proxy screen we might want to revisit that design. Currently in implementation Tor and regular proxy.
Design documentation

The design documentation website is being maintained and updated by Christoph at present and would welcome contributions. The repo for this is here.
Design documentation website
@rabbitholiness has also contributed to the design documentation with these PR's.

Research
The UX research that was done was a great collaborative effort supported by many people. The next phase of the process is now bucketing the insights and presenting it. Updates on the process can be found here.

Update on the research
Bitcoin Core App website
There is a write up being created about the past research efforts done on Bitcoin Core App. This will be added as an additional page to the website. It is currently a WIP but we can see that there's been some discovery research that has been done as well as qualitative and quantitative research done. This shows that there could be some more experimental research that could be done in terms of A/B testing current designs before they move to development.

Bitcoin research summary
Qualitative interviews were conducted with current and potential bitcoin core users. A report is now being created based on those interviews.
What's next?

Finish research summary
Decide on what research could be valuable to the project moving forward
Make all past research efforts public and accessible on Github.

UX research report
The following research report was created after doing a research sprint to try to understand the users of bitcoin core.

Link to affinity diagram where we sorted through the data and bucketed it.

User needs: Bitcoin Core Node Runners
The Jobs to be done framework from the UX Research toolkit to speak with a bitcoin miner to understand if it would be useful for the project to speak with more miners.
During the interview a few questions were asked to identify the "jobs" that bitcoin core app would need to do to meet with the needs of miners.
Questions asked and the replies

Q: When was the last time you opened bitcoin core with reference to mining?
A: Last week

Q: Why did you open it and what was the context?
A: Testing V2 so we needed a bitcoin core node and get it up and running. For me to to mine SV2 you need a bitcoin core node.

Q: When do you typically use bitcoin core?
A: Usually just for mining. That's it.

Q:  What do you generally love about bitcoin core?
A:  It's what we as a bitcoin community agree on it's the best bitcoin out there. its the best code out there so I'm happy to use it.

Q: What do you find frustrating?
A: Nothing

Q: What settings are the most relevant for you as miner?
A:

The bitcoin core has a template provider.
So Stratum version 2 pool you're gonna need Bitcoin Core running locally on your comp because you'll need block template creation.
Solo miners: So for a solo miner to build their own block template they will have to run their own node. Great for decentralization.
Bitcoin core has a rule as a recommend set up which is it adds the transactions which has the highest fees, that's an important setting for us as miners.

Open ended conversation:
Efficiency for pool mining: The miner creates a block not a pool for decentralization efforts. You'll need a node to do this. You don't want to lose efficiency with money.
When you are connected to a pool you send shares and if those shares are late or stale. Then you don't make any money. Bitcoin running on your system is a better way. Its much more efficient. There's miners in far away places. They are in the middle of the jungle. They really want to use the pool. But they will need to run their own node.
Solo mining vs pool mining;
Pool mining you have a payment system, they aggregate all the miners and shoot that at bitcoin which increases the chances of finding a block.
Solo miners are those trying to reach the block on their own, we provide the infrastructure for them. People would rather connect to a solo pool.
It's two different pools. The solo mining is more of a community thing. The pool mining that's where money is made. That's the main emphasis.
Does it require a graphical interface?
It will require a GUI, it will require a dashboard. Stratum V2 is already open source.
GUI connected to a pool. The software which is another service. Every miner has a different UI.
Summary User Needs: Bitcoin Core Node Runners (Preliminary)
Interview Findings:
Frequency of Usage:
Miners typically open Bitcoin Core for mining purposes, and the last usage was reported to be within the past week.
Use case:
The primary use of Bitcoin Core for miners is to support the mining process, solo and pool miners would need to run their own bitcoin core node.
Relevant Settings:
The most relevant settings for miners include

The ability to use Bitcoin Core as a template provider for mining pools
Recommended set up of adding transactions with the highest fees is of the most value

Efficiency Concerns:
Efficiency is essential for miners both with solo and pool mining to prevent losses in revenue.
Miners use a dashboard depending on which mining tool/pool they are connected to.
Conclusion:
Jobs to be done:
As a miner I want to use the block template creator so that I can provide the mining software I use with information. This info is used to construct a coinbase transaction.
As a miner I want to add transactions with the highest so that I can prevent loss in revenue.
getblocktemplate RPC
An improved method is the Bitcoin Core “getblocktemplate” RPC. This provides the mining software with much more information: The information necessary to construct a coinbase transaction paying the pool or the solo miner's bitcoind wallet.

More investigation into the use cases of miners would be interesting to hear from a larger group of people how they are using bitcoin core for mining. This initial investigation shows that this is an audience with a clear use case who are using bitcoin core on a weekly basis and might be in the more frequent group of users.
More investigation into node runners in general

Peer screens
Second PR for peers details - help test (one, two)
PR 388 is the most recent one and would be the best to test.

Miniscript explorations
Michael: Some explorations for Miniscript capabilities, based on the how it works page and the time-based recovery reference design.
Assume UTXOs prototype

Gee will start working on this again very soon.
Quick online test for different feature names via Discord poll
Currently there are 4 prototypes: Design assumeUTXO user flow · Issue #79 · BitcoinDesign/Bitcoin-Core-App (github.com)

Error messages

Make sure initial crashes communicate something useful so that users understand what happened as well as next steps they can take.
Jakub’s crash was related to different prune settings in existing core vs new onboarding settings
Do we need a migration document for people who have Bitcoin-QT installed?

I've started working on the case study of the project, and this is the draft so far. Cae study

During the last call we discussed the project roadmap. Points discussed:

MVP of the wallet features by Summer 2014 and a more solid version by Fall, and then potentially the application go live as part of Bitcoin Core (replacing the current GUI) by next April.

To dos:

User documentation for onboarding current plus new existing users
Create or expand on the FAQ's
Discuss PRs to test in weekly calls

Prototyping and quality testing prior to the release in a staggered format would ensure that when it's released to the wider public the user exp is as smooth as possible.

Design Specs
A developer has requested that some guidance be created around the different interactive states.
Specifically the wallet selector was requested.
Ideally then the interactive states in the various forms would also reflect in the prototype.
Prototype: Bitcoin Core App Prototype (lively-kashata-cfde7e.netlify.app)
Planning

Continue with designs for Activity as well as send flows and prepare prototypes for testing

User testing and UX Research roadmap

A roadmap has been created to break the MVP into chunks to allow for user testing of the prototypes before they go into development.
The user testing is being documented here

Milestones progress as well as what's being worked on atm
First use and create wallet: 1.4

Prototypes created and tested on new and existing users

Using the wallet: 1.5: Activity

Designs being finalized

Using the wallet: 1.6: Receive

Designs being worked on

The send flow and receive flow are being worked on now in sync. The activity flow is mostly wrapped up however there are still some states that are being designed as we speak.
Send flow
The MVP scope for the send flow is being designed

Receive


remove jest import from every.ts file

oh wow thank you @KABBOUCHI !

:tada: This PR is included in version 1.3.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Improve All The Docs!

This issue combines all existing and stale documentation-related issues:

[ ] Transparent Mode on Windows

#323, #336
https://discourse.mitmproxy.org/t/intercept-roku-traffic-on-windows/406

[ ] Setting up local transparent proxy

#630

[ ] Improve Server Replay Docs

#635

[ ] HTTP body streaming and Content-Length header

#856

[ ] Link to the right branch in the option documentation

#2243

[ ] Inline certificate installation docs

#2089

[ ] Using external libraries with mitmdump

#2238

Do we want to collect infrastructural doc-related issues here? We really need to move away from Sphinx/ReadTheDocs to a simple static generator. The current system is enormously cumbersome to work with, and we can do much better on the layout/design/presentation side if we had full control.

I think we need an FAQ. There's a ton of common questions that could be presented pretty well in this format.

I agree. Let's collect questions and answers at mitmproxy/mitmproxy.org#21. :)

Hi, What are our plans with this?

@armudgal I can help with this. How do you want to go about this?

Hi @MrTsRex, I couldn't take a look on this. I would wait for the reply from the maintainers cause a lot has been done in the past year.

@MrTsRex just pick a topic and start contributing by sending a PR 😄 👍
If you are a mitmproxy-beginner, I would recommend looking at for easy-to-fix things first to get to know our codebase.

@armudgal @Kriechi Thanks for the prompt replies guys. 👍

All issues you referenced in the OP are closed now? (Fixed?)

Indeed they are!


fix: TRACEFOSS-1285 [FE][BE] Eclipse dash job is not working correctly + adjustments to QG4 and QG5 preparations

Last run when I tested Eclipse Dash job (because normally it's triggered only when we change sth in deps).
https://github.com/catenax-ng/tx-traceability-foss/actions/runs/4554682347/jobs/8032873625


If there is a single copy of a DLL in memory, how can it be loaded into an application's memory space?

The second paragraph on this page says the following:

A DLL isn't a stand-alone executable. DLLs run in the context of the applications that call them. The operating system loads the DLL into an application's memory space. It's done either when the application is loaded (implicit linking), or on demand at runtime (explicit linking). DLLs also make it easy to share functions and resources across executables. Multiple applications can access the contents of a single copy of a DLL in memory at the same time.

I believe the highlighted sentence above is incorrect. How does one reconcile this statement with the first bullet in Advantages of Dynamic Linking which I reproduce below:

Multiple processes that load the same DLL at the same base address share a single copy of the DLL in physical memory. Doing this saves system memory and reduces swapping.

In summary, if there is a single copy of a DLL in memory, how can it be loaded into an application's memory space?

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

ID: dfc6a520-6880-1dee-6c80-30a54fd90169
Version Independent ID: bb521f2c-9784-9432-f098-8e488cea7b2d
Content: Create C/C++ DLLs in Visual Studio
Content Source: docs/build/dlls-in-visual-cpp.md
Product: visual-cpp
Technology: cpp-tools
GitHub Login: @corob-msft
Microsoft Alias: corob

@AlexanderMace
"Load" as used in both documents means "what the OS loader does." It may mean copying from storage, if it's the first time some image is loaded into memory. And, it may mean virtual memory mapping, if the image is already in memory somewhere. After copying or mapping, as required, the loader then fixes up the relative virtual addresses for symbols to match the virtual pages loaded for all the various images in the process. The bit about matching base addresses is no longer true. Addresses get translated from the virtual addresses used by a process to physical memory addresses by way of some processor-based look-up table managed by the OS. That's how different apps can make use of the same DLL image, at a virtual base address that may be different for every app, while there's only one copy of the DLL image itself at some particular physical location in memory. Basically, you get a form of ASLR whether you ask for it or not. And all that old Windows documentation about carefully setting the base addresses of your images to speed loading and avoid collisions is long obsolete. Unless you're writing real mode code, image addresses don't matter at all.
I'm closing this because I don't see an issue with the doc as written. If you think that's wrong, feel free to argue your case. I've been known to come around.


[iOS] Crashes if UserDialog.AlertAsync is called before LoadAplication is called

First of all, thanks for such a great work and quick reply for all my queries, I really appreciate it.
Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[] iOS 11.0.1

Version of ACR UserDialogs Library
6.5.1
Expected Behaviour
When I call AlertAsync before LoadApplication is called it crashes on iOS. I don't call UserDialogs.Init on iOS anywhere.
However on Android, there is no crash, I call AlertAsync before LoadApplication is called, but after UserDialogs.Init(this) is called,
i.e on Android
UserDialogs.Init(this)
UserDialogs.Instance.AlertAsync("message", "title", "OK");
LoadAplication(app);
Should I call Init or do something on iOS to make it work? Does LoadApplication needs be called before UserDialogs can be used on iOS?
Actual Behavior
If applicable, please include entire exception - type, message, stacktrace
System.AggregateException: One or more errors occurred. ---> System.NullReferenceException: Object reference not set to an instance of an object
at Acr.Support.iOS.Extensions.GetTopViewController (UIKit.UIApplication app) [0x00006] in <1ab414c5209048af944db003df36143d>:0
at Acr.UserDialogs.UserDialogsImpl+<>c.<.ctor>b__1_0 () [0x00005] in :0
at Acr.UserDialogs.UserDialogsImpl+<>c__DisplayClass19_0.b__0 () [0x00011] in :0
at Foundation.NSActionDispatcher.Apply () [0x00000] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/src/Foundation/NSAction.cs:57
at (wrapper managed-to-native) ObjCRuntime.Messaging:void_objc_msgSend_IntPtr_IntPtr_bool (intptr,intptr,intptr,intptr,bool)
at Foundation.NSObject.InvokeOnMainThread (System.Action action) [0x00007] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/src/Foundation/NSObject2.cs:560
at Acr.UserDialogs.UserDialogsImpl.Present (System.Func1[TResult] alertFunc) [0x00026] in <e327c6f339624db09cd6e3a2fe28de55>:0    at Acr.UserDialogs.UserDialogsImpl.Alert (Acr.UserDialogs.AlertConfig config) [0x0000d] in <e327c6f339624db09cd6e3a2fe28de55>:0    at Acr.UserDialogs.AbstractUserDialogs+<AlertAsync>d__21.MoveNext () [0x00054] in C:\dev\acr\userdialogs\src\Acr.UserDialogs.Interface\AbstractUserDialogs.cs:130     --- End of inner exception stack trace --- ---> (Inner Exception #0) System.NullReferenceException: Object reference not set to an instance of an object   at Acr.Support.iOS.Extensions.GetTopViewController (UIKit.UIApplication app) [0x00006] in <1ab414c5209048af944db003df36143d>:0    at Acr.UserDialogs.UserDialogsImpl+<>c.<.ctor>b__1_0 () [0x00005] in <e327c6f339624db09cd6e3a2fe28de55>:0    at Acr.UserDialogs.UserDialogsImpl+<>c__DisplayClass19_0.<Present>b__0 () [0x00011] in <e327c6f339624db09cd6e3a2fe28de55>:0    at Foundation.NSActionDispatcher.Apply () [0x00000] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/src/Foundation/NSAction.cs:57    at (wrapper managed-to-native) ObjCRuntime.Messaging:void_objc_msgSend_IntPtr_IntPtr_bool (intptr,intptr,intptr,intptr,bool)   at Foundation.NSObject.InvokeOnMainThread (System.Action action) [0x00007] in /Users/builder/data/lanes/5481/2f8bbec0/source/xamarin-macios/src/Foundation/NSObject2.cs:560    at Acr.UserDialogs.UserDialogsImpl.Present (System.Func1[TResult] alertFunc) [0x00026] in :0
at Acr.UserDialogs.UserDialogsImpl.Alert (Acr.UserDialogs.AlertConfig config) [0x0000d] in :0
at Acr.UserDialogs.AbstractUserDialogs+d__21.MoveNext () [0x00054] in C:\dev\acr\userdialogs\src\Acr.UserDialogs.Interface\AbstractUserDialogs.cs:130 <---
}

https://github.com/aritchie/userdialogs/blob/master/docs/faq.md  (point 1)


New HTML (Go) grammar for Go HTML templates

Includes support for indention and folding. More information about Go HTML
templates can be found at:
https://golang.org/pkg/html/template/

Cool. GoSublime and Atom are both setup to syntax highlight HTML inside raw strings in Go source as well. I'm not sure if that's a great idea, because raw strings could be a number of things. Any thoughts?


Unable to find Artemis while I did install it.

I did install Artemis, when I open the creator,  it cannot find the Artemis Roleplaying Kit config.


Fix navigation and account selection on the accounting company card export page

Details

This PR:

ensures that the user is navigated to the correct screen depending on the entity type selected
If the entity type is either Credit card or debit card, the user is navigated to the Account Selection page. If the entity type is Vendor, the user is navigated to the Default Vendor Select page.
ensures that, on the Company Card Expense Account Page, the correct value is displayed (either account selected or default vendor selected) depending on the entity type selected.

Fixed Issues

$ https://github.com/Expensify/App/issues/41046
PROPOSAL: N/A
Tests / QA Steps

Create a workspace
Go to workspace editor page -> Enable tags and account on the More Features page
On the accounting page, connect to QBO
After the connection is established, click Export
Click export company card expenses as
Check that the Credit card is selected by default for Export company cards as
Check that one of the QBO credit card accounts is displayed for Account
Click Account and ensure that you're taken to the page where you can change the account
Go back and change the entity type to Vendor for Export company cards as
Ensure that the Account menu disappears and there is a Vendor menu
Check that you're taken to the page where you can change the default vendor if you click the Vendor menu

Offline tests

N/A
PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Bug (unrelated to the PR): After changing the export destination, the account value is uncleared / outdated
https://github.com/Expensify/App/assets/16493223/725e20e2-d414-4bc5-939c-8eb2ca2b6ed0

@hayata-suenaga We have conflicts

There is one failing test though. I gonna rerun the test to see if this is a flakey one.

@hayata-suenaga We have conflicts

Resolved it 😄

Reviewer Checklist

[X] I have verified the author checklist is complete (all boxes are checked off).
[X] I verified the correct issue is linked in the ### Fixed Issues section above
[X] I verified testing steps are clear and they cover the changes made in this PR

[X] I verified the steps for local testing are in the Tests section
[X] I verified the steps for Staging and/or Production testing are in the QA steps section
[X] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[X] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[X] I checked that screenshots or videos are included for tests on all platforms
[X] I included screenshots or videos for tests on all platforms
[X] I verified tests pass on all platforms & I tested again on:

[X] Android: Native
[X] Android: mWeb Chrome
[X] iOS: Native
[X] iOS: mWeb Safari
[X] MacOS: Chrome / Safari
[X] MacOS: Desktop

[X] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[X] I verified proper code patterns were followed (see Reviewing the code)

[X] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[X] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[X] I verified that comments were added to code that is not self explanatory
[X] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[X] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[X] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[X] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
[X] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[X] I verified the JSDocs style guidelines (in STYLE.md) were followed

[X] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[X] I verified that this PR follows the guidelines as stated in the Review Guidelines
[X] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[X] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[X] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[X] If a new component is created I verified that:

[X] A similar component doesn't exist in the codebase
[X] All props are defined accurately and each prop has a /** comment above it */
[X] The file is named correctly
[X] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[X] The only data being stored in the state is data necessary for rendering and nothing else
[X] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[X] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[X] All JSX used for rendering exists in the render method
[X] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[X] If any new file was added I verified that:

[X] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[X] If a new CSS style is added I verified that:

[X] A similar style doesn't already exist
[X] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)

[X] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[X] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[X] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[X] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[X] If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:

[X] I verified that all the inputs inside a form are aligned with each other.
[X] I added Design label and/or tagged @Expensify/design so the design team can review the changes.

[X] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[X] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[X] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

https://github.com/Expensify/App/assets/16493223/a3e4045e-164c-4aa7-8dc4-50805ee6afaa

Android: mWeb Chrome

Networking issue

iOS: Native

https://github.com/Expensify/App/assets/16493223/39c61abc-7a93-448b-bcdc-25511a8334c7

iOS: mWeb Safari

https://github.com/Expensify/App/assets/16493223/7cffe5df-9259-45c1-aeba-e27f1f1401df

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/16493223/663b7310-7161-44d7-a882-406fc9f205b0

MacOS: Desktop

https://github.com/Expensify/App/assets/16493223/b932e78b-2c05-4191-8f5d-d10ed5494d35

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/AndrewGable in version: 1.4.75-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/puneetlath in version: 1.4.75-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Release v2<IP_ADDRESS> [skip pd_pr]

What did:

Hide "diagnose" app
Add metrics relationship graph feature back (added in PR #760 and removed in PR #1113 uncarefully)
Disable control form if conprof is diabled

Screeshots:

@breeswish @lilyjazz PTAL, thanks!

Will cherry-pick back to master after the PR is merged.

Codecov Report

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

@@            Coverage Diff             @@
##             release    #1137   +/-   ##
==========================================
  Coverage           ?   28.09%
==========================================
  Files              ?      227
  Lines              ?    12908
  Branches           ?      647
==========================================
  Hits               ?     3626
  Misses             ?     9132
  Partials           ?      150

Flag
Coverage Δ

be_integration_test_latest
6.88% <0.00%> (?)

be_integration_test_v4.0.1
6.88% <0.00%> (?)

be_unit_test
23.83% <0.00%> (?)

e2e_test
46.85% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 367ff3b...d1368a7. Read the comment docs.


Pulling singularity image isnt working for me

Hej. I'm trying to pull the singularity image for offline use but I am getting an error message that I am unauthorized. I get a similar error when trying to pull the image with docker directly. In docker I could fix it by using docker login first. But yet I have not managed to convert the local docker image to a singularity image either...
Commands and results I used:
pascalp@kingfisher ~/Documents/Code/Autolymphom $ singularity pull --name nf-core-rnaseq-1.3.img docker://nf-core/rnaseq:1.3
WARNING: pull for Docker Hub is not guaranteed to produce the
WARNING: same image on repeated pull. Use Singularity Registry
WARNING: (shub://) to pull exactly equivalent images.
Docker image path: index.docker.io/nf-core/rnaseq:1.3
ERROR UNAUTHORIZED: authentication required
ERROR Check existence, naming, and permissions
Cleaning up...
ERROR: pulling container failed!

pascalp@kingfisher ~/Documents/Code/Autolymphom $ singularity pull --name nf-core-rnaseq-1.3.img docker://nf-core/rnaseq:latest
WARNING: pull for Docker Hub is not guaranteed to produce the
WARNING: same image on repeated pull. Use Singularity Registry
WARNING: (shub://) to pull exactly equivalent images.
Docker image path: index.docker.io/nf-core/rnaseq:latest
ERROR UNAUTHORIZED: authentication required
ERROR Check existence, naming, and permissions
Cleaning up...
ERROR: pulling container failed!

pascalp@kingfisher ~/Documents/Code/Autolymphom $ docker pull nfcore/rnaseq:1.3
Error response from daemon: Get https://registry-1.docker.io/v2/nfcore/rnaseq/manifests/1.3: unauthorized: incorrect username or password

After login with
pascalp@kingfisher ~/Documents/Code/Autolymphom $ docker login
Authenticating with existing credentials...
Stored credentials invalid or expired
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username (NNNNN): NNNNN
Password:
WARNING! Your password will be stored unencrypted in /home/pascalp/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

docker pull nfcore/rnaseq was sucessfull.
Not sure where the problem lies exactly, but documentation and how docker hub and singularity play together seems not to match

The original command was from https://github.com/nf-core/rnaseq/blob/master/docs/installation.md and removing the hyphen as suggested in https://github.com/nf-core/chipseq/issues/8 worked also here (after suggestion from @drpatelh on slack).
Leaving the issue open since the documentation could be updated.

@pascal-git This will be fixed in the new release because this documentation is now all on the website. However, as you rightly observed we will need to fix the command on this webpage:
https://nf-co.re/usage/installation
Once you have created an issue on the website repo we can close this 👍

Thanks @pascal-git !


filters -- remove open cv import

This is no longer needed since we entirely use skimage. Opencv should also be removed from setup.py and requirements.txt.

Could this be reconsidered? If OpenCV is supported both R and golang versions of this package can be made without having to reinvent the wheel for all the heavy lifting.

Could that functionality be provided by language bridges (FFI) rather than to maintain a separate identical package?

Yes C/C++ as the common language for all the heavy lifting with image processing.
FFI calls to C/C++ from both python, R and golang would be easier to maintain. In addition performance with opencv is better than scikit-image. No? Or are you suggetsing R and golang would make FFI to python?

Essentially doing similar what mc-stan did for hamilton monte carlo:
https://github.com/stan-dev
http://mc-stan.org/
But here instead of Bayesian modeling with MCMC/HMC the analogy here being a common interface for basic image processing.
mcstan's approach has been extremely successful with interfaces actually used and maintained to all the most popular data analysis languages:
R, Python, shell, MATLAB, Julia, Stata
And works great across platforms:
Linux, Mac, Windows

I would prefer postponing optimizing for performance until we have a robust pipeline and infrastructure.  Fast iteration to get us there is key, and python is good for that.  We also don't want to tie ourselves down to a particular image processing backend (opencv or scikit-image).  The idea is that the interfaces are well-defined, but if people want to build an alternative backend (perhaps opencl for GPU acceleration), there is nothing preventing them for doing so.
It depends on what you need starfish to do.  Do you just want to process images?  Or do you want to develop algorithms?  If you're just processing images, R/golang can just shell out to starfish to do the work.  If you're developing algorithms, that is trickier and I'll have to give it some thought.

Do you just want to process images? Or do you want to develop algorithms?
Both preferably, no?
More specifically I have a dataset with 204 FOV, 30 z-stacks per FOV and about 2000-4000 amplicons per cell.
See:
http://www.histo.io/?v=cycle001
This sequencing run is for 30 cycles.
If I'm developing routines for handling these kinds of data I might as well develop in the starfish framework no?
To get really high reads it is not enough to do registration and segmentation on maximum intensity projection but it has to be done on the stack. Nor is it enough to do registration on single FOV.

If you develop an algorithm that requires opencv, we'd definitely be happy to add it back as a requirement.  I don't think that @dganguli removing it as a requirement now should be read as a sign that opencv cannot be a requirement or cannot be used. :)

@ttung cool. I'll make a fork and have a stab at it during the weekend.
I'll also add the first round of the cycle of this dataset to cloud if anyone wants to use it for starfish since it is kind of an extreme dataset (16-bit depth, many FOV, several z-stacks, thousands of amplicons per cell).

Hi Daniel! Sorry to be late to this! Yeah we're totally open to opencv (pun intended) being in the project. However, as Tony said, for now we're in rapid iteration mode and not yet considering performance and/or interlanguage operability. As such, we've landed on skimage for now to simplify things.
Would love the first round of the cycle of this dataset as another dataset to develop against.

opencv is gone.


BoringSSL implementation

How likely is it to see a BoringSSL (https://boringssl.googlesource.com/boringssl/) implementation be accepted? OpenSSL is supported on the same platforms, but we end up with an additional native dependency which is not idea on some resource limited embedded devices.

Someone would need to make sufficiently fully featured bindings to BoringSSL first.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Does that mean that you would not take BoringSSL support in this crate?

I'd probably want a Google person maintaining the support since they're the only people that are actually intended to be consuming BoringSSL AFAIKT.

https://github.com/google/mundane


creating an onGet in a layout and an index file collide with each other.

Qwik Version
0.9.0
Operating System (or Browser)
Chrome / MacOS
Node Version (if applicable)
16.13.2
Which component is affected?
Qwik City
Expected Behaviour
when specifying multiple nested onGet calls between layout.tsx and index.tsx files I'd expect them all to resolve with their specified resource data.
Actual Behaviour
when specifying multiple nested onGet calls between layout.tsx and index.tsx files they seem to all resolve to the leaf layout/index that had an onGet defined.
Additional Information
if this is as designed, that's fine, but I'm not sure where in the qwik city docs it define this behavior.

Also, if it's helpful, this app isn't finished by any means, but this is the starting point of how I ran into this issue, any feedback on how you would do things differently would be greatly appreciated, happy to also add this as a Qwik example on the site! https://github.com/lifeiscontent/qwik-realworld

It would be a nice mental model if each onGet() in the chain of nested layouts would be called. Although I think that might require a change to the useEndpoint() API so that you could specify which onGet()'s data you want to access. Perhaps this could be modelled as a kind of context? Or perhaps onGet() could call useContextProvider() to attach data to a well known context object? And then rather than useEndpoint() one could just useContext()?

@petebacondarwin what is the current recommendation for fetching data in a larger application built on qwik / qwik city?

If you are using QwikCity to create an MPA (i.e. no client-side navigation) then I think simply putting an onGet() handler in each page is a reasonable approach. That way you can control closely what data is retrieved for the specific page being displayed.
It gets more complicated if you start using client-side navigation since the old page template can currently be executed again with the new page data.
You might have more power if you make use useResource() hooks rather than relying upon onGet() handlers.
I don't yet think we have nailed down what the best architectural pattern is for larger applications.

not sure if it's helpful, but imo https://remix.run/ has one of the best experiences for dealing with data fetching/mutation. might be worth copying/taking inspiration from.

Im also running into this issue. I have a main layout.jsx that fetches user posts to display in a sidebar using onGet, and then a pages/[slug] route that fetches individual page data using onGet. When I'm at the page/[slug] route, the main layout route returns data from the lowest onGet. I tried using useResource without any luck, but perhaps I was implementing it wrong.

Hi,
i'm playing with qwik/qwik-city, it seems i'm trying to use onGet with the same structure as you @ramsaylanier
On local it seems to work, but once deployed it does not : see this PR and the last deploy on netlify

thanks for the report @lifeiscontent
is this still the case with the latest version?

@shairez not sure, I haven't played with Qwik again since I opened the issue.

thanks @lifeiscontent !
Looks like the new server actions should solve this issue
will wait for Manu to closed this one after he's done


[Feature]: MetaNode support rocksdb store mode

Contact Details
<EMAIL_ADDRESS>Is there an existing issue for this?

[X] I have searched all the existing issues

Is your feature request related to a problem? Please describe.
Rocksdb is a popular key-value database, and has been widely used in many fields.
Supports rocksdb storage mode, so we can place metadata on disk and reduce the cost of the metadata subsystem.
Describe the solution you'd like.

Each disk own a rocksdb instance, so we can share block cahce and write buffer. Using prefix key to isolate different meta partitions.
Support migrate a memory meta partition(replica) to rocksdb meta partition.
Refactor behavior of extent deletion, use a new kind of tree to store deleted extent data.
Monitor available space of each disk and report it to master, adjust our node and nodeset selector to support disk space based meta partition placement.
Support configurate default meta partition store mode of volume.

Describe an alternate solution.
No response
Anything else? (Additional Context)
No response

be include in 2024 roadmap


Add OZ ERC2771Forwarder example

We observe some very strange behaviour of this setup.
It can be summarized from the ticket I posted in the Open Zeppelin forum:
https://forum.openzeppelin.com/t/erc-2771-forwarder-verify-returns-the-wrong-address/38503


multimc: create compatibility symlink to fix desktop icon (18.03)

Motivation for this change
close #42784 for 18.03
This also includes an update -> 0.6.2 which I thought would be safe to do here also.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build multimc

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: multimc
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnfree = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnfree = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: multimc
Partial log (click to expand)
shrinking /nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2/bin/libMultiMC_logic.so
shrinking /nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2/bin/libMultiMC_gui.so
shrinking /nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2/bin/.MultiMC-wrapped
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2/bin
patching script interpreter paths in /nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2
/nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2/MultiMC: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
checking for references to /build in /nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2...
postPatchMkspecs
/nix/store/rrcac7d2nhin7ich1iq8sfim3z7p2n2f-multimc-0.6.2

This is weird.. Why did it succeed on x86, but fail with the unfree message on aarch..

Package ‘oraclejdk-8u171’ in /var/lib/gc-of-borg/nix-test-rs-26/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-26/pkgs/development/compilers/oraclejdk/jdk-linux-base.nix:71 has an unfree license (‘unfree’), refusing to evaluate.

The JDK used @Infinisil

Ah right, will check the logs next time. Didn't realize that it's possible to have different derivations depending on the arch.


Errors when compiling

It gives me a lot of errors after I setup every thing it gives me about 200 errors please help

Use Visual Studio 2015

1.Change all "char *abc" to "const char *abc" (file UDP.cpp)
2.Add all the files to your IDE (if it's VS - rclick on project->add->existingitem)
3. Fix errors with stdafx.h (put 1 stdafx.h in each folder and require stdafx in each file)


Deep Research Tool

The Deep Research Tool is basically a way to help guide the AI with their research process. We can programmatically keep track of topics researched, data, facts, sources, etc and also keep track of things we should research but haven't done yet. The Deep Research Tool is also intended to act like a mentor to the AI and provide guidance on how to do things.

There's an unanswered question of how we go from Deep Research Tool -> evaluate user prompt -> topics to research -> google search -> scrape -> digest and get more topics, etc.  It may require more tools or maybe it can all be in this one


Broadlink RM pro and rm mini not discovered, worked until 2 days ago.

[Important!] We've discovered an unknown Broadlink device.
Please raise an issue in the GitHub repository (https://github.com/lprhodes/homebridge-broadlink-rm/issues) with details of the type of device and its device type code: "2722" so that we can handle it correctly and prevent this message from appearing.

This is all the log after loading homebridge:
*** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=node
*** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!

Setup Payload:
X-HM://0024X4ALT6PJL
Scan this code with your HomeKit app on your iOS device to pair with Homebridge:
Or enter this code with your HomeKit app on your iOS device to pair with Homebridge:
┌────────────┐
│ 876-54-321 │
└────────────┘

[2018-2-25 18:13:07] Homebridge is running on port 37657.
[Important!] We've discovered an unknown Broadlink device.
Please raise an issue in the GitHub repository (https://github.com/lprhodes/homebridge-broadlink-rm/issues) with details of the type of device and its device type code: "2722" so that we can handle it correctly and prevent this message from appearing.
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5b)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:ca:be:24)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:8b:a8)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5f)
[2018-2-25 18:13:09] [Broadlink] Kids Aircon setCurrentHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Kids Aircon setCurrentHeatingCoolingState: already 0 (no data sent - A)
[2018-2-25 18:13:09] [Broadlink] Kids Aircon setTargetHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Kids Aircon setTargetHeatingCoolingState: already 0 (no data sent - A)
[2018-2-25 18:13:09] [Broadlink] Parents Aircon setCurrentHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Parents Aircon setCurrentHeatingCoolingState: already 0 (no data sent - A)
[2018-2-25 18:13:09] [Broadlink] Parents Aircon setTargetHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Parents Aircon setTargetHeatingCoolingState: already 0 (no data sent - A)
[2018-2-25 18:13:09] [Broadlink] Oriels Aircon setCurrentHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Oriels Aircon setCurrentHeatingCoolingState: already 0 (no data sent - A)
[2018-2-25 18:13:09] [Broadlink] Oriels Aircon setTargetHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Oriels Aircon setTargetHeatingCoolingState: already 0 (no data sent - A)
[2018-2-25 18:13:09] [Broadlink] Main Aircon setCurrentHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Main Aircon setCurrentHeatingCoolingState: already 0 (no data sent - A)
[2018-2-25 18:13:09] [Broadlink] Main Aircon setTargetHeatingCoolingState: 0
[2018-2-25 18:13:09] [Broadlink] Main Aircon setTargetHeatingCoolingState: already 0 (no data sent - A)
[Important!] We've discovered an unknown Broadlink device.
Please raise an issue in the GitHub repository (https://github.com/lprhodes/homebridge-broadlink-rm/issues) with details of the type of device and its device type code: "2722" so that we can handle it correctly and prevent this message from appearing.
[Important!] We've discovered an unknown Broadlink device.
Please raise an issue in the GitHub repository (https://github.com/lprhodes/homebridge-broadlink-rm/issues) with details of the type of device and its device type code: "2722" so that we can handle it correctly and prevent this message from appearing.
[Important!] We've discovered an unknown Broadlink device.
Please raise an issue in the GitHub repository (https://github.com/lprhodes/homebridge-broadlink-rm/issues) with details of the type of device and its device type code: "2722" so that we can handle it correctly and prevent this message from appearing.
[Important!] We've discovered an unknown Broadlink device.
Please raise an issue in the GitHub repository (https://github.com/lprhodes/homebridge-broadlink-rm/issues) with details of the type of device and its device type code: "2722" so that we can handle it correctly and prevent this message from appearing.

Hi,
The error isn't that it's not been discovered it's that we don't know exactly how to treat the device.
Is it the RM mini that's causing the error or the Pro?
Can you please provide details about which version of the device it is and whether it's meant to support RF.

I have also 3 RM mini and also an RM Pro and all worked well for a few
months!
I just had today a problem that the home bridge did not load and I deleted
the persist and accessories folders in .homebridge folder and left only the
config file in that folder.
Then started this error.
Can you please give me instructions how to uninstall completely all
homebridge and re install again?
I tried my self to uninstall and re install but it did not help. I think I
am missing something.
I think that homebridge is expecting some cache files that are missing.
My RM Pro is on version v20028
And my rm minis are on v20029
But again I am saying that it worked for a long time with this setup so it
is not a version issue I think.
Thanks for the help!!!
Refael.S
On Sun, 25 Feb 2018 at 23:27 Luke Rhodes<EMAIL_ADDRESS>wrote:

Hi,
The error isn't that it's not been discovered it's that we don't know
exactly how to treat the device.
Is it the RM mini that's causing the error or the Pro?
Can you please provide details about which version of the device it is and
whether it's meant to support RF.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lprhodes/homebridge-broadlink-rm/issues/270#issuecomment-368346218,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABgGRXSGVK9KpSCsJ3jZ8Z8zqgqbL0pqks5tYdAlgaJpZM4SSV_Z
.

--
בברכה,
רפאל זומר
0526222068

The error is simply a way of reporting devices to us that we don't yet know how to handle.
I need to know which of your devices is the one causing the error to show

I have disconnected all devices from their power and left only my RM Pro
connected and I get the same error.
Looks like all devices are getting this error.
My Rm Pro sn is RM0300039198
On Sun, 25 Feb 2018 at 23:41 Luke Rhodes<EMAIL_ADDRESS>wrote:

The error is simply a way of reporting devices to us that we don't yet
know how to handle.
I need to know which of your devices is the one causing the error to show
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lprhodes/homebridge-broadlink-rm/issues/270#issuecomment-368347445,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABgGRT_4PIYDpgMemIgfNbJXaraQdmBsks5tYdOTgaJpZM4SSV_Z
.

--
בברכה,
רפאל זומר
0526222068

But also tried now without the RM pro connected to the power and only the 3 RM minis connected and still get the error, there is nothing changed in the setup of my house, I want to have a fresh re install of home bridge so I can try and fix the problem, can you please instruct me what commands should I type in my Raspberry PI to re install? I will then put my config file and try again.

I also downgraded home bridge and didn't help, still same error.
Very weird since nothing changed in the setup of my Broadlink devices.

Yes, it's because of the latest versions of this plugin which I added the error for.
It looks like device 2772 is for a Broadlink S1 (SmartOne Alarm Kit). Do you have one of these?

Yes I do, if I will disconnect it all will work?
I will disconnect now and update you.
On Mon, 26 Feb 2018 at 2:14 Luke Rhodes<EMAIL_ADDRESS>wrote:

Yes, it's because of the latest versions of this plugin which I added the
error for.
It looks like device 2772 is for a Broadlink S1 (SmartOne Alarm Kit). Do
you have one of these?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lprhodes/homebridge-broadlink-rm/issues/270#issuecomment-368358829,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABgGRZQQuwhBdVLLDHwuPSQZBfzGvCePks5tYfdbgaJpZM4SSV_Z
.

--
בברכה,
רפאל זומר
0526222068

It will simply stop the error from appearing. As for making the other devices work...your logs show that they are being discovered:
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5b)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:ca:be:24)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:8b:a8)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5f)

Yes, disconnecting the sc1 works and no errors.
Can you please add a fix so I can use homebridge without disconnecting the
sc1?
I looked at your profile and I see you developed the GMGridView (:
I am an iOS developer and I use the GMGridView a lot in my apps!
Great code! Greate 3rd party.
Thanks!
Refael.S
On Mon, 26 Feb 2018 at 2:20 Luke Rhodes<EMAIL_ADDRESS>wrote:

It will simply stop the error from appearing. As for making the other
devices work...your logs show that they are being discovered:
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5b)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:ca:be:24)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:8b:a8)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5f)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lprhodes/homebridge-broadlink-rm/issues/270#issuecomment-368359229,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABgGRRkpKmSAFqRGIJFPh-LvYySWL_bHks5tYfi0gaJpZM4SSV_Z
.

--
בברכה,
רפאל זומר
0526222068

But the HomeKit app shows all devices with no response.
Something is still not right
On Mon, 26 Feb 2018 at 2:22 רפאל זומר<EMAIL_ADDRESS>wrote:

Yes, disconnecting the sc1 works and no errors.
Can you please add a fix so I can use homebridge without disconnecting the
sc1?
I looked at your profile and I see you developed the GMGridView (:
I am an iOS developer and I use the GMGridView a lot in my apps!
Great code! Greate 3rd party.
Thanks!
Refael.S
On Mon, 26 Feb 2018 at 2:20 Luke Rhodes<EMAIL_ADDRESS>wrote:

It will simply stop the error from appearing. As for making the other
devices work...your logs show that they are being discovered:
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5b)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:ca:be:24)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:8b:a8)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5f)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lprhodes/homebridge-broadlink-rm/issues/270#issuecomment-368359229,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABgGRRkpKmSAFqRGIJFPh-LvYySWL_bHks5tYfi0gaJpZM4SSV_Z
.

--
בברכה,
רפאל זומר
0526222068
--
בברכה,
רפאל זומר
0526222068

I managed to fix my problem by removing the homebridge accessory from
HomeKit and re adding it again.
Thanks a lot
On Mon, 26 Feb 2018 at 2:25 רפאל זומר<EMAIL_ADDRESS>wrote:

But the HomeKit app shows all devices with no response.
Something is still not right
On Mon, 26 Feb 2018 at 2:22 רפאל זומר<EMAIL_ADDRESS>wrote:

Yes, disconnecting the sc1 works and no errors.
Can you please add a fix so I can use homebridge without disconnecting
the sc1?
I looked at your profile and I see you developed the GMGridView (:
I am an iOS developer and I use the GMGridView a lot in my apps!
Great code! Greate 3rd party.
Thanks!
Refael.S
On Mon, 26 Feb 2018 at 2:20 Luke Rhodes<EMAIL_ADDRESS>wrote:

It will simply stop the error from appearing. As for making the other
devices work...your logs show that they are being discovered:
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5b)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:ca:be:24)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:8b:a8)
Discovered Broadlink RM device at <IP_ADDRESS> (0d:43:b4:dc:90:5f)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/lprhodes/homebridge-broadlink-rm/issues/270#issuecomment-368359229,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABgGRRkpKmSAFqRGIJFPh-LvYySWL_bHks5tYfi0gaJpZM4SSV_Z
.

--
בברכה,
רפאל זומר
0526222068
--
בברכה,
רפאל זומר
0526222068

--
בברכה,
רפאל זומר
0526222068


[Suggestion] Use "Caret requirements" instead of "Tilda requirements"

Because ~ is too strict and we always hit unnecessary dependency confliction like

I know that you prefer ~ (https://github.com/LinkTed/async-http-proxy/pull/3#issuecomment-884125155) but if we use "Caret requirements", we don't need PRs like #4 unless there are real break changes.

What is the difference?

I am fine with that. Can you change the commit message to:
Use "Caret" instead of "Tilda"

Because `~` is too strict and we always hit unnecessary dependency
conflictions.

Any new commit, should use the convention that the title of a commit message is max 50 char and the description 72 per line.

Thanks for the quick response 👍  I did and force pushed 😄

Could you please release 1.2.5? @LinkTed

Could you please release 1.2.5? @LinkTed

Done


no results using custom widget & bindkey to run fzf command

[x] I have read through the manual page (man fzf)
[x] I have the latest version of fzf
[x] I have searched through the existing issues

Info

OS

[ ] Linux
[x] Mac OS X
[ ] Windows
[ ] Etc.

Shell

[ ] bash
[x] zsh
[ ] fish

Problem / Steps to reproduce
I'm trying to set a bindkey to launch an fzf command (with more options than the following example) but I'm getting stumped at the first hurdle. I can't get any results to show up when the function is triggered from a bindkey.
# declare function
fzf-custom-widget(){
  fzf
}

# create widget
zle -N fzf-custom-widget

# bind the key (alt-z)
bindkey "^[z" fzf-custom-widget

If I type fzf or fzf-custom-widget in the command line, I get the expected result. i.e.

however if I press alt-z, I get the following:

FZF therefore starts, it just doesn't show any results.
The output of bindkey shows "^[z" fzf-custom-widget so I'm pretty sure there's no conflict there.
C-t, C-r and M-c default bindings work perfectly too.
Is there any way to get this to work? Or a better alternative workflow? I feel like I might be overcomplicating things here!

For anyone who stumbles across this, I got help from @romkatv on reddit here where he states:

Zle redirects stdin to /dev/null, so you need to redirect it back to the tty.
fzf-widget() {
  fzf <"$TTY"
}

Note that it’ll print the selection to stdout. If you want it inserted into the command line, do this:
fzf-widget() {
  local selection
  selection=$(fzf <"$TTY") || return
  LBUFFER+="$selection"
}

Just adding the <"$TTY" at the end of the function solved the problem for me.


js: Checks that non-preemptible machines are not set as spot machines

Before this commits, the chooseSize function does not distinguish
between spot and reserved machines. It simply assumes that all
machines can be preempted. This is not always the case, e.g. Amazon
t2.micro can only work when using reserved machines. This commit
makes sure that user is either using a spot machine or preemptable
is set to False in blueprint, and warns user to change the config
otherwise.

Fixed.


Can't manage/edit hyperlink on Busy Editor

maybe we should be able to select and edit link URL

This has been solved in Busy new design.


importing types with "vite-plugin-svgr/client" does not work for "moduleResolution": "node16"

Typescript requires package exports with condition "types" for subpath imports like  "vite-plugin-svgr/client" when moduleResolution node16 is enabled.
Reproduction is easy:
Create a minimal React Typescript App with Vite and add like:
npm create vite@latest node16-bug -- --template react-ts
cd node16-bug
npm install vite-plugin-svgr

Add  "types": ["vite-plugin-svgr/client"] to compilerOptions in tsconfig.node.json
Change to "moduleResolution": "node16" in tsconfig.json.
Change all existing relative imports to include the extension to make them compatible to node16 resolution.
Add the svgr plugin to vite.config.ts.
Add a SVG import.
Run type check with tsc --noemit. There will be an error:
error TS2688: Cannot find type definition file for 'vite-plugin-svgr/client'.
  The file is in the program because:
    Entry point of type library 'vite-plugin-svgr/client' specified in compilerOptions

  tsconfig.json:9:30
    9     "types": ["vite/client", "vite-plugin-svgr/client"]
                                   ~~~~~~~~~~~~~~~~~~~~~~~~~
    File is entry point of type library specified here.

For an easy fix add the following to the exports in vite-plugin-svgr package.json:
    "./client": {
      "types": "./client.d.ts"
    }

Thanks for the feedback! Would you like to send a PR?

ok, done :)


fix(headless): serialize and deserialize endInclusive parameters for range facets (numeric, dates)

Fixes #2877
Add optional serialization and deserialization of search parameter endInclusive for range facets.
It's optional in the sense that, by default endInclusive is false (at the API and index level).
So it's un-necessary to persist endInclusive=false in the URL.
Previous URL format was : (nf/df)-somefacetfield=start..end
With this change format becomes (nf/df)-somefacetfield=start..end(optional)..endInclusive
https://coveord.atlassian.net/browse/KIT-2460

I'm also seeing other languages like Perl and Pascal which use two dots or three dots to signify an inclusive range.
Given that, I think we could use triple-dots to mean an inclusive range.

Very good idea ! I'll apply those changes


WIP: New gengl module using opengl-registry

We now generate two modules:

gl.py containing 4.6 core enums and functions
gl_compat.py containing 4.6 compatibility enums and functions

We use the core version by default and users can opt in to compatibility mode by using gl_compat instead. Using compatibility mode will cause issues on certain platforms and drivers where only core is available.

I kept the old gengl.py around because the new one doesn't generate glx, agl or wgl etc. It only generates gl and gl_compat

TODO:

[ ] Update docs
[ ] Put requirements somwhere (opengl-registry)
[ ] Remove old gl modules

I think this is ready to merge now unless you find something. It worked fawlessly on MacOS.

Just cloned your branch, and it seems to work fine on my Linux machine as well. Great work!
I'm going to give the code a quick manual review, then merge it in.

I think gengl.py is not as smooth as it can be, but at least it's not horrible.


Fix switching between ensembl objects

Type

Bug fix

Description
Bug 1. Genome browser code does not receive correct chromosome and location when user changes the focus object
Steps to reproduce:

Select human
Go to genome browser and choose to view BRCA2
In the right-hand sidebar (track panel bar) click on the bookmark icon
Change from gene object to region object
Notice that genome browser did not respond. If you console log the event sent to the browser, you will see that it received the wrong chromosome (13 instead of 17) and wrong coordinates

Possible complications
Don’t know why the previous version of code used location from the browser state (props.chrLocation[genomeId]). Will this bugfix break things?

The location has to be retrieved from browserQueryParams when the focus changes. It shouldn't look for the previous location.


Bluetooth: Controller: ISO Sync Receiver with ticks_slot_window

Add implementation for ISO Sync Receiver to use ticks slot
window feature.
Added implementation to have ISO Sync Receiver resume its
subevents after being aborted by other overlapping events.
Introduce BT_CTLR_PERIPHERAL_RESERVE_MAX Kconfig option so
that disabling this option will use minimum time reservation
and exercise the peripheral connection event continuation
using is_abort_cb mechanism.
Add implementation for Extended Advertising Auxiliary PDUs
to use ticks slot window feature.
May fix #56201.

rebased to ensure CI is passing, keeping this PR draft and will be sending smaller PRs with considerations to already provided review comments here.

@cvinayak what was the reason for closing this?

This PR contained a mix of some fundamental changes to nRF specific Low Level scheduling (for which I will need new bsim tests, only tested using manual bsim samples); and, commits that fix/improve inter-operability with Sony Xperia and Samsung S24 phones. The fix/improvement commits are now in #77921 (which is also draft, as I need to complete handling of is_abort_cb mechanism for CIG events).
Also, I would like #78894 to be merged ahead.
To summarize the order:

#78894
#78096
#77921
#67231 or remaining commits of #75760 (both are enhancements)