Tour UI

Adds UI for Tour Model.
User can step through Tour Waypoints or pick them from the list individually.
https://user-images.githubusercontent.com/40494088/179044769-605c4122-3d04-436b-87ad-3da36e9e2abc.mp4

That demo video is awesome!

This is great, @marySalvi!
My one suggestion is to change the default method of interpolating between waypoints. This seems to be using a straight linear interpolation (move from A to B at a constant speed, with "infinite" acceleration to full speed or 0 at the beginning and end, respectively), where it might feel more natural to use a form of "easing" (that is, a velocity curve that accelerates and decelerates smoothly at the ends).
I'm not sure how simple this is in GeoJS, but we should dig into it.


Modules View Composers

Hi!
I have created a Module and i'm trying to pass a data to all view (within the main layout) with the view composer method. But it doesn't seem to pass.. I got a "Undefined variable" exception when I call my variable. Here's what i got:
My module name is Frontend
In my Modules/Frontend/Providers folder, i'v created a ViewComposersServiceProvider file, and added the line in my config\app.php
Then, in this file, here's my boot() method:
View::composer('frontend::layouts.home', function($view) {
    $view->with('data', Seo::find(1)->first());
});

I'v tried different views path (Frontend::layouts.home, frontend.layouts.home) But none seems to be the right way..
I have my layouts files also in the same module folder, in the Resources/View folder.
Does anyone have an idea how to achieve this? Or a direction to take?
Thank you!

In my project, I have the following setup and it works:
Method inside my ModuleServiceProvider
/**
     * Register the Visittransfer module composers.
     *
     * @return void
     */
    protected function registerComposers()
    {
        View::composer(
            ["visittransfer::admin._sidebar"],
            \App\Modules\Visittransfer\Resources\Viewcomposers\StatisticsComposer::class
        );
    }

Call this method inside register()
public function register()
    {
        ...

        $this->registerComposers();
    }

Hi!
Wonderful! It worked like a charm! thank you!


can we merge 2 stl files such that they are overlapping, and we dont have to take care about overlapping traingles

That sounds like concatenating the two meshes. That's easily done:

new_mesh = mesh.Mesh(numpy.concatenate([
    mesh_a.data.copy(),
    mesh_b.data.copy(),
]))

@WoLpH ya but these doesn't really take care of intersection, lets say there are 2 cubes to be intersected side wise to create cuboid, the intersecting face of cube should get deleted, but it doesn't happen.

Very true, I assumed that was what you meant with not caring about overlapping triangles.
Properly merging meshes is a lot harder to do and a little outside of the scope of this library.
The big problem with merging meshes is that you need to create and destroy triangles within your mesh. Since this library is based on numpy arrays that's hard to do, beyond recreating.


Missing files when installing js-yaml on Windows

npm install js-yaml on Windows 7. npm version 1.1.0-beta-4; node version v0.6.6. Missing files from the package
./js-yaml.js
./js-yaml.min.js
./lib/js-yaml.js

these files exist in the repo https://github.com/nodeca/js-yaml, but aren't installed for some reason. Also, I tried cloning the repo to a local directory and then npm install <that directory> and got the same result.

They're explicitly excluded.  Bug the author.  https://github.com/nodeca/js-yaml/blob/master/.npmignore

Thanks Isaac! I remove these two lines
/js-yaml.js
/js-yaml.min.js

from the .npmignore file, retested, and it fixed the issue. However, the file /lib/js-yaml.js was excluded as well where it wasn't explicitly listed in .npmignore. Is this a bug? Or is the listing /js-yaml.js in .npmignore supposed to match any file js-yaml.js in any subdirectory as well?

Thanks Isaac! I remove these two lines
/js-yaml.js
/js-yaml.min.js

from the .npmignore file, retested, and it fixed the issue. However, the file /lib/js-yaml.js was excluded as well where it wasn't explicitly listed in .npmignore. Is this a bug? Or is the listing /js-yaml.js in .npmignore supposed to match any file js-yaml.js in any subdirectory as well?

I was advised by the js-yaml author to give more details, and here there are
Results on Mac
airportyhs-MacBook-Air:testem airportyh$ sudo npm install js-yaml
<EMAIL_ADDRESS>./node_modules/js-yaml
airportyhs-MacBook-Air:testem airportyh$ node
> require('js-yaml')
{ scan: [Function: scan],
  compose: [Function: compose],
  load: [Function: load],
  loadAll: [Function: loadAll],
  safeLoad: [Function: load],
  safeLoadAll: [Function: loadAll],
  addConstructor: [Function: addConstructor] }
>

Worked great. Now on Windows
C:\Users\airportyh\testem>npm install js-yaml
npm http GET https://registry.npmjs.org/js-yaml/0.3.1
npm http 304 https://registry.npmjs.org/js-yaml/0.3.1
<EMAIL_ADDRESS>./node_modules/js-yaml

C:\Users\airportyh\testem>node
> require('js-yaml')
Error: Cannot find module './lib/js-yaml.js'
    at Function._resolveFilename (module.js:334:11)
    at Function._load (module.js:279:25)
    at Module.require (module.js:357:17)
    at require (module.js:368:17)
    at Object.<anonymous> (C:\Users\airportyh\testem\node_modules\js-yaml\index.
js:1:80)
    at Module._compile (module.js:432:26)
    at Object..js (module.js:450:10)
    at Module.load (module.js:351:31)
    at Function._load (module.js:310:12)
    at Module.require (module.js:357:17)
>

So, on Windows it can't find the file ./lib/js-yaml.js and I verified that it is indeed not there
C:\Users\airportyh\testem>dir node_modules\js-yaml\lib
 Volume in drive C has no label.
 Volume Serial Number is 14EC-C85F

 Directory of C:\Users\airportyh\testem\node_modules\js-yaml\lib

12/31/2011  10:11 PM    <DIR>          .
12/31/2011  10:11 PM    <DIR>          ..
12/31/2011  10:11 PM    <DIR>          js-yaml
               0 File(s)              0 bytes
               3 Dir(s)   1,539,788,800 bytes free

If I remove the line /js-yaml.js from .npmignore in js-yaml, it fixes the problem. I think this is a bug in npm though, as I don't think listing /js-yaml.js should ignore /lib/js-yaml.js.

I was advised by the js-yaml author to give more details, and here there are
Results on Mac
airportyhs-MacBook-Air:testem airportyh$ sudo npm install js-yaml
<EMAIL_ADDRESS>./node_modules/js-yaml
airportyhs-MacBook-Air:testem airportyh$ node
> require('js-yaml')
{ scan: [Function: scan],
  compose: [Function: compose],
  load: [Function: load],
  loadAll: [Function: loadAll],
  safeLoad: [Function: load],
  safeLoadAll: [Function: loadAll],
  addConstructor: [Function: addConstructor] }
>

Worked great. Now on Windows
C:\Users\airportyh\testem>npm install js-yaml
npm http GET https://registry.npmjs.org/js-yaml/0.3.1
npm http 304 https://registry.npmjs.org/js-yaml/0.3.1
<EMAIL_ADDRESS>./node_modules/js-yaml

C:\Users\airportyh\testem>node
> require('js-yaml')
Error: Cannot find module './lib/js-yaml.js'
    at Function._resolveFilename (module.js:334:11)
    at Function._load (module.js:279:25)
    at Module.require (module.js:357:17)
    at require (module.js:368:17)
    at Object.<anonymous> (C:\Users\airportyh\testem\node_modules\js-yaml\index.
js:1:80)
    at Module._compile (module.js:432:26)
    at Object..js (module.js:450:10)
    at Module.load (module.js:351:31)
    at Function._load (module.js:310:12)
    at Module.require (module.js:357:17)
>

So, on Windows it can't find the file ./lib/js-yaml.js and I verified that it is indeed not there
C:\Users\airportyh\testem>dir node_modules\js-yaml\lib
 Volume in drive C has no label.
 Volume Serial Number is 14EC-C85F

 Directory of C:\Users\airportyh\testem\node_modules\js-yaml\lib

12/31/2011  10:11 PM    <DIR>          .
12/31/2011  10:11 PM    <DIR>          ..
12/31/2011  10:11 PM    <DIR>          js-yaml
               0 File(s)              0 bytes
               3 Dir(s)   1,539,788,800 bytes free

If I remove the line /js-yaml.js from .npmignore in js-yaml, it fixes the problem. I think this is a bug in npm though, as I don't think listing /js-yaml.js should ignore /lib/js-yaml.js.

Yes, that much is a bug, because /js-yaml.js should only match it in the root of the repo, not in a sub directory.  You can work around this for now by explicitly including it by adding !./lib/js-yaml.js as the last line in the .npmignore file.
I'm in the process of rewriting the .npmignore logic from scratch in a generic way.  A pure-js replacement for glob was the first step, and meant putting a lot of love into minimatch.  I'm going to close this bug for now, since it'll be addressed when the ignorefile module is finished, and it's not worth hacking around for now.

Yes, that much is a bug, because /js-yaml.js should only match it in the root of the repo, not in a sub directory.  You can work around this for now by explicitly including it by adding !./lib/js-yaml.js as the last line in the .npmignore file.
I'm in the process of rewriting the .npmignore logic from scratch in a generic way.  A pure-js replacement for glob was the first step, and meant putting a lot of love into minimatch.  I'm going to close this bug for now, since it'll be addressed when the ignorefile module is finished, and it's not worth hacking around for now.

Okay, thanks a lot!

Okay, thanks a lot!


fix: broken URL link to demo site

Codecov Report

Merging #543 (f2f33ae) into main (b6dea09) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #543   +/-   ##
=======================================
  Coverage   39.70%   39.70%
=======================================
  Files         122      122
  Lines        6294     6294
  Branches     1541     1541
=======================================
  Hits         2499     2499
  Misses       3483     3483
  Partials      312      312

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Extending Twig

Can I have guidance regarding extending twig with custom filters and functions? Not sure where to code is located

Found it.


[Bug]

🐞 Bug Report
Describe the bug

Is this a regression?

To Reproduce

Expected behaviour

Media prove

Your environment

OS:
Node version:
Npm version:
Browser name and version:

Additional context

I want to correct/supplement all the above suggestions. It's exactly what I thought it would be when using portfolio.


Is the 10A Version the same or different?

Is it possible to do the changes to the 10A Version in the same manner as to the 100A Version?

I think it uses a shunt resistor instead of a  CT but I think the rest of the circuit is probably the same. Can't say for sure because I don't have one but I would assume the mod would still work
On Tuesday, 25 October 2022 at 12:53:04 BST, joed74<EMAIL_ADDRESS>wrote:

Is it possible to do the changes to the 10A Version in the same manner as to the 100A Version?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


MEMO doesn't scale well to large numbers of genomes

This is an incomplete list, but for example:

"too many open files" errors occur in Bash for large numbers of genomes. At a minimum adjusting ulimit for these might be a good idea, but it would be better if it was handled in Python and not so many files were opened in the first place.

Code like this does not take large numbers of genomes into account, causing "ValueError: invalid literal for int() with base 10" because the 1010111... number is too long for int on each line:

