Add support for Obsidian Callouts

🚀 The feature, motivation and pitch
As  @epwalsh  suggested in the discussion, submitting a feature request here for greater visibility.
Motivation
I have been frequently using Obsidian callouts in my notes since I started using Obsidian. It serves as an important highlight tool in my workflow and I enjoy the look. If the plugin could present some kind of interaction when one is implementing a callout, it might provide an even smoother editing experience.
Feature
Add (at least a certain degree of) support for Obsidian callouts.
Here is a simple example of callout syntax:
> [!info] Callout can have a title
> Here's a callout block.
> It supports **Markdown**, [[Internal link|Wikilinks]], and [[Embed files|embeds]]!

Basically what I would like is similar experience as editing a callout in Obsidian. I am no expert but I imagine it would be a hassle and unnecessity to try to reproduce the exact effect of callouts in Neovim. It may very well be sufficient for a smooth editing experience imho if something like the following is achieved:

When typing something like > [!info] the line turns into an icon, in similar fashion to say - [x] in checkboxes.

When I hit enter/return to go to a new line inside a callout block, it would automatically add >  to the beginning of this new line. I presume a simple solution/workaround is some custom comment format options like

vim.api.nvim_create_autocmd("FileType", {
	pattern = "markdown",
	callback = function()
		vim.opt_local.formatoptions:append("r") -- `<CR>` in insert mode
		vim.opt_local.formatoptions:append("o") -- `o` in normal mode
		vim.opt_local.comments = {
			"b:>",
		}
	end,
})

(code snippet copied from reddit)
Alternatives
No response
Additional context
No response

I'd like to take a crack at this.

I think I have something working, but I'm not sure what the process is to create a pull request. @epwalsh; do you have a general procedure?

