How to retrieve timezone?

I have seen in the config web page that the time zone is detected and shown but I can't figure out how to retrieve that in my program so that I can use it to initialize a NTP SyncProvider for the time library I'm currently using (https://github.com/PaulStoffregen/Time).

Hi,
I already add the new requested feature and will publish new release within tomorrow.
Hereafter is the debug terminal
Starting Async_ConfigOnDoubleReset using LittleFS on ESP32_DEV
ESPAsync_WiFiManager v1.8.0
ESP_DoubleResetDetector v1.1.1
ESP Self-Stored: SSID = HueNet1, Pass = password
[WM] * Add SSID =  HueNet1 , PW =  password
Got ESP Self-Stored Credentials. Timeout 120s for Config Portal
[WM] LoadWiFiCfgFile
[WM] OK
[WM] stationIP = <IP_ADDRESS> , gatewayIP = <IP_ADDRESS>
[WM] netMask = <IP_ADDRESS>
[WM] dns1IP = <IP_ADDRESS> , dns2IP = <IP_ADDRESS>
Got stored Credentials. Timeout 120s for Config Portal
Current Timezone is America/New_York        <===============  The timezone Name
LittleFS Flag read = 0xD0D04321
No doubleResetDetected
Saving config file...
Saving config file OK
[WM] * Add SSID =  HueNet1 , PW =  password
[WM] * Add SSID =  HueNet2 , PW =  password
ConnectMultiWiFi in setup
[WM] ConnectMultiWiFi with :
[WM] * Flash-stored Router_SSID =  HueNet1 , Router_Pass =  password
[WM] * Add SSID =  HueNet1 , PW =  password
[WM] * Additional SSID =  HueNet1 , PW =  password
[WM] * Additional SSID =  HueNet2 , PW =  password
[WM] Connecting MultiWifi...
[WM] WiFi connected after time:  1
[WM] SSID: HueNet1 ,RSSI= -30
[WM] Channel: 2 ,IP address: <IP_ADDRESS>
After waiting 10.94 secs more in setup(), connection result is connected. Local IP: <IP_ADDRESS>
Stop doubleResetDetecting
Saving config file...
Saving config file OK
HHHHHHHHHH HHH

Will publish new v1.8.0 soon, waiting for final touch.
The new feature will provide the complex TZ ( for example TZ =  EST5EDT,M3.2.0,M11.1.0 ) so that you can use directly in ESP32/ESP8266 code as follows
#if ESP8266
      configTime(ESPAsync_wifiManager.getTZ(WM_config.TZ_Name), "pool.ntp.org");
#else
      //configTzTime(WM_config.TZ, "pool.ntp.org" );
      configTzTime(WM_config.TZ, "time.nist.gov", "0.pool.ntp.org", "1.pool.ntp.org");
#endif

The debug terminal outputs
1. ESP8266
Starting Async_ConfigOnDoubleReset_TZ using LittleFS on ESP8266_NODEMCU
ESPAsync_WiFiManager v1.8.0
ESP_DoubleResetDetector v1.1.1
ESP Self-Stored: SSID = HueNet1, Pass = password
[WM] * Add SSID =  HueNet1 , PW =  password
Got ESP Self-Stored Credentials. Timeout 120s for Config Portal
[WM] LoadWiFiCfgFile
[WM] OK
[WM] stationIP = <IP_ADDRESS> , gatewayIP = <IP_ADDRESS>
[WM] netMask = <IP_ADDRESS>
[WM] dns1IP = <IP_ADDRESS> , dns2IP = <IP_ADDRESS>
Got stored Credentials. Timeout 120s for Config Portal
[WM] Current TZ_Name = America/Toronto , TZ =  EST5EDT,M3.2.0,M11.1.0   <======= TZ name and TZ here
LittleFS Flag read = 0xD0D04321
No doubleResetDetected
Saving config file...
Saving config file OK
[WM] * Add SSID =  HueNet1 , PW =  password
[WM] * Add SSID =  HueNet2 , PW =  password
ConnectMultiWiFi in setup
[WM] ConnectMultiWiFi with :
[WM] * Flash-stored Router_SSID =  HueNet1 , Router_Pass =  password
[WM] * Add SSID =  HueNet1 , PW =  password
[WM] * Additional SSID =  HueNet1 , PW =  password
[WM] * Additional SSID =  HueNet2 , PW =  password
[WM] Connecting MultiWifi...
[WM] WiFi connected after time:  1
[WM] SSID: HueNet1 ,RSSI= -42
[WM] Channel: 2 ,IP address: <IP_ADDRESS>
After waiting 3.49 secs more in setup(), connection result is connected. Local IP: <IP_ADDRESS>
Stop doubleResetDetecting
Saving config file...
Saving config file OK
Local Date/Time: Sat May  1 12:34:50 2021
Local Date/Time: Sat May  1 12:35:50 2021
Local Date/Time: Sat May  1 12:36:50 2021
Local Date/Time: Sat May  1 12:37:50 2021
Local Date/Time: Sat May  1 12:38:50 2021

2. ESP32
Starting Async_ConfigOnDoubleReset_TZ using LittleFS on ESP32_DEV
ESPAsync_WiFiManager v1.8.0
ESP_DoubleResetDetector v1.1.1
ESP Self-Stored: SSID = HueNet1, Pass = password
[WM] * Add SSID =  HueNet1 , PW =  password
Got ESP Self-Stored Credentials. Timeout 120s for Config Portal
[WM] LoadWiFiCfgFile
[WM] OK
[WM] stationIP = <IP_ADDRESS> , gatewayIP = <IP_ADDRESS>
[WM] netMask = <IP_ADDRESS>
[WM] dns1IP = <IP_ADDRESS> , dns2IP = <IP_ADDRESS>
Got stored Credentials. Timeout 120s for Config Portal
[WM] Current TZ_Name = America/New_York , TZ =  EST5EDT,M3.2.0,M11.1.0   <======= TZ name and TZ here
LittleFS Flag read = 0xD0D04321
No doubleResetDetected
Saving config file...
Saving config file OK
[WM] * Add SSID =  HueNet1 , PW =  password
[WM] * Add SSID =  HueNet2 , PW =  password
ConnectMultiWiFi in setup
[WM] ConnectMultiWiFi with :
[WM] * Flash-stored Router_SSID =  HueNet1 , Router_Pass =  password
[WM] * Add SSID =  HueNet1 , PW =  password
[WM] * Additional SSID =  HueNet1 , PW =  password
[WM] * Additional SSID =  HueNet2 , PW =  password
[WM] Connecting MultiWifi...
[WM] WiFi connected after time:  1
[WM] SSID: HueNet1 ,RSSI= -40
[WM] Channel: 2 ,IP address: <IP_ADDRESS>
After waiting 10.95 secs more in setup(), connection result is connected. Local IP: <IP_ADDRESS>
Stop doubleResetDetecting
Saving config file...
Saving config file OK
Local Date/Time: Sat May  1 11:52:50 2021
Local Date/Time: Sat May  1 11:53:50 2021
Local Date/Time: Sat May  1 11:54:50 2021
Local Date/Time: Sat May  1 11:55:50 2021
Local Date/Time: Sat May  1 11:56:50 2021

The ESPAsync_WiFiManager Releases v1.8.0 has just been published.
Your request for enhancement, leading to new v1.8.0 has also been noted in Contributions and Thanks

Major Releases v1.8.0

Add auto-Timezone feature with variable _timezoneName (e.g. America/New_York) and function to retrieve TZ (e.g. EST5EDT,M3.2.0,M11.1.0) to use directly to configure ESP32/ESP8266 timezone. Check How to retrieve timezone? #51
Store those _timezoneName and TZ in LittleFS or SPIFFS config file.
Using these new timezone feature is optional.
Add checksum in config file to validate data read from LittleFS or SPIFFS config file.
Update examples to show how to use the new TZ feature.


bug: modify the catalog reset method

The reset method only clears the contents of the catalog table and preserves the existing schema.

How do we reset the schema now? By deleting the catalog_database_uri?

How do we reset the schema now? By deleting the catalog_database_uri?

We used to drop the tables and also the database. I felt it is unnecessary and we should only clear the contents to the table. Hopefully, it is stable.


Make pools messages specify a JSON instead of many error-prone CLI args

As title. We should allow pool's to be specified by a JSON representation, not many distinct CLI arguments. (Especially as there's really no way to 'undo' a pool creation)
This is similar to whats done in the SDK for governance proposals, we can likely lift a lot of the logic from there.