# plot_conservation.py line 52
num_docs_per_pos = list(map(int, list(fileReader(path))))

Thank you for bringing up these issues! I'll keep this in mind and see what I can do to make MEMO more scalable.

I'm not bringing them up just to complain. The number of available genomes is increasing at a fast rate, so we really need tools like this one to scale well. I appreciate your work.


Refactoring code based on Nicolas feedback and adding currency exchange after invoice settlement

The biggest things to review:

@NicolasDorier has refactored the connection string to remove unnecessary parameters and options.
I would like input from @Marfusios on two TODO items left: https://github.com/rockstardev/strike-btcpayserver-plugin/commit/ff21690005873b6d7c2a94a974f13654f8562e14.

Most of the points and explanations from my first PR still stand: https://github.com/rockstardev/strike-btcpayserver-plugin/pull/1.
I have already deployed a version with these changes and will start production testing. I would very much like to merge this upstream based on @Marfusios's feedback and then use that version going forward.
@Marfusios, what needs to be removed from this PR are references to the Strike.Client library whenever you merge this PR: https://github.com/Marfusios/strike-client/pull/10.

The TenantId bug that affected us during yesterday's testing of multiple stores has now been resolved. Additionally, both of my previously mentioned TODO items have been addressed.
I had a pair programming session with @NicolasDorier to explain my rationale behind refactoring the listening functionality into StrikePluginHostedService. We also agreed that removing the dependency on OData Builder was a good idea. Instead, we will use bulks and hit the Strike API multiple times with the $filter OData query.
The only remaining task is to introduce proper indexes, which @NicolasDorier will handle on top of this PR. After that, we need a review from @Marfusios so we can merge the changes upstream instead of relying on my fork of the plugin.

I have significantly refactored the library after stress testing on Friday when I realized that dependence on TenantId creates issues as soon as you have more than one store.
During our testing, we created a second store that kept payments in Bitcoin. As soon as we did that, we stopped getting notifications for payments because TenantId got set to whatever the latest connection string specified.
Now, with these changes, you get a nice effect - even if you have 20 stores, as long as they share the Lightning connection string, they'll be serviced by one listener loop in HostedService and one StringLightningClient (since it's the same TenantId).
I'm available to meet in the next two days to go over the changes and explain the ideas behind them. The problem is that we are now almost out of time; I'll have to go with these set of changes since I don't have time to test new approaches.

Now, with these changes, you get a nice effect - even if you have 20 stores, as long as they share the Lightning connection string, they'll be serviced by one listener loop in HostedService and one StringLightningClient (since it's the same TenantId).

I tried to incorporate your changes into the master branch, and I think it works as expected.
Tested multiple stores with different currencies but the same API key and worked flawlessly.
It is released under 1.2.3 version

Closing as the plugin was reimplemented to use the new API Receive requests 9c0a9ef65b0d28cf034c43158265a370ff538abd


Change icon

Change icon to white on red version.

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

GitHub release
v1.31.3

Your semantic-release bot :package::rocket:


mavros: 2.7.0-1 in 'rolling/distribution.yaml' [bloom]

Increasing version of package(s) in repository mavros to 2.7.0-1:

upstream repository: https://github.com/mavlink/mavros.git
release repository: https://github.com/ros2-gbp/mavros-release.git
distro file: rolling/distribution.yaml
bloom version: 0.11.2
previous version for package: 2.6.0-1

libmavconn
* Merge branch 'master' into ros2
  * master:
  1.18.0
  update changelog
  sys_status.cpp: improve timeout code
  sys_status.cpp: Add a SYS_STATUS message publisher
  [camera plugin] Fix image_index and capture_result not properly filled
  Fix missing semi-colon
  GPS_STATUS Plugin: Fill in available messages for ROS1 legacy
* 1.18.0
* update changelog
* Contributors: Vladimir Ermakov

mavros
* Merge branch 'master' into ros2
  * master:
  1.18.0
  update changelog
  sys_status.cpp: improve timeout code
  sys_status.cpp: Add a SYS_STATUS message publisher
  [camera plugin] Fix image_index and capture_result not properly filled
  Fix missing semi-colon
  GPS_STATUS Plugin: Fill in available messages for ROS1 legacy
* 1.18.0
* update changelog
* move /conn parameters to /sys and /time
* sys_status.cpp: improve timeout code
  # Conflicts:
  #     mavros/src/plugins/sys_status.cpp
* sys_status.cpp: Add a SYS_STATUS message publisher
* Removed warning from geometry2 header
* Fix PR 1922 regarding EVENT message
* use synchronise_stamp to create stamp
* new checksum for event enum
* remove event_time_boot_ms, fill stamp instead
* handle events
* fix mav service  call and wp load
* Remove hardcoded namespace from px4_pluginlists
* Remove hardcoded namespace from px4_config
* Define _frd frames in odom plugin based on parent/child frame parametrs
* Define parameters for base_link, odom, map frames
* Contributors: Alejandro Hernández Cordero, Dr.-Ing. Amilcar do Carmo Lucas, Mattia Giurato, Mohamed Abdelkader, Vladimir Ermakov, elgarbe, sathak93, victor

mavros_extras
* re-generate with cogall.sh
* Merge branch 'master' into ros2
  * master:
  1.18.0
  update changelog
  sys_status.cpp: improve timeout code
  sys_status.cpp: Add a SYS_STATUS message publisher
  [camera plugin] Fix image_index and capture_result not properly filled
  Fix missing semi-colon
  GPS_STATUS Plugin: Fill in available messages for ROS1 legacy
* 1.18.0
* update changelog
* [camera plugin] Fix image_index and capture_result not properly filled
* [camera plugin] Fix image_index and capture_result not properly filled
* Update mavros_plugins.xml
* Update wheel_odometry.cpp
  fix typo
* Fix typo
  fix typo in odometry frame child id
* Removed unused variable
* Use SensorDataQoS for gp_origin subscriber
* Fix missing semi-colon
* GPS_STATUS Plugin: Fill in available messages for ROS1 legacy
  Filled in available fields in GPS_RAW_INT & GPS2_RAW messages
  p.s. seems GPS2_RAW more complete than original GPS_RAW_INT
* Define _frd frames in odom plugin based on parent/child frame parametrs
* Contributors: Beniamino Pozzan, Kristoffer Bergman, Matteo Molinari, Mattia Giurato, Mohamed Abdelkader, Seunghwan Jo, Vladimir Ermakov, hpbrandal

mavros_msgs
* re-generate with cogall.sh
* Merge branch 'master' into ros2
  * master:
  1.18.0
  update changelog
  sys_status.cpp: improve timeout code
  sys_status.cpp: Add a SYS_STATUS message publisher
  [camera plugin] Fix image_index and capture_result not properly filled
  Fix missing semi-colon
  GPS_STATUS Plugin: Fill in available messages for ROS1 legacy
* 1.18.0
* update changelog
* sys_status.cpp: Add a SYS_STATUS message publisher
* cog checksum
* remove event_time_boot_ms, fill stamp instead
* handle events
* Fix errata in GPSRAW.msg
* Contributors: Dr.-Ing. Amilcar do Carmo Lucas, Seunghwan Jo, Vladimir Ermakov, victor

Rolling is currently in transition to Ubuntu 24.04. The metadata created by bloom is platform specific and will need to be regenerated once the transition has been completed. It will not be necessary for you to tag a new source release, re-running bloom once Rolling has been updated will be sufficient to create a release targeting Rolling on 24.04.


Cannot add second domain

I tried to switch my primary domain. In the portal there is option only to create alias, so I tried the gam command  gam create domain xxxxxx. This is giving the following error
Error 412: The customer cannot add new domains as multidomain feature for the customer is disabled. - conditionNotMet

Do I need to activate some settings to add secondary domain?

Hi chetan
Do you have the free version of Google Apps or are you paying a
subscription? If you go to the Admin Console and select the Billing option,
it should tell you which version you have
Secondary domains are not available on the old free version, so in order to
use the rename you would need to upgrade to the paid for version (and you
cannot roll back to the free version)
Graham
Graham Ingleby | Cloud Computing Consultant | +44 1344 203395 |
<EMAIL_ADDRESS>[image: Google+] http://google.com/+Ancoris
http://www.linkedin.com/company/98835 http://www.ancoris.com
http://www.ancoris.com/news-and-views/ancoris-blog/crn-recognises-ancoris-with-2015-cloud-services-provider-award.html
http://www.ancoris.com/news-and-views/ancoris-blog/crn-recognises-ancoris-with-2015-cloud-services-provider-award.html
On 2 December 2015 at 18:41, Chetan Sachdev<EMAIL_ADDRESS>wrote:

I tried to switch my primary domain. In the portal there is option only to
create alias, so I tried the gam command gam create domain xxxxxx. This
is giving the following error
Error 412: The customer cannot add new domains as multidomain feature for the customer is disabled. - conditionNotMet
Do I need to activate some settings to add secondary domain?
—
Reply to this email directly or view it on GitHub
https://github.com/jay0lee/GAM/issues/139.

--

This message is for the named person's use only.  If you receive this message in error, please delete it and notify the sender.  Ancoris reserves the right to monitor all e-mail communications through its networks. Ancoris Limited, Registered in England Number: 04830784, Registered address: 5a Frascati Way, Maidenhead, Berkshire SL6 4UY. Trading Address: Lily Hill House, Lily Hill Road, Bracknell, Berkshire RG12 2SJ

I also have the old Free edition. Tried to use Directory API (directory.customers.patch) but online tool has  problem (Invalid language error).
I finally, got GAM going on my mac. I have seen the same problem that secondary domain is disabled. I tired to do the rename with alias but it doesn't work.
It looks like there are no way to rename primary domain that has expired.
Taylor

The old free edition doesnt support secondary domains, only aliases
The rename only supports secondary domains, not aliases
Upshot is you cannot rename an old free domain - shame as I would like to
do that myself
Graham Ingleby | Cloud Computing Consultant | +44 1344 203395 |
<EMAIL_ADDRESS>[image: Google+] http://google.com/+Ancoris
http://www.linkedin.com/company/98835 http://www.ancoris.com
http://www.ancoris.com/news-and-views/ancoris-blog/crn-recognises-ancoris-with-2015-cloud-services-provider-award.html
http://www.ancoris.com/news-and-views/ancoris-blog/crn-recognises-ancoris-with-2015-cloud-services-provider-award.html
On 12 December 2015 at 06:11, Taylor luk<EMAIL_ADDRESS>wrote:

I also have the old Free edition. Tried to use Directory API
(directory.customers.patch) but online tool has problem (Invalid language
error).
I finally, got GAM going on my mac. I have seen the same problem that
secondary domain is disabled. I tired to do the rename with alias but it
doesn't work.
It looks like there are no way to rename primary domain that has expired.
Taylor
—
Reply to this email directly or view it on GitHub
https://github.com/jay0lee/GAM/issues/139#issuecomment-164114218.

--