ah i just realized i missed point 2. Back to drawing board :(

@aquilesg I would say don't worry about point 2 for now. We currently don't do anything like that in this plugin. Not that I'm against it, but I think it should be a separate project.

I went ahead a made a PR here:
https://github.com/epwalsh/obsidian.nvim/pull/665

While I'm here, would it be too much to add cmp completion for callouts? There are so many different ones that it makes it hard to remember them sometimes


Uncaught Exception: Attempting to call a function in a renderer window that has been closed or released. Function provid

An uncaught exception was reported.
Info:
OS: win32
Arch: ia32
GPMDP Version: 3.0.1
Time: Fri Mar 25 2016 21:34:25 GMT-0500 (Central Daylight Time)
Error:
Attempting to call a function in a renderer window that has been closed or released. Function provid
Error: Attempting to call a function in a renderer window that has been closed or released. Function provided here: Object.<anonymous> (C:\Users\Jaden\AppData\Local\GPMDP_3\app-3.0.1\resources\app\build\inject\GPMInject\interface\mouseButtonNavigation.js:8:8.
    at BrowserWindow.callIntoRenderer (C:\Users\Jaden\AppData\Local\GPMDP_3\app-3.0.1\resources\atom.asar\browser\lib\rpc-server.js:201:19)
    at emitTwo (events.js:92:20)
    at BrowserWindow.emit (events.js:172:7)

This issue was created automatically inside the uncaughtException handler

Closing this automatically reported issue as a duplicate of #470


kor: initial at 0.3.0

Description of changes
Package: https://github.com/yonahd/kor.
Description: A Golang Tool to discover unused Kubernetes Resources.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2990

Result of nixpkgs-review pr 267199 run on x86_64-linux 1

1 package built:

kor

@onemoresuza can I please ask you if you generated this list using software or you did it manually?

Sure!
It was manually generated based on the New Packages Section
of the the README file under the pkgs/ directory.

Sure! It was manually generated based on the New Packages Section[1] of the the README file under the pkgs/ directory. [1]: https://github.com/NixOS/nixpkgs/blob/d3fcdeccae0b3e2504493a6a4147a65f49e77630/pkgs/README.md?plain=1#L764

Got it, thanks!


How to query data

This is a question father than a issue.
So we all this data in the the gets shown on the dashboards.
I want to know if there is an ideal way to query this data. I am looking to make some alerting based on this data. i.e machine is disk is getting full, no bound to AD
I can just query the DB for the info, but is there a better way?

Something like https://github.com/munkireport/munkireport-php/issues/102

I may have a sponsor to pay for a notification system, but I won't be able to work on that before the end of august.
Please feel free to try and build something for that.

Thanks, i will give it a go, it was going to me external the
munkireport-php then having something built it, but i will see what i can
do
On Wed, Jul 15, 2015 at 3:57 PM, Arjen van Bochoven <
<EMAIL_ADDRESS>wrote:

I may have a sponsor to pay for a notification system, but I won't be able
to work on that before the end of august.
Please feel free to try and build something for that.
—
Reply to this email directly or view it on GitHub
https://github.com/munkireport/munkireport-php/issues/270#issuecomment-121643330
.

--
Adam Barnett


net/http: tests failing on Plan 9 since CL 31173

Since CL 31173 the HTTP server relies on deadlines to read requests from clients. This change broke various tests in the net/http package, because deadlines aren't implemented on Plan 9 yet.
2016/10/18 03:15:56 httptest.Server blocked in Close after 5 seconds, waiting for connections:
  *net.TCPConn 0x10976f98 <IP_ADDRESS>:47045 in state active
  *net.TCPConn 0x10976110 <IP_ADDRESS>:43006 in state active
panic: test timed out after 3m0s
FAIL	net/http	180.069s

See https://build.golang.org/log/726c2a2970f3e33d3728a27645521822e2ef8d03

To be clear, the fix here is to implement deadlines on Plan 9, right?

Yes. And there's now a pending CL for it too.

Yes, we have to implement deadlines on Plan 9.
I've proposed an experimental implementation in CL 31521, which is able to pass the currents tests.


Ionic serve unable to update live reload

When I edit a file I show that error in the command line: Unable to update live reload: Error getaddrinfo EONENT localhost:35729
Cordova Cli: 6.0.0
Gulp version: cli version 3.9.1
Gulp local: local version 3.9.1
Ionic framework version<EMAIL_ADDRESS>Ionic cli version: 2.0.0-beta.32
Ionic app lib version: 2.0.0-beta.18
OS: Windows 10
Node version v6.2.2

Hi, have you solved this problem, I met the same problem. Looking forward to your reply soon!


Repo sync for protected CLA branch

The pull request is created from main637789913376184433 to main to fix git push error for protected CLA branch

@opbld16 : Thanks for your contribution! The author(s) have been notified to review your proposed change.


[BUG] Config Orders İs Not Working

Just Working "Name" Order Other Ones Are Not Work

This was recently fixed by a PR

ok

It's on the dev branch, it will be merged to master when 1.2.0 is ready


Document GridFunction::ProjectCoefficient and FiniteElement::Project.

Improving documentation.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#1955
@dylan-copeland
@tzanio
@mlstowell + @rw-anderson + @tzanio
12/22/20
⌛due 01/05/21
⌛due 01/12/21

I updated the wording a bit in 50197feee0d2b13afbaee4776a1acf2f28539c66. Please revert if you don't like it :)

Merged in next for testing...


Support verifying cookies from Firebase

This PR adds support for verifying session cookies from Firebase. They are JWTs that have the same shape as idTokens, but are longer lived for backend applications. The difference is the kid values are unique between idToken and sessionCookies payloads.
I did my best to work inside the existing API to avoid any major rewrite, but am happy to adjust the approach.
Other Changes
I loosened the version constraints on Finch

FYI I am using this fork in a new library I am working on called flame.
Given the overlap, it may make sense to pull this code into that library. Thoughts?

Security wise that makes a lot of sense, we can definitely come up with an api that doesn't cause too many dupes. As long as verify_token and mock still work with the current behavior I think we're fine?

@Nickforall I changed the API to ExFirebaseAuth.Cookie.verify_cookie/1 to mirror the ExFirebaseAuth.Token.verify_token/1 pattern.
I think you should be able to release this as a 0.x release in this form

@Nickforall any luck on getting your eyes on this? I want to release the Flame library I've been working on, but I need a packaged version of ExFirebaseAuth first 😬

@Nickforall any luck on getting your eyes on this? I want to release the Flame library I've been working on, but I need a packaged version of ExFirebaseAuth first 😬

Having a look now! Sorry for the inactivity here, founded a startup so have been super busy and no longer using this lib in production myself.

Ah gotcha, I was not aware of that dependency.
On Tue, 18 Oct 2022 at 16:29, Justin Smestad @.***>
wrote:

@.**** commented on this pull request.
In lib/source/google_key_source.ex
https://github.com/Nickforall/ExFirebaseAuth/pull/53#discussion_r998312592
:

if Enum.any?(results, &(&1 == :error)) do

 :error

else

I struggled with this one as well. If you are using both session cookies
and id tokens, you need both of these keys for the program to function
correctly. Having one and not the other would result in a difficult
debugging path so I favored failing.
—
Reply to this email directly, view it on GitHub
https://github.com/Nickforall/ExFirebaseAuth/pull/53#discussion_r998312592,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABGBWMWSSH5CYK5UYQY3JO3WD2X3BANCNFSM5UQDL72Q
.
You are receiving this because you were mentioned.Message ID:
@.***>


[rpc][indexer][feature request]  Make it possible to query event count.

Currently there's no way to query the number of times an event has been emitted. The queryEvent call fetches paginated events but there's no way to get the total number of them.
This would be useful for UIs to show e.g. how many times an NFT has been minted when the mint call is a single writer transaction and doesn't keep track of the count in a shared object.

You can pass the event filter and get data array. The length of result array is the event number.

The length of result array is the event number.

It's not because it's paginated.

If you're running the indexer you can just filter the events table with event type and count the results that should help.
Thoughts?


added check to see if valid block height is greater than current block

Can you see if this fixes your issue?

The number of orphan is still not as expected, but the forks are now resolved after network recover

Yes, the way it counts orphans is not reliable in my opinion. Let me know when you're confident this hasn't broken approve it and I'll merge it.


Invert Colors doesn’t work on Ti 84 Plus Ce Python Edition

Dont merge this, I’ve tried holding it and doing it as soon as it starts. Nothing. I’ve updated to latest cesium and it does not work

It does work trust me. You are doing something wrong.

Dang.
Any chance it ever will?

It does work trust me. You are doing something wrong.

it doesn't work for me. Please help a little further instead of "You are doing something wrong." I don't believe I am.

Do you have the latest Cesium version from here?
What's your datecode/hardware revision? (On the back of the calc, it's the characters like L-0921T.
Does it behave the same way after resetting the calc? (Holding the reset button for like 3s)
Does it behave the same way before and after having run the python app?

Yes
L-0621T
No, I have to launch Cesium first otherwise the on-shortcuts dont work (like on->stat still works for password)
Yes

Its been 11 days -- anyone?

Well we aren't able to reproduce the issue, apparently, so... :(


Prevent __pycache__ directories in /layers at build time

Describe the Enhancement

Per investigation in https://github.com/paketo-buildpacks/python/issues/507, when pip installs dependencies, it caches precompiled Python bytecode in __pycache__ directories. The bytecode isn't reproducible, because it contains timestamps. Currently, those __pycache__ directories end up in /layers, which makes python builds non-reproducible.
Possible Solution

As https://github.com/paketo-buildpacks/cpython/pull/352 indicated, setting PYTHONPYCACHEPREFIX changes the location where these cached files are stored. The environment variable should be set to some temporary location at build time so __pycache__ directories don't pollute otherwise-reproducible layers.
Motivation

Exploration in https://github.com/paketo-buildpacks/python/issues/507 indicates that setting PYTHONPYCACHEPREFIX to /tmp at build time is sufficient to make python + pip-install image builds reproducible!

@fg-j Can you clarify what you did to set PYTHONPYCACHEPREFIX to /tmp at build time?
Did you run pack build --env PYTHONPYCACHEPREFIX=/tmp? Did you modify the code of the cpython buildpack? Did you modify others? How did you modify this variable only for build time, and not for launch time?

@robdimsdale For most of my investigation, I used the --env flag of pack to set the environment variable at build time (see this comment for an example pack build).
In https://github.com/paketo-buildpacks/conda-env-update/pull/189, I experimented with setting the environment variable in the buildpack code itself, since I needed to splice out the conda-meta/history file anyway.  I saw the same effect on conda builds when setting PYTHONPYCACHEPREFIX with --env and when setting it inside the buildpack.
Throughout my investigation, I set the environment variable only at build time. The change should not have had any impact on the value of PYTHONPYCACHEPREFIX that the buildpack sets at launch time.

Great, super helpful, thanks.
I constantly find myself confused about when the lifecycle will set an env var for build vs launch. Can you confirm (or correct) my understanding:

If I set the env var via pack build --env FOO=bar then FOO=bar will only be set at build time
If I modify the buildpack to use os.SetEnv("FOO","bar") (or equivalent in languages other than Go) it will only modify the environment variable for the duration of the process (i.e. while the buildpack is running in the build phase)
If I set the env var on the layer, then the env var will be persisted on the layer.

If I set the layer to build: true then the env var will be present on all future uses of the layer during the build phase.

The env var won't be read by downstream buildpacks during their build phase unless they explicitly read it from the layer and choose to set it during their own process.

If I set the layer to launch: true then the env var will be present on the layer during launch.

The env var will be present in the environment variable of the running app, assuming the layer makes it on to the container

If I set the env var during a pre-launch process (e.g. the env process in Cpython) it will only be present during launch, and is set dynamically at launch time (vs statically at build time)

I appreciate that this isn't really for you to answer, but you've been spending time in this space so hopefully you can help me get an accurate mental model.
Also cc @ryanmoran - is my model above of environment variables accurate?

@robdimsdale Everything you laid out there looks correct to me. One bit of nuance is that it's possible to set the BuildEnv, LaunchEnv, ProcessLaunchEnv and SharedEnv for a given layer (see packit). So, if you want, you can decide when an environment variable should apply regardless of when the layer is present.
To give a concrete example:
In the dotnet-core-sdk buildpack, we put the layer containing the SDK on the $PATH only in the build environment because we only want to use the binary installed in that layer at build-time. Some other buildpack might request the SDK layer at launch time. The SDK buildpack doesn't control that. Regardless of whether the layer is present at launch, it won't be on the $PATH.

Ah, ok. That's helpful context.
Again, mostly for my own notes:
It sounds like there is a slight difference in what I was describing about setting the environment variable in the layers:

All env vars set by a buildpack on a layer with "Build Env" will be automatically loaded by the lifecycle for future buildpacks that use that layer. Concretely, if we set a variable with "build env" in the Cpython buildpack, then all downstream buildpacks will have that env var loaded without having to explicitly read it from the layer.

I think that what that means for the Python __pycache__ directory is as follows:

we can set PYTHONPYCACHEPREFIX=/tmp (or PYTHONDONTWRITEBYTECODE=any-value) in the layer generated by the CPython buildpack
all downstream buildpacks will pick up that environment variable automatically because they depend on the CPython buildpack and its layers.

For posterity, the official spec is here.


fix: speaker image placeholder problem resolved

Fixes #1646
Changes:
Speaker image placeholder is displayed even if the internet is off and the user has opened the app for the first time.
Screenshots for the change:

@iamareebjamal please review.

@mahikaw This should solve #1644 too

@mahikaw Please test the current branch and tell if that bug is resolved too

@iamareebjamal I'll just do that and revert.


Bug: Adding a subscriber to a TestRabbitBroker persists between test runs

Describe the bug
If I create a TestRabbitBroker in a  fixture, and then add a subscriber. This subscriber is still available in the next test. As the fixture is function scoped, so on every call this means that the subscriber is added to the real broker.
One can work around this by creating the broker in a factory method.
How to reproduce
Install pytest + faststream[rabbit] save source as 'test_bug.pythen runpytest`
import pytest
import pytest_asyncio

from faststream.rabbit import RabbitBroker, TestRabbitBroker

broker = RabbitBroker("bug")

@pytest_asyncio.fixture
async def test_broker():
    async with TestRabbitBroker(broker) as br:
        yield br

@pytest.mark.asyncio
async def test_one(test_broker):
    @test_broker.subscriber("queue")
    async def sub():
        return "foo"

    result = await broker.publish("", queue="queue", rpc=True)

    assert result == "foo"

@pytest.mark.asyncio
async def test_two(test_broker):
    result = await broker.publish("", queue="queue", rpc=True)

    assert result == "foo"...

Environment
Include the output of the faststream -v command to display your current project and system environment.
Running FastStream 0.3.3 with CPython 3.11.6 on Linux

Thank you for the Issue, I'll take a look tomorrow

Well, TestClient patches the original broker indeed. And it doesn't make it in a clearest way. Seems like I have to refactor all test class logic and implementation and it can't be a fast fix, sorry.

The behavior of this test case has changed. I can no longer add new subscribers after TestRabbitBroker has been called, instead I need to add them before creating the TestRabbitBroker.
However: This is an annoying issue, not actually a critical one.


Consider switching dependency logic to 'withDependencies' introduced in Gradle 4.4

https://docs.gradle.org/4.4/javadoc/org/gradle/api/artifacts/Configuration.html#withDependencies(org.gradle.api.Action)
This is some more backward incompatibility though as the API was just introduced.

Initial migration shows lots of tests failing for 4.4 and 4.5, but not with 4.6 when using withDependencies


restrict vagrant up to only if vagrant version is 1.8.6+

for all vagant files here : https://github.com/contiv/netplugin/tree/master/vagrant

@dseevr : if you know the code fix could you please work on this one ?

@dseevr : Please close this if this has been merged !

@gaurav-dalvi  It hasn't been merged yet, but this issue will be auto-closed when it does get merged


Replaced django's User model into get_user_model to increase reusability

Replaced django's User model into get_user_model in factories. Because there is no auth_user table in database when I use custom User model.

Good catch, thanks!


handle quote tweet-style mentions

original post discovery needs to run recursively on attachments (if
the attachment belongs to our user) to find the original URL for the
attachment
ref #504

this is deployed on https://bridgy-kwm.appspot.com
here's a backfed quote tweet: https://bridgy-kwm.appspot.com/log?start_time=1450912031&key=agxzfmJyaWRneS1rd21yNQsSCFJlc3BvbnNlIid0YWc6dHdpdHRlci5jb20sMjAxMzo2Nzk3OTU4NDM1MTIxNzY2NDEM

uhm, but it also backfed a response to tantek for his own tweet :/
https://bridgy-kwm.appspot.com/log?start_time=1450912031&key=agxzfmJyaWRneS1rd21yNQsSCFJlc3BvbnNlIid0YWc6dHdpdHRlci5jb20sMjAxMzo2Nzc2ODY5NTQ3NzE4MDAwNjQM

yup, whee. afaik that's one of the edge case casualties of the post-#51 OPD new world order. for many of them (like that one), i think we didn't even agree amongst ourselves what the right behavior was.
so to confirm, that's entirely unrelated to this PR?

Yep, unrelated! I was worried it might be a regression at first but it wasn't
On December 23, 2015 3:33:33 PM PST, Ryan Barrett<EMAIL_ADDRESS>wrote:

yup, whee. afaik that's one of the edge case casualties of the post-#51
OPD new world order. for many of them (like that one), i think we
didn't even agree amongst ourselves what the right behavior was.
so to confirm, that's entirely unrelated to this PR?

Reply to this email directly or view it on GitHub:
https://github.com/snarfed/bridgy/pull/582#issuecomment-167008943

you were right! this definitely seems straightforward. thanks for doing it!

oh also, corresponds to snarfed/granary#69, just for the record.

oh, and updating the "what gets sent back" section in the docs! always a fun last step, at least for me.


Add LlamaBerry to the list

Thanks for putting together this list!
For full disclosure, I'm the creator of LlamaBerry. It's a free game, and I just want to share it with others. 😀

I'm so sorry it has taken me this long to get around to this. I just checked it out and I appreciate the contribution!


METRON-284: SensorParserConfig object cannot be serialized with the default Jackson ObjectMapper

The SensorParserConfig object cannot be serialized without a custom Jackson ObjectMapper. Specifically, this is caused by the way the FieldTransformer is implemented. A call to SensorParserConfig.toJSON() will fail with this message if a transformer is configured:
No serializer found for class org.apache.metron.common.field.transformation.MTLTransformation and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) )

