Societal Web3 Grant Application

Project Abstract
Societal is an all-in-one DAO creation and management platform. Societal allows all types of groups or communities to build their own online, transparent, and decentralized organization. Societal bundles all of the tools required to create and manage a DAO in one place.
Utilizing Polkdaot’s layer-0 infrastructure and ecosystem, Societal will provide DAOs with both maximum functionality and a cohesive user experience. With features including agnostic token compatibility, zero gas fees, a freemium entry point, and a SaaS-based membership pricing, Societal combines best-in-class features into one vertically integrated product. With integrations into DeFi, privacy, and identity protocols, Societal will enable web3 organizations to seamlessly transition and manage their DAOs into the future.
For which grant level are you applying?

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $50,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for > $100k Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied, renamed ( project_name.md) and updated.
[x] I have read and understood the FAQs, application guidelines and announcement guidelines.
[x] A BTC or Ethereum (DAI/USDT) address for the payment of the milestones is provided inside the application.
[x] I have read and acknowledge the terms and conditions.
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted.
[ ] I prefer the discussion of this application to be in a private Element/Matrix channel. My username is: @_______

How Did You Hear About our grants program?

[ ] Social Media
[ ] Hackathon
[x] Personal Recommendation
[ ] Substrate Builders Program
[ ] Investor/VC
[ ] Online Search
[ ] Other: _______

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @semuelle, thanks for the quick response! Here are the answers to your questions:

The mockup image links don't seem to work (I get a redirect to accounts.google.com/ServiceLogin and then Bad Request), could you check those?

Here is the link to the google album. This link should be fine. I will also upload the images to github and use those new links in the updated application.

Could you list all the pallets and functions you are planning to build as part of deliverable 1.2? Deliverable specs should be verifiable, to reduce possibility of misunderstanding.

Based on the MVP that I would like to make, I believe we would need the following pallets to support all of the features: System, Support, Executive, Assets, Authority Discovery, BABE, Balances, Democracy, Elections, Referenda, GRANDPA, Indices, Membership, Multisig, Nicks, Proxy, Scheduler, Transaction Payment, Treasury
The MVP Testnet Requirements docs that lists the pallets and features we are looking to make can be found here
I did not include an initial list of pallets in the application as these are the pallets that I believe I will require from my research. However, I may be missing some pallets that need to be added later or some of these pallets may need to be removed

What do you mean by the existing governance pallet?

Sorry, I meant to say "existing governance pallets", by which I am referring to the democracy, elections, and referenda pallets.
I would like to make a pallet that allows the DAOs on the Societal platform to execute a smart contract on Moonbeam, after an approved referendum
I believe that this should be a separate a pallet, apposed to being being a modification of the democracy, elections or referenda pallets

Why do you want to charge DAOs for certain functions? Where would these funds go to? Do you already know how to implement this?

I want to charge DAOs a monthly fee as payment for advanced functions on the platform or if they have more than 10 members of their DAO.  I have created a list of different subscription tiers that the DAOs can select from, if they would like advanced functions or more than 10 users. Please note that not all of those features listed in the different tiers will be availble in the initial product and represent a future state of the application.
The funds that are collected would go to the Societal treasury, which would be used to fund future parachain slots, community approved initiatives and project operations
User transactions on the platform will be free, so the subscription model is Societal's source of revenue
In regards to implementation, to make this work I believe I would have to set transactions to zero on the Transactions Payment Pallet. Then I would have to create a separate pallet that does two things; First, it checks how many members are in the DAO via how many holders there are of the DAO token. Second, it would have to check if the DAO has made a monthly payment from one of its wallets to the Societal subscriptions wallet. Based on the answer to these questions, the UI would display certain functions to the DAO users on their dashboard.

I hope this answers your questions.

Thanks for the update, @gfox1, and sorry for the late reply. Could you put your questions into the application document? That way it'll be easier to revisit during milestone review. The list of pallets doesn't have to be exhaustive, we just need a rough understanding of what's involved in implementing this.
Lastly: making transactions free makes the chain susceptible to DDOS attacks. Have you thought about how to counter this?

Hi @semuelle, no problem at all!
Yes, I can put my list of questions into the application document.  I will put a list under each milestone. I will also put in the list of pallets in the document.
To counter act the DDOS attacks, the main methods I have thought of are:

Proposal Generation: You will only be able to create one proposal per DAO at a time. You will have to wait for your proposal to be accepted or rejected to until you can create a new proposal
Voting: You will only be able to vote on a proposal if you have the community token and only one vote for proposal
DAO creation: I have not found the best way to prevent people from creating multiple DAOs and swarming the network if there is not cost to generate them.  As well, I would like to use the Statemint parachain to create all of the assets, which I from my understanding uses DOT for transactions. So right now I believe I will have to get the user to pay for the initial DAO creation.

Until I can find the best method to do this, I believe I will have to limit the initial MVP to only allow for free transactions for proposal creation and voting. Then role out free transaction for user profile updates and DAO creation.

I will list my assumptions in the application, as well change milestone 3 to only include free proposal creation and governance voting.

Hey @semuelle, I was wondering if there was any update on this with the new information that I provided in the application? Or if you need anything else from my side?

Hey @semuelle, I just wanted to follow up here again to see if there was anything else you need from my side to have this application approved? Hope you have a good weekend!

Hey @semuelle, no problem at all. I hope you had a good time away. I am glad to hear you think the application looks good and thanks for sharing it with the rest of the team!
Here are the answers to your follow up questions:
What was this other Polkadot project you were involved in where you found the DAO tooling to be lacking?

My co-founders and I were at Ruby Protocol, prior to starting Societal. The idea for Ruby was to transition into a DAO, so while searching for DAO tooling in the ecosystem we did not find many options as compared to the Ethereum ecosystem. We did not find a good place for communities to come and create / manage their DAO, so we decided to build it.

Are you planning to reuse any code from previous/ongoing projects? Payroll, job boards, mobile applications all have come up quite often in the past.

At this time we are not looking to reuse any code.

Your whitepaper lists several possible partnerships, if I see correctly. Do you already have any ongoing partnerships or partner ship talk you can share?
Yes, I have been in communication with Moonbeam about opening an HRMP channel between our chains and they seem very interested. We just have some development work to do on our side before we are able to formally pursue this. I have also applied for grant from Acala for an AUSD integration to be the main stable coin for our DAOs.
Can you expand what functionality will be included in "governance and treasury management" in the first milestone?

For the first milestone, the treasury board will include the following details: Display information for what is kept in the DAOs wallets, who owns what percentage of the DAO (on-chain cap table) , and they will also be able to manage the DAOs multi-sig wallets. From the governance board, it will display the type of governance model they have selected for their DAO upon creation, the ability create and vote on governance proposals and keep track of the outstanding / executed proposals.

Btw. sorry for the delay here. We will try to speed this up now. A lot of the team is/was ooo for various reasons.

Hi @Noc2, no problem. Glad to hear that you like the UI!
Here are the answers to your questions:

Yes, the UI will be based on the mockups provided. We will only change the UI if at the time of development we believe that it is better to go with a different style to display all of the product features correctly. However, as of right now it will be based on the images. As for the UI language/framework, we will use React.

Yes, the UI will probably be updated with each pallet update. Ideally minor updates to allow for use of the milestone features. I can add this to the deliverables.

Yes, I have looked at the tech stack document and other governance/DAO projects in the Polkadot Ecosystem. The Societal whitepaper goes into the difference between our platform and others in the Polkadot ecosystem.    https://docsend.com/view/2gte2fd8wc4jp4rg

No problem about the delay and appreciate you speeding up the process!

@Noc2 - Thanks, great to hear it!
@gautamdhameja Thanks for approving the changes.
Let me know if there is anything else you need!

Thanks for accepting my application. Looking forward to building the Societal platform and milestones!


Bump helm chart to garnet-1.0.46

The goal of this PR is to build the helm chart via the github workflows.

closes #845


Releaser cannot merge master into release for Bloc using iceberg