closed by #129


Labeler reports year (YYYY) or list of integers as address

General Information:

OS: Arch Linux
Python version:  3.8
Library version: v0.3.4

Describe the bug:
File / Data is mostly correct, but the Year column is labeled as address
To Reproduce:
Download file, execute commands.

Now reported as integers


Implement SolrDriver/GoraDriver for PO.DAAC Integration

As requested by the project team, we should look into extending Mudrod storage functionality such that we can use Apache Solr as an indexing server. Justification is simple, this is what is in use at PO.DAAC.
We should review both Solrj and Apache Gora as options before hardcoding anything.

Just doing a little preliminary research, this is going to be very difficult. Doing a search for "import org.elasticsearch" yields 27 different files where we are dependent directly on the Elastic Search libraries. This means at a minimum we will need to alter these 27 files. I haven't done any further analysis as to how hard it will be to extract ES from these files.

Occurrences of 'import org.elasticsearch' in Project

mudrod-core

esiptestbed.mudrod.driver

ESDriver.java

esiptestbed.mudrod.integration

LinkageIntegration.java

esiptestbed.mudrod.metadata.pre

ApiHarvester.java

esiptestbed.mudrod.metadata.structure

MetadataExtractor.java

esiptestbed.mudrod.ontology.process

OntologyLinkCal.java

esiptestbed.mudrod.recommendation.pre

ImportMetadata.java
NormalizeVariables.java
SessionCooccurence.java

esiptestbed.mudrod.recommendation.process

VariableBasedSimilarity.java

esiptestbed.mudrod.recommendation.structure

HybridRecommendation.java
MetadataOpt.java
RecomData.java

esiptestbed.mudrod.ssearch

ClickstreamImporter.java
Dispatcher.java
Searcher.java

esiptestbed.mudrod.ssearch.ranking

TrainingImporter.java

esiptestbed.mudrod.utils

ESTransportClient.java
LinkageTriple.java

esiptestbed.mudrod.weblog.pre

CrawlerDetection.java
HistoryGenerator.java
ImportLogFile.java
LogAbstract.java
RemoveRawLog.java
SessionGenerator.java
SessionStatistic.java

esiptestbed.mudrod.weblog.structure

Session.java
SessionExtractor.java

No joke, it is a non trivial upgrade. We have two options,

essentially rip all ES stuff out and do a direct replacement with Solrj, or
make an attempt to abstract the functionality out into a core Driver interface, which would live in esiptestbed.mudrod.driver.

The other issue we need to consider is what the tradeoff's are in terms of performance between the Spark + ES integration we currently have (parrallize log ingestion and subsequent processing) Vs the Spark + Solr alternative (which we still have to design and implement).
I have previously used Lucidworks spark-solr for achieving this. It would be a great please to start.
Right now I think that it may be best for us to


Python QL: Use Module.getPath() to implement ModuleObject.getPath()

Should make ModuleObject.getPath() more robust

Looks good to me. Can you retarget against rc/1.20 so we can get it into the next patch release?


Not For Cosmic

this seems to be out of date and is for gnome not cosmic desktop itself please update to the real cosmic desktop by system76

oops i was wrong... there in the settings folder


Create new project