This message is for the named person's use only.  If you receive this message in error, please delete it and notify the sender.  Ancoris reserves the right to monitor all e-mail communications through its networks. Ancoris Limited, Registered in England Number: 04830784, Registered address: 5a Frascati Way, Maidenhead, Berkshire SL6 4UY. Trading Address: Lily Hill House, Lily Hill Road, Bracknell, Berkshire RG12 2SJ

Closing issue as this is WAI.


Can't get to comments of link post

From my user profile https://www.lesserwrong.com/users/j_thomas_moros I have a number of link posts that show under blog posts.  I can't find anyplace to click that takes me to the comments on the post (i.e. to the LW page for the post) rather than to the link.

This is not confined to link posts on the user profile.  The same issue exists on the daily page.  For example, see "dojo - Bad day contingency plan" on 2017-10-02

Should be fixed with latest update.


SymPy for preprocessing examples

While dependence on SymPy was dropped in #37 for computing basis functions, it might be useful for preprocessing certain examples.  It would not then be a dependence for the scikit-fem package, just for the examples.
One is suggested by the FEniCS tutorial example ft05_nonlinear_poisson.py. The example is basically like docs/examples/ex10.py, except that it adds an artificial right-hand side to balance the equation for a specified solution; i.e. it uses the method of manufactured solutions.  That right-hand side is computed from the stipulated exact solution using SymPy.
A translation of the FEniCS example into scikit-fem is at https://github.com/gdmcbain/fenics-tuto-in-skfem/tree/master/05_poisson_nonlinear.  It goes beyond the original in using:

sympy.vector for gradient and divergence
sympy.utilities.lambdify to evaluate symbolic vector fields on points specified by a numpy.ndarray like Mesh.p

There are a few examples (ex12, ex13, ex14, ex16, ex17, ex18, ex19, ex20) which involve exact solutions; I wonder whether it would be worth modifying one or more of them to use SymPy to compute the exact solution to show how it's done here.

According to Cellier & Ruyer-Quil (2019), Scikit-FDiff uses SymPy to allow ‘easy and automated finite difference discretization’; might be worth a look for inspiration or comparison.

Cellier, N. & Ruyer-Quil, C. (2019). scikit-finite-diff, a new tool for PDE solving. Journal of Open Source Software, 4, 1356. doi:10.21105/joss.01356


Alt-Tab stops working with #Include <dual/defaults>

The standard Windows Alt-TAB behavior stops working altogether when I include defaults.ahk. If I edit defaults.ahk to comment out Tab from the list of combo keys, it works normally again.
I get this problem without configuring any specific keys, using this as my AutoHotkey.ahk:
SendMode Input
#NoEnv
#SingleInstance force

#Include <dual/dual>
dual := new Dual()
#Include <dual/defaults>

*ScrollLock::dual.reset()

I'm on Windows 8.1, AutoHotKey <IP_ADDRESS>, dual from github trunk.

Thanks for noting and providing a workaround! I'm sure it'll help others running into the issue.


Remove ActorScanInterval

This PR is built on top of #6669 (which is included in this PR) . In draft until that's merged

Small refactoring to the actors subsystem to remove the "ActorScanInterval" configuration. Idle actors are now deactivated automatically shortly after the idle timeout for their actor type.
Benefits:

Simplifies the experience for users who now need to worry about one less property
Makes the actor subsystem more predictable: idle actors are now deactivated after the idle timeout, and there's no uncertainty due to the next scan interval.
Should offer some perf improvements since we are not scanning the map of active actors on regular intervals.

This is not minor and this setting has been key to balance timely GC and CPU usage.

Yes, that's why it's been removed :) Before there was a goroutine that on an interval was scanning all actors, thus with the concerns around GC and CPU. Now, we block the goroutine until we know an actor becomes idle.
You can see the single commit here: https://github.com/dapr/dapr/pull/6715/commits/c75700f48c63ca4f056979f1a2cf0909cce813d4