I took the liberty to also add a unit test to ensure that the enrichment configs also serialize and deserialize properly.

+1

+1 all tests pass.


[Request] Build and publish package in NuGet

Currently, to use Heap, you have to clone the repository and then reference that locally - Following TinYard, we should publish the package to NuGet for consumption.

#9 should resolve this.


Granular scss rebuild

For each .scss or .sass module:

Track declared variables/mixins
Track external variables/mixins being used

When a module is updated, insert external variables at the top of the module before transpiling.
This strategy lets us avoid re-transpiling the entire bundle when a .scss or .sass module changes.
Note: We won't support cross-file @extend for now.

This is more effort than it's worth, I think.
I completed the reference/declaration parser and got cold feet after digging into the complexity of resolving and tracking dependencies between modules.
May revisit in the (not nearby) future.

This would be easier to implement if only direct parents have access to the variables, mixins, and functions of a module.


Zarmada/working/ADTS-212

Summary of changes 🔍

Fix: Can no longer drag to order property items or drag to/from templates
Reordering of properties should be accessible rather than just drag
With template items we should be able to add without just dragging

@jamescarpinter ready to go

@jamescarpinter I think it's good to go


Exponential notation from Y axis not exported

I have a problem with the exported .png file (and others too). The exponential notation on the top of the left Y axis does not show in the png exported image. Has anyone experienced this?
For instance I have a plot with value 0 to 5 "x10^-12". The exponential shows at the top of the axis but none of the formats I have tried (eps, pdf, jpg, png) show it. See images.