Completed create new project feature up to specifications. Will need to add cuke and rspec tests later (but waiting on dependent tests to be implemented first). Also will add better styling to the projects list later.

LGTM, verified locally

Will need to add cuke and rspec tests later (but waiting on dependent tests to be implemented first)
What does this mean?

Will need to add cuke and rspec tests later (but waiting on dependent tests to be implemented first)
Which dependent tests? It seems like to me you have enough to add a cuke for logging in and adding a proj--lemme know if I'm wrong. :P

Oh I was waiting for Daniel to complete his tests for the login functionality so that I could use it in my cuke test.


problems with the console

Actual behavior:
Hi there. I've got several problems since i came back from holiday at the beginning of august. First my wallet didnt synchronized anymore and i just saw my DFI Token on the wallet but not my LM pair and my dBTC.
After i reinstalled the wallet the synchronisation problem is solved,but i still dont see my dBTC and LM Pair. And the other problem is, that the console doesn't react if i#m typing something in. Hope somebody can help me with that problem.
sorry for my bad english!
Expected behavior:
How to reproduce it (as minimally and precisely as possible):

What are your environment parameters?

DeFi Wallet Version: 2.6.2
Operating System (OS): win10
Current free storage capacity: 200GB

Anything else we need to know?

Hi @cryptopinky ,are you synced to 100%? Do you have a screenshot of your issue? Can you also attached your logs please, it'll help with the investigation.

Hi @cryptopinky , update v2.6.3 is out.
Please read through the release notes before updating. This comment is to notify you about the update.

I still have the same problems with the update.

Hi @cryptopinky , I'm unable to investigate your issue further since I do not have a visual or logs. Are you synced to 100%?
You can try to Restore Wallet via Backup.
* If you have not backup your wallet before, go to the menu bar and select backup wallet.

1. Click on Exit icon & ensure app is 100% synchronized (green tick at bottom left hand corner), select Restore wallet via backup (wallet.dat)

2. A window should pop up, direct the app to your wallet.dat location
• In the wallets folder you'll likely see wallet-bak-123456789 as well, these are additional backups.
• Select the wallet.dat
*Note: the wallets folder is a default location and should not be moved

3. Another possible scenario, could be that you saved it in another folder.
• For example, I saved the wallet backup in Documents/_BACKUP
• Hence, I'd redirect the app to the folder Documents/_BACKUP, and select the wallet.dat

Leave the app to run for awhile, your balances should reflect as per the wallet.dat selected.

Hi @cryptopinky , is your issue resolved? The latest version is v2.6.5, if you've not updated.

Hi @cryptopinky  update v2.7.0 is out, this is a mandatory update. Kindly backup wallet before updating.
 Please read through the release notes before updating. This comment is to notify you about the update.

Hi @cryptopinky , update v2.7.1 is out, this is a mandatory update. Kindly backup wallet before updating.
 Please read through the release notes before updating. This comment is to notify you about the update.

Update v2.10.0 is out, this is a mandatory update. Kindly backup wallet and read through the release notes before updating. This comment is to notify you about the update.
If your issue persists, you may create a new one and elaborate on your issue.


channel /XXX has no listener registered, skipped

If event is registered after emit.start, chances are events binding will not take effect immediately.
this is caused by asyncio scheduling. emit.register is a synced call, however, if emit is running on top of aioredis engine, it's async call, so we have to use asyncio.create_task to add event and bind channel to listening. No way to enforce asyncio interrupt current loop and let the binding jump the queue.

the other reason is emit.start is not called, then the registry is empty. logging message need to be fixed.


The calendar control cannot display

3.0.0-avalonia11-preview5.198-nightly
The calendar control cannot display !  this control It is very important that the upgrade has resulted in the inability to select a date. We hope to fix it as soon as possible. Thank you！

Duplicate of https://github.com/AvaloniaCommunity/Material.Avalonia/issues/250
I'll try to prioritize this in order to fix it asap.


Migrate Selector to transaction provider

Selector still uses ristretto. It should be migrated to the new architecture that delegates RUSK for ZK operations

The BB proof verification changed substantially so we no longer have to maintain Z and the BidList for verifying the score. The code needs to change accordingly

This includes also adapting to the newer RPC after dusk-network/dusk-protobuf#90


Revert "Fix tooltip so only one shows at a time when hovering (#90457)"

This reverts commit 885b2f56e180faac645c7ec9b60b3809131dc628 to green up the build.

TBR = @darrenaustin


Pull Request #5 is not live

The pull request to fix the scope override defect is not in a tagged version and isn't available through bundler.

A temporary fix is to use this in the Gemfile:
gem 'omniauth-discord', git: 'https://github.com/adaoraul/omniauth-discord', branch: 'master'

Can we get this one out? I'm in need of the identity + email scope, and am currently unable to request it from here.

Will be live today, sorry for the delay.


Batch commands

Now that we have a proper syntax for patch series 1-3, we can think about adding multiple arguments to certain commands in an unambiguous way from a parsing standpoint. The idea is that a gps command followed by multiple rather than a single series: gps command 1 2-3 4-7 should batch said commands to something like gps command 1; gps command 2-3; gps command 4-7.
This will subsume commands like gps batch-request-review.
Now there are some questions that we need to answer in order to fully develop this idea.

How to do error handling?
Which commands to these semantics make sense for?
Is it intuitive to use?
Is it useful?

The parsing for this has been implemented and it has been integrated into the request-review command in mainline.
The behavior I implemented for handling errors with batched commands in request-review was to NOT have it short circuit the application. Instead it allows the other batched patch index ranges to run as well. I did this to maintain the behavior of the batch-request-review command which already had this behavior. I also think that this behavior makes sense for the request-review command as I don't believe previous patch index ranges should have any impact on the later ones requesting review.
However, even though we have the parsing available to all of the commands. I think that the behavior we want for other commands may be different. For example if we talk about integrate it can run a pull at the end of each integrate which would rebase the patch stack and then the patch index ranges wouldn't match correctly for the following patch index ranges.
So my point is that we likely just need to think through each of the cases where we want batching support and determine what type of behavior we want for that command when batching.