Merging for the current version of Bloc the master branch into the release branch produces the following error:
[ self errorKeyNotFound: key ] in MethodDictionary(Dictionary)>>at: in Block: [ self errorKeyNotFound: key ]
MethodDictionary>>at:ifAbsent:
MethodDictionary(Dictionary)>>at:
TraitedMetaclass(Behavior)>>compiledMethodAt:
TraitedMetaclass(Behavior)>>>>
[ :each |
| aCompiledMethod |
aCompiledMethod := aClass >> each.
aCompiledMethod isFromTrait
	ifFalse: [ self addMethod: aCompiledMethod ] ] in RPackage>>importProtocol:forClass: in Block: [ :each | ...
Array(SequenceableCollection)>>do:
RPackage>>importProtocol:forClass:
[ :each | self importProtocol: each forClass: aClass ] in RPackage>>basicImportClass: in Block: [ :each | self importProtocol: each forClass: aCla...etc...
Array(SequenceableCollection)>>do:
RPackage>>basicImportClass:
RPackage>>importClass:inTag:
RPackage>>moveClass:fromPackage:toTag:
RPackageOrganizer>>systemClassRecategorizedActionFrom:
WeakMessageSend>>value:
WeakMessageSend>>cull:
WeakMessageSend>>cull:cull:
[ action cull: anAnnouncement cull: announcer ] in WeakAnnouncementSubscription>>deliver: in Block: [ action cull: anAnnouncement cull: announcer ]
BlockClosure>>on:do:
BlockClosure>>on:fork:
WeakAnnouncementSubscription>>deliver:
[ "Ensure delivery to remaining announcements" subscription deliver: anAnnouncement ] in SubscriptionRegistry>>deliver:to:startingAt: in Block: [ "Ensure delivery to remaining announcements" sub...etc...
BlockClosure>>ifCurtailed:
SubscriptionRegistry>>deliver:to:startingAt:
SubscriptionRegistry>>deliver:to:
SubscriptionRegistry>>deliver:
Announcer>>announce:
SystemAnnouncer>>announce:
SystemAnnouncer>>class:recategorizedFrom:to:

Currently this breaks the release of Gtoolkit. Seems to be caused by pharo-project/pharo#4565

Manually merge the release branch into master using another git client


Fix type annotation

Summary
Fix the annotated type of filters.
Details and comments
In qiskit.providers.providerutils, filters is used as the first argument of filter function against backends: list[Backends].
# 3. Apply acceptor filter.
backends = list(filter(filters, backends))

So the annotated type of filters must be Callable[[IBMBackend], bool] rather than Callable[[list[IBMBackend]], bool].
Note that there are exactly the same lines in qiskit_ibm_provider.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 82.299%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
6035

Relevant Lines:
7333

💛  - Coveralls


edav_wcs guidelines

Reference issue/ticket: https://github.com/MAAP-Project/maap-documentation/issues/281
Added new sections and updated the base WCS link. Also had to change the dataset since the coverage id 'test_afrisar_onera_ClopeTB10_biomass_COG' didn't seem to exist. Used ESACCI_Biomass_L4_AGB since Alex provided that as a test ID, but can also change.

I'll go ahead and recommend the Pangeo workspace, but it probably wouldn't hurt to ask JPL to upgrade their pip version. I'll go back and adjust if they do 🙂

View entire conversation on ReviewNB

Updated and I think I rebased develop into the branch?


Removed Start() call, avoing double requesting google's service

This start function call was causing a double request, and, as a consequence, 2 responses.

I can't figure out why the tests are failing.

Now I can see it failed because of the API Key, the Travis server isn't using a valid key.
How did you do to manage this @psirenny?

Thanks for pointing out the double callback problem. I've rewritten much of the code and unit tests to guard against this particular issue.
The api key was hashed in the .travis.yml. I'm not sure why it wasn't being read. At any rate, I moved the key from the file to travis settings. It appears to be working.


Bump python dependencies & add initialize capability

Codecov Report

Merging #29 (2eb662f) into main (6bed6cf) will increase coverage by 0.45%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #29      +/-   ##
==========================================
+ Coverage   76.38%   76.83%   +0.45%
==========================================
  Files           8        8
  Lines         741      734       -7
  Branches      137      135       -2
==========================================
- Hits          566      564       -2
+ Misses        148      143       -5
  Partials       27       27

Flag
Coverage Δ

python-3.10
76.56% <100.00%> (+0.45%)
:arrow_up:

python-3.8
76.56% <100.00%> (+0.45%)
:arrow_up:

python-3.9
76.56% <100.00%> (+0.45%)
:arrow_up:

unittests
76.70% <100.00%> (+0.45%)
:arrow_up:

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

Impacted Files
Coverage Δ

salt_lsp/server.py
67.02% <100.00%> (+2.66%)
:arrow_up:

salt_lsp/workspace.py
76.04% <100.00%> (ø)

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 6bed6cf...2eb662f. Read the comment docs.

I don't quite understand why it's needed. I expected that it is enough to have super().__init__(protocol_cls=SaltLspProto) in SaltServer() in order to get the overridden lsp_initialize called confused

I am not sure why it is necessary either, but if you omit the function call, then the test lsp server will not launch for the unit tests :shrug:

I don't quite understand why it's needed. I expected that it is enough to have super().__init__(protocol_cls=SaltLspProto) in SaltServer() in order to get the overridden lsp_initialize called confused

I am not sure why it is necessary either, but if you omit the function call, then the test lsp server will not launch for the unit tests shrug

I saw that as well, but something else is fishy. After checking out this branch, the initialization happens again and again

I think I understand what happens, more or less.
We register our "user" INITIALIZE feature in salt_lsp.server. This feature calls salt_lsp.workspace.SaltLspProto.lsp_initialize. That initialization routine, that's only used to replace its self.workspace with an SlsFileWorkspace instance, calls super().lsp_initialize. super().lsp_initialize is resolved to pygls.protocol.LanguageServerProtocol.lsp_initialize, which is decorated with lsp_method(INITIALIZE). Once that function is called, it goes through the call_user_func wrapper which calls the built-in feature and then the user-supplied feature. In other words, we loop around.
I'm not 100% sure on all details, e.g. why only the "user" feature is called in the first place.

Looks like I need to add a test to get a positive test coverage delta. Other than that, I think this PR is in a decent state.

@agraul I don't want to block this PR due to a coverage drop, so if you're happy with the current state, I'd merge it anyway. WDYT?

I think it's good enough to merge as it is  :+1:


Move implementation details to comment in the package

I think that they are more fit to be put inside the package itself, if a user wants to know the inner workings it can look in the files

Good idea. Anyone curious can just take a peek anyway, with this comment being a brief introduction.


Removing einops from files

What does this PR do?
Removing einops from dependencies in H3. WIP, not tested yet.

Fixes # (issue)
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you read the contributor guideline,
Pull Request section?
[ ] Was this discussed/approved via a Github issue or the forum? Please add a link
to it if that's the case.
[ ] Did you make sure to update the documentation with your changes? Here are the
documentation guidelines, and
here are tips on formatting docstrings.
[ ] Did you write any new necessary tests?

Who can review?
Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

Thanks a lot! 🙏


AMLSettingsJsonString - blacklist_algos

I'm not sure if this is the right place to bring this up.
I noticed in the JSON for a AutoML run one of the variables is blacklist_algos. I've noticed a trend recently to avoid negative connotation in computer science (the biggest one being renaming master to main). A better term for blacklist_algos could be deny_algos?
Welcome to pass on to the developers or point me there.
Thanks
"AMLSettingsJsonString": "{"enable_early_stopping":true,"enable_ensembling":true,"enable_stack_ensembling":true,"ensemble_iterations":15,"enable_onnx_compatible_models":false,"max_cores_per_iteration":-1,"send_telemetry":true,"blacklist_algos":["ElasticNet",...

Thanks for calling this out!
I believe this is already being addressed in an upcoming update to the SDK


.env file QUEUE_DRIVER & etc

Checkout changelog there is upgrade for:
QUEUE_DRIVER -> QUEUE_CONNECTION
APP_LOG_LEVEL -> REMOVED
Maybe It's better to take an .env.example and work on it, rather than put your including APP_KEY, even if resets later.

@elnurxf - Fixed. Thank you.

@elnurxf - Fixed. Thank you.

Sorry, but what do you mean by fixed ?
https://github.com/rashidlaasri/LaravelInstaller/blob/3dec1d54669959a5bd46f0cdde22e3e8c0a59836/src/Helpers/EnvironmentManager.php#L102


Using Soft Assertion in WDIO

Hi,
Can anyone suggest, how to use soft assert in WDIO.
My scenario is I am validating around 50 fields, if the 5th field doesn't match WDIO is skipping other and proceeding with other scenario.
But I need that step to fail and continue to next step. This can achieved in Selenium with Java but I am not sure In Type script.
It would be great if someone support.
Thanks in advance.

Duplicate of https://github.com/webdriverio/expect-webdriverio/issues/227


Core signal concerns (globals, auto/implicit tracking, async)

Concerns
I don't know if this is an appropriate place to start this discussion, but I've had some concerns about signals for a while now.
I've worked on some statemanagement systems in the past myself, and independently came up with something similar to signals.
Then when I found out that signals already exist and are semi-standardized, I got quite excited. However, there are 3 major caveats I see with signals that I don't like:

They rely on global state
Dependency tracking is implicit
Computed values require synchronous code

Reliance on globals
In order for computed values to be aware of their dependencies, dependencies have to communicate their presence to computed values. The approach I have seen taken by several libraries to achieve this, is the following:
Before evaluating a computed value, it tells some global entity G that it will evaluate. Then the computed value computes and accesses a signal S, during wich S informs G of the access. In turn, G can let the computed value know that it apparently depends on S.
This approach relies on globals, and without special runtime language features, I don't think one can do much better than this approach with the current form factor of signals. The reliance on globals hurts interoptability of different libraries however, similar to the problem that was faced by React hooks.
I don't know how this problem was solved in React (because I believe it is now?) so it might be solveable. Additionally if this becomes a core part of JavaScript itself, it might not be an issue to begin with. But I wanted to express my doubts on this either way.
Implicit dependency tracking
Dependency tracking is implicit in signals. This means that when looking at the code for computed values, you can not directly see which of the dependencies can cause recomputations. Now you might argue that you don't have to see it, that it's not relevant, but I think it can be for several reasons:

New users: For new users to learn the system and get introduced to signals, the current approach does barely even hint at computed signals recomputing automatically when data changes, making it harder to understand what's going on and properly work with the system without introducing bugs.
Spotting mistakes: It is easy to read values of signals in an environment where automatic re-evaluation doesn't occur, without even being aware of this.
Opting out of tracking: In certain scenarios you might want to access the value of a signal in a computed value, without actually registering it as a dependency. This is probably rare, but it is possible that you just want to have access to the value at that moment in time and nothing more.

I like the system that async/await introduces more. Here an explicit 'await' keyword exists, that makes awaiting data explicit. Similarly a 'watch' keyword could exist for computed values, that makes dependency tracking explicit. For async/await it was decided that having an explicit await keyword was beneficial, even though this could also have been implicit. I don't know what the reasons for this choice were, if it was for technical reasons or usage reasons, but either way I believe this to have been the better choice.
Requiring synchronous code
One thing that seems to be lacking from most signal libraries/systems, is asynchronous computations. There may be several reasons for this, potentially including hydration and server side rendering concerns, but besides this the current way of dependency tracking also limits potential async implementations. Ideally, I would want to be able to write something like this:
const somethingLoadable: Signal<number> = AsyncComputed(()=>{
  const val = someDependency.get();
  const newVal = val*2;
  return new Promise(res=>setTimeout(()=>res(newVal)), 1000); // Dummy delay promise
}, 0);

This would result in a signal that has a default value of 0, and when accessed would perform the computation but without updating its value yet since the computation does not finish synchronously, updating its value and signalling it only afterwards when the computation finishes.
I believe there can be a very nice interplay between asynchronous computations and signals in this way, symplifying how asynchronous computations are used in defining state. The current norm for dependency tracking however falls apart in this use case. If a value is accessed after some delay, the global entity orchestrating the whole process no longer knows what computed value to add the dependency to. This for instance would happen in the following code:
AsyncComputed(async ()=>{
  const someNumber = await getSomeNumber();
  return someNumber * someDependency.get();
});

Personal ideas
So let me first mention that I'm aware I'm not as deep into this material as the people working on this repository are, but because I've worked on my own system for a while and have thought about some of these tradeoffs, I did think it was worth reaching out.
All of the issues above were solved in my own system by a simple 'change' (this is actually just how I designed it before I learned about signals) of the interface of computed values. In my system I work with a 2 phase notification, which I believe is similar to what many signal libraries do, where I first mark dependents as dirty before dispatching a change event. As such my signals (which I call "watchables" in my system) have the following interface:
/**
 * A watchable value type
 *
 * Invariants for every watchable `w`:
 * 1.  Notifies: if for `const v1 = w.get()` and `const v2 = w.get()` with `v1` obtained before `v2` we have `v1 != v2`, then `w` must have dispatched `w.change` events before `v2` could have been obtained
 * 2.  NoRedundantEvents: Between any two `w.get()` calls, at most a single `w.dirty` (or symmetrically `w.change`) event is dispatched
 * 3.  DirtyBeforeChange: When `w.change` is dispatched between two `w.get()` calls, `w.change` is always preceded by `w.dirty`: `w.get() ⋅ w.dirty ⋅ w.change ⋅ w.get()`
 */
export interface IWatchable<X> {
    /**
     * The current value
     * @returns The current value of the watchable
     */
    get(): X;
    /**
     * A function to register listeners for value dirtying, returns the unsubscribe function
     * @param listener The listener to be invoked
     * @returns A function that can be used to remove the listener
     */
    onDirty(listener: IRunnable): IRunnable;
    /**
     * A function to register listeners for value changes, returns the unsubscribe function
     * @param listener The listener to be invoked
     * @returns A function that can be used to remove the listener
     */
    onChange(listener: IRunnable): IRunnable;
}
export type IRunnable = () => void;

Then, computed values (which I call derived values) are defined using explicit dependency tracking.  Consider for example the following fragment:
const val1: IWatchable<number>;
const val2: IWatchable<number>;
const derived = new Derived(watch=>{
  return watch(val1) * watch(val2);
});

Here the watch function both calls the get of the watchable, and registers the watchable as a dependency of the derived value. As a result, this system does not rely on globals, allows users to choose whether to actively watch dependencies, and can deal with asynchronous computations.
In my own system I go a bit further and also attach metadata to watchables that allow for automatic tracking of additional data like whether the derived value depends on any data that's still loading. But this is probably outside the scope of a standard JavaScript primitive.

the global entity orchestrating the whole process no longer knows what computed value to add the dependency to.

imo, this is a feature, not a bug or design flaw -- you need some way to choose what signals to entangle with.
As in: https://github.com/NullVoxPopuli/signal-utils/
import { Signal } from 'signal-polyfill';
import { signalFunction } from 'signal-utils/async-function';

const url = new Signal.State('...');
const signalResponse = signalFunction(async () => {
  const response = await fetch(url.get()); // entangles with `url`
  // after an away, you've detatched from the signal-auto-tracking
  return response.json();
});

// output: true
// after the fetch finishes
// output: false
<template>
  <output>{{signalResponse.isLoading}}</output>
</template>

This is implemented via an impure Computed:
const state = new State(fn);
const computed = new Signal.Computed(() => {
  state.retry();

  return state;
});

If we always tracked any signal accessed within an async function, we'd more easily have infinite loops -- as any Signal accessed within state would entangle with along with url changes -- which would make loading state (or any async state) much harder to handle.

return watch(val1) * watch(val2);

This is an interesting idea, and would indeed be very explicit about what's happening.
However, it "feels like" (to me, I could be wrong! and please correct me if I am), that we'd lose autotracking, and the transparent abstractions we can achieve by hiding the underlying Signal API -- for example, app-devs consuming a Signals (as designed today), may not even know they have reactive data! and things would just work! :tada: (provided folks using destructuring in their component renderers do not do so too eagerly -- this is a DevEx thing being explored in frameworks that use functions as components / computeds / async computeds).
For example, if I'm a library author, and I implement a reactive array, such as: https://github.com/NullVoxPopuli/signal-utils/tree/main?tab=readme-ov-file#array, and then pass it to you, you could mutate the array with and my library could just reactive update without you having any knowledge of reactivity -- it behaves just like a native array :tada:

Requiring synchronous code

I believe AsyncContext would make it possible to have Computeds with async callbacks "just work", but I think that should wait until that proposal is (at least) Stage 3.

imo, this is a feature, not a bug or design flaw -- you need some way to choose what signals to entangle with

I'm sorry, but I don't quite follow this statement. Would it not be nicer if after an await, it would still track the following dependencies? Consider for example the following code:
const signalResponse = signalFunction(async () => {
  const response = await fetch(url.get()); // entangles with `url`
  const json = await response.json();
  return json.someField * someSignal.get(); // Should entangle with `someSignal`?
});

Would the current signal implementations throw an error here when accessing someSignal? I don't think so right? Because signal values should also be accessible outside of contexts that register dependencies. So in that case, a developer is likely to think that their computed signalResponse will also update when someSignal changes, but it in fact does not.
Again, I don't have enough experience with signals to know this for sure, so you should correct my train of thought if it's wrong, but to me this seems a bit error prone?

we'd lose autotracking, and the transparent abstractions we can achieve by hiding the underlying Signal API

That is indeed correct. I don't think my own system is flawless either, there's just different tradeoffs to consider. These considerations become especially important when making something a real part of the language, which is why I thought I should mention it. I personally have my doubts whether this should be part of the language, but there are already different issues regarding that topic so I won't make any further mention of that here.

provided folks using destructuring in their component renderers do not do so too eagerly

This is actually where my concern lies. A fully automatic transparent system is really nice, if it indeed is fully transparent. However when there are caveats to consider I prefer non-transparent systems and forcing developers to be aware of what they are doing. I am not aware of how many caveats there are with the implicit system, so it might not be that bad, but this is at least part of where my concern comes from.

@TarVK I share your concerns! And I find your personal ideas very interesting!
They are actually quite similar to what we have in VS Code:
https://github.com/microsoft/vscode/blob/5ccc2db0a2ed24e8c0dc3ecd7d515e4f76c87e69/src/vs/base/common/observableInternal/base.ts#L22-L88
Your interface is much simpler, but I wonder how you would support transactions (i.e. updating two source observables at once).

Good to hear I'm not the only one with these concerns @hediet 🙂
Seems like VS code observables (at least on a high-level) function the same as the one in my project, which is nice to see!
I chose a slightly different interface, to be more similar to async/await syntax, but they seem to function similarly.
The transactions have also been a concern of mine. I see VS code used:
transaction((tx) => {
  observable1.set(6, tx);
  ...
  observable2.set(4, tx);
});

I also considered the interface you chose here, but eventually settled on something different. The main concern here (which you are probably aware of) is that it becomes difficult to abstract this over functions. E.g. if I write some function:
function calculateAndUpdate(tx: ISomeTransactionType) {
  const value = ...; // Compute the value according to some logic
  observable1.set(value , tx);
}

I now have to add this extra parameter in the signature in order to be able to use it in transactions. I have not found a great solution to this problem myself, but ended up creating a "mutation" type that is returned from updating fields:
function doSomething(): IMutator {
  const value = ...; // Compute the value according to some logic
  return myField.set(value);
}
function doSomething2(): IMutator {
  return synchronized(myField2.set(25), doSomething());
}

The idea is that mutations can be combined, and no reusable function should commit the mutations but should instead return them. Only event handlers would actually commit the final created mutations. Here is a gist of a planning document I wrote in the past, which contains this concept: watchables updating-multiple-fields-without-invalid-states . The main benefit of my approach is that no parameters/types have to be added to function signatures syntactically.
With my approach it however becomes harder to enforce functions to support transactions, which I think would be slightly easier in VS code's approach by restricting how transactions can be obtained while making them required parameters for setters. In addition to this, my approach has a large risk of users forgetting to call commit, resulting in bugs. I believe the issues in my approach could be mitigated with linters, but this is not ideal. I currently don't have a strong preference for either the mutator or parameter approach, either approach seems to be lacking in my opinion.
It would be nice to hear more opinions on this issue, so I might be able to improve my own system in the future!

I share your concerns, but primarily #.2 I am on the side of "be explicit" (if a value on the explicit list changes then the function runs; end of story - no edgecases)
I do think the proposal should stay as small as possible, so instead of solving the whole async problem, I'm curious what you think about having a warning system to limit the damage of implicit dependencies (which I don't like very much but I think its more likely to get accepted).
Discussion: Runtime Warnings for Autotrack
I think the biggest footgun of this proposal is using an external value like Math.random() in a conditional that then breaks auto-tracking of dependencies. The silver lining is that its often possible to detect this kind of usage. For example:
new Signal.Computed(()=>{
    if (Math.random() > 0.5) {
        return person1Name.get()
    } else {
        return person2Name.get()
    }
})

Warnings can be done performantly by checking for a sequence-change in signals.
If person1Name was used on the first run. Then person2Name on the second run, thats a warning because the only way the first evaluated signal can change is if external value is being used as a conditional.
While deeper values are more difficult. Ex:
new Signal.Computed(()=>{
    if (randomViewEnabled.get()) {
        if (Math.random()>0.5) {
            return person1Name.get()
        } else {
            return person2Name.get()
        }
    }
})

Its still possible to check "if the value of the first signal value did not change, then the subsequent signal should always be checked next". E.g. if randomViewEnabled stays true, but person2Name is evaled the first time, and person1Name is evaled the next time, then that is also a warning.
If warnings like this were extremely robust, I think it would massively reduce the foot-gun damage.
But I'm curious how you feel @TarVK (if this would address your # 2 or not)

And in support of your concerns:
Its incredibly useful to say "this computed didnt run, therefore the signals on this explict list have not changed" WITHOUT looking at the contents of the function or the values of stuff like Math.random().

I can see adding some mechanism to Signal.Computed to opt into manual dependencies. But I can't see removing auto-tracking.

(^ From a different thread)

While performance scenarios can be crafted favoring autotracked or explicit, I think explicit dependencies are faster in many cases. And yes, performance isnt everything, but we are talking about a native API. The API should at minimum have verbose/clunky option that allows for maximum performance of frequent scenarios.
I think auto-track could be a WONDERFUL warning system when combined with explicit dependencies. E.g. if using a signal, but its not in the explicit tracking list, print a warning by default if the autotracked finds it. Require clunky API for disabling the warnings.
Sometimes I intentionally don't want to track a value. Ex: I want to use the most up to date C value if value A or B change, but otherwise I don't want value C busting the cache for an expensive computation. Its confusing to have a computed listener that just saves the value in a non-signal var just so that another computed value will bypass the auto-dependency detection.
I don't think there's a good way to do async without explicit dependencies.

I'm not sure I fully understand the following statement, could you elaborate:

this computed didnt run, therefore the signals on this explict list have not changed

I do think that the warning system you propose, especially using auto tracking for warnings combined with explicit dependency tracking, could be very neat. In the explicit tracking system you may forget to watch a value and in the auto tracking system you may be unaware of whether a value will be reactive or not. So in either case, such a runtime warning system during development could be very valuable!
It does not fully address my concerns though. It's kind of hard to put my concerns into words I suppose, because it's more of a general scepticism of the "unknown". I already know that there are caveats with autotracking, e.g. regarding asynchronous computations. So my stance is more based on being unaware of what other major caveats one might run into (since I don't have enough experience using signals myself), and not knowing how these things will affect new developers. In this case, I prefer a system with a clunkier interface that is more predictable (if I told the system to watch a dependency it will be tracked and otherwise it will not be, end of story). So I do think your suggestion is very nice and addresses one of the known caveats of signals, but it does not address my broader concern related to auto dependency tracking.

I'm not sure I fully understand the following statement, could you elaborate:

this computed didnt run, therefore the signals on this explict list have not changed

Yeah so, if we have explicit tracking like an array of what to watch:
new Signal.Computed([person1Name, person2Name], ()=>{
   console.log("ran")
   if (randomViewEnabled.get()) {
       if (Math.random()>0.5) {
           return person1Name.get()
       } else {
           return person2Name.get()
       }
   }
})

If there's no "ran" printed, then that means, for sure, that person1Name and person2Name have not changed. We don't even need to know what the contents of the function are.

It's kind of hard to put my concerns into words I suppose, because it's more of a general scepticism of the "unknown".

That helps. I should word my question  a different way though; If there were only these three choices, which would you pick

add signals api as-proposed
add signals with warnings system
no change (reject proposal)

Definitely. So, if we have explicit tracking like an array of what to watch:

Ember used to have computeds like this, and they were slower and more memory-intensive than auto-tracking.
We found (and adapting to the proposal, for demonstration) that this would be a more efficient on memory:
new Signal.Computed(()=>{
   console.log("ran")
   if (randomViewEnabled.get()) {
       let name1 = person1Name.get();
       let name2 = person2Name.get();

       if (Math.random() > 0.5) {
           return name1;
       }

       return name2;
   }
})

and still give you correct behavior with less cpu/memory resource consumption.

less references / book-keeping in the computed
autotracking still is entangled with person1Name and person2Name

Tho, we've found that using a getter / function is faster than managing a cache for something this small:
// no cache present, "just works"
get randomName() {
   if (randomViewEnabled.get()) {
       let name1 = person1Name.get();
       let name2 = person2Name.get();

       if (Math.random() > 0.5) {
           return name1;
       }

       return name2;
   }
}

as for smaller derived values, there is often the tradeoff of "how much does it take to maintain a cache vs just access the values" - where cache is always going to increase memory consumption, no matter how you do it.
Now, that said, we do still need to have some benchmarking done on this implementation in the proposal, as the results could be different!
Just my 2 cents from one corner of JS <3
I know we have some competing experiences with whether or not explicit deps is faster or not (due to being in different ecosystems / environments), so I think the sooner we can formally test it out, the better!

I do think its a bit unfair to heavily imply "slower", and then kinda backpedal on "smaller derived values" and benchmarking. At the theory level, static is faster for any non-conditional computed values (sorts, hashes, math, substrings, etc). I don't know if that makes up the majority of in-the-wild computed values or not, but I do know its a frequent usecase.
But, its the other case, the has-conditional case, that I find incredible irony with: My prof once said "There is an algorithm that can compute, for any problem(!), the answer in O(1). The downside is the answer is wrong ... but still O(1)!". I would say it looks pretty bad to talk about auto-dependency tracking being faster for the first or second example I gave when the behavior is wrong for both of them.
So speedy that new and senior devs alike shoot themself in the foot without even noticing, is not really an argument in-support-of auto dependency tracking. (Keep the gun, just inform people when its pointing at their foot.)

think the sooner we can formally test it out, the better!

I agree, we can let good benchmarks decide speed, but let the (lack of) footguns decide the API

One reason why an explicit list of dependencies might be "slower" is that it wouldn't cater to conditional computeds.
Example:
new Signal.Computed([nameSelector, person1Name, person2Name], ()=>{    console.log("ran")    if (nameSelector.get())       return person1Name.get();    else       return person2Name.get(); })
If nameSelector currently returns true, so the computed returns person1Name, this computed would be re-evaluated whenever person2Name changes, which in its current state is irrelevant.
Auto-tracking would only capture nameSelector and the current name being used, at all times, which are the only changes that should result in re-evaluation.
It wouldn't be hard to consider other examples where more code would be involved which could result in more cpu cycles burning, for no reason.

Right I see @jeff-hykin then we were not fully on the same page.
I personally am in favor of explciit dependency tracking in the form I mentioned at the end of my report, something like:
const derived = Signal.Computed(watch=>{
  return watch(val1) * watch(val2);
});

Or using an interface more similar to that of vs-code observables:
const derived = Signal.Computed(reader=>{
  return val1.get(reader) * val2.get(reader);
});

Most of the benefits you mentioned are lost here, with my approach one:

Needs to check the function body for dependencies (though they are somewhat highlighted)
Gets no performance gains, dependencies are tracked per run

On the other hand it does have the benefits:

Allowing for conditional dependencies
Not requiring users to "duplicate" dependencies in two places

And we keep the shared benefits that both of us mentioned of:

Allowing one to opt-in to watching a depndency or not
Knowing for sure whether a given dependency is tracked or not by looking at the function call rather than the implementation of the dependency
Allowing for async computations to work smoothly

As for your question of the 3 options. As mentioned before I personally think this proposal should be rejected. I think that's outside the scope of this debate, but I will mention my reasons briefly:

There seem to be many stances on how a primitive like this should work, not a clear consensus. We already saw 4 approaches in this short thread
Since no syntax is attached to the proposal, a consensus on a standard (within specific contexts) can be reached without making it official part of the language
Making it official part of the language will probably slow down experimentation with these types of primitives, since any other implementation will then have to compete with an official language feature for adoption

So taking that choice out of the question, would I prefer adding signals as proposed vs adding signals with a warning system? I definitely would prefer having one with a warning system.

Thanks for all the clarifications @TarVK . I think you covered pretty much everything. I also would reject, but originally I would have for different reasons. I would definitely pefer your method over the proposal, but proabably still reject because I think javascript has enough footguns, and signal-based footguns the only ones senior college grads email me about.
Your reasons for rejection are strong points I hadn't considered. Especially because they're kind of beyond the relm of personal preferences. And on that note, I don't think any of our ideas pass those criticisms.
I'll leave this summary for others visiting (correct me if something looks wrong)

original method

not clunky
doesn't work with async
predicting control flow requires knowing deep function contents, runtime state, and shallow function contents
doesn't have a missed-deps footgun (for the synchonous case)
tracks everything (no ability to not-track)
has the external-conditional footgun, which can be partially mitigated with a warning system
computed values without conditionals are likely slower than static list approach
computed values with signals in the conditional body are likely faster that static list approach

dynamic explicit list (@TarVK )

not clunky
works with async
predicting control flow requires knowing shallow function contents and runtime state, but not deep function context
has ability to intentionally not-track
has a different kind of missed-deps footgun, but can be fully mitigated with a warning system
has the external-conditional footgun, but can be partially mitigated with a warning system
computed values without conditionals are likely slower than static list approach
computed values with signals in the conditional body are likely faster that static list approach

static explicit list (@ me)

clunky
works with async
predicting control flow requires the static list, but not shallow function contents, runtime state, or deep function contents
has ability to intentionally not-track
has a missed-deps footgun, but can be fully mitigated with a warning system
doesn't have a external-conditional footgun
computed values without conditionals are likely faster than dynamic approach
computed values with signals in the conditional body are likely slower that then dynamic approach

How would an invoker "explicitly read" the signals accessed in something like a natively-called generator function?
    public *[Symbol.iterator]() {
        for (const signal of this.internalSignals) {
            yield signal.get();
        }
    }

@DavidANeil I think that for any explicit system, one makes the distinction between raw return values and "trackable" values. In my implementation those trackable values are IWatchables, in VS-code those are IObservables, etc. This item contains the actual value that we are interested in, as well as an interface that allows to set up the tracking concerns.
Any function (in this case iterator) should return a trackable value rather than a raw value. Then from within the context of the invoker, both the tracking concerns can be set up and the value can be extracted (in the watchables case using watch).
For the static list of dependencies approach, I'm not entirely sure how one would deal with a changing list of trackable items. When the list is constant (even if obtained from a generator) I see no problem.

@DavidANeil for implicit reads, I would actually have strong doubts if fields accesses in generator functions are (or rather can be) tracked correctly anyway.

For the static list of dependencies approach, I'm not entirely sure how one would deal with a changing list of trackable items. When the list is constant (even if obtained from a generator) I see no problem.

This is a good point, it could a more refined version of something like:
let comp1 = Signal.Dynamic([sig1, sig2], (triggers)=>{
    // triggers is just [sig, sig2]
    triggers.push(sig3)
})

// alternative
comp1.triggers.push(sig3)

// another alternative
let triggers = [sig1, sig2]
let comp2 = Signal.Dynamic(triggers, ()=>{
    triggers.push(sig3)
})
triggers.push(sig4)

@TarVK Is your library opensource? It sounds nice, I'd be keen to have a play with it.


The serial gives me:
[0]Job BAD,Too high starting difficulty: Share #1 0:00:09
and
[0]Job BAD,Incorrect result: Share #2 0:00:12
How can I solve this?

I'm using DuinoCoin_Tiny_Slave

With one ATTiny85 it gives Job GOOD... with 2 ATTiny it give Job BAD

And it's normal that i cannot see the attiny in duino coin wallet with other miners?


Add permission in plugin-redis-fingerprint-storage.yml

Description

Add @afalko for upload permission to artifactory.
repo: https://github.com/stellargo/redis-fingerprint-storage-plugin
hosting: https://issues.jenkins-ci.org/browse/HOSTING-964
Submitter checklist for changing permissions

Always

[x] Add link to plugin/component Git repository in description above

For a newly hosted plugin only

[x] Add link to resolved HOSTING issue in description above

For a new permissions file only

[ ] Make sure the file is created in permissions/ directory
[ ] artifactId (pom.xml) is used for name (permissions YAML file).
[ ] groupId / artifactId (pom.xml) are correctly represented in path (permissions YAML file)
[ ] Check that the file is named plugin-${artifactId}.yml for plugins

When adding new uploaders (this includes newly created permissions files)

[x] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[x] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[x] Make sure to @mention the users being added so their GitHub account names are known if they require GitHub merge access (see below).
[ ] All newly added users have logged in to Artifactory at least once

Reviewer checklist (not for requesters!)

[ ] Check this if newly added person also needs to be given merge permission to the GitHub repo (please @ the people/person with their GitHub username in this issue as well). If needed, it can be done using an IRC Bot command
[ ] Check that the $pluginId Developers team has Admin permissions while granting the access.
[ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
[ ] If security contacts are changed (this includes add/remove), ping the security officer (currently @daniel-beck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it

@afalko needs to login to Artifactory once before we land it

User name not known to Artifactory: ma3oxuct


Make ContextManager public

Signed-off-by: David Powers<EMAIL_ADDRESS>Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] New functionality includes testing.
[ ] New functionality has been documented.

[ ] New functionality has javadoc added

[ ] Commits are signed with a real name per the DCO

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

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

@@          Coverage Diff           @@
##             1.3    #1429   +/-   ##
======================================
  Coverage       ?   93.87%
  Complexity     ?     1100
======================================
  Files          ?      153
  Lines          ?     3067
  Branches       ?      255
======================================
  Hits           ?     2879
  Misses         ?      138
  Partials       ?       50

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 33ca7a2...ac7d14b. Read the comment docs.


The display of trusses and lamps cannot be seen in the 3D view under Win11

Duplicate of
https://www.qlcplus.org/forum/viewtopic.php?t=16496
https://www.qlcplus.org/forum/viewtopic.php?t=16585

If I want to debug 3d rendering for intel graphics, do you have any suggestions, since most laptops still have intel graphics?

The only way to debug is to build from sources, understand the code, understand the GLSL shaders, use proper tools like RenderDoc and eventually fix the specific case.


please add example using other library

first, thanks for making interesting framework..
can you please add example using another framework?
since tornadoweb need different library with standard python like burkva instead of redis..
does it keep application asynchronous when using standard library?

really looking forward to the betterment of this framework. looking for some tutorials related to this project :)

Thanks! I'm working it now and will release a new version soon.


fix git clone url

Thanks for this great plugin! I found a minor error in the installation instructions. It's an easy spot for experienced coders, I'm sure, but I'm submitting a change request in case it helps neophytes like me. Thanks again for sharing this plugin! It's really helped with some of our organizational workflows.

Thanks! @theopen-institute! Sorry about that!


Support for .erb files

In sprockets if you place assets/javascript/client/pay.html.erb  and assets/javascript/client/pay.js.erb both will be compiled and placed in assets folder as client/pay.html and client/pay.js . Is there a way to replicate this behaviour in propshaft?

Unfortunately no. Propshaft by design does not do transpiling/compiling (coffee to js, scss to css, etc). You need extra gems like cssbundling-rails and jsbundling-rails for that. Currently I’m not aware of any gems that handle erb files.

Feel free to keep comenting, but I’m closing this since it is not an issue.


resolves #1472; resolve 3d editor reverting to Move

makes modifier keys modify modify mode only temporarily until all modifier keys are released
when any modifiers have changed but no modifiers are pressed, the default modify mode is restored.
default modify mode is also applied when restoring state from persistent storage

lgtm


NUGET-package: Strict reference to Microsoft.AspNet.WebApi v5.1.2

Got an issue adding WebApi.Hal to a project due to a very strict reference to WebApi version 5.1.2 (had 5.2.3 installed). From the .nuspec-file:
<dependencies>
     <dependency id="Microsoft.AspNet.WebApi" version="5.1.2" />
</dependencies>

Worked around it by first removing Microsoft.AspNet.WebApi and everything referencing it, then installed WebApi.Hal, and lastly reinstalled and upgraded everything referenced in the first place.
Loosening up the restrictions could possibly be helpful for others, can this be done?

closing stale issue


Modify event API response format for frontend design spec

Types of changes

[x] Bugfix
[ ] New feature
[ ] Refactoring
[ ] Breaking change (any change that would cause existing functionality to not work as expected)
[ ] Documentation Update
[ ] Other (please describe)

Description
The event API response format is defined based on the 2020 website since the frontend design of the 2021 website was WIP at the time, which does not perfectly meet the new spec.

Set the value of speaker profile URL to be an empty string if ID (including GitHub ID or Twitter ID) is not given.
Return the full URL of the speaker thumbnail (e.g. <host>/media/XXX.jpg) rather than just the path (e.g. /media/XXX.jpg).
Add/remove the fields to/from the response to meet the design spec.

API Response Format
Talk List

Current

[{
    "id": Number,
    "title": String,
    "category": String,
    "labels": String, // unused, always empty
    "speakers": [
        {
            "name": String,
            "facebook_profile_url": URL,
            "github_profile_url": URL,
            "twitter_profile_url": URL,
            "thumbnail_url": String (incomplete URL)
        },
        ...
    ],
}, ...]

Modified Version

[{
    "id": Number,
    "title": String,
    "category": String,
    "speakers": [
        {
            "name": String,
            "facebook_profile_url": URL,
            "github_profile_url": URL,
            "twitter_profile_url": URL,
            "thumbnail_url": URL
        },
        ...
    ]
}, ...]

Talk Detail

Current

{
    "abstract": String,
    "category": String,
    "detailed_description": String,
    "language": String,
    "python_level": String,
    "recording_policy": Boolean,
    "slide_link": URL,
    "slido_embed_link": URL,
    "speakers": [
        {
            "facebook_profile_url": URL,
            "github_profile_url": URL,
            "name": String,
            "thumbnail_url": String (incomplete URL),
            "twitter_profile_url": Path
        },
        ...
    ],
    "title": String
}

Modified Version

{
    "proposal": {
        "title": String,
        "category": String,
        "language": String,
        "python_level": String,
        "recording_policy": Boolean,
        "abstract": String,
        "detailed_description": String,
        "slide_link": URL,
        "slido_embed_link": URL,
        "speakers": [
            {
                "thumbnail_url": URL,
                "name": String,
                "github_profile_url": URL,
                "twitter_profile_url": URL,
                "facebook_profile_url": URL,
                "bio": String
            },
            ...
        ]
    },
    "begin_time": Datetime,
    "end_time": Datetime,
    "is_remote": Boolean,
    "location": String
}

More Information
This PR is still WIP (currently finalizing FE design spec of talk/tutorial pages)

Codecov Report

Merging #1032 (35cb560) into master (67809a5) will decrease coverage by 0.31%.
The diff coverage is 41.66%.

@@            Coverage Diff             @@
##           master    #1032      +/-   ##
==========================================
- Coverage   70.55%   70.23%   -0.32%
==========================================
  Files          90       90
  Lines        3349     3377      +28
==========================================
+ Hits         2363     2372       +9
- Misses        986     1005      +19

Impacted Files
Coverage Δ

src/users/models.py
87.03% <0.00%> (-3.35%)
:arrow_down:

src/events/api/serializers.py
77.21% <44.00%> (-12.79%)
:arrow_down:

src/events/api/views.py
75.86% <57.14%> (-3.39%)
:arrow_down:

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 67809a5...35cb560. Read the comment docs.


Lateral Water Hazard preset adds natural=water to ways

The Lateral Water Hazard preset adds natural=water to ways. It should only add it to areas, so there needs to be a separate version for “line” geometry.
/cc @bhousel @MateoV

I agree - per wiki, looks like golf=water_hazard and golf=lateral_water_hazard both work this way.


change object streams into text stream

Problem Description
Hi
i have a big data results that make me to recieve results by stream mode
but when i pipe stream to server response i get 'first argument must be a string or Buffer' error that mades by type of stream
now my question
is there any way to change the type of node oeacle given streams to text stream that able to pipe to server response ?
thank you
Code Example
dbi.getConnection(c.dbConfig, function (err, connection) {
            if (err) {
                done(err);
                log.error(config.e[1], err);
            } else {
                var stream = connection.query(input.query, [], {streamResults: true});
                stream.pipe(response)
            }
        });

Error Stack/Info (if any)

The stream output is basically a 'row' object with field and value for each column.
for example
{
  name: 'my name',
  age: 25
}

I'm not sure exactly how you would like to transform that object into string, but you do know that you can do pipe my output to your stream that will format it to string however you want and than pipe that to the response object you have there which expects strings.


Unstable z-direction pose estimation

Hi, @TixiaoShan
I have been testing this system in various scenarios such as a daily crowded street. But I found out there may be large offsets mainly along the z-direction of the final pose. I thought it would be surf-optimization problems. So I tried changing the amount of /flat feature points which are on the ground, decreasing the threshold of converging, or increasing the number of iterations during /Odom and /mapping(sometimes it won't converge within the iterations). They didn't work out well.
I'm not saying this system has such problems. Maybe it is due to my data and scenes. All I need is some advice on enhancing the stability of pose estimation in the z-direction. How to improve it? Could you please give me some comments on this?
Some examples:

Looking forward to your help
THANKS

Are you using IMU with the lidar? Both LOAM and LeGO-LOAM uses IMU roll and pitch data to correct the final pose. If the IMU is not mounted in ROS standard or not aligned with lidar, it will cause significant drift.

No, @TixiaoShan
Laser points are the only input.

@YangSiri
How is your lidar mounted?

Actually no, @TixiaoShan
My VLP-16 is normally horizontally mounted above ground at around 1m. For my data, A-LOAM perferms not better. So you strongly recommand using the IMU to solve this kind of problem?

Point cloud from lidar is always skewed (or distorted). Since you are not using an IMU, the point cloud deskew is not perfectly done in all the methods. Using skewed point cloud for odometry estimation will eventually cause a large drift. That's why all the methods recommend using an IMU for point cloud deskew and transformation initial guess.
Did you try LIO-mapping? It's a more recent and tightly coupled method but it requires an IMU.

Yes, @TixiaoShan
Thank you for your help. I will think more about what you said. I think lio depends even more on the IMU.

Yes, @TixiaoShan
Thank you for your help. I will think more about what you said. But why does it only happens at z-direction? I'm still confused.
Yes, I think LIO depends even more on the IMU.

According to my own experience, the more drift along Z is caused by the sensor itself. It only has 16 channels along Z direction. Compared with the 1800 horizontal measurements, 16 is too small!

Yeah, @TixiaoShan
That's an interesting explanation.lol Thank you very much!

@YangSiri
Another "hacking" method just comes to my mind to fix the z drift problem if you use LeGO-LOAM for your own pose estimation tasks. However, this is only suitable if the robot only drives in a relatively flat area.
You can add these lines to the [transformUpdate()](https://github.com/RobustFieldAutonomyLab/LeGO-LOAM/blob/38f087c06b8832c49760d0de54ce74321f5bcc3f/LeGO-LOAM/src/mapOptmization.cpp#L458) function in mapOptimization.cpp. These lines will constraint the final system transformation.
// pitch
        if (transformTobeMapped[0] < -rotation_tollerance)
            transformTobeMapped[0] = -rotation_tollerance;
        if (transformTobeMapped[0] > rotation_tollerance)
            transformTobeMapped[0] = rotation_tollerance;
// roll
        if (transformTobeMapped[2] < -rotation_tollerance)
            transformTobeMapped[2] = -rotation_tollerance;
        if (transformTobeMapped[2] > rotation_tollerance)
            transformTobeMapped[2] = rotation_tollerance;
// z
        if (transformTobeMapped[4] < -z_tollerance)
            transformTobeMapped[4] = -z_tollerance;
        if (transformTobeMapped[4] > z_tollerance)
            transformTobeMapped[4] = z_tollerance;

Thanks, @TixiaoShan
I'll try on that. But i think thresholding is still not useful though driving on a flat road but with a slightly changing slope? Sometimes it has to be a relatively large deltaZ.

Thanks, @TixiaoShan
I'll try on that. But i think thresholding is still not useful though driving on a flat road but with a slightly changing slope? Sometimes it has to be a relatively large deltaZ.

You are right. The usage of thresholding is very limited.


Add padding around boundary area

When I cut icon images align it's boundary, and then found display problems on some android devices browser.
The sprite image looks like this: (dark area means padding of spritesmith)

So I have to keep another padding when I cut the images, to achieve the effect like that:

It's boring and not effective, could spritesmith help me add the boundary padding like that? It whill solve my big problem, thx~

Could you elaborate on the problem you are encountering?

For example, the icon images might look like this:

And then join them into the sprites images:

The problem arises:

The yellow icon is in the right bottom corner, but it might mix up with the icon right top and left bottom.

Ah, I see. Setting background-repeat: no-repeat in the CSS should resolve that. It's caused by scaling images and why we initially introduced padding as an option:
https://github.com/Ensighten/spritesmith/issues/7

Oh, I forgot adding it to my automatic tasks... Maybe this problem won't show on most android devices again, thank you!

I'm glad that resolved that issue =)


missing images  in Readme.

../screenshots/screenshots/best_rf_model_3D.png path is missing.
could you push that folder? so that the images get displayed properly

Hi Bharathgs, thanks for pointing this out to me, and for the contribution earlier today! Could you please let me know if it is displaying on your machine now?

Hi jason, Nope it is not, check the new PR.
we should put those images in an Assets folder and update the relative paths. so that it can be displayed everywhere.


Migrations do not start against Azure Blockchain Service

I'm perfectly able to execute the 'Using Truffle' (to connect to Azure Blokckchain Service) post but having trouble with 'Send transactions' tutorial. When connecting to a local version of Ganache (and ommiting the privateFor part) all goes fine and the migrations kick off. When following the setup above you see the project compiling and the console waiting for a moment and then it goes back to the commandline 'PS D:\BLOCKCHAIN\consensys\truffledemo>'. No 'Starting migrations...' whatsoever.
Am I missing a setting in Azure? Seems that connectionstrings are correct as well as the public key and all.

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

ID: df32d8b8-aa8f-b8da-3bc6-3fcba16be8bd
Version Independent ID: 71fdb7e0-bb97-f96a-84fc-778eeb590982
Content: Send transactions using Azure Blockchain Service
Content Source: articles/blockchain/service/send-transaction.md
Service: azure-blockchain
GitHub Login: @PatAltimore
Microsoft Alias: patricka

@albertoaguzzi74 Thanks for your comment. We are actively investigating and will get back to you shortly.

Hi @albertoaguzzi74 can you point us to the exact step on this tutorial that is failing for you? Thanks!

@albertoaguzzi74 Can you verify you are using web3 version 1.0.0-beta.37?  You can also try the reset switch for truffle migrate. For example, "truffle migrate --reset --network defaultnode".
Pat

truffle migrate --network defaultnode is the step on which it is failing.
I added a file with an overview of steps. I can connect to Blockchain Service with use of truffle develop and do a getAccounts(). When migrate to defaultnode it just stops after 'Compiling your contracts...'. Versions seems fine. Migrate to Ganache kicks of the 'Starting migrations...'
migrate-abs-fail.txt

Yesterday in a call I heard somebody say that when migrating to Azure Blockchain Service with Truffle it uses a a newer (not compatible) compiler version than is available in Quorum. Could this be the case?

@albertoaguzzi74 Can you verify you are using web3 version 1.0.0-beta.37? I don't know if you noticed that in my first response?
Thanks,
Pat

Spoken to other developers and the way to go in uninstall everything, follow the exact steps and migrate! This should do the trick. As others are able to migrate to ABS I will be so as well. Thanks for responding quickly! This issue may be closed.

Spoken to other developers and the way to go is uninstall everything, follow the exact steps and migrate! This should do the trick. As others are able to migrate to ABS I will be so as well. Thanks for responding quickly!


How to adjust fragment duration

Is there way to adjust the default fragment duration without rebuilding the code?
I see here https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/824de900c2d4b42a403319ace5de9d68ec88b171/kinesis-video-gst-demo/kinesis_video_gstreamer_sample_app.cpp#L33 that there is a default fragment length of 2 seconds for the kinesis_video_gstreamer_sample_app.
Is the only way to adjust that value to modify kinesis-video-gst-demo/kinesis_video_gstreamer_sample_app.cpp and rebuild?
Thanks.

@ekcheng ,
Yes. There is no command line argument you can give if that is what you mean. You will have to set the parameter in the code and rebuild

Ok, thanks for the quick response! On a related note, how does this interplay with the DEFAULT_STREAM_FRAMERATE parameter (which I see is set to 25)?
For example, if the true frame rate of the source is actually 5 frames per second but I leave the default framerate unchanged at 25, will the gstreamer sample app effectively provide a fragment length that is 5x longer than expected (because it was assuming a frame rate 5x faster than truth)?

Hello,
I just tried adjusting the DEFAULT_FRAGMENT_DURATION_MILLISECONDS parameter here https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/824de900c2d4b42a403319ace5de9d68ec88b171/kinesis-video-gst-demo/kinesis_video_gstreamer_sample_app.cpp#L33
to both 1000 (1 second) and 10000 (10 seconds) but it seems to have no effect on the reported Fragment Duration in the AWS KVS web console.
I did this by modifying the Dockerfile to overwrite the kinesis_gstreamer_sample_app.cpp file in the docker image, instead replacing it with my file containing the modified fragment duration before it runs the build script, e.g.:
RUN git clone https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp.git
# Overwrite with file containing custom fragment duration prior to building
COPY kinesis_video_gstreamer_sample_app.cpp /opt/amazon-kinesis-video-streams-producer-sdk-cpp/kinesis-video-gst-demo/                                         18
# ================ Build the Producer SDK (CPP) ===============================    =============================

WORKDIR /opt/amazon-kinesis-video-streams-producer-sdk-cpp/kinesis-video-native    -build/
RUN  chmod a+x ./min-install-script                                             23 RUN ./min-install-script
RUN ./java-install-script

I then ran the rtspdockertest per the example here: https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/docker_native_scripts/README.md
However, the fragment duration reported in the AWS console is always 2.1 seconds.
Am I modifying the right value?
Thanks.

@ekcheng the fragment rate and fragment duration are not affecting the source of the media. Let me cover in details:
fragment rate or FPS: The SDK is using the value to optimize the temporal storage requirements. This is intended to be used as a loose range. For example, for video, you can leave this as the default and it would work fine. However, if you are streaming some custom high-frame rate (for example raw audio when you have 48K samples a second), then specifying this value will result in proper temporal storage. Most of the people don't change this value.
fragment duration: If the low-level SDK is configured to do the fragmentation itself (no key-frame fragmentation) then the SDK will produce a fragment on a key-frame after this time elapses. For example, if you have an audio stream, all of the frames are key frames. The application can specify a key-frame fragmentation as FALSE and set the fragment duration to something manageable like 2 seconds. The higher-level assets like GStreamer plugin or samples rely on the media pipeline to produce key-frames at their intervals and set the key-frame fragmentation as TRUE. In this case, the upstream encoder configuration dictates the fragment duration.
Please let us know if you have more questions. Resolve the issue if you have enough information.

Thank you, @MushMal.
My video source is a standard IP camera, streaming h264 over rtsp. I am using the start_rtsp_in_docker.sh to stream this to KVS.
To change my fragment duration, do I understand correctly from your answer that I should set this parameter https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/824de900c2d4b42a403319ace5de9d68ec88b171/kinesis-video-gst-demo/kinesis_video_gstreamer_sample_app.cpp#L35 to TRUE and simply adjust my the keyframe frequency at my source?

@ekcheng yes, you would want to drive the fragmentation from your source indeed. Once the source specifies the frame being a key-frame then the SDK would cause fragmentation on that key-frame. As you said, in this case, you need to adjust the fragment duration at your source camera - each would have it's own way to configure it. In case of video, it's also called GoP (Group-of-pictures) or an I-frame interval - depending on the manufacturer. Some specify the period in seconds, while others specify the number of frames per I-frame.

Got it. Thank you!


tuf-0.3.0-beta11 fails to build against ToT Rust toolchain

Beginning with rust-lang/rust 42752cbe, tuf fails to build with the following error message:
error[E0733]: recursion in an async fn requires boxing
   --> ../../third_party/rust_crates/vendor/tuf-0.3.0-beta11/src/client.rs:955:5
    |
955 | /     async fn lookup_target_description(
956 | |         &mut self,
957 | |         start_time: &DateTime<Utc>,
958 | |         default_terminate: bool,
...   |
962 | |         targets: Option<(&Verified<TargetsMetadata>, MetadataPath)>,
963 | |     ) -> (bool, Result<TargetDescription>) {
    | |__________________________________________^
    |
    = note: a recursive `async fn` call must introduce indirection such as `Box::pin` to avoid an infinitely sized future

Should be fixed with the latest release now.


reload image from source

🚀 Feature
The ability to reload images from file easily within the viewer.
Motivation
Sometimes people are running external programs which replace a file on disk. If people have an existing layer created by opening that file, it would be nice to be able to reload that file from within napari without having to find the file in a file browser.
Pitch

Add an action to 'reload' a file from disk for layers derived from files.
Make this action easily accessible, in a context menu on the layer in the layer list

Alternatives
Additional context
layers loaded from files already contain a source entry in the metadata dict (added in #2053)

I like it!
Quick pointer, layer.source is an attribute (not in the metadata dict), see https://github.com/napari/napari/pull/2518 for details

thanks @tlambert03 !


Deployment to Vercel is broken

What version of Remix are you using?
1.4.3
Steps to Reproduce

Create a new Remix App with npx create-remix@latest
Select "Just the basics" and "Vercel"
Push to a Github repo, deploy to Vercel with "Remix" preset

Expected Behavior

Project builds and deploys without issues

Actual Behavior

Project apparently builds without issues
Visiting the deploy will throw the default Vercel 404:

Trying to view the deploy Function Logs will show "No Serverless Functions":

The deploy source output has no "api" folder:

This could be an issue with Vercel since everything was working fine just days ago.

@ananni13 try redeploy now it worked for me, Vercel did an update yesterday

Yes now it's working again, looks like it was an issue on Vercel side.

Getting the same issue. Any ideas on how to fix it. Followed the guide here https://vercel.com/changelog/remix-projects-can-now-be-deployed-with-zero-configuration

+1 Getting the same error :( 404. Everything looks fine on vercel.

@submetu Managed to fix it with help of vercel support. Refer this repo https://github.com/vercel/vercel/tree/main/examples/remix
Specifically, you will need to api directory with index.js and update remix.config.js

@mocon So when I had setup the project, the api directory in the root folder was absent. I had to add it manually that contained the index.js file. That made the 404 go away.


reduce certificate log spam

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Agreed, will improve in next PR. Still merging this to remove immediate noise in logs.


Display zone and wind settings

This adds the UI pieces to the main display to add the zone information and the wind information. I've included a small refactor since I was reusing the dial for both the circular control that sets the wind and the view-only wind control on the screen.

Thanks, it looks good, but when I play with it here:
http://wildfire.concord.org/branch/display-zone-settings/index.html
I can't really interact with the model. So, I guess it's something wrong with CSS / layering?

@pjanik thanks for the feedback! I've adjusted the styling to fix that issue, plus I've added the Time Elapsed styling as per the guidelines so we're much closer to spec. Model dimension details are now hidden by default, but can be displayed with the url parameter showModelDimensions=true if required.

Thanks! Labels were in front of the terrain dialog, so I just pushed it down a bit. Merging.


How to get all mime types for mime group?

How to query this crate to list all mime types that belong to a given group (specified by string, e.g. the "audio/*" or "image/*" group)?
(This would be very useful for web scrapers / bulk downloaders.)
(Also it would be useful to be able to get the group of a given mime type.)

There is currently no API available in this crate that allows this. PRs for that are welcome though.


While running the go build getting error

While running the go build getting below error
github.com/ibmcloud/packer-builder-ibmcloud/builder/ibmcloud
builder/ibmcloud/builder.go:68:48: cannot use self.config.KeyValueFilter.FlatMapstructure().HCL2Spec() (type map[string]"github.com/hashicorp/packer/vendor/github.com/hashicorp/hcl/v2/hcldec".Spec) as type "github.com/hashicorp/hcl/v2/hcldec".ObjectSpec in return argument

vknemanavar  if your OS is Ubuntu you can use the script https://github.com/IBM/packer-plugin-ibmcloud/tree/master/vsi-linux-setup, to setup your machine. Otherwise you can follow the steps on the script to install the dependencies required by Packer HCL2. Please install the dependencies on the script Steps 5-7, the README.md is not updated.

In Ubuntu OS getting below error. Is there possible to get directly plugin binary to use it in packer?
import cycle not allowed
package github.com/ibmcloud/packer-builder-ibmcloud
imports github.com/ibmcloud/packer-builder-ibmcloud/builder/ibmcloud
imports github.com/hashicorp/packer/hcl2template
imports github.com/hashicorp/hcl/v2/ext/typeexpr
imports github.com/hashicorp/hcl/v2/hclsyntax
imports github.com/zclconf/go-cty/cty/function/stdlib
imports github.com/apparentlymart/go-textseg/v12/textseg
imports github.com/apparentlymart/go-textseg/v12/textseg

I am not able to reproduce your error. Could you please run setup.sh script , you will be fine after running it.

I was able to fix the issue, default it is connecting to vsi using public IP can we change it to private IP?

@Nitinhuralikuppi


Hello, can you tell me the complete training steps? Thank you very much

train amr, make cam, eval cam;
cam_to_ir_label, train_irn;
make_sem_seg, eval_sem_seg;
train deeplabv2 with sem_seg pseudo labels;


iOS 8 support

Is there anyway that I can use this library with iOS 8 support ?

Hi, I will check on iOS 8 to see if there's any issue and let you know.
Thanks.

Hi, thanks for the quick response. It didn't work with Cocoapod when I used iOS 8 as deployment target. But when I added the library files manually it did work fine. Thanks a lot for the great library.

It works on iOS 8. Really good~~


feat(foundationdb): add Database.get_main_thread_busyness

Closes: https://github.com/foundationdb-rs/foundationdb-rs/issues/130

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.19%. Comparing base (a2e5614) to head (ecf2cd0).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
+ Coverage   83.24%   84.19%   +0.95%
==========================================
  Files          23       23
  Lines        5001     4979      -22
==========================================
+ Hits         4163     4192      +29
+ Misses        838      787      -51

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
9 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.8%) to 74.674%

Files with Coverage Reduction
New Missed Lines
%

foundationdb/src/database.rs
1
64.67%

foundationdb/src/directory/directory_layer.rs
8
93.1%

Totals

Change from base Build<PHONE_NUMBER>:
0.8%

Covered Lines:
4349

Relevant Lines:
5824

💛  - Coveralls