Also, I can't seem to find how to add images.. I'm new to github. I have the images but can't upload them.

Also, I can't seem to find how to add images.. I'm new to github. I have the images but can't upload them.

Fixed. This was cause by an internal Matlab bug that conflicted with Kevin's fix #63 from last week (May 4, 2015): apparently, setting the axes' TickLabelMode to 'manual' in HG2 (R2014b+) causes the exponent label to be deleted:
plot(1:5, [1:5]*1e7);  % exponent label shown
set(gca,'YTickLabelMode','manual')  % exponent label deleted
set(gca,'YTickLabelMode','auto')    % exponent label shown again

So for now I'm reverting change #63, because I believe that it affects fewer users than this issue (#67). I'll be in contact with Kevin regarding a better fix for #63.

Thanks for the fast response!!

I was just informed that at the issue with the disappearing exponent was fixed in Matlab release R2015b. I'm still not reverting to Kevin's fix since there are still many users who use R2015a or earlier.


Store hash of email addresses rather than the plain text?

This is something that I've been background thinking about for awhile.
For our purposes, we don't need to store email addresses that aren't subscribed to the newsletter.
I've been wondering if it might make sense to hash them with some salt

Does the backburner label mean a FOSS contributor such as myself shouldn't pick this one up at this time? Or is that just for employees to look elsewhere for work?
This one reminds me of the API Keys changes where we ended up hashing API Keys in the DB. It piques my interest.