Upgrade lru-cache to v7

Fixes #189.

Thanks for this.  I'll get to it soon.

Thank you.

Thank you


Open AI  Integration

Description of the changes
AI Integration
Breakdown & Estimates

Expected Time Range:
Actual Time:
Feedback Cycle

Cycle Count: 0
Checklist:

[ ] The PR title follows this syntax: <#IssueID> <PR Title>
[ ] I have linked the issue id in the PR description.
[ ] I have performed a self-review of my own code.
[ ] I have added comments on my code changes where required.

This is not needed for now.


Update v3.6.0

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

@conda-forge-admin, please rerender

https://conda-forge.org/status/ shows errors in trying to parse the recipe, but I didn't see any obvious problems other than a redundant dev_url.  I've tried to fix that but we'll have to see if the bot picks up the next version or not.

Thanks @rxm7706!


Cannot access the authenticated user in query scopes (Auth facade)

Laravel Version: 5.5.21
PHP Version:7.1.9
Database Driver & Version:

Description:
I am trying to access the currently authenticated user within the query scope class. I am using 3 custom guards for 3 types of users. Each of the user models contains a region_id column, value of which I want to access to filter virtually all models in the app.
When I call the Auth::guard($guard)->user() within the query scope class the value is always null, even though the user is authenticated. Information about the authenticated user is accessible from e.g. controllers, so it is not the issue of a user not being authenticated.
It seems to me like the authentication check occurs after the query scopes are executed.
Steps To Reproduce:

Define a custom query scope
Define a call to Auth::guard($guard)->user() within a query scope class constructor.
Log the value of the authenticated user
Log the value of the authenticated user in some other place, e.g. in the controller, to make sure that the user is indeed authenticated.

My query scope class:
<?php

namespace App\Scopes;

use Illuminate\Database\Eloquent\Scope;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Builder;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Log;

class RegionScope implements Scope
{

    protected $region_id;

    public function __construct() {

        Log::debug('Region query scope constructor just started');

        $guards = array_keys(config('auth.guards'));

        foreach ($guards as $guard) {
            Log::debug('Checking guard: ' . $guard);
            // I am hitting the route for managers in the browser, and I know that a manager user
            // is authenticated.
            Log::info('Managerial user is: ', ['user' => Auth::guard('manager')->user()] );
            if(Auth::guard($guard)->check()) {
                Log::debug('Guard: ' . $guard . ' checked');
                $this->region_id = Auth::guard($guard)->user()->region_id;
            }
        }

        Log::debug('Region query scope constructor just finished');
    }

    public function apply(Builder $builder, Model $model)
    {
        $builder->where('region_id', $this->region_id);
    }

}

EDIT:
I am not sure whether it is by design, but there's a thread on Laracasts forums, where someone reports a similar issue. The solution recommended in that thread is to move the middleware from 'web' group to 'global' - I don't really understand whether it is something that should be done or not.
EDIT 2:
Quite interestingly, when I define an anonymous global scope directly in the model using a closure, the authenticated user is accessible. For example:
static::addGlobalScope('region', function (Builder $builder) {

        Log::info('Authenticated user is: ', ['user' => Auth::user()] );

 });

works fine.
Trying to pass the user value directly to the scope object does not work:
static::addGlobalScope( new RegionScope( Auth::user() ) );

This repo is for bug tracking. Use the forums or slack channel for solving your issue

The scope constructor executes where early, before the auth middleware has run. Resolve the user within the apply method, not in the constructor.

@sisve Thank you. It worked!

Can someone please help me understand the sequence of execution or at least guide me in the right direction.
I had a somewhat related problem
Unable to access authenticated User's Roles and Permissions in global scope
And solved it by delaying the load using lazy loading instead of eager loading a scoped model.
Any help on the sequence front would be appreciated.
Thanks


Use the db name as well as the table name in --ignore-table to avoid failure.

Hey @bakert,
Your changes look good to me!
View build log
TravisBuddy Request Identifier: ea0060a0-1e7d-11ea-8c7c-334558e6cc20


Build system updates

https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/

I am concerned with the don't compreda artifacts.
Would kindly ask for some evidence it does good.
Right now we use xz -8 and it can be compressed more for sure (see my other PR) so data is surely not-non-compressible right now


Dependabot create a separate pr for each sub-package (pnpm)

Is there an existing issue for this?

[X] I have searched the existing issues

Package ecosystem
npm
Package manager version
pnpm v8
Language version
No response
Manifest location and content before the Dependabot update
No response
dependabot.yml content
No response
Updated dependency
No response
What you expected to see, versus what you actually saw
After migrating from yarn to pnpm, every time that dependabot creates a pull request to update a dependency, it creates a separate pull request for each sub-package. As an example, to update webpack, it will create at least seven pull requests, one for each package.
Previously, in yarn, one PR was created for all sub-package
Is this related to the package manager or have there been changes in dependabot?
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
No response
Smallest manifest that reproduces the issue
No response

behavior

unfortunately no, these are private repositories, perhaps I can provide some information or screenshots?


How to conitnue trainig?

Using colab is and issue, cos every 12h u re getting disconnected, is there any way to continue training?

[INFO] Loaded checkpoint '/content/drive/MyDrive/TTS/vits/D_0.pth' (iteration 1)
This is answer for my question.


Context install

Hi. First of all thank you so much for this project. It has mitigated almost all the pain of installing applications on osx.
Description
I'd like to be able to install context directly from the brew instead of running this script
mkdir $HOME/context
cd $HOME/context
rsync -av rsync://contextgarden.net/minimals/setup/first-setup.sh .
sh ./first-setup.sh --modules=all --engine=luatex