We can't remove this for this release as it's a breaking chang. We can mark this as deprecated in 1.12 (if there's consensus for it) and then remove in 1.14.

We can't remove this for this release as it's a breaking change. We can mark this as deprecated in 1.12 (if there's consensus for it) and then remove in 1.14.

There's no breaking change and it's a pretty important perf improvement (see #6592)

We can't remove this for this release as it's a breaking change. We can mark this as deprecated in 1.12 (if there's consensus for it) and then remove in 1.14.

There's no breaking change and it's a pretty important perf improvement (see #6592)

It's documented as part of the API and contract between Dapr and the app. Removing this will result in a breaking behavioral change.

We can't remove this for this release as it's a breaking change. We can mark this as deprecated in 1.12 (if there's consensus for it) and then remove in 1.14.

There's no breaking change and it's a pretty important perf improvement (see #6592)

It's documented as part of the API and contract between Dapr and the app. Removing this will result in a breaking behavioral change.

cc @daixiang0 @mukundansundar

We can't remove this for this release as it's a breaking change. We can mark this as deprecated in 1.12 (if there's consensus for it) and then remove in 1.14.

There's no breaking change and it's a pretty important perf improvement (see #6592)

It's documented as part of the API and contract between Dapr and the app. Removing this will result in a breaking behavioral change.

It doesn't alter the behavior that actors are deactivated after they become idle for a certain amount of time. If the scan interval option is passed, it is ignored.
This just makes it more efficient and more predictable. Before, if scan interval was 5s, an idle actor could be deactivated right away or after 5s. Now, idle actors are deactivated "as soon as" their timeout expires.
There's no user-facing behavior change. Per the contract, users should have assumed that an actor could be deactivated any time after its idle timeout passed. This doesn't change that at all.

Ok, so to be clear:
If a user passes an ActorScanInterval value of 1m, can they expect an actor to become deactivated after 1m?

Ok, so to be clear:
If a user passes an ActorScanInterval value of 1m, can they expect an actor to become deactivated after 1m?

If a user passes "ActorIdleTimeout" of 1m, they can expect an actor to be deactivated after 1m of inactivity. This was the case before and is the case after
What changed is:

Before: if users passed "ActorScanInterval" of 1m, the (idle) actor could be deactivated after 1 min of becoming idle in the "best case" scenario, and 2 mins in the "worst case" scenario. This was not guaranteed and it depended on where in the scan loop the actor runtime was. Users should have assumed the actor's lifetime was not to extend 1m after becoming idle.
After: there's no "ActorScanInterval", so an actor that becomes idle is deactivated "right after". This means that an idle actor gets deactivated after 1 min of becoming idle in all cases.

https://docs.dapr.io/developing-applications/building-blocks/actors/actors-runtime-config/

Ok, so to be clear:
If a user passes an ActorScanInterval value of 1m, can they expect an actor to become deactivated after 1m?

If a user passes "ActorIdleTimeout" of 1m, they can expect an actor to be deactivated after 1m of inactivity. This was the case before and is the case after
What changed is:

Before: if users passed "ActorScanInterval" of 1m, the (idle) actor could be deactivated after 1 min of becoming idle in the "best case" scenario, and 2 mins in the "worst case" scenario. This was not guaranteed and it depended on where in the scan loop the actor runtime was. Users should have assumed the actor's lifetime was not to extend 1m after becoming idle.
After: there's no "ActorScanInterval", so an actor that becomes idle is deactivated "right after". This means that an idle actor gets deactivated after 1 min of becoming idle in all cases.

https://docs.dapr.io/developing-applications/building-blocks/actors/actors-runtime-config/

I'm not debating the benefits or correctness of this change, simply this is a clear breaking change and should be treated as such. Will wait for feedback of other maintainers on this.

I'm not debating the benefits or correctness of this change, simply this is a clear breaking change and should be treated as such. Will wait for feedback of other maintainers on this.

I am not sure I follow. Why do you consider this a breaking change?

Can this be enabled via a configuration. If ActorScanInterval <= 0 then it is the new behavior, otherwise it is the old behavior.

I didn't think this would be controversial as it shouldn't be a breaking change at all.
The current behavior is that there's an optimistic case, which is that actors are deactivated as soon as the idle timeout passes, and a pessimistic case, which is that actors stay alive for longer, as long as the scan interval. There's obviously a trade-off between the two things: keeping actors alive for longer uses more resources, while a shorter scan interval means more frequent scans which use more resources too. I believe @artursouza when he says that the scan interval option was added to find the right balance with GC and CPU usage.
The point of this change is to remove the make the optimistic case the only case. It's quite literally the "have your cake and eat it too": you get actors that are deactivated right away after the idle timeout (so not wasting more resources and acting very predictably), and you don't pay the cost of the periodic scan interval.
Although it's true this PR does remove a configuration option, it does that by retaining the same functionality, so users are not missing out on anything. I would be surprised to hear from anyone complaining about this.

The only situation where users would be impacted here is if they were counting on actor scan interval as a way to "extend" the lifetime of an actor beyond its idle timeout. I am not concerned about these users much because they shouldn't have done this to begin with: in some cases the actors were alive for an extra "scan interval" time, but in others they'd be terminated right away, and users should not have taken a dependency on this random behavior.

I would be surprised to hear from anyone complaining about this

Personally knowing how many users are using it, I wouldn't be.

Although it's true this PR does remove a configuration option, it does that by retaining the same functionality

Yes, but that same functionality is retained by utilizing a different configuration option. If you had said that users who previously set ActorScanInterval to 7h and expected that actors get deactivated after 7 hours (at minimum) or later would expect the exact same behavior when moving to 1.12 without code changes, then I would have agreed this should ot be considered a breaking change. To my understanding, this is not what's being said.

Yes, but that same functionality is retained by utilizing a different configuration option. If you had said that users who previously set ActorScanInterval to 7h and expected that actors get deactivated after 7 hours (at minimum) or later would expect the exact same behavior when moving to 1.12 without code changes, then I would have agreed this should not be considered a breaking change. To my understanding, this is not what's being said.

Hold on, I think I understand where the misunderstanding is. Are you maybe thinking of ActorIdleTimeout?

ActorIdleTimeout is what determines how long after the last message the actor is considered idle.
ActorScanInterval indicates how often the loop runs to check which actors are idle and are past ActorIdleTimeout.

If you want actors to have a 7h lifetime minimum, you set ActorIdleTimeout to 7h. This will not change in this PR.

I will make this clearer - If users set ActorScanInterval to any value in 1.11.x and expected the scan to elapse at the configured interval to check which actors are idle after ActorIdleTimeout, and after having upgraded to 1.12.x have not changed anything in their code or configuration and are observing a different behavior, then this is a breaking change.

if users set ActorScanInterval to any value in 1.11.x and expected the scan to elapse at the configured interval to check which actors are idle after ActorIdleTimeout

Users must not have this expectation. Actors in 1.11 can be terminated any time after ActorIdleTimeout lapses. In the "optimistic case", the loop happens immediately after so actors are terminated right away.
For users to rely on the pessimistic case to determine the lifecycle of an actor is a bug even in 1.11 because it is not deterministic.

if users set ActorScanInterval to any value in 1.11.x and expected the scan to elapse at the configured interval to check which actors are idle after ActorIdleTimeout

Users must not have this expectation. Actors in 1.11 can be terminated any time after ActorIdleTimeout lapses. In the "optimistic case", the loop happens immediately after so actors are terminated right away.
For users to rely on the pessimistic case to determine the lifecycle of an actor is a bug even in 1.11 because it is not deterministic.

Bug or not, expectation or not - are all subjective. What's not subjective is that we are removing an API field that will no longer do what it was supposed to do, and that is objectively a breaking change that we must, and will, treat as one.

I think the suggestion made by @artursouza to retain backwards-compat is solid and should allow this PR to be merged once implemented.

PS: please don't "merge master" into draft PRs. When the underlying PR is merged, I'll have to cherry-pick the second commit and having master merged in makes that harder! 🙏

👍

The current behavior is that a 0 value means "accept the default", which is 30s. So that could be a breaking change too per your definition.

If a user isn't required to perform any changes to their code/config from 1.11 to 1.12 and will observe the exact same behavior as they did before, then this isn't a breaking change.

This PR is now ready for review and it's been updated to be even more efficient thanks to using a priority queue, which allows avoiding all scans of the active actors table. (The Queue and Processor structs used by the priority queue are the same used for #6716).
I have expanded the description and also included an explanation on why this does not include a breaking change for users, and at the same time offers very welcome improvements on perf and ease of use.
I ask maintainers to please give this a reconsideration.

I have expanded the description and also included an explanation on why this does not include a breaking change for users, and at the same time offers very welcome improvements on perf and ease of use.

Thanks for the update. The ActorScanInterval field exists as a public contract in all Dapr SDKs. If we remove it from the runtime, we must also remove it from the SDKs. In that case, applications that update their dependencies to a new Dapr SDK version as part of upgrading to Dapr 1.12 will break at compilation time, forcing users to change their code to adapt. Do you agree this is a breaking change for the SDKs, and in general how do you suggest we tackle that issue if we remove ActorScanInterval?

I have expanded the description and also included an explanation on why this does not include a breaking change for users, and at the same time offers very welcome improvements on perf and ease of use.

Thanks for the update. The ActorScanInterval field exists as a public contract in all Dapr SDKs. If we remove it from the runtime, we must also remove it from the SDKs. In that case, applications that update their dependencies to a new Dapr SDK version as part of upgrading to Dapr 1.12 will break at compilation time, forcing users to change their code to adapt. Do you agree this is a breaking change for the SDKs, and in general how do you suggest we tackle that issue if we remove ActorScanInterval?

The field can continue to be provided it is just ignored. SDKs can manage the deprecation nicely, and make the property a no-op to avoid breaking users. So outdated SDKs will send the field which is ignored by the runtime. Updated SDKs can continue to have the method which either sends the field (for compat with old Dapr versions), or becomes a no-op.

I have expanded the description and also included an explanation on why this does not include a breaking change for users, and at the same time offers very welcome improvements on perf and ease of use.

Thanks for the update. The ActorScanInterval field exists as a public contract in all Dapr SDKs. If we remove it from the runtime, we must also remove it from the SDKs. In that case, applications that update their dependencies to a new Dapr SDK version as part of upgrading to Dapr 1.12 will break at compilation time, forcing users to change their code to adapt. Do you agree this is a breaking change for the SDKs, and in general how do you suggest we tackle that issue if we remove ActorScanInterval?

The field can continue to be provided it is just ignored. SDKs can manage the deprecation nicely, and make the property a no-op to avoid breaking users. So outdated SDKs will send the field which is ignored by the runtime. Updated SDKs can continue to have the method which either sends the field (for compat with old Dapr versions), or becomes a no-op.

As an SDK maintainer I feel uncomfortable providing a field that has no use, because this not only affects existing users but more so it means developers who are getting started with the SDK have an option that is seemingly provided for them but in fact does nothing. It creates a drift between the API spec of the runtime and the different SDKs. So far changes /removals made to the API spec were followed by SDK changes in the same release, the Configuration API is a recent example. At the very least we need to communicate to SDK maintainers that a runtime flag present as a typed entity in their SDK is going to be removed.

Alright, if that’s the consensus among maintainers we’ll merge this PR in our distribution. Actor perf is important to us and we want to provide our users the best experience.
Thanks for the feedback.

Alright, if that’s the consensus among maintainers we’ll merge this PR in our distribution. Actor perf is important to us and we want to provide our users the best experience.
Thanks for the feedback.

I don't know if that's the consensus among maintainers.. we're still waiting for feedback here. There's no reason to close this PR.

@mukundansundar @daixiang0 your input on this matter is required as we want to arrive at a resolution of this soon.


Automated cherry pick of #2026: fix: zstack system disk resize

Cherry pick of #2026 on release/2.10.0.
#2026: fix: zstack system disk resize

Codecov Report

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

@@               Coverage Diff                @@
##             release/2.10.0   #2028   +/-   ##
================================================
  Coverage                  ?   7.61%
================================================
  Files                     ?     410
  Lines                     ?   63186
  Branches                  ?       0
================================================
  Hits                      ?    4812
  Misses                    ?   57963
  Partials                  ?     411

Flag
Coverage Δ

#aFlag
7.61% <ø> (?)

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 9ffc238...62391c7. Read the comment docs.

/lgtm

/approve


Replacing package with new source

Hello,
I've seen the FAQ section on changing the repo when a package is transferred to a new owner, but I'm wondering what could be done when a new project wants to replace an old one.
In this instance, non-jedi registered https://github.com/non-Jedi/Org.jl as Org in 2019 but hasn't had the time he hoped to spend on it since. I have recently developed https://github.com/tecosaur/Org.jl which has progressed much further, and talking to non-jedi we'd both be happy if my Org.jl replaced his in the registry.
What would be the best way to accomplish this? I see for transfers a repo URL edit is all that's needed, but here the UUID and git sha for non-jedi's v0.1 wouldn't match. Is v0.1 cached in such a way that this could be switched and I could release v0.2 without any issues?
One hacky way that I'd imagine this works is if:

I delete my repo
non-jedi transfers his repo to me
I add a commit wiping everything
I cherry-pick all of my commits on top of the repo
I add a commit changing my UUID to match non-jedi's UUID
I open a "package transfer" PR changing the repo URL

However, this feels like a last resort to me.

You can merge the two git histories like was done with LightGraphs. Then all that has to be done on this repo is changing the repo location. This will obviously have fewer potential conflicts than were introduced by the lightgraphs procedure since nobody uses my existing package.

Thanks for that link, I've ended up doing it in two parts, but I think it's sorted now. For anyone that stumbles across this in future, the git merge flag --allow-unrelated-histories came in handy.


Add more notification platforms

Take a look at apprise for it.

Just to confirm, adding more notification platforms means like WhatsApp, Gmail, etc. right?

hi following up

For me it's useful:

Matrix
Xmpp (not in apprise)
Linux notifications
Mastodon
Mail

Hey,
We are planning to add integrations with platforms like PagerDuty and Opsgenie since they are the most actively used alerting platforms in engineering organizations.
Is that what you were referring to?

Thanks, yes, that's what I meant. I would like to learn more about the integration with Opsgenie and the current plans, so I can contribute as well.


deadname remover breaks reddit on brave

i know this isn't very helpful to the issue but please use firefox

i know this isn't very helpful to the issue but please use firefox

if firefox was good, I would use it.


Muted microphone becomes unmuted after connection drop and rejoin

From community email list:
%%%
I have a problem with edumeet. The problem arises when someone has a poor connection and the connection is lost. After restoring the connection, the client enters the conference automatically with the microphone on. Interestingly, his microphone is marked in red, which suggests that it is turned off. Unfortunately, everyone can hear him.  My users are reporting the problem. I checked it out and it really is. The same happens not only on my servers but also on servers in other universities.
%%%

I have fixed it in #963

According to Barteck this is only in master branch but anyways closing this.


plugin/ocgrpc: TestEndToEnd_Single failing on Travis

Just seen on https://travis-ci.org/census-instrumentation/opencensus-go/builds/416994981?utm_source=github_status&utm_medium=notification
--- FAIL: TestEndToEnd_Single (0.02s)
	end_to_end_test.go:202: Failed to find row with keys [{{grpc_server_method} testpb.Foo/Single} {{grpc_server_status} UNKNOWN}] among:
		[[{{grpc_server_method} testpb.Foo/Single} {{grpc_server_status} OK}]]
    --- PASS: TestEndToEnd_Single/view=grpc.io/client/sent_messages_per_rpc (0.00s)
    --- FAIL: TestEndToEnd_Single/view=grpc.io/server/received_messages_per_rpc (0.00s)
    	end_to_end_test.go:92: Count = 1; want 2
    --- PASS: TestEndToEnd_Single/view=grpc.io/client/received_messages_per_rpc (0.00s)
    --- FAIL: TestEndToEnd_Single/view=grpc.io/server/sent_messages_per_rpc (0.00s)
    	end_to_end_test.go:92: Count = 1; want 2
    	end_to_end_test.go:95: Mean = 1; want 0.5
    --- PASS: TestEndToEnd_Single/view=grpc.io/client/sent_bytes_per_rpc (0.00s)
    --- FAIL: TestEndToEnd_Single/view=grpc.io/server/received_bytes_per_rpc (0.00s)
    	end_to_end_test.go:92: Count = 1; want 2
    	end_to_end_test.go:95: Mean = 0; want 1

Of which the PR https://github.com/census-instrumentation/opencensus-go/pull/866 seems unrelated to that failure and running it locally both on 32-bit and 64-bit mode passes

It turned out to be a flake as the subsequent non-related code push https://travis-ci.org/census-instrumentation/opencensus-go/builds/417004244 got it to pass. Nonetheless concerning that the test failed once in the first place, hopefully not an obscure race?


[RFC] Missing parts of libc required for CivetWeb

Introduction
This issue is created as prompted by the discussion on the Networking Forum.
We are working on implementing support for CivetWeb HTTP library (https://github.com/civetweb/civetweb), but it requires improvements in the libc layer. It's a good example of an external project using sockets APIs that should be relatively easy to integrate with Zephyr, as a proof of concept.
Problem description
CivetWeb uses different POSIX API calls, as any application or library runnable on Linux.
Using Newlib is not an option due to heavy conflicts with the POSIX layer (see https://github.com/zephyrproject-rtos/zephyr/issues/13787).
Improving minimal-libc requires some consideration to maintain compatibility with other layers.
Here we list features missing from minimal-libc that would be required for CivetWeb to work.
Detailed RFC
Here is the list of functions that are used by CivetWeb, with pull requests were applicable.
For some we will prepare stub implementations that will be enough to get the library to work.

strcspn (https://github.com/zephyrproject-rtos/zephyr/pull/16451)
iscntrl (https://github.com/zephyrproject-rtos/zephyr/pull/16451)
strerror (https://github.com/zephyrproject-rtos/zephyr/pull/16527)
strtoull, strtoll (https://github.com/zephyrproject-rtos/zephyr/pull/16511)
atof (we have the implementation ready, will publish it with [DNM] for reference)
sscanf
localtime
gmtime
time
difftime

Dependencies
This is relevant to the POSIX and libc layers. Also time Infrastructure is affected.
CC: @pfalcon @nashif @rakons @andrewboie @jukkar @laperie @tgorochowik
Concerns and Unresolved Questions
The main purpose of minimal-libc is to be, well, minimal. Further work should preserve this approach.
Time related functions rely on a concept of current time. Right now there is no such thing in Zephyr.
There is a proposal by @pfalcon we were about to follow, using the work he submitted via https://github.com/zephyrproject-rtos/zephyr/pull/15602
Current status
As suggested by @nashif (see https://github.com/zephyrproject-rtos/zephyr/pull/16451), we will now proceed with including relevant functions in the sample itself.

Using Newlib is not an option due to heavy conflicts with the POSIX layer (see #13787).

To me this seems like what we should be spending effort on fixing.

Using Newlib is not an option due to heavy conflicts with the POSIX layer (see #13787).

To me this seems like what we should be spending effort on fixing.

Not only that, but the quoted issue, #13787, was made to draw attention to the problem, and gather interested parties to brainstorm and solve the issue. Not to provide interested parties with excuses for not doing that ;-).

No excuses here, we'd love to see newlib and posix support to be too notch.
And I think we discussed that already on the networking forum and there is an agreement in that matter. It doesn't mean though that this is the first step we should do, or can do, to keep the topic active.
@laperie asked me to create this issue to keep track of things. I added you to CC because we discussed these topics earlier.

create this issue to keep track of things. I added you to CC because we discussed these topics earlier.

This is absolutely great that you posted this ticket and also RFC on the mainling list! The same should have been be done regarding CivetWeb (for as long as that effort is supposed to influence Zephyr back, and not just independent porting effort).
However, please kindly accept the possibility to receive criticism as a result of posting this RFC - that's done both for common good, and to potentially save your own efforts from going in the wrong direction.

And I think we discussed that already on the networking forum

I find that discussion such insightful that I decided to put off other tasks assigned to me and cleaned up and flushed a number of patches I had in my queue:

https://github.com/zephyrproject-rtos/zephyr/pull/16621
https://github.com/zephyrproject-rtos/zephyr/pull/16626
https://github.com/zephyrproject-rtos/zephyr/pull/16009
https://github.com/zephyrproject-rtos/zephyr/pull/15937

I didn't lie however that POSIX/Newlib issues isn't going to be fixed, unless people will contribute to that fixing. It can be as small as testing and voting up, but it has to be there. For example, my patches above turn into the usual bikeshed playground (and I see the same happening with @tgorochowik's and @PiotrZierhoffer's patches). Again, there should be active interest to get that into working state, and common approach and understanding, or it will be drown in Zephyr's ever-growing patch well.

@pfalcon, by all means, your insight and comments are always very welcome!

This is absolutely great that you posted this ticket and also RFC on the mainling list!

Oops, multitasking too much. I saw a github notification in email, and my mind tricked me into seeing the desirable - that it was also posted on the Zephyr "devel" mailing list. Well, I'd suggest to do that anyway, even if a quick link to this ticket. Doing so helps the much wider audience to stay in loop on Zephyr's developments and progress. And as pointed several times already, gathering critical mass is a muss for such projects. Thanks in advance.

@pfalcon , yeah, about multitasking - I missed your message, sorry for that. I will post to devel at once.

@PiotrZierhoffer:

@pfalcon , yeah, about multitasking - I missed your message, sorry for that. I will post to devel at once.

Many thanks for posting, and sorry for lack of reply from my side - company sprint, followed by vacation. That's definitely helpful, as we clearly have different parties interested in this matter, while not aware of the current state of affairs, so any publicity efforts like that are required, even if seemingly don't lead to immediate responses.
I, from my side, have been working on "POSIX subsys maintenance approach RFC" which I promised, and I hope to post it shortly (definitely before going for another vacation streak by the end of next week).

civetweb is no longer a module, closing


(docs) rename Telekube -> Gravity + introduce opscenter earlier

Closin in favor of https://github.com/gravitational/gravity/pull/313


Multiple networks

Add support for multiple networks.

Docs also need an update for deploying the seed and any other changes necessary


Moving to completed folder

In PT 0.23, PicoTorrent would move a finished download to the order I specified in Preferences -> Move completed downloads. In 0.24, this no longer happens -- the completed downloads stay, where they are, as if the "Move completed downloads" checkmark was not set. Is this a bug?

This is odd - a similar bug was reported in 0.23 (#1033) but was then closed because it worked fine in 0.24 🤔
If it's not working, it's a bug 😄
How have you configured it? Did you check Only move from default save path? If so, the torrent is only moved if it was downloaded to the default save path (the path configured at the top of that section).

This is odd - a similar bug was reported in 0.23 (#1033) but was then closed because it worked fine in 0.24 🤔
If it's not working, it's a bug 😄
How have you configured it? Did you check Only move from default save path? If so, the torrent is only moved if it was downloaded to the default save path (the path configured at the top of that section).

That's my config: (pixeled out the paths because of privacy, but they are valid and worked in 0.23)

Same problem with PicoTorrent 0.24. The downloads never moves to completed folder specified.

Same problem with PicoTorrent 0.24. The downloads never moves to completed folder specified.

Adding unicode label since the setting move_completed_downloads_path ends with \u0000 in the database.

Adding unicode label since the setting move_completed_downloads_path ends with \u0000 in the database.

Still not working in 0.25

Effectively
Sobre 24/05/2021 3:15:23, Richard Reiner @.***> escribió:
Still not working in 0.25
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub [https://github.com/picotorrent/picotorrent/issues/1108#issuecomment-846668550], or unsubscribe [https://github.com/notifications/unsubscribe-auth/ADRBMSCRBQUCS6VDQC4QUO3TPGSCTANCNFSM4VZT4PCQ].

Definitely not working in 0.25. Bummer, I'm missing this big time!

Thank you anyway.
Sobre 22/08/2021 1:12:14, mitchger @.***> escribió:
Definitely not working in 0.25. Bummer, I'm missing this big time!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub [https://github.com/picotorrent/picotorrent/issues/1108#issuecomment-903187110], or unsubscribe [https://github.com/notifications/unsubscribe-auth/ADRBMSC65M6Q4TDKEKXMB23T6AXEZANCNFSM4VZT4PCQ].
Triage notifications on the go with GitHub Mobile for iOS [https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675] or Android [https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email].
[1ac2741c-e5a0-4e76-bc83-57fddb71cfe6]
--
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus


how to enable debug mode in macos

how to enable debug mode in macos

At this moment you can start Lens app in debug mode from command line with DEBUG=true env var set:
DEBUG=true /Applications/Lens.app/Contents/MacOS/Lens


New version: vim.vim version 9.0.1558

Pull request has been created with WinGet Releaser v2 :rocket:
Microsoft Reviewers: Open in CodeFlow

@wingetbot run

/azp run

/azp run


[Week 12] 5: Try PDF conversions early

https://nus-cs2103-ay2324s1.github.io/website/schedule/week12/project.html#5-try-pdf-conversions-early

[ ] @bwangpj
[x] @Cloud7050
[ ] @mamayuan
[ ] @rayshawntan

Done on my end, but would need to do it again before submission.

We are going to do final submission where we'd need to convert, and will be looking through some docs during the meeting. Closing.


Update scopes when restarting paused notebook VMs

I had created a notebook VM a few weeks back during a time in which the wrong scopes were set on the VM. When I returned to that VM today, it was paused, and so I restarted it, but the scopes were not updated, even though https://github.com/DataBiosphere/terra-ui/pull/1298 was submitted a few weeks back.
The evidence of the problem is:

Ronaldo::getServiceAccountKey()
[1] "\n<script [snip]\n401 Unauthorized\n\nUnauthorized\nThis server could not verify that you\nare authorized to access the document\nrequested.  Either you supplied the wrong\ncredentials (e.g., bad password), or your\nbrowser doesn't understand how to supply\nthe credentials required.\n\nApache Server [snip] Port 443\n\n"

Deleting the notebook VM and recreating it resolved the problem, but I think we should consider automatically updating the scopes on the VM or give users visibility and control. The GCE API does allow for updating scopes on a stopped VM:
https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#changeserviceaccountandscopes

@sharmatime @rtitle is this the sort of thing that should get proxied through the Leo APIs, or just be part of the rollout of scope changes?
@mbookman I'm marking this issue it as blocked on external dev while we await a reply from our Leonardo friends. Thanks!

Currently scopes are only set at cluster creation time, and never modified. I agree it would be a nice enhancement to be able to change vm scopes without a delete/recreate. GCP allows changing scopes for stopped VMs; Leo could provide the same capability.


Documentation

Can you provide me the documentation of this project please?

Here's my project report, if you want: Image_Captioning_Report.pdf

Thank you so much 😊
On Sun, 18 Nov 2018, 12:18 Divyansh Garg<EMAIL_ADDRESS>wrote:

[image: Boxbe] https://www.boxbe.com/overview This message is eligible
for Automatic Cleanup<EMAIL_ADDRESS>Add cleanup rule
https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Fkey%3DwJqYStPHH3sEfoG4gnwFSVQIQJ%252FXNodUkM4qWcrW98k%253D%26token%3Do3ZzeGKdlg8MhAdbLzpC7gQGo2iZcx%252FnzgnAXk2XeggesD3C7m2br9xTJb1zu2mmFqZ%252FItpvwXPpTxXTqq6VYlIZLwXW3gUlWAUbwHU7dGrXeSil4UaVHFv7zE5oglbgLKlQ0WMkEDzQ0HwJMQ020w%253D%253D&tc_serial=45282369833&tc_rand=873599869&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001
| More info
http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=45282369833&tc_rand=873599869&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001
Here's my project report, if you want: Image_Captioning_Report.pdf
https://github.com/Div99/Image-Captioning/files/2592554/Project.Report.pdf
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Div99/Image-Captioning/issues/5#issuecomment-439670991,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AcrKEiCxC-RW9S24iuRDJkW8uQ7yH7CSks5uwPz4gaJpZM4YnweR
.


Added en SQL course

Hacktoberfest notes:

due to volume of submissions, we may not be able to review PRs that do not pass tests and do not have informative titles.
please read our contributing guidelines
be sure to check the output of Travis-CI for linter errors
if this is your first open source contribution, make sure it's not your last!

What does this PR do?
Add Resource
For resources
Description
Why is this valuable (or not)?
Pretty informative interactive course for beginners in SQL
How do we know it's really free?
You can check any section of course to ensure. You only have to pay for the possibility of obtaining a course certificate.
For book lists, is it a book? For course lists, is it a course? etc.
Interactive course
Checklist:

[x] Not a duplicate
[x] Included author(s) if appropriate
[x] Lists are in alphabetical order
[x] Needed indications added (PDF, access notes, under construction)

please use title as given by resource


gcc: undeterministic info pages

Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible-builds.org/ .
Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems.
Steps To Reproduce
nix-build '<nixpkgs>' -A pkgsStatic.buildPackages.gccCrossStageStatic.cc --check --keep-failed

You can use diffoscope to analyze the differences in the output of the two builds.
To view the build log of the build that produced the artifact in the binary cache:
nix-store --read-log $(nix-instantiate '<nixpkgs>' -A pkgsStatic.buildPackages.gccCrossStageStatic.cc)

Additional context
An example of a diff can be found at https://reproducible.nixos.org/nixos-iso-minimal-r13y/diff/a7ca61e3544ed4d048e59882fae1eb24dbc04f0f5e7b832202581193b2eeca67-ee6aa0602d40df3930bb7192c44be53c703d9b49512904e39ee93b7b09333eb7.html (in /nix/store/4rll8l0q3ycfpykwn1wqk93x1jqayqkl-x86_64-unknown-linux-musl-stage-static-gcc-12.2.0.drv which was built from da45bf6ec7bbcc5d1e14d3795c025199f28e0de0)

Diff says it comes from share/info/dir file (an .info index file). I wonder how many tiles it's expected to be ran against the directory: 1 per file (then install order parallelism causes unstable index), 1 per directory with reliance on file order on file system, or inherent install-info non-determinism.

Yeah, it's a per-file registration.  I think we can work it around by removing and regenerating dir file with something like https://nixos.org/manual/nixpkgs/stable/#sec-gnu-info-setup and rely on shell globs to do sorting for us.

So the saillant bit is in gcc/Makefile.in:
install-info:: doc installdirs \
    $(DESTDIR)$(infodir)/cpp.info \
    $(DESTDIR)$(infodir)/gcc.info \
    $(DESTDIR)$(infodir)/cppinternals.info \
    $(DESTDIR)$(infodir)/gccinstall.info \
    $(DESTDIR)$(infodir)/gccint.info \
    lang.install-info

$(DESTDIR)$(infodir)/%.info: doc/%.info installdirs
    rm -f $@
    if [ -f $< ]; then \
      for f in $(<)*; do \
        realfile=`echo $$f | sed -e 's|.*/\([^/]*\)$$|\1|'`; \
        $(INSTALL_DATA) $$f $(DESTDIR)$(infodir)/$$realfile; \
        chmod a-x $(DESTDIR)$(infodir)/$$realfile; \
      done; \
    else true; fi
    -if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \
      if [ -f $@ ]; then \
        install-info --dir-file=$(DESTDIR)$(infodir)/dir $@; \
      else true; fi; \
    else true; fi;

I guess the root cause of the issue is that the $(DESTDIR)$(infodir)/%.info: doc/%.info installdirs: rule does not only output to $(DESTDIR)$(infodir)/%.info, but also modifies $(DESTDIR)$(infodir)/dir as a side effect.
I guess we could restructure the Makefile to install the makefile in a deterministic order, but I wonder if parallelism in the install phase is useful at all for gcc - might be OK to disable it entirely?

gcc does quite a bit of relinking and file copying in the install phase. I would suggest keeping install phase parallel.
Changing makefiles might be complicated as it's a recursive makefile with different compiler frontends (c++ and fortran). They ought to build and install independently (in parallel). On top of that Makefile regeneration requires autotools dependencies for gcc which makes bootstrap a bit trickier.
https://nixos.org/manual/nixpkgs/stable/#sec-gnu-info-setup might be a less invasive way to do it. And I think it's generic enough that could be implemented as a hook for more packages.

gcc does quite a bit of relinking and file copying in the install phase. I would suggest keeping install phase parallel.

:+1:

Changing makefiles might be complicated as it's a recursive makefile with different compiler frontends (c++ and fortran). They ought to build and install independently (in parallel). On top of that Makefile regeneration requires autotools dependencies for gcc which makes bootstrap a bit trickier.

It seems the gcc sources already don't have a gcc/Makefile, so aren't we already (re)generating them?

https://nixos.org/manual/nixpkgs/stable/#sec-gnu-info-setup might be a less invasive way to do it. And I think it's generic enough that could be implemented as a hook for more packages.

That's a good point. It seems the info files are already first generated into <<NIX>>-x86_64-unknown-linux-musl-stage-static-gcc-12.2.0/share/info and then somehow moved to <<NIX>>-x86_64-unknown-linux-musl-stage-static-gcc-12.2.0-info/B/share/info - it's not obvious to me where that happens, though?

gcc/Makefile is generated from Makefile.in at ./configure time. Makefile.in is committed into gcc's .git and is generated from autogen Makefile.def (and Makefile.tpl) (autogen is a program written in guile, somewhat heavy on depends).
-info output is split out for derivations with outputs = ["info" ... ] at pkgs/build-support/setup-hooks/multiple-outputs.sh:    moveToOutput share/info "${!outputInfo}"

I wonder if install-info itself could be fixed to generate consistent dir files regardless of the registration order of .info files added to it. It feels like that would be the best place to fix it properly. No idea if dir structure allows an extension for such mode.

I wonder if install-info itself could be fixed to generate consistent dir files regardless of the registration order of .info files added to it. It feels like that would be the best place to fix it properly. No idea if dir structure allows an extension for such mode.

Looking closer, it looks like install-info already doesn't use the input order, but puts items in alphabetical order. The problem is the 'left' side is missing entries. I wonder if install-info supports multiple parallel processes trying to write to the same dir?

https://git.savannah.gnu.org/cgit/texinfo.git/tree/install-info/install-info.c#n2293 seems simple enough, and indeed reads/writes the dir file without any protection against parallel processes...

I filed https://gcc.gnu.org/PR109898 upstream to track proper resolution.

I filed https://gcc.gnu.org/PR109898 upstream to track proper resolution.

Thanks! I hadn't found the time to figure out whether the problem was in gcc or further upstream in the autoconf/automake/etc templates (and wasn't sure gcc would welcome reports for such possibly-upstream problems). Great to track a proper solution :+1:


Enable/Disable AKS kube-dashboard addon

Enable/Disable AKS kube-dashboard addon
This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR has modified HISTORY.rst describing any customer-facing, functional changes. Note that this does not include changes only to help content. (see Modifying change log).

[x] I adhere to the Command Guidelines.

/LGTM


project configuration, tox, travis, codecov

[Current coverage][cc-pull] is 92.98%

Merging [#20][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master        #20   diff @@
==========================================
  Files             2          2
  Lines           114        114
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            106        106
  Misses            8          8
  Partials          0          0

Powered by Codecov. Last updated by [cd2eb65...772094d][cc-compare]
[cc-base-branch]: https://codecov.io/gh/scrapy-plugins/scrapy-crawlera/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/scrapy-plugins/scrapy-crawlera/compare/cd2eb6518519faf6a34db1b0f2d24f3c85922704...772094dbd31b40f43a90e8f4a043cc9bc81b8b60
[cc-pull]: https://codecov.io/gh/scrapy-plugins/scrapy-crawlera/pull/20?src=pr

@eLRuLL , thanks for this.
You can also update setup.py classifiers to state Python 3 support

@redapple setup also updated 😄

ready

LGTM


Version number label obscures settings menu item

On complex sites, the settings menu can exceed the window height, causing it to receive a scrollbar. When this happens, the version number label scrolls along with the menu items, causing it to permanently obscure one of those items:

It would be better for the version number label to stay fixed on scroll, and for the menu to be given enough bottom padding to ensure that the last item can be scrolled above that label.

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: no

Technical details

Python version: 3.7
Django version: 2.1.9
Wagtail version: master
Browser version: Chrome/74.0.3729.169 https://whatsmybrowser.org/b/ZM555Y9

Fixed in a459e91692659aba04e662978857d14061aecaee via #5606

The PR that fixed this was reverted, so this issue should probably be reopened, no?

@abeyerpath Good point, yep!


Optimizing webpack build with babel & babili

The current build sequence for a typical webpack project is transpile -> bundle -> minify. As babili doesn't traverse through Objects and its properties (yet), there will not be much optimizations on the bundler generated code (modules[moduleId].call()) other than mangling and whitespace/comments removal. The pipeline can be transformed to (transpile + minify) -> bundle - if the bundler already produces mangled and has an option to output minified (just the syntax and comments) code. But, we could already do this now -

transpile + minify (mangle=false)
bundle - remove dead code module level (tree-shaking?)
mangle + deadcode(if required) + minify(syntax, comments)

// stage 1
{
  loader: 'babel-loader'
  presets: [
    'es2016',
    'react',
    [
      'babili', { // <- options not yet supported (https://github.com/babel/babili/pull/162)
        mangle: false // this will be performed on the entire bundle.
        deadcode: false // not tested which is better for deadcode - stage1 or 3 - just an idea
      }
    ]
  ]
}

// stage 2
bundle - webpack

// stage 3
new BabiliWebpackPlugin({
  mangle: true, // <- option not yet supported
  deadcode: true, // <- option not yet supported
  [everythingelse]: false // <- just a notation
  comments: false,
});
// or
babel.transform(bundledcode, {
  minified: true, // syntax
  compact: true,
  comments: false,
  plugins: ["mangle", "deadcode"]
})

From https://github.com/babel/babel.github.io/pull/898#r76562069 - edited and added more description

babel/babili#162 is merged 😄 .. I'll start work on this...

Just for your information:
With babel/babili#162 shipped, we can now pass options to Babili through the babili property like this:
new BabiliWebpackPlugin({
  babili: {
    presets: [
      [
        require('babel-preset-babili'),
        {
          mangle: { topLevel: true },
          deadcode: false,
          removeConsole: process.env.NODE_ENV === 'production',
        },
      ],
    ],
    plugins: [
      'transform-inline-environment-variables',
    ],
  },
}),

I've tried setting up my webpack plugin config as above, but I still end up with compiled code that is actually larger than just using uglify-webpack-plugin... Any ideas of things I could try? I've tried lots of combinations of config/babelrc but each produces a build larger than that of uglify which doesn't seem right?
.babelrc
{
  "presets": [
    [
      "es2015",
      {
        modules: false
      }
    ],
    "es2017",
    "react",
    "stage-3",
    "stage-0",
  ],
  "plugins": [
    "transform-object-assign"
  ],
  "env": {
    "production": {
      "presets": ["react", "babili"]
    }
  }
}

webpack.config.js

  devtool: 'cheap-module-source-map',
  module: {
    rules: [
      {
        test    : /\.js$|\.jsx$/,
        exclude : [
          /node_modules/,
          /\.spec\.js$/
        ],
        loaders : [
          'babel-loader',
          'eslint-loader'
        ],
      },
    ],
  },
  plugins: [
    new BabiliPlugin({
      test: /\.js$|\.jsx$/,
      babili: {
        presets: [
          [
            require('babel-preset-babili'),
            {
              mangle: { topLevel: true },
              deadcode: false,
              removeConsole: true,
            },
          ],
        ],
      },
    }),
  ],
};

I'm having the same issue as @icd2k3, the plugin is not doing any basic minification (whitespace removal).
It does seem to be running, since I am using typescript so I need to pass test: /\.tsx?$/, in the 2nd parameter for 'overrides' to get it to run without error.
I'm not trying to do any custom configurations, just get basic minification working. Any idea why it would run without error but fail to minify?
The files are React + es6 + typescript.

(I should add that I did not include a .babelrc file in my project since from your docs it seems like I can just used the options/overrides objects in the plugin.)

Yes for me the minify of variables and what not is happening but agree that white space not getting stripped

@boopathi There is a confusion..
This used to work as of version "babili-webpack-plugin": "0.0.11". It has stopped working now. I don't want to have .babelrc file and trying with this also doesn't help
What's the latest way of using it? Can you please help!

Is there really a reason to use this strategy?
So far, I have seen that basically every rule I leave enabled improved bundle size, even without node_modules dependencies.
When would you need to optimize for compile time rather than bundle size?

@boopathi Coming here from the README, and reading through the comments in this thread, I am still unclear on what strategy is recommended? Since the plugin has seen changes in the year since the thread started, could you suggest your current recommendations? Thank you!

The defaults are just fine now and the why section of the readme explains the benefit of doing the minification at the end with babel (works on the entire output and uses modern JS). This is what we have to generate a nicely optimized bundle:
webpack.config.js
const path = require('path');
const webpack = require('webpack');
const BabelMinifyPlugin = require('babel-minify-webpack-plugin');

module.exports = (env) => {
    return [
        {
            context: __dirname,
            entry: { platform: [path.join(__dirname, 'index.js')] },
            module: {
                rules: [
                    { test: /\.js$/, exclude: /node_modules/, loader: ['babel-loader'] },
                ]
            },
            output: {
                path: path.join(__dirname, './dist'),
                filename: '[name].js'
            },
            plugins: [
                new webpack.optimize.ModuleConcatenationPlugin(),
                new BabelMinifyPlugin()
            ]
        }
    ];
};

.babelrc
{
  "presets": [
    [
      "env",
      {
        "targets": {
          "browsers": [ "safari 10", "ie 11", "ios 9" ]
        },
        "modules": false,
        "useBuiltIns": true
      }
    ]
  ],
  "plugins": [
    "transform-runtime"
  ],
  "comments": false
}


Add first gridding process files

Adds the renewable potential analysis

Note that I also made some changes to include the shipping data from MariTeam in our original repo

added the new shipping proxies

Also added fgas implementation


Event 3 newsfeed

Basically, this is the easiest way for everyone to keep up-to-date with all the information about our next event.
You can un-watch the repo (if you don't like many notifications), and just subscribe to this issue, to be in the loop and not risk to miss it 😎
I'll lock it up and we will post as new comments the new info, while also keeping this top post up-to-date.
In case you want to leave/read feedback about event 2, you can check #11.
To submit a topic proposal for event 3 head instead to #12.
EVENT 3
When: ?
Where: ?
Sponsors: ?
Tickets: ?

We will soon be ramping up again on organising a third event!
It will be a virtual event, so to ensure that we can still keep the original spirit of the event ongoing, we are still defining the precise way we will be running it. More info to come, we are aiming to run it in early Q4 2020.


A series of minor fixes and updates

•	Changed the NPC’s Defenses section to make it more like the PC’s
•	Added an Armor Section for the NPC sheet
•	Changed the NPC’s Attacks Section to make it more like the PC’s.
•	Removed the red text from the sheet to make it more pleasing to the eye.
•	Changed the Repeating Skills Section on the NPC Sheet to be more like the PC skills.
•	Fixed NPC Sheet’s Damage Threshold
•	Fix NPC Sheet’s Condition Tracker
•	Fix NPC Grapple and Skills
•	Fix PC and NPC Sheet’s Weapon Damage, it should not be counting Non-Heroic Levels for damage.

Might I ask why you've removed all of the translation information from the sheet?

My bad, I didn't realize that's what it was. I thought it was some sort of glitch since it caused the text to become red.

The tags are connected to the translation.json file, and if some tag is missing or misspelled it appears red in the sheet, I managed to do that with one of the sheet's I created that I based on a sheet that had the translation tags.
It might be easier for you in the future to divide your pull request into several commits, which results in having easier to make changes and track your work than doing it in just one big one. If say your tag fix would have been in one single commit, it would be also be easier to review or revert.

If you prevent the changes from being committed, I could just go back and add the translation information back into my custom sheet and resubmit.

You can just re-add the translation information to your master branch and it will automatically become part of this pull request.


mix DEV - use default kube config

User convenience - check out project and play around.

Good idea @bryanhuntesl - thanks


Add missing install targets

Add missing install targets for the following:

nodelet library
launch files
xml files
rviz config files

This will be fixed in the next release.

This issue has been fixed in Release 1.0.2


[INTERNAL] SearchProvider: Add missing @abstract

The module sap.ui.core.search.SearchProvider was not marked as "abstract".
The API Reference can now display this as such.
Fixes: https://github.com/SAP/openui5/issues/1730

Hello @boghyon ,
Thank you for your pull request. I've created an internal record<PHONE_NUMBER>. The status of the issue will be updated here in GitHub.
Regards, Diana


ACC/Gyro, coeff, cal and raw values converting

I disagree with subtracting the acc cals here. It should only be used in the coeff.
https://github.com/mfosse/JoyCon-Driver/blob/6886a86d27ff5303079304c904629fc24e8deac6/joycon-driver/src/main.cpp#L276
It produces wrong values.
The cal here is not exactly the origin position. It's actually the position the controller has when you level it on a flat surface and the trigger protrudes the surface. you can test it by raising the trigger opposite end of the controller.
It should produce values of around
[0.0, 0.0, -9.8 or -10.0]m/s^2. (Z axis is -9.8 or -10 depending on the accuracy of math calculations.)
or (If you don't convert to SI)
[0.0, 0.0, -1.0]G

The following though, as stated by @JibbSmart seems correct:
https://github.com/mfosse/JoyCon-Driver/blob/6886a86d27ff5303079304c904629fc24e8deac6/joycon-driver/src/main.cpp#L292
The gyro cal here is indeed what the IMU produces when still. And it must be used to both the coeff and the raw value calculations. I tested it and the values are closer to 0.0 when resting.
Sorry for writing wrong documentation.

But i want to state something else also. I see at your code that you state (variable naming) that the math you do is for degrees.
If that's the case, then you should not use 0.01745329251994 degrees to radians converter constant.
For Degrees/s - dps:
gyro_cal_coeff[0] = (float)(936.0 / (float)(13371 - uint16_to_int16(sensor_cal[1][0])));
For Radians/s - rad/s:
gyro_cal_coeff[0] = (float)(936.0 / (float)(13371 - uint16_to_int16(sensor_cal[1][0])) * 0.01745329251994);
For Revolutions/s - rps - rev/s:
gyro_cal_coeff[0] = (float)(936.0 / (float)(13371 - uint16_to_int16(sensor_cal[1][0])) * 0.0027777778);
Unfortunately, I don't have time to review the math involved to understand what units you use, so if you use rad/s math it's ok. But please check, because using the wrong values can have 6x, 57x or 360x times difference.

That makes sense to me. I guess that the accel calibration info is instead mostly useful for sensor fusion -- determining confidence in the accel vector as a gravity vector for correcting absolute orientation calculated by integrating gyro data, and also for cancelling out the gravity vector from accel input so we can detect linear movements by the user (shaking the controller, for example).

Yeah, internally in switch, it is mostly used as a fusion sensor.
But it also has functions to use them separately.


I want to join here.

I want to join here. Thank you.
Colleen Hillyard

I want to join this

Follow the instructions given by the github actions bot


Support for mobile devices and UI Improvements

Added touch events for mobile compat
Some improvements on the UI

Anything else or can we go for the merge?


run-to-completion services

Isn’t it possible to connect pub/sub (concurrency:1, max inst:1) <-> cloud run and push one message and have it work once only? Just an idea.

PubSub isn't a only-once delivery service. It supports retries and a task may run more than once if not completed successfully. We'll update when we have a better way.


Use extern "system" instead of extern "C" for RtlGetVersion win32 API

It's a tiny bug fix, but it makes 32-bit windows builds work! I updated the example repo to use my branch and the build succeeds.
Closes #87.

Thank you for the pull request!


Setting progressInterval to less than 1000ms does not work for Twitch videos

Be sure to search for your issue before opening a new one.
Current Behavior

Setting onProgress interval for any value less than 1000 has no effect. Setting it to a higher value (like 5000ms) does work.
Expected Behavior

I should be able to set progressInterval to 100ms and have it call my onProgress function every 100ms
Steps to Reproduce

Visit my jsFiddle below
Look at the console logs, you will notice each callback happens every 1000ms instead of 100ms

Environment

URL attempting to play: https://www.twitch.tv/videos/971833140
Browser: Chrome
Operating system: MacOS catalina
jsFiddle example: https://jsfiddle.net/8rq3726h/9/

Other Information

Hello, any update on this? Seeing the same exact issue on my end. Will be investigating more.

Does anyone have any ideas? If someone can point me in the right direction of what the issue is I can investigate and try and fix. I'm also willing to put a $100 bounty on this for a pr that fixes the issue :)
@cookpete @gatesyp

I have the same problem, not for Vimeo only, but for every source. Callback gets called, but value is the same

@RusseII Turns out the problem is pretty simple:

The getCurrentTime method of the Twitch player only updates the value every second.
onProgress is not fired if the values are the same as the previous call, to prevent needless re-rendering.

See below for a console log of the result of getCurrentTime() every 0.5 seconds. Notice that the value returned doesn't increase by ~0.5 each time, but is the same value until roughly a second has passed.

Sounds like this issue is caused by twitch and can't be fixed by react-player ?


[1.7.10]Luckperms-Legacy not loading

Plugin will not load at all on startup
Version: LuckPerms-Bukkit-Legacy-3.0.0
Thermos Version: Thermos-1.7.10-1614
FML LOG LOG

Caused by: java.lang.IllegalArgumentException: INVOKESPECIAL/STATIC on interfaces require ASM 5

Update your SpecialSource.

Um.....thanks I guess.....special source ......

The SpecialSource library included with Thermos uses ASM4.
Updating it to the latest version will fix the issue.
Instructions for updating to ASM5:
Navigate to the libraries\net\md-5\SpecialSource\1.7-SNAPSHOT folder of the server
Delete the SpecialSource-1.7-SNAPSHOT.jar jar file
Download SpecialSource v1.7.4 from http://central.maven.org/maven2/net/md-5/SpecialSource/1.7.4/SpecialSource-1.7.4.jar
Copy the jar file to the libraries\net\md-5\SpecialSource\1.7-SNAPSHOT folder
Rename the jar file you just copied to SpecialSource-1.7-SNAPSHOT.jar

Thanks Eufranio much appreciated

Related CyberdyneCC/Thermos#498

Yeah. Thermos will not be updated so we have to fix it by ourselves.

Guys, the old link has been deleted so heres the new one https://repo1.maven.org/maven2/net/md-5/SpecialSource/1.7.4/


Use APIReader for reading desired object directly from k8s apiserver

Issue #, if available: https://github.com/aws-controllers-k8s/community/issues/894
Description of changes:

Use APIReader for making reading desired state of k8s resource directly from apiserver and avoid any client caches.
Also see: https://github.com/kubernetes-sigs/controller-runtime/issues/585#issuecomment-528102351

Tested locally with apigatewayv2 controller and this change resolves the duplicate API creation issue.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Seems simple enough. Interested to see what effect this has when there are many custom resources being reconciled at once.

By default our controller only reconciles one object per GVK at any given time, so I do not think it will overload the API Server. But yes we'll see.

/lgtm


Command to toggle pry-state

Super useful extension!
However, I'd like the ability to toggle this when debugging.
What do you think? @SudhagarS?

Thanks @justin808.
I have plans to add some commands to have control over how values are displayed.
Think I will add a command for this too.

@SudhagarS Sweet, let me know, and I'll try on the gem or directly from your repo. Check out my company's open source at https://github.com/shakacode/ and let me know if you need any help!

Just few days ago I came to the same question.
You make so useful screen at the breakpoint, so, it will be great to be able to call it

@kvokka I tried doing it few months ago but put it off as it required digging into pry. Anyway I will take a fresher look at it sooner and let you know.

@SudhagarS Thank you. I've done the same yet. As variant, you may run binding.pry inside debugger session.

Any updates on this? I'm willing to help on this feature, just let me know what the parameters are (if any) and I'll get to it

I have a fork with two commands:

show-state which just shows the state of the current binding (as if it had been toggled)
toggle-state which turns on and off the automatic display.

Since show-state is available as a command now, it made sense to me to turn off the hook by default. I also updated the README with information.
https://github.com/bbugh/pry-state/tree/state-commands#usage
When I have some time, I will write tests for the commands and changes, and submit a pull request.

I added PR #10 for this, with test coverage now. 👍


[Spark?] Shred: events being silently dropped during shredding

See http://discourse.snowplowanalytics.com/t/how-to-debug-shredding-process/1218/3

Attaching example enriched events here since I couldn't on the forum and I'm probably going to delete that bucket: part-00001.gz

De-scheduling


KeyError: '__flags'

I did these steps:

Set the CHECKPOINT_DIR variable in main.py.
Make sure the files block_features.csv and edge_features.csv are in the src/main/python/data directory. Use the example from the previous section for this.
Convert the CSV files to .npy with data/convert_scala_csv.py.
Train the unary CNN with python3 main.py train_unary.

but, the fourth step failed with this error:
  File "main.py", line 262, in <module>
    main()
  File "main.py", line 28, in main
    train_unary()
  File "main.py", line 83, in train_unary
    dropout_keep_prob=DROPOUT_KEEP_PROB)
  File "/root/work/web2text/src/main/python/forward.py", line 19, in unary
    c = Config()
  File "/root/work/web2text/src/main/python/config.py", line 12, in __init__
    for k, v in iteritems(FLAGS.__dict__['__flags']):
KeyError: '__flags'

Could you tell me how to fix it?
My tensorflow version is 1.10.0

This seems to be an incompatibility with more modern Tensorflow versions (the code was written for Tensorflow 1.4 or so)
The commit above should fix this.

Another error happened.
KeyError: b'data'
so I replaced all b' to ' and it seemed to work correctly.


add mso_schema_site_external_epg

As the resource doesn't yet support specifying the schema/template for the L3Out, has this code been tested to see what its behaviour is in the following situations?

L3Out defined locally on the APIC
L3Out defined in an NDO L3Out template
L3Out defined in the same template/schema
L3Out defined in a different template within the same schema
L3Out defined in a different template/schema

It would be good to raise an issue to capture the current limitations and track their resolution as the provider improves.


Dark/Light them applied after logout in a light/dark themed browser.

Before you start please confirm the following.

[X] Yes, I've searched similar issues on GitHub.
[X] Yes, I've checked whether this issue is covered in the Portainer documentation or knowledge base.

Problem Description
Unintentionally noticed that dark/light theme didn't behave correctly after logout as long as system/portainer theme is not the same dark or light.
I'm not sure if this is really a bug since the color theme of portainer follows the user? if I'm understanding it correctly, but the behavior is a little confusing.
Expected Behavior
If portainer is set to be dark them, it either has the login page to be dark along with it's own setting, or let the login page to be light theme following the browser setting regardless login status.
Actual Behavior
When the first time you land at the login page, the login page theme is light following the browser/system theme. After login, and logout the login page will have the theme applied to portainer, as long as it's a different theme to browser/system them. Details in the reproduce section.
Steps to Reproduce

Set browser theme to dark, set Portainer theme to be light.
Open the web interface at ip:9443, the login page will follow browser theme to be dark
Login, Portainer is light theme.
Logout, the login page will use light theme as well.
If you refresh on the same page, the landing page will then use dark theme.
Vice versa if you have browser theme to be light and portainer them to be dark.

Portainer logs or screenshots
No response
Portainer version
2.19.2
Portainer Edition
Community Edition (CE)
Platform and Version
Docker 24.0.6
OS and Architecture
Manjaro 23.0.3
Browser
Chrome 119, Edge 119
What command did you use to deploy Portainer?
No response
Additional Information
No response

This is more a feature request than a bug, so I'm converting it to a discussion.


[KOGITO-258] - Create job to execute build and tests the Kogito image…

…s and a PR is created.
Signed-off-by: Filippe Spolti<EMAIL_ADDRESS>

@mswiderski can you please review?


Issue with nested query

I am not sure whether this is an issue with the gem or the endpoint I'm hitting but I get a 500 code with nested queries.
The request looks like this:
params = {
  'title' => 'Mr',
  'first_name' => 'Chandler',
  'last_name' => 'Bing',
  'email' =><EMAIL_ADDRESS>  'addresses' => [
    {
      'flat_number' => '4',
      'street' => 'Main Street',
       'town' => 'London',
       'postcode' => 'SW4 6EH',
        'country' => 'GBR'
      }
    ]
  }

Typhoeus.post('api_endpoint', body: params)

To get around the issue, I am using Rack to build the nested query:
Typhoeus.post('api_endpoint', body: Rack::Utils.build_nested_query(params))

This is an issue with Typhoeus. Kind of. Look at the difference:
Rack::Utils.build_nested_query(params)
#=> "title=Mr&first_name=Chandler&last_name=Bing&email=chandler_bing%40friends.com&addresses[][flat_number]=4&addresses[][street]=Main+Street&addresses[][town]=London&addresses[][postcode]=SW4+6EH&addresses[][country]=GBR"
Ethon::Easy::Form.new(nil, params)
=><EMAIL_ADDRESS>Street&addresses[0][town]=London&addresses[0][postcode]=SW4 6EH&addresses[0][country]=GBR

This is because the way Rack encodes nested hashes and arrays is ambiguous. Typhoeus adds an array index. We have a middleware to help decoding the params but not the body: http://www.rubydoc.info/github/typhoeus/typhoeus/Rack/Typhoeus/Middleware/ParamsDecoder. Now that I think about it should take care of the body too I think....

Cool, thanks for looking into it. Let me know if I can be of any help!

I was thinking about supporting both ways of params encoding. Do you want to take a stab at it?

yep I can give it a go

Let we know if you need help. I thought about adding a config option in Typhoeus. You could check in Ethon if Typhoeus is defined and then check the config option. That was my plan...

Hey @i0rek I haven't had time to look into this yet(lame!). Still planning on working on it though

@PericlesTheo no worries :)

Hi @i0rek and @PericlesTheo, I've added an option to Ethon to encode arrays the Rack way. I've left a FIXME in the code for a smelly situation :smiley: - please check it out.
I'm using it now on ifad/hawk@74890c8 and it looks good. What do you think? Opening a pull to let travis do its homework.
Thanks!


Update Emissary version in docs

Emissary package should be at version 3.x, and the following references need to be updated.

[ ] https://anywhere.eks.amazonaws.com/docs/reference/packagespec/
[ ] https://anywhere.eks.amazonaws.com/docs/reference/packagespec/emissary/

This may not be a exhaustive list.

I just wasn't sure if there was some reason for the v0.3.3.

Yeah not quite sure. Under https://anywhere.eks.amazonaws.com/docs/tasks/packages/, the version is correct.

en/docs/reference/packagespec/emissary/v0.3.3.md
en/docs/reference/packagespec/emissary/v0.3.0.md
en/docs/reference/packagespec/_index.md

Done.


Add Phoenix, AZ template

so sorry, i had to do a force push to gh-pages :^(  would you mind merging that branch back in so I can review?

Here are the Phoenix emails

Thank you.

Closing because stale. Thank you!


Enable collecting attributes from environments

I am not sure about this: adding all the environment variables as attributes to the resource might lead to leak some sensitive env var.
You can also use static_attributes and flexible config to add the environment vars that you want to have.


Publishing your paper on arxiv is great.
But please, you achieve state of the art results, so publish your result on the World reference for state of the art which is:
Paperswithcode.com
Add your results here
https://paperswithcode.com/task/coreference-resolution
Someone already published your paper
https://paperswithcode.com/paper/bert-for-coreference-resolution-baselines-and

Thanks.


Mel stats and Vocoder

Hi,
I try to reproduce your paper and I encounter a problem with mel stats and vocoder.
When I use your pre-trained vocoder and mel stats, I can notice the speech synthesis performance is quite good.
However, when I run the preprocess code and get new mel stats, the speech synthesis performance degrades on the same pre-trained vocoder.
Thus,  the questions are as below:
1.) I wonder if I get new mel stats, it is necessary to train the vocoder again.
2.) I wonder if you use mel stats from the preprocess code for vocoder input normalization.
Thank you

Hi, based on my experience, using the same mel stats for vocoder and VC model leads to better voice quality, so for your questions:

I think that training a vocoder using the new mel stats could generate the speech with higher quality, or you can use my provided mel stats (from PWG vocoder trained by VCTK) to normalize mels for training the VC model.
the mels stats for vocoder input normalization is not from preprocess code, it is from the PWG repo for preprocessing mels.

Thank you for answering!
I understand and solve it.


New data model implementation

This is a draft PR for implementing the new data model that is currently proposed at https://github.com/KhronosGroup/glTF-Project-Explorer/pull/167 . The changes that are currently in this PR are summarized in the first comment of that PR, together with some open discussion points.
I'd suggest to keep the discussion going on in https://github.com/KhronosGroup/glTF-Project-Explorer/pull/167 , to align the document that describes the actual state of the data model (as a "specification"). I'll try to keep this PR here up to date with decisions that are made there.

This is now part of https://github.com/KhronosGroup/glTF-Project-Explorer/pull/172


Feature/swift 2.3

This pull request migrates SwiftGen to Swift 2.3 and would temporarily fixes #169 particularly.
A migration to Swift 3.0 would be much heavier and would take more time.
Currently, one can compile swiftgen-cli and all unit tests pass.
But I haven't checked the stencil templates yet.

Seems cool 👌  will check that more thoroughly a bit later in the week when I've time to actually test the resulting project with the templates (don't see a reason why they would be affected)

Superseded by #179. Thanks for the pull request though!