Yep, I'm just trying to indicate it isn't a priority. I gave this one backburner because there are consequences to this that I haven't thought about carefully.
A. The primary way we get new newsletter subscribers is when they sign up with email.
B. If we ever want to send notification digests we'll need to store the email in plaintext.
So UX of A & B degrade. I can't tell if it's worth it. Open to thoughts.

I've been thinking about it and I agree.
We'll need to figure out how to handle the newsletter and how to otherwise promote it in the ui though.

I'll think it over and try to work up a proposal here for discussion.

I am working up a PR to see the effect of these changes and help make some decisions. A couple of notes I've made thus far:

Salting the email before hashing doesn't really work because the user would have to therefore provide the salt in order for us to do a lookup, which won't work. So I think in this case, we're limited to hashing the email address as-is before saving in the DB. Similar to what we do for API Keys.
No longer storing the email address also has the impact of not being able to show the user the email address that is currently linked to their account in the settings page, should they want to unlink the email address. Are you ok with an experience like the following, where users can unlink the email address, but they don't know which email address it is?

I was thinking we would provide the salt, that way you'd really need both the db and the salt to confirm an email address belonged to someone.
It'll probably be a new source of support tickets but we already have this problem with lnauth.

I was thinking we would provide the salt, that way you'd really need both the db and the salt to confirm a known email address belonged to a nym on sn.

Can you elaborate a little on what you mean by "we would provide the salt"? Do you mean, we give it to users when they create an account via email on SN? Or that we as SN would provide the salt when doing the lookup in the DB? If the latter, this is what I started with, but quickly realized that when a user attempts to login with just an email, it's impossible to know which salt to salt it with, unless you intend to use a shared salt for all emails? I was operating under the assumption that each email would have its own salt, but maybe that's where the confusion came from. If it's a shared salt, then yes, it could be a env var secret or something that way DB access doesn't give you everything. That should work.

It'll probably be a new source of support tickets but we already have this problem with lnauth.

As long as you're ok with this implication :) I hadn't considered it previously until I found it locally so wanted to surface it.

If it's a shared salt, then yes, it could be a env var secret or something that way DB access doesn't give you everything. That should work.

Yes that one! :)

As long as you're ok with this implication

We'll see lol

It'll probably be a new source of support tickets but we already have this problem with lnauth.

As long as you're ok with this implication

We'll see lol

Since we're moving into the direction of encrypting credentials for attached wallets, E2EE for #56, #519 and other stuff, we will probably provide users with some kind of passphrase anyway. I think we could use the same passphrase for users to backup their accounts in case they lose access[^1]. If they can't login, they could select "lost access?" or similar below "Been here before?" or "New to town?" which redirects them to a page to enter their passphrase to regain access.
This should solve any support request if the information is prominent enough that you will lose access if you lose this passphrase, similar to losing seed words in bitcoin.
[^1]: This would mean it's a single point of failure if an attacker gets plaintext access, but it doesn't mean we're using the same encryption keys. We can derive different encryption keys for different methods.


"At home button"

I am not using HomeKit for detecting if the members of my house are at home.
would it be possible to trigger the "at home" button that is featured by the camera-UI from a different source. As far as I am aware at the moment this button can only be triggered manually within HomeKit as far as I am aware. Correct?
Thank you!

This would be a great feature. If there is a "at home" button accessory, we can trigger it with a Shortcut automation.

I couldn't find it on the UI, but if you set this true in the config, it will appear in Home.

I am not using HomeKit for detecting if the members of my house are at home.
would it be possible to trigger the "at home" button that is featured by the camera-UI from a different source. As far as I am aware at the moment this button can only be triggered manually within HomeKit as far as I am aware. Correct?
Thank you!

I don't know if this applies to your needs: I use Homebridge People Geofence  and Locative for IOS to trigger absence/presence in HK. Based on that I have further automations like switching 'at home'.


ARMv7 not supported.

ARMv7 isn't supported on vendetta since a while ago, so I haven't been able to use it, however is it possible to fix this somehow? This should also be clarified somewhere that ARMv7 doesn't work anymore.

Can you please give more details about the problem?
What kind of error did you face?
Can you provide crash logs if possible?

no crash logs, no error it just closes

I have begun having the same issue, starting after the April 2024 Google Play system update. The app simply crashes on launch with no error message or logs whatsoever.
My device is a Samsung Galaxy A13 5G (armv7) running Android 13 and One UI 5.1.

I think this is similar to what @palmdevs pointed out months ago, where things randomly stopped working on ARMv7 Samsung devices, hopefully Palm would be able to share helpful info if they still remember any