Motivation
To make it easier to install the dependency for pandoc and tex related support. See pandoc_resume project.
Relevance
It's relevant in the tex, latex, pandoc world of scientific documents and typesetting. Pandoc is already formulated in brew.
Alternatives
I haven't found an alternative that can do what context can do. I did find a suboptimal, alternative way to install it using the shell script provided by contextgarden.net as mentioned above.
Also a previous attempt was made at this but it doesn't look like it met standards.

@nitrocode:  ConTeXt should be available as part of TeX Live, distributed for OS X/macOS from Homebrew Cask using the TeX Users' Group's upstream MacTeX package; run brew cask install mactex to get it.

I did not know about this. :tada:

Glad I could help, @nitrocode!

@RandomDSdevel wait sorry. I spoke to soon. I ran brew cask install mactex but it did not install the command line app context.

@nitrocode please read the upstream ConTeXt documentation on how to set up ConTeXt with MacTeX: http://wiki.contextgarden.net/Mac_Installation and contact them if you need more help with that.
This issue tracker is for bugs related to the brew package manager itself.

     Couldn't have said it better myself, @ilovezfs.  @nitrocode probably should have filed this issue with Homebrew/homebrew-core instead in the first place, too, since he was initially asking for a new formula for ConTeXt, but that's water under the bridge now; on with the day…


Blocks propagation is at least 10% slower than it can be.

Problem
When miner mines a new block (this is the most sensitive case since we want that reward and would like to make chances of making an orphaned block as low as it possible) or when we receive a block from the network it usually takes 0.8 - 1.5 seconds before we actually start announcing it to the peers.
Average block propagation time on bitcoin network (until >50% of the network know about the block) is ~11 seconds so having that 0.8-1.5 sec delay is actually slowing the propagation by at least ~10%.
Why is it happening?
We're adding new block's header to the list of headers for propagation and check this list every 1 sec (see BlockStoreSignaled.RelayWorker). So in case we add a new header just after the list was checked we would end up waiting 0.999 sec till we start propagating added hash.
Solution
I suggest replacing continuous checking if the list is empty with triggering the propagation when new hash is added.

@Aprogiena mind if I take this one or you have plans for this one in the next node job PRs?

this has nothing to do with node refactoring
but @dangershony had some input on this when we discussed it

in any case, do not start any work until we agree on how to proceed (and also when - some things may be more important)

I'll try to elaborate on my approach:
Current implementation:
When new block appears we add it to a list of blocks, once a second we flush that list and announce hashes that this list contains.
Suggested implementation:
Instead of checking the list once a second we will do following:

New block arrives- add it to the list.
When new block is added we would attempt to start an announcing task. If the task is already running we will do nothing.
Announcing task will be identical to the current one logic-wise but when in the end it checks if there are still some blocks in the list and if there are the task would restart itself.

Doing it this way will prevent announcing each hash separately- instead if while we were announcing some hashes and some more were added during that we would announce them all together. Also this approach won't announce hashes in a wrong order.

Please let me know if you think this should be done differently, probably we will come up with even better solution.

it seems that you want to open the pandora's box, or maybe you don't know that it is a pandora's box :-)
for the first look, it might seem logical - yes, do propagate the block as soon as possible, well obviously and i agree with that. the problem is that it won't reduce the orphaning, not if everyone improves. but there is more to it
the current situation on the network is that there are StratisX clients and C# clients. if we assume StratisX implementation to be optimal (we don't know it though), then C# clients are going to have higher orphan rate because of this problem. If we improve it, it should be on par with StratisX clients. But since later we want to get rid of StratisX clients anyway, it won't matter, all nodes will be on par, with this improved or not.
the pandora's box here is that you can do more than that to improve your orphan rate, but not very much to the benefit of the network. now the difficult question is - should the reference client be optimally selfish even if that makes the network worse? and another difficult question is - what the equilibrium of this game
the major factor here is that there are only certain timestamps where it is allowed for the block to be mined, so the blocks are not mined in random intervals, but in very discrete moments, so the chance of two blocks appearing at once is super high, we can't do much with it unless we want to hardfork and fix that on very consensus level
so let's say i know how to improve my orphan rate, there are at least two methods for that

one is to connect to more nodes
second is to FBT

for "optimal" orphaning rate for my node, i would like to connect with everyone. but if everyone did that, we would have N^2 number of connections in the network and the network would be far from optimal, it would be actually much worse and the orphaning rate would be the same for everyone (i.e. not improved), so by improving connectivity, one can gain advantage, but if everyone does so, the overall result is negative
with the FBT it is the same, if one node does it, it will gain advantage, but if everyone does it, it will make the network worse. so should the reference client do it? if the answer is yes, we will end up with worse network, if the answer is no, since this post opens the pandora's box, someone will implement it and gain advantage. but then if other people see someone took the advantage, they will copy and we have sort of tragedy of commons situation
so, i leave it to the reader to figure out what FBT is, just for fun ;)

so what to do with this? I actually think this particular thing you've mentioned should be improved, but the question is how
when you mine a block, for sure you want to get propagated as soon as possible, and now there is second problem - we wait until the block is on disk, i suggest we should not do it for blocks we mine
for all other blocks, having a trigger for propagation is probably good idea (probably trigger the event from the block store, when the block is on disk)

the thing is that if we do on trigger sending, then we won't do batches, this may be inefficient, esp. if we receive more blocks in very short time
on the other hand, it probably happens rarely - if we are NOT in IBD and we are at the tip of the best chain, we usually only receive one block at the time from one peer
another block can be mined no sooner than 16 seconds after that, although due to network propagation delay, we may receive it with arbitrary small gap, so in theory we can receive 3 blocks in one second, but it is probably unlikely and not worth considering
the current code operates in batches, the question is - would it be better to avoid batches and go one by one as quickly as possible?
the problem is maybe when a reorg happens and we suddenly have e.g. 5 blocks coming at the same moment, we might want to analyze this if we should handle this somehow special