I think this either is or is similar to what @palmdevs pointed out months ago, where things randomly stopped working on ARMv7 Samsung devices, hopefully Palm would be able to share helpful info if they still remember any

Something might've changed about React Native a few versions back (or maybe LSPosed just doesn't want to work on ARMv7). The module complains about not being able to find a method to inject to, even though when listing methods manually using a modified module works fine, as in the method is listed.
Injecting alternative methods without the jni prefix causes an issue where no icons are displayed. Opening some pages (notably forum posts) results in a hard crash. I can probably attach some logs, if I can find them.

If you really want to use Bunny, I recommend downgrading to somewhere around 210.x. As far as I can remember, those versions work.

I tried it on v210.10 and v207.23, both with the same result - instant crashing on startup.

That's very odd, used to work fine for me. I'll try if I have time.

Something else that may be useful - Bunny was working just fine for me on v227.12 just yesterday night. I did not update the app or do anything else since then except for installing the latest Google Play system update and rebooting my phone.

I can confirm that this is an issue with Google Play System Updates. I've recently factory reset my phone and I am running on July 2023 updates, BunnyXposed works correctly.

I can confirm that this is an issue with Google Play System Updates. I've recently factory reset my phone and I am running on July 2023 updates, BunnyXposed works correctly.

I made a Google play system update but it still instantly crashes when I try to launch it

For future reference, the issue stems from a Google Play system update for the com.android.art component. If you have superuser, you can manually revert the update for that specific component by deleting<EMAIL_ADDRESS>Tested on May 2024 GPSU, Android 14.

@amsyarasyiq You can probably close this as not planned.

For future reference, the issue stems from a Google Play system update for the com.android.art component. If you have superuser, you can manually revert the update for that specific component by deleting<EMAIL_ADDRESS>Tested on May 2024 GPSU, Android 14.

@amsyarasyiq You can probably close this as not planned.

Unfortunately, I don't have superuser, but alright.

I know this will not be fixed but is there any way to change the methods used in Bunny to fix this issue ? Or has the update changed too much

This issue has already been fixed in https://github.com/pyoncord/BunnyXposed/pull/4

Well not for me apparently...


Update Dialogs.de.json

Reflect changes made in English Dialogs.json

Seems like you changed the file formatting from the script and the git diff.


Support for alternative workflows