the problem is that it won't reduce the orphaning, not if everyone improves

ofc. If everyone improves it just speeds up the propagation speed by 10% and will have nothing to do with the orphans.

the current situation on the network is that there are StratisX clients and C# clients. if we assume StratisX implementation to be optimal (we don't know it though), then C# clients are going to have higher orphan rate because of this problem. If we improve it, it should be on par with StratisX clients. But since later we want to get rid of StratisX clients anyway, it won't matter, all nodes will be on par, with this improved or not.

Who would want to switch to a C# full node from the StratisX if full node have a higher chance of producing the orphan? No one in right mind would reduce their staking income.
Btw overall this is not really about the orphan rates, more like about that 10% propagation speedup for the whole network by propagating the block as soon as we have it instead of waiting for 1 second.

on the other hand, it probably happens rarely - if we are NOT in IBD and we are at the tip of the best chain, we usually only receive one block at the time from one peer

Agreed. We can check those conditions and if it's ok we send it asap. Batches otherwise.
Btw: we already do the IBD check in current implementation (if in IBD- don't announce the block at all), not sure about the tip.

the problem is maybe when a reorg happens and we suddenly have e.g. 5 blocks coming at the same moment, we might want to analyze this if we should handle this somehow special

What is the probability of having a 5 blocks reorg? Did we EVER had such long reorgs on the mainnet?
And for the small reorgs (that are also relatively rare) it's ok to have a small overhead. Sending 2 blocks in 2 messages instead of 2 in 1 message once in 3-4 hours is not such a big overhead at all. The benefits are worth it.

I suggest doing it like this:

We get the block and propagationTask == null? - start propagating
If we get another block\blocks while still propagating prv block (propagationTask  != null)- add it to queue.
After the propagation task is finished- wait 0.5 seconds before we can start a new task.

Doing it like this will make sure that if we receive a single block we will propagate it right away.
But if we are receiving a sequence of blocks we're still forming batches.

I've collected some of the relay worker logs and I've noticed that we usually get those 2 scenarios (not counting rare reorgs):

We are behind the best chain, we start a node- we're in IBD. Around 1290-1300 blocks before the tip we assume we're no longer in IBD and we start announcing those blocks to everyone. (gosh, we should really reduce the MaxTipAge, wtf why are we announcing 1300 blocks?!)

We get a single new block every ~60 sec.

So it looks like the suggested approach will work well in both scenarios.

there is an issue for max tip age reduction
anyway, IBD is misnomer, IBD is done once, if you are not in sync, it is technically not IBD
however, it is fine to announce to peers that you are almost synced, you just send headers, they will update their view, no blocks is sent, that's fine
as mentioned on slack, my preference is

if you mined a new block -> send now one block, don't wait on ANYTHING

if you receive a new tip and you propagate it -> send now, but only after it is on disk

if you are not sending tip -> batch it

and i believe 1. and 2. can be merged once block store cache is implemented

if you mined a new block -> send now one block, don't wait on ANYTHING

Which breaks the architecture. PoSMinting shouldn't do anything but creating a block, propagating the block is not's it's responsibility.
Right now saving the mined block delays sending it by ~90ms. Comparing to 1 sec delay in AsynWorker it's nothing. And when we implement the block store cache it will be even lower then this 90ms.
So I don't think that breaking the architecture worth the gain.
And also suggested approach won't solve the problem in general. What I want to achieve is general network's propagation speed.
I think we should first agree if 10% network propagation speedup is a good thing or not. And when we agree on what we wish to achieve we can discuss the implementation reasonably.
Right now it looks like we're suggesting on how to do 2 different things differently.

Which breaks the architecture. PoSMinting shouldn't do anything but creating a block, propagating the block is not's it's responsibility.

it doesn't, you can simply achieve that from consensus loop accept method

anyway, improving this is a good thing, so i'm for it, the discussion i think is now about just how to do it

it doesn't, you can simply achieve that from consensus loop accept method

You mean changing the AcceptBlockAsync so if the block is mined by us it gets propagated straight forward?
Ok, Agreed, this approach won't break the architecture.
I thought you've men't bypassing the consensus loop and do the  signals.SignalBlock() from the PoSMinting as soon as the block is mined.

anyway, improving this is a good thing, so i'm for it, the discussion i think is now about just how to do it

You mean improving the overall propagation speed of the new blocks no matter if we've mined them or someone else?

improve the propagation in general

in blockstore we now wait until the block is on disk, this is usually good thing, so i would keep doing that UNLESS our newly minted tip is in the queue, in which case i would skip that wait in that place

i don't think the idea with the propagation task is good one

We can do it the other way, I don't mind.
We can simply keep a bool variable IsPropagating (set true when we start, set false when we finish propagating what we have in the queue) and a timestamp LastPropagationTime.
So every time we get a new block we add it to the queue in case (IsPropagating  == true ||
DateTime.UTCNow - LastPropagationTime < 1 second), otherwise we start propagating. And if it's our mined block we don't check if the last propagation was at least 1 sec ago- we flush the batch right away.
So that way we perform the same logic but we won't have a propagation task and checking if it's null.

Or we can add a method for the AsynLoop- start next iteration immediately. This method would run a loop iteration immediately if it's not running now or skip the delay before the next run in case it's running.
So effectively we will have an option to flush the queue on demand. And we will do this flush when we've mined a block OR if when we've received a new block from the network and last propagation time was > 1 sec ago.
So this also ensures having 1 sec batches and propagating new blocks that were just mined by us or someone on the network.

the normal way of implementing this is with event that you add the job to the queue, trigger an event and the consumer is waiting for the event

Can you please elaborate on the solution with events?

it is classical scenario that is known as producer-consument, you can implement it with threads or tasks, does not matter. in our code base we will go for tasks as it is more efficient
in our context, it will look like this:
one task is producer, its role is to add new things to the queue, once a thing is added, it sets the event (e.g. ManualResetEventSlim)
on the other side is consumer, consumer is a task that waits on

shutdown
event
5 second timer

if any of those three signal, consumer is woken up and reacts

if shutdown -> then exit
if event -> consume the things from the queue as per our algorithm (this means either copy the queued items to local list and wait again, or (if tip is present) send the items to peers)
5 second timer -> send batch

there is no active waiting anywhere and there is only a very simple synchronization - there is lock on the queue and there is the event

@Aprogiena thanks, it's pretty much clear now.

@Aprogiena I've pushed the PR.
Though I've studied the logs and it looks like block store saving now became the bottleneck. When we're trying to announce the block right away the block is usually is not saved on disk so we have to wait for the next iteration (0.5 sec).
So this change will gain it's full power after block store cache is implemented.

told ya :P

@Aprogiena well.. yeah.
Though this change wasn't for nothing. Without it it would have been a bottleneck as soon as block store is fixed.

Ah ok I now read the thread, very good discussion.
And yeah if we can boost propagation (I believe by more then 10% with block caching) it will be great.
@Aprogiena StratiX disadvantage is fine it will just encourage people to move to the C# node.
FBT - Faster Block Transfer
By the way I think technically when the node is just resyncing its still considered IBD.
I think tip age is fine as apro said we just announce headers or inv hashes (we could optimize this a bit by not using header first propagation for blocks that are not close to the tip, so the 1300 blocks will only send in hashes not headers).
But I think apro pub/sub suggestion is just complicating things, to start we can just reduce the loop from 1 sec to 0.1 sec and achieve a massive increase.
We can also use a BlockingCollection mush easier to implement and understand.
As part of this PR we should also push to cache blocks that can be announced regardless to Store and make sure Store is not disrupted and that the propagation behaviour does read from cache.

Those blocking collections in old node code caused a major headaches to me during past week. It is nightmare and I want to remove it from the code base. The original node actually seemed to waste about 5 threads for a single peer. I say no to blocking collections.

and no, FBT was not for faster block transfer :)

and no, FBT was not for faster block transfer :)

🤔 FirstBlockTransfer?
Yeah BlockcinCollection is a thread huger
The old node indeed had so many threads per peer so I am happy we moved away form that.

I found this link that might be relevant and interesting
http://diyhpl.us/wiki/transcripts/gmaxwell-2017-11-27-advances-in-block-propagation/

oooh, a hidden gem you found for me, feels like a christmas present! thank you

not First Block Transfer though :D

@dangershony any time i hear GMax to talk about Bitcoin, i feel amazing vibes, then i reflect that to what we are working on - like PR 976, and i realize that the only thing that makes sense is to implement those optimal solutions. we can be ok with temporarily imperfect solutions, but if we are working on an improvement of something and we know we can do better, then we must do it better.
in other words, you don't need me to create subprime solutions, i'm interested to develop the best we can at each particular moment. if we allowed a subprime solution to be developed when a better one is available for just little extra work/cost, i say we must go for the better one. it would be different if the cost was too high that it would not justify the benefit. but we can pay some of the tech debt there, so i say we do it!
and now i will enjoy the rest of GMax in peace :-)

Another thing I'm thinking about for long time is that when we mine a block we send it to consensus loop to accept it, that loop verifies that the block is correctly built and if so it accepts it.
However, unless there is a bug in mining process, we should not be able to mine invalid block. We should be able to skip the validation and this could help us propagating our block even faster.
Doubling however-ness however, we need to execute the block (i.e. we need to apply the transactions in the new block to our coinview). However, this can happen after we propagate the block! This problem is not that much visible as of today as the number of transactions, even on the mainnet, is very low. But imagine we did have full blocks, then block validation can take very long time (actually did anyone analyze this? afaik it can take quite a long time for full bitcoin block to be validated if certain special transactions are present - i.e. quadratic hashing problem etc., although it should not take 64 seconds (target spacing in stratis), it could probably take as much as 30 seconds and this can be a problem), so then the miner who would skip validation of its own block (which is valid for sure unless there is a bug right?) would benefit from this compared to others who could also produce the block at the same timestamp, but are validating.
So, there seem to be a huge space for improvement in this as well.

Indeed we just need to flip the skip validation switch to achieve this optimization, I wonder however why core don't skip this (I think they don't skip it) perhaps one could effect a valid block based on config values.
I agree on the do the best we can comment for sure.

bitcoin core is not a software you would use for high performance mining, they don't need to be efficient in that


Create mlc

@nightyiscute lib/domains/tw/edu/mlc: this request has an incorrect file path format, please ensure that you are familiar with     this repository rules located at the bottom of this page and change     your request accordingly. If you don't know how to change request, close it and open a new one.     If you are not able to make the pull request according the instructions, please send us an email to<EMAIL_ADDRESS>Please mention this request URL in the message.

@nightyiscute Please provide us with:

the school official name
the school street address, including city and country
an URL of a page on the official website where the school offers an IT-related long-term (>1 year) course
a proof, which shows that the school recognizes the domain you are submitting as an official email domain for the students.

@nightyiscute You might miss my previous comment. Please react.

Sorry ,I see your react lately and give some time and I will done this

@nightyiscute Regrettably, this request remains not answered for a while. I have to close it without merging. Please create a new request with all the required information as soon as you are ready. Thank you.


Card component for template templates

Creating the component to show cards for previous Template options for picker

Fraser will get to this next sprint. He has been busy working on wireframe updates.

I have moved to done, this is a bit of an orphan as it was done as part of the template builder functionality PR


Swapping workspaces using touchpad gesture in conflict with any software that maintains per window layout.

Already reported ? *

[X] I have searched the existing open and closed issues.

Regression?
No
System Info and Version
 System/Version info