I had a look at cargo-release and found that it does only support one workflow (please correct me if I'm wrong).
Current workflow
From what I see, the workflow for using cargo-release is that I have to be on my main branch (cargo-release checks that) and I do a release from there. cargo-release then does pre-release steps (clearing up the changelog file, setting the right version strings), then does the release (cargo-publish) and tag that commit appropriately. After that, it does some post-release steps (bump versions). Then, these commits and tags are pushed to the remote repository.
Please correct me if anything from above is not correct.
Desired workflow
I currently use workflows that do not support committing to the main branch at all and actually pushing changes to "main" is forbidden on all my repositories. I exclusively use bors for merging to main/master!
There are two scenarios:
Small projects
For "small projects" (few contributors, less frequent merges to main) I branch off of "main" and create a "prepare-x.y.z" branch (where "x.y.z" is acutually the version of the release about to be created), that prepares for the next release. I update the changelog (by hand for now, but I plan on implementing cargo-changelog soon), update version strings in README, examples, Cargo.toml if needed. I push that out as a normal PR to github and wait for CI to be green.
I merge using bors. Bors is the only actor that is allowed to push to my main branch in any case.
Once bors merged, I forward my local main branch to that merge commit, create a tag, do cargo-publish and push out that tag.
Big Projects
For big projects, I am going to use a more sophisticated workflow (I did not yet get the chance to actually use that workflow, but it has been discussed among my peers and it looks like we want to go with exactly that workflow).
The overall idea of that workflow is that main does never slow down. With the "Small projects" workflow from above, I do not merge changes to main between the branch-off of the "prepare" branch and its merge. With this workflow, merging to main is never forbidden or even delayed for one second.
For this workflow, I create a release-1.2.x branch (normally patchlevel is set to the string "x" because patch-releases will happen on that release branch) on a commit on main. Because main has to be always green, it does not matter which one.
That release-1.2.x branch is directly protected on github. Nobody is allowed to push to that branch, except for the merge bot (bors).
I then create a PR to that release-1.2.x branch for consolidating the changelog. Once that is merged, I go to that merge commit and create a tag and do a cargo-publish just like above.
To visualize (I left out progress on main because that would make the diagram even more complicated):
gitGraph
    commit
    branch release-1.2.x
    branch changelog-1.2.0
    checkout changelog-1.2.0
    commit id:"make changelog"
    checkout release-1.2.x
    merge changelog-1.2.0 tag:"v1.2.0"

Once the release is done, the commits for consolidating the changelog (and others, if any) are cherry-picked to PRs for main, to backport these patches to the main development branch.
Also, a PR is opened for main to update the version number (minor version) for the next release.
To visualize based on the diagram from above (I left out progress on main because that would make the diagram even more complicated):
gitGraph
    commit
    branch release-1.2.x
    branch changelog-1.2.0
    checkout changelog-1.2.0
    commit id:"make changelog"
    checkout release-1.2.x
    merge changelog-1.2.0 tag:"v1.2.0"
    checkout main
    branch backport-changelog-1.2.0
    checkout backport-changelog-1.2.0
    commit id:"cherry-pick make changelog"
    checkout main
    branch post-release-version-bump
    commit id:"bump version to 1.3.0"
    checkout main
    merge backport-changelog-1.2.0
    merge post-release-version-bump

Patch-releases will happen in the same way: A PR is created towards the "release-1.2.x" branch and if merged, that merge will be tagged as release and published. (Fixes are actually cherry-picked because they have to be merged to main before they can be backported, but that's a detail that's not relevant here).
To visualize (based on the first diagram, again without progress on main to keep the diagram less complicated):
gitGraph
    commit
    branch release-1.2.x
    branch changelog-1.2.0
    checkout changelog-1.2.0
    commit id:"make changelog"
    checkout release-1.2.x
    merge changelog-1.2.0 tag:"v1.2.0"

    checkout release-1.2.x
    branch backport-fix-abc
    checkout backport-fix-abc
    commit id:"Cherry-pick fix ABC"
    checkout release-1.2.x
    merge backport-fix-abc tag:"v1.2.1"

The whole idea of that workflow is that main is always green and always in a release-able state and that development on main never slows down. Nobody has to care about me making a release off of main, they are not impacted at all by that workflow.
How to support these workflows
My question now is: How can these workflows be supported by cargo-release. From what I see, there's actually nothing that could be automated further (except for the parts with cargo-changelog that are not yet implemented... but will be at some point).
Maybe you can see how cargo-release can provide value for these workflows where I don't! :laughing:

FYI I'd recommend also checking out #119 as it discusses an alternative workflow

While I will step through to see how cargo-release can help, I think being too strict on what/who can push can end up causing more pain to the process than it is worth and I'd recommend re-evaluating that stance.

Small projects
For "small projects" (few contributors, less frequent merges to main) I branch off of "main" and create a "prepare-x.y.z" branch (where "x.y.z" is acutually the version of the release about to be created), that prepares for the next release. I update the changelog (by hand for now, but I plan on implementing cargo-changelog soon), update version strings in README, examples, Cargo.toml if needed. I push that out as a normal PR to github and wait for CI to be green.
I merge using bors. Bors is the only actor that is allowed to push to my main branch in any case. Once bors merged, I forward my local main branch to that merge commit, create a tag, do cargo-publish and push out that tag.

With 0.22 out, you can use
$ cargo release changes  # review changes to choose versions
$ cargo release version patch  # update versions including in dependents
$ ./prepare.sh  # call `cargo release replace` and `cargo release commit` as needed

Then once merged
$ cargo release tag --workspace  # will automatically skip existing tags
$ cargo release push --workspace # will push the tags
$ cargo release publish --workspace  # will automatically skip existing published

In #119, I discuss a cargo release prepare that would replace the need for the prepare.sh script.  Feel free to chime in their with any additional thoughts.
I left out cargo release owner in this as it is usually used to update the owners when new ones are added.  cargo release will also automatically add owners when publishing new crates.  It might be worthwhile to integrate that into cargo release publish.  Feel free to create an issue on that if you want.
What this buys you over doing it by hand

You get various health checks up front (releasing something that isn't needed, forgetting to release something, missing metadata earlier in the process, etc
The updating of version strings is automated.
A commit template is used for consistency
Consistent tag names are enforced
For workspaces, no need to manually order the publishing of crates
Makes it easier to keep the expected owners set for crates
Fewer steps to document for others to take over within rust-cli

Large projects
The overall idea of that workflow is that main does never slow down. With the "Small projects" workflow from above, I do not merge changes to main between the branch-off of the "prepare" branch and its merge. With this workflow, merging to main is never forbidden or even delayed for one second.

Why does main have to pause for the small workflow?  You can let main continue to progress and then merge the release back in.  We have https://github.com/crate-ci/cargo-release/issues/147 for tracking making that easier.

Why does main have to pause for the small workflow?

Because between forking off the release preparation branch and the merge of the same, another PR could be merged that introduces new functionality, bugs, etc.:
gitGraph
    commit
    branch release
    checkout release
    commit id:"release preparation"
    checkout main
    branch feature
    checkout feature
    commit id:"new feature"
    checkout main
    merge feature
    merge release tag:"v0.1.0"

I will have a look at the other points you mentioned, thanks! :+1:

Oh right, you would be tagging and publishing main.  When done locally and not pushing to bors, this isn't an issue which is why I overlooked this.


fix typos, layout, capital letters, add actual bugs and workarounds

In response to https://github.com/MicrosoftDocs/azure-docs/issues/29076 as well as fixing layout, capital letters, add actual bugs we reported and workarounds.
Also fixing the redirection for a cmdlet that is for Admins only and does not allow you to view permissions to the cmdlet that actually provides some semblance of permissions to your subscription.

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

Hello @cblackuk -- thank you for the feedback! I left some inline comments, please address them before we can merge this PR. Thanks again...

I replied to some already :-) Please read my comments :-) @sethmanheim

@cblackuk I have read your comments, but it was after I submitted my comments and hadn't seen yours yet. A little patience would be well served in this case... :-)

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

@cblackuk : Thanks for your contribution! The author, @sethmanheim, has been notified to review your proposed change.

thanks @cblackuk .
@sethmanheim - as you have time, can you provide specific guidance for this PR.

#sign-off if it's ready to merge
#hold-off if it requires changes before it's ready for sign off
#please-close - if these changes aren't going to be merged

Thanks!

thanks @cblackuk .
@sethmanheim - as you have time, can you provide specific guidance for this PR?
* `#sign-off` if it's ready to merge

* `#hold-off` if it requires changes before it's ready for sign off

* `#please-close` - if these changes aren't going to be merged

Thanks!

Now that we fixed all the outstanding issues - or so I hope ;-) - there should be no reason not to merge :-)

#sign-off

Thanks guys! Really appreciate the help and effort to make docs better!