Hyprland, built from branch  at commit 4520b30d498daca8079365bdb909a8dea38e8d55  (version: bump to 0.44.1).
Date: Wed Oct 9 12:54:39 2024
Tag: v0.44.1, commits: 5309
built against aquamarine 0.4.3

flags: (if any)

System Information:
System name: Linux
Node name: gomzik-nuc
Release: 6.11.6-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Fri, 01 Nov 2024 03:30:41 +0000

GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Pro Graphics 580 [8086:193b] (rev 09) (prog-if 00 [VGA controller])

os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

plugins:

Description
When I switch between workspaces using touchpad gesture, I see that my keyboard layout indicator reports, that layout is changed for a specific window, but when I start typing, I see the zero indexed layout symbols. You probably will say, that I should to create Issue in per-window-layout manager software repository, but I would like to say, that it is working fully as expected, when I switch workspaces using keyboard hotkeys. And once again, Layout indicator is showing that layout has been changed, but symbols, that are typed aren't from this layout, they from zero indexed layout.
As I noted also, it is enough to just press CTRL and typing becomes normal
I'm not only used an existing software for that and also created my own version to check. Seems that events sent trough socket are ordered correctly, but I could also try to debug this stuff with your help.
I would be happy to fix this issue, because it is very annoying
How to reproduce
Setup multiple layouts in config
Launch per-window-layouts software. For example hyperland-per-window-layout (Rust)
Create two windows on two different workspaces but on the same monitor
Switch layout for one window
Go to the another workspace and type something
Go back to the workspace with window, that has changed layout !USING TOUCHPAD GESTURE!
See that any indicator that shows layout reports non-default layout
Try to start typing (do not press any modificator keys such as CTRL, ALT, Meta, even Shift probably)
See that symbols aren't aligned with selected layout
Crash reports, logs, images, videos
No response

Seems that issue is gone now. I'l add one more comment after some checks


Update README.md

haha, checking why the pipelines were failing. Looks like a new release of scikitlearn was causing the following estimator checks to fail:

estimator_checks.check_sample_weights_pandas_series
 estimator_checks.check_sample_weights_list

As our bucketers do not accept a sample_weight argument. I've removed these 2 checks from the tests


Updating with 2017 data

Yes, I made the above changes, will remove commented lines and will resubmit.


Save-Data post for web updates

@PaulKinlan @petele please take a look!

@petele I'm giving this a quick copy edit.

\o/ - thanks guys!
@petele when will this go live?

I'm going to push Monday morning around 10am ET so that it's fresh for next
week, though happy to push earlier if you'd prefer.
PEte
On Fri, Feb 19, 2016 at 1:52 PM, Ilya Grigorik<EMAIL_ADDRESS>wrote:

\o/ - thanks guys!
@petele https://github.com/petele when will this go live?
—
Reply to this email directly or view it on GitHub
https://github.com/google/WebFundamentals/pull/2573#issuecomment-186359574
.

--
Pete LePage | Developer Advocate |<EMAIL_ADDRESS>|<PHONE_NUMBER>

Monday is good -- thanks Pete!

\o/**\o/
On Fri, 19 Feb 2016, 18:54 Ilya Grigorik<EMAIL_ADDRESS>wrote:

Monday is good -- thanks Pete!
—
Reply to this email directly or view it on GitHub
https://github.com/google/WebFundamentals/pull/2573#issuecomment-186360001
.


model-viewers (5.7MB) causes other primitive components to "lag" across the page when scrolling

I'm using model-viewer to display 1 model-viewer per card, and I have about 2-5 cards on the screen at any given time and about 11 models (5.7MB each) on the page total. Whenever I scroll down the page of cards, the models follow the scrolling fine (with low "latency"), and all of the other components, including the divs that hold the models and the text within those divs lag behind. What can be done to improve this experience?
P.S.
Even when the page is only showing one model (the others are visibility: hidden), there is enough lag to be noticeable.

@danksky thanks for reporting this! I must admit, that's not something I have heard anyone report before. Would it be possible for you to share a test case that demonstrates the problem so that we can play around with it?
Also, which devices and browsers did you experience this in?

Hi @cdata sorry for the delay. The asset I'm using is sensitive, so I was making a demo that I could share publically. In doing so, I couldn't replicate the problem. There were 2 differences in the demo vs. the project where I experienced this lag effect:

The demo was using 2.2 MB models. My project was using 5.7 MB.

The demo excluded mapbox. My project has a dynamic mapbox component.

I still have some tests to do, but I'm assuming that also rendering the map is causing the lag.

@danksky very interesting. I know that mapbox is able to use WebGL, so it's possible that this causes complications. I'm very interested to see a test case if you are working on one :)

@cdata
Here ya go: https://model-viewer-mapbox-demo.herokuapp.com/

Wow, that is fascinating. Thanks for sharing this!

Alright, after a bit of poking, I think we uncovered the problem. It seems that the problem only occurs in Chrome (please let us know if you discovered this issue in other browsers).
Fundamentally, the problem is that the <model-viewer> elements are being rendered on the compositor, and their containers are not, so there is an async lag between the two as they paint.
One potential fix for this is to force the container to be rendered on the compositor by forcing it onto a render layer. You can do this in Chrome by setting a CSS property like will-change: transform or transform: translate3d(0, 0, 0) on the container. For example, I was able to set transform: translate3d(0,0,0) on <div class="demo-list"> and the lag in your demo disappears.
Please be aware that while this will fix the problem, render layers allocate GPU memory, and if they are overused you will see bad effects from them on mobile devices and possibly even desktop browsers. I recommend using the "Layers" tab in Chrome dev tools to analyze the cost of the layers you have created.
Kudos go to @azakus for applying his deep well of web platform knowledge to this problem 🍻


does this work on iOS

Hello, I have tried to use this on my mac, but I have failed. Is this software compatible with mac iOS?
thank you.

Not natively, but I'm sure it'll work in docker.