@cblackuk And we really appreciate your feedback as well!


Migration issue comments from github missing comments which issue index > 8600

When trying another migration gitea itself from github to https://gitea.com, the dumped comments missed some which issue index > 8600. It's odd.

I submitted a ticket with GitHub support asking about this. They may need additional detail to provide assistance.


Django Admin on Saleor based app

Hi.
I would like to reimplement django admin in my Saleor based application. Is there any problem this might cause? What do I need to do to be able to use Django Admin on Saleor?
Thanks for any help.

Hi @alcfernandes,
I just wonder, what features are you missing from Django admin, that aren't present in Saleor's dashboard?

Hi @Pacu2,
There are several simple features that I can add to my application using only Django Admin. Without having to spend hours of development and customer money.
My intention here is not to discuss whether or not to use Django Admin, but to know if there is any contraindication to reinstalling it.
I just want to know the reasons that led to the decision to remove Django Admin from Saleor.
Thanks a lot

@alcfernandes You should be able to add it without problems. We don't use Django Admin as we view it primarily as a scaffolding tool for developers. It's not enabled as we don't intend to expose it to any of our customers. We believe a custom-tailored dashboard is the only way to deliver great user experience.

Thanks @patrys!

I want to use export order, but now I don't know how to develop.


Stop run before creating more

In Organize_ML_runs.ipynb, we encourage the user to create another run before stopping the first one. This will assign a new run to the run variable and the previously created run is left hanging.
https://github.com/neptune-ai/examples/blob/32c1e659a2f54f4372edd83f2e58308af1725f9f/how-to-guides/organize-ml-experimentation/notebooks/Organize_ML_runs.ipynb?short_path=3cf92bc#L266
Should we change the order here, or something else?

Thanks for raising this. #135 will fix this


Added GDST Farm Harvest Object Event

Added GDST Farm Harvest Object Event for issue #52

Hi @bCamba and @MarceloWholechain
I've merged another pull request with this fix here, https://github.com/ift-gftc/opentraceability/pull/55
The main difference is I did not rename the FarmHarvestEvent type to FarmHarvestTransformationEvent to prevent errors in projects consuming this package when they update to the latest version.


Walk is broken when an element is too large

Hello :)
I had an issue while testing my project on a mobile phone. It looks like when an element of a walk is too big, the walk is broken.
Here is a showcase : here https://codepen.io/grimu/project/editor/ZKVJpg .
You can see in this pen that the demo is stuck, but if you zoom out, you will be able see the next steps.

Ok I think I should not focus on those big elements then :)
But I think that when this happens (if the users have zoomed a bit too much, or it's screen is too small) the library should throw an error (with a callback), or at least close the walker, as the app is unusable.
To be more generic, when the lib finds that  itCanBeRenderedIn(Right|Top|...) is false for every directions, it should throw an error, or close the walker :)

Do you have any preferences to manage those error case :
we could add an error function to every WalkPoint, or we could add the error function to an option object passed to the walk function
WalkPoint:
MaterialWalkthrough.walk([{
    target:"",
    content:"",
    color:"",
    acceptText:"",
    onSet:()=>{},
    onClose: ()=>{},
    onError: (error) => {}
}])

global options :
MaterialWalkthrough.walk([{
    target:"",
    content:"",
    color:"",
    acceptText:"",
    onSet:()=>{},
    onClose: ()=>{},
}], {
    onError: (error) => {}
})

Btw both can be added :)

@NathanGrimaud, I think it would be better to make it possible to treat errors only in global options. And in the arguments of the onError function would be passed the information of which WalkPoint the walker broke. And if the developer dont pass the onError callback, it will be nice if the library launches a console.warn to warn the user that the walker has closed by a usage error.

I just edited #47.
I removed walk specific errors, and added the walkpoint as parameter to 'global' errors :)
Now default behavior is to console.warn the user instead of using the built-in _log('ERROR', msg)

Hi @NathanGrimaud , sorry for th delay. We're a little busy in the day work but we will take a look on this.
You mentioned that:

Now default behavior is to console.warn the user instead of using the built-in_log('ERROR', msg)

I think that maybe the _log function should know when to use console.log/error/warn or the plugin could use the Browser Support of the debug package. What do you think @menosprezzi ?

Hi @oliveirafilipe @menosprezzi, have you found the way you want me to log those errors to the console ?

Yes, I talked yesterday with @menosprezzi about it. I will commit some
updates in your pull, really really soon. Maybe within 1 week
Em qui, 23 de ago de 2018 11:31, NathanGrimaud<EMAIL_ADDRESS>escreveu:

Hi @oliveirafilipe https://github.com/oliveirafilipe @menosprezzi
https://github.com/menosprezzi, have you found the way you want me to
log those errors to the console ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/essetwide/material-walkthrough/issues/46#issuecomment-415438659,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVAzeisx2KDMbrEsKl30EM0qXMA8l2URks5uTrzGgaJpZM4VS5m1
.

Great news !

Closing this issue because i created a more specific one #48


Fix TO API test failure when starting from a fresh db/admin reset

What does this PR (Pull Request) do?
This PR fixes an issue that causes the TO API tests to fail when being run against a freshly reset TODB (i.e. db/admin --env=test reset).

[x] This PR is not related to any Issue

Which Traffic Control components are affected by this PR?

TO API tests

What is the best way to verify this PR?
On master, run db/admin --env=test reset on your test environment to reset the test DB. Then run the TO API tests, and observe the test failure (type already exists).
Follow the same steps on this PR, and observe the test success.
The following criteria are ALL met by this PR

[x] This PR fixes a testing issue
[x] ^ no docs necessary
[x] ^ no changelog necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/4628/