text:
oracle和mssqlserver能连接吗？

如能，怎么写呢？

from pyetl import DatabaseReader, DatabaseWriter
reader = DatabaseReader("oracle://user:password@local:1521/xe", table_name="source")
reader = DatabaseWriter("oracle://user:password@local:1521/xe", table_name="target")
Task(reader=reader, writer=writer).start()

更多关系型数据库连接参考pydbclib， 可以先用pydbclib.connect建立好连接，然后传入DatabaseReader或DatabaseWriter使用
import pydbclib
from pyetl import DatabaseReader, DatabaseWriter
con = pydbclib.connect("oracle://user:password@local:1521/xe")
reader = DatabaseReader(con, table_name="source")
writer = DatabaseWriter(con, table_name="target")
Task(reader=reader, writer=writer).start()

authors: iamhrm taogeYT

repo: taogeYT/pyetl


text:
后台管理的入口url是啥啊

后台管理的入口url是啥啊

127.0.0.1:8081/login

source: gharchive/issue

license_type: permissive

license_source: github-api


text:
Allow change default shard func

By default CRUD calculates bucket ID using primary key and a function vshard.router.bucket_id_strcrc32(key),

In addition to adding the ability to change the shard function, it should be explained to new users why using the default value (strcrc32) is a bad idea.

@R-omk Good idea, I would do it in the scope of #237.
BTW, do you know effects aside of ones described here, about which we should warn users?

#237 is implemented and released in crud 0.11.0. The guides are in the readme. Feel free to reopen the issue if you think we should add something here.

authors: R-omk Totktonada

repo: tarantool/crud


text:
feature: add noreturn opt for some DML operations

This patch introduces noreturn opt for DML operarions:

insert, insert_object, insert_many, insert_object_many
replace, replace_object, replace_many, insert_object_many
upsert, upsert_object, upsert_many, upsert_object_many
update
delete

The opt allows to suppress returning successfully processed tuple(s).

[x] Tests
[x] Changelog
[x] Documentation

tarantool> crud.insert_many('customers', {
    {10, box.NULL, 'Elizabeth', 23},
    {20, box.NULL, 'Anastasia', 22},
  })
---
- rows:
  - [10, 569, 'Elizabeth', 23]
  - [20, 826, 'Anastasia', 22]
  metadata: [{'name': 'id', 'type': 'unsigned'}, {'name': 'bucket_id', 'type': 'unsigned'},
    {'name': 'name', 'type': 'string'}, {'name': 'age', 'type': 'number'}]
- null
...

tarantool> crud.insert_many('customers', {
    {30, box.NULL, 'Elizabeth', 23},
    {40, box.NULL, 'Anastasia', 22},
  }, { noreturn = true })
---
- null
- null
...

tarantool> crud.replace_object_many('customers', {}, {
    stop_on_error = true,
    rollback_on_error  = true,
    noreturn=true,
})
---
- null
- []
...

tarantool> crud.delete('customers', 1, {noreturn=true})
---
- null
- null
...

==== BATCH COMPARISON PERFORMANCE REPORT ====

== SUCCESS REQUESTS ==
(The higher the better)

|                        |         1 |           10 |          100 |      1000 |     10000 |
| ---------------------- |---------- | ------------ | ------------ | --------- | --------- |
| insert_many (noreturn) |    126625 |        88188 |        30930 |      4441 |       548 |
|            insert_many |    129512 |        84003 |        27593 |      4046 |       491 |

== SUCCESS REQUESTS PER SECOND ==
(The higher the better)

|                        |         1 |           10 |          100 |      1000 |     10000 |
| ---------------------- |---------- | ------------ | ------------ | --------- | --------- |
| insert_many (noreturn) |   4220.82 |      2939.59 |      1030.98 |    148.02 |     18.26 |
|            insert_many |   4317.06 |      2800.09 |       919.75 |    134.82 |     16.36 |

== AVERAGE CALL TIME ==
(The lower the better)

|                        |         1 |           10 |          100 |      1000 |     10000 |
| ---------------------- | --------- | ------------ | ------------ | --------- | --------- |
| insert_many (noreturn) |  0.236 ms |     0.339 ms |     0.969 ms |  6.751 ms | 54.766 ms |
|            insert_many |  0.231 ms |     0.356 ms |     1.086 ms |  7.414 ms | 61.131 ms |

== MAX CALL TIME ==
(The lower the better)

|                        |          1 |           10 |          100 |      1000 |     10000 |
| ---------------------- | ---------- | ------------ | ------------ |---------- |---------- |
| insert_many (noreturn) |  21.071 ms |    25.501 ms |    23.810 ms | 38.389 ms | 79.063 ms |
|            insert_many |  21.615 ms |    25.376 ms |    27.647 ms | 45.744 ms | 88.411 ms |

Closes #267

tarantool> crud.insert_many('customers', {
    {30, box.NULL, 'Elizabeth', 23},
    {40, box.NULL, 'Anastasia', 22},
  }, { noreturn = true })
---
- null
- null
...

Receiving nil, nil is rather confusing. Let's do true, nil like in truncate.

Receiving nil, nil is rather confusing. Let's do true, nil like in truncate.

Done, PR description updated

Receiving nil, nil is rather confusing. Let's do true, nil like in truncate.

Done, PR description updated

it was decided to return to the idea:

nil, nil for a completely successful batch
nil, err if at least one tuple failed

Let's change performance test cases to use noreturn

Added a separate performance test for insert_many (noreturn):
==== STATISTICS PERFORMANCE REPORT ====

== SUCCESS REQUESTS ==
(The higher the better)

|                                   | crud (without stats wrapper) | crud (stats disabled) | crud (local stats) | crud (metrics stats, no quantiles) | crud (metrics stats, with quantiles) |
| --------------------------------- | ---------------------------- | --------------------- | ------------------ | ---------------------------------- | ------------------------------------ |
|                      select by pk |                              |                       |                    |                                    |                                      |
|        select gt by pk (limit 10) |                              |                       |                    |                                    |                                      |
|        pairs gt by pk (limit 100) |                              |                       |                    |                                    |                                      |
| select eq by secondary (limit 10) |                              |                       |                    |                                    |                                      |
|   select eq by sharding secondary |                              |                       |                    |                                    |                                      |
|                            insert |                       516804 |                551412 |             522171 |                             495607 |                               457784 |
|                       insert_many |                       126982 |                473683 |             472113 |                             420794 |                               418445 |
|            insert_many (noreturn) |                       130216 |                511051 |             499745 |                             478886 |                               430803 |

...
...
...

==== BATCH COMPARISON PERFORMANCE REPORT ====

== SUCCESS REQUESTS ==
(The higher the better)

|                                   |            1 |           10 |          100 |         1000 |        10000 |
| --------------------------------- | ------------ | ------------ | ------------ | ------------ | ------------ |
|                            insert |       127672 |        17440 |         1924 |          190 |           19 |
|                       insert_many |       118009 |        78974 |        28482 |         3978 |          484 |
|            insert_many (noreturn) |       130131 |        85822 |        30740 |         4394 |          559 |

...
...
...

Please, rebase on master to verify that dev_checks are fine

Done

source: gharchive/pull-request

authors: DifferentialOrange GRISHNOV


text:
Add params to Elasticsearch URI

This is usefult for example when one needs to add shard preference

@evantahler is something like params going to be available in elasticsearch-dump or you think this just doesn't make sense?

This does make sense, can you add a basic test which proves that the params are passed through appropriately?

@datashaman I added a test.

@datashaman @evantahler is it OK now?

Looks good! Thank you for adding the test!
@datashaman I can see how this would matter in a large cluster... say you have a special node that you reserve just for "backend" tasks, like making snapshots and dumps, and you don't want to hurt the performance of the whole cluster.

say you have a special node that you reserve just for "backend" tasks, like making snapshots and dumps, and you don't want to hurt the performance of the whole cluster.

Yes, this is one of use cases. Other is dumping only a subset of data or dumping data shard by shard or starting many processes in parallel (each reading from one shard only).

authors: datashaman evantahler prog8

repo: taskrabbit/elasticsearch-dump

license_source: bigquery


text:
Stopping/Starting MultiWorker children eventually causes an event-emitter leak

From https://github.com/evantahler/actionhero/issues/935

Using the following task (which is guaranteed to create and remove a multiWorker),  I am able reproduce this error.
// task
'use strict';
var async = require('async');

exports.task = {
  name:          'looper',
  description:   'My Task',
  frequency:     0,
  queue:         'default',
  middleware:    [],

  run: function(api, params, next){
    var jobs = [];

    jobs.push(function(done){
      var i = 0;
      while(i < 999999999){
        i++;
      }

      done();
    });

    jobs.push(function(done){
      api.tasks.enqueueIn(1001, 'looper', {}, 'default', done);
    });

    async.series(jobs, next);
  }
};

Which yields:
...
192.168.7.25 @ 2016-09-02T15:21:24.367Z - info: worker: ended workerId=2
192.168.7.25 @ 2016-09-02T15:21:26.288Z - info: worker: job success default workerId=1, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
192.168.7.25 @ 2016-09-02T15:21:27.344Z - info: worker: started workerId=2
192.168.7.25 @ 2016-09-02T15:21:27.820Z - info: worker: job success default workerId=2, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
192.168.7.25 @ 2016-09-02T15:21:27.845Z - info: worker: ended workerId=2
192.168.7.25 @ 2016-09-02T15:21:30.778Z - info: worker: job success default workerId=1, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
192.168.7.25 @ 2016-09-02T15:21:31.830Z - info: worker: started workerId=2
192.168.7.25 @ 2016-09-02T15:21:32.301Z - info: worker: job success default workerId=2, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
192.168.7.25 @ 2016-09-02T15:21:32.333Z - info: worker: ended workerId=2
192.168.7.25 @ 2016-09-02T15:21:34.231Z - info: worker: job success default workerId=1, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
(node) warning: possible EventEmitter memory leak detected. 21 error listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at Redis.addListener (events.js:239:17)
    at connection.connect (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/connection.js:86:14)
    at queue.connect (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/queue.js:25:19)
    at worker.connect (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/worker.js:54:20)
    at multiWorker.startWorker (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/multiWorker.js:67:10)
    at Immediate._onImmediate (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/multiWorker.js:165:12)
    at processImmediate [as _immediateCallback] (timers.js:383:17)
192.168.7.25 @ 2016-09-02T15:21:35.293Z - info: worker: started workerId=2
192.168.7.25 @ 2016-09-02T15:21:35.761Z - info: worker: job success default workerId=2, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
192.168.7.25 @ 2016-09-02T15:21:35.796Z - info: worker: ended workerId=2
192.168.7.25 @ 2016-09-02T15:21:38.703Z - info: worker: job success default workerId=1, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
192.168.7.25 @ 2016-09-02T15:21:41.172Z - info: worker: job success default workerId=1, class=looper, queue=default, result=[undefined, 0=undefined, 1=1, 2=1, 3=1]
(node) warning: possible EventEmitter memory leak detected. 21 end listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at Redis.addListener (events.js:239:17)
    at connection.connect (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/connection.js:90:14)
    at queue.connect (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/queue.js:25:19)
    at worker.connect (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/worker.js:54:20)
    at multiWorker.startWorker (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/multiWorker.js:67:10)
    at Immediate._onImmediate (/Users/evan/PROJECTS/actionhero/node_modules/node-resque/lib/multiWorker.js:165:12)
    at processImmediate [as _immediateCallback] (timers.js:383:17)

solved by https://github.com/taskrabbit/node-resque/pull/157

node-resque v3.0.3 is published, which fixes this issue.  Thanks for catching it!
https://github.com/taskrabbit/node-resque/releases/tag/v3.0.3

repo: taskrabbit/node-resque


text:
View cart button is not visible when placing a large order

Expected behavior
User should be able to click on the cart icon and see the 'view cart' button and click to go to their cart.
Actual behavior
When there are several items in the cart and the user clicks the cart icon, they are not able to see the 'view cart' button and there is no scroll bar within that dropdown view. The only scroll bar is in the background.
Steps to reproduce behavior
Go to ts.com and add several items to your cart.
Click the cart icon on the top right to get the cart pop up to display and view.

https://razoyo.atlassian.net/browse/TST-296

Looks like this is working now, I can see with small screen that I have a scroll bar, and can scroll down to get to the view cart page

and if clicked it takes me to the cart as expected

authors: monicakarnes staciejurczak suehamre

repo: tastefully-simple/cornerstone

license: MIT


text:
[Bug]: net::ERR_ABORTED 404 (Not Found)

What happened?
Hi, i have installed your system successfully,but when i opened the link http://example.com/admin/login，it showed：

What did you expect to happen?
how to get these files
Version
3.0.x
What browser are you seeing the problem on?
Chrome
Relevant log output
No response

This issue is fairly old and there hasn't been much activity on it. Closing, but please reopen if it still occurs.

authors: huiwenStudio sampoyigi

repo: tastyigniter/TastyIgniter

license: mit


text:
All mail template are not  working after upgrade to V3.0.4 Beta 23.1

Expected behavior:
Expected that customers and admin receive e-mails
Actual behavior:
No emails received
Reproduce steps:
Tried test to test the mail templates and when I click send test message, I get the below error.
"Call to a member function getFilePath() on null" on line 128 of /home/lebanesebakery/public_html/vendor/tastyigniter/flame/src/Pagic/Loader.php#0 /home/lebanesebakery/public_html/vendor/tastyigniter/flame/src/Pagic/Template.php(163): Igniter\Flame\Pagic\Loader->getFilePath() #1 /home/lebanesebakery/public_html/vendor/tastyigniter/flame/src/Pagic/Template.php(62): Igniter\Flame\Pagic\Template->getSourceFilePath() #2 /home/lebanesebakery/public_html/vendor/tastyigniter/flame/src/Support/PagicHelper.php(23): Igniter\Flame\Pagic\Template->render(Array) #3 /home/lebanesebakery/public_html/app/system/classes/MailManager.php(253): Igniter\Flame\Support\PagicHelper::parse('Please verify y...', Array) #4 /home/lebanesebakery/public_html/app/system/classes/MailManager.php(151): System\Classes\MailManager->renderView('Please verify y...', Array) #5 /home/lebanesebakery/public_html/app/system/classes/MailManager.php(82): System\Classes\MailManager->addContentToMailerInternal(Object(Illuminate\Mail\Message), Object(System\Models\Mail_templates_model), Array) #6 /home/lebanesebakery/public_html/app/system/ServiceProvider.php(270): System\Classes\MailManager->addContentToMailer(Object(Illuminate\Mail\Message), 'igniter.user::m...', Array, false) #7 /home/lebanesebakery/public_html/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php(369): System\ServiceProvider->System{closure}(Object(Igniter\Flame\Mail\Mailer), Object(Illuminate\Mail\Message), 'igniter.user::m...', Array, NULL, NULL) #8 /home/lebanesebakery/public_html/vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php(218): Illuminate\Events\Dispatcher->Illuminate\Events{closure}('mailer.beforeAd...', Array) #9 /home/lebanesebakery/public_html/vendor/tastyigniter/flame/src/Events/Dispatcher.php(17): Illuminate\Events\Dispatcher->dispatch('mailer.beforeAd...', Array, true) #10 /home/lebanesebakery/public_html/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(261): Igniter\Flame\Events\Dispatcher->fire('mailer.beforeAd...', Array, true) #11 /home/lebanesebakery/public_html/vendor/october/rain/src/Mail/Mailer.php(403): Illuminate\Support\Facades\Facade::__callStatic('fire', Array) #12 /home/lebanesebakery/public_html/vendor/october/rain/src/Mail/Mailer.php(77): October\Rain\Mail\Mailer->addContent(Object(Illuminate\Mail\Message), 'igniter.user::m...', NULL, NULL, Array) #13 /home/lebanesebakery/public_html/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php(261): October\Rain\Mail\Mailer->send('igniter.user::m...', Array, Object(Closure)) #14 /home/lebanesebakery/public_html/app/system/controllers/MailTemplates.php(94): Illuminate\Support\Facades\Facade::__callStatic('send', Array) #15 [internal function]: System\Controllers\MailTemplates->onTestTemplate('edit', '5') #16 /home/lebanesebakery/public_html/app/admin/classes/AdminController.php(411): call_user_func_array(Array, Array) #17 /home/lebanesebakery/public_html/app/admin/classes/AdminController.php(262): Admin\Classes\AdminController->runHandler('onTestTemplate', Array) #18 /home/lebanesebakery/public_html/app/admin/classes/AdminController.php(167):
Version:
V3.0.4 Beta23.1
Additional Information:
(Additional information, if any)

Yep, that's a bug but it doesn't seem to affect sending mails in other parts of the app. Thanks a lot for opening this issue! I'll get back to this later!

For my side all mails are not working, the only thing is working that from settings I can test the SMTP, but I found a temp solution by restoring loader.php & Template.php under this path /public_html/vendor/tastyigniter/flame/src/Pagic from the previous version

authors: salamaahm sampoyigi


text:
🛑 Lavalink Backup is down

In 6f72712, Lavalink Backup (https://lava2.chirailava.tk/metrics) was down:

HTTP code: 500
Response time: 21985 ms

Resolved: Lavalink Backup is back up in 788c854.

repo: tathaha/bruhuptime


text:
TensorFlow 2D encoding added

Hey, thanks for the code. I have most of my code in TensorFlow/Keras already so I converted your 2D encoding from torch to TensorFlow. I think other might also find this useful.
Cheers

Hey @IRiViI! Thanks for the contribution!
I agree, i think that others might find this useful as well. Ill make a quick change to this pr as well (mainly cleanups and more changes to the readme), and then I'll merge it.

Cool, let me know when you are ready. I already found a bug in my code (which I just fixed).

Oke cool, I only added a small part to the readme.
Well spotted the import redundancy. I guess that is what you get when copy pasting your code.

Cool, thank you! I'll merge this.

Awesome!
I could probably also do the same for 1D and 3D but I didn't need it though.
There is one small difference in the outcome between the TensorFlow en PyTorch version. the outcome has a difference in the order of e-8 when I tested it. So I think it it due to rounding when the data was in 8 bit format or something. I don't care enough to track down where it happens but let me know if you think this should also be addressed.
Cheers,

Nah, I think thats fine. Actually, I can try myself to see if i can do the 1 and 3d version as a learning experience.
Also, i think that this small rounding error is fine, as it is not so much.


text:
refactor: match prompt list

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Docs
[ ] New Binding issue #___
[ ] Code style update
[x] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change?

[ ] Yes, and the changes were approved in issue #___
[x] No

Checklist

[ ] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
[ ] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
[x] I have added a convincing reason for adding this feature, if necessary

Other information
Modified the order of some of the code to match the CLI prompt list.

closing in favor of #202

authors: amrbashir xTeKc

repo: tauri-apps/create-tauri-app


text:
What is the 'name of the database' mentioned in the docs for sql db.close?

In https://tauri.app/reference/javascript/sql/#close the doc for the db? arg to close is "Optionally state the name of a database if you are managing more than one. Otherwise, all database pools will be in scope." But there is no other reference to "name of the database" or connect pools other than in the docs for close. The only string associated with the Database object an api user would know is the path used with Database.load, but since the Database object should know that too, I don't know why I would need or want to specify it.

It's indeed the path you use in load() and i agree that it doesn't make that much sense. I think having a seperate closeAll api would have been better.

authors: FabianLars lendle

repo: tauri-apps/plugins-workspace


text:
Stronghold plugin running very slowly problem

I am currently developing a very large project at TAURI.
I have adopted the official Stronghold plugin for storing crypto keys and other information, but the Stronghold plugin is very slow in initializing, inserting and reading data, and other operations.
It is excruciatingly slow, especially in development builds, and we have to wait several minutes per action.
I am convinced that the Stronghold plugin is a powerful crypto storage, but the overhead is going to increase dramatically.
Any insights or solutions would be appreciated if you could contact me.
When using the Stronghold plugin, we have implemented it using the following official documentation.
https://v2.tauri.app/plugin/stronghold/
Thanks!
development environment
[✔] Environment
    - OS: Windows 10.0.22631 x86_64 (X64)
    ✔ WebView2: 130.0.2849.80
    ✔ MSVC:
        - Visual Studio Build Tools 2022
        - Visual Studio Community 2022
    ✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
    ✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 22.10.0
    - pnpm: 9.12.3
    - npm: 10.9.0

[-] Packages
    - tauri 🦀: 2.1.0
    - tauri-build 🦀: 2.0.3
    - wry 🦀: 0.47.0
    - tao 🦀: 0.30.6
    - @tauri-apps/api : 2.0.3 (outdated, latest: 2.1.1)
    - @tauri-apps/cli : 2.0.5 (outdated, latest: 2.1.0)

[-] Plugins
    - tauri-plugin-process 🦀: 2.0.1
    - @tauri-apps/plugin-process : 2.0.0
    - tauri-plugin-shell 🦀: 2.0.2
    - @tauri-apps/plugin-shell : 2.0.1
    - tauri-plugin-http 🦀: 2.0.3
    - @tauri-apps/plugin-http : 2.0.1
    - tauri-plugin-deep-link 🦀: 2.0.1
    - @tauri-apps/plugin-deep-link : not installed!
    - tauri-plugin-fs 🦀: 2.0.3
    - @tauri-apps/plugin-fs : 2.0.1 (outdated, latest: 2.0.2)
    - tauri-plugin-dialog 🦀: 2.0.3
    - @tauri-apps/plugin-dialog : 2.0.1
    - tauri-plugin-single-instance 🦀: 2.0.1
    - @tauri-apps/plugin-single-instance : not installed!
    - tauri-plugin-stronghold 🦀: 2.0.1
    - @tauri-apps/plugin-stronghold : 2.0.0
    - tauri-plugin-store 🦀: 2.1.0
    - @tauri-apps/plugin-store : 2.1.0
    - tauri-plugin-global-shortcut 🦀: 2.0.1
    - @tauri-apps/plugin-global-shortcut : 2.0.0

[-] App
    - build-type: bundle
    - CSP: img-src * blob: blob: data:; connect-src 'self' https://google.github.io/magika/model/ https://www.youtube.com/ https://googleads.g.doubleclick.net/ ipc: http://ipc.localhost; worker-src 'self' blob:; script-src 'self'; style-src 'self' 'unsafe-inline'; frame-src 'self' https://www.youtube.com/embed/; style-src-elem 'self' 'unsafe-inline'; default-src 'self'
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite

thanks for the report, i'll close this as a duplicate of https://github.com/tauri-apps/plugins-workspace/issues/2048


text:
Browser Compatibility

It is unclear to me what browsers this polyfill supports. Caniuse shows IE9/10/11 and Safari 7 not supporting native promises. Does this poyfill support those browsers?
The minimum supported browser should be documented in the readme.
Thanks

I added a minimum browser support to the Readme https://github.com/taylorhakes/promise-polyfill/commit/21e1deb7c23990b862e2a1f546deb04a4ece856b . It should work in every major browser and all versions. If you see any issues please let me know.

authors: taylorhakes vinnymac

repo: taylorhakes/promise-polyfill


text:
some proportional and cumulative sum values don't make sense for DO eval

Why are these both both 1 but maxrun shows 27 and 24?
mosum <- anlz_domopep(dodat, thr = 3)
mosum[7:8, ]

# # A tibble: 2 x 6
#   site             yr mo    do_mgl below_ave below_maxrun
 #  <fct>         <dbl> <ord>  <dbl>     <dbl>        <dbl>
# 1 Peconic River  2013 Jul     3.12         1           27
# 2 Peconic River  2013 Aug     3.13         1           24

This was caused by missing DO data in the record, added an impute option to take average for each year, site, month combo, starting here https://github.com/tbep-tech/peptools/commit/0f33e70e251e8679128370f0f11ca9798e19d60d

repo: tbep-tech/peptools


text:
Should we deal with holes?

The operative question is:
var arrayWithHoles = [,,,];
arrayWithHoles.contains(undefined) // true or false?

Additionally there is a consequence for proxies: because holes are checked via HasProperty before doing the GetProperty, a weird proxy could respond inconsistently between the two (e.g. proxy[5] === "foo" but Array.prototype.contains.call(proxy, "foo") === false).
I am leaning toward consistency with other array functions in that we should respect holes.

Found through https://stackoverflow.com/questions/42103761/javascript-array-find-has-problems-with-sparse-arrays.
I haven't been able to find a place which explains the whole  reasoning behind this. If the idea is "holes: nobody wants them", then doesn't it make more sense to skip them? The consequence of this is that if I'm consuming an array - such as React props.children, which tends to have holes - I either have to handle the undefined cases with some sort of if check in find callbacks, or I have to run _.compact to remove them.

Skipping holes involves a costly branch check on every iteration.

Skipping holes involves a costly branch check on every iteration.

The branch check happens regardless, since if the element is a hole/array does not have the element itself, a prototype chain lookup is done

I wonder if I'm missing something given @allenwb's comment to @rwaldron  in https://bugs.ecmascript.org/show_bug.cgi?id=3107 that "I doubt that any use of these functions will even notice the change. That's the whole point of "holes, nobody wants them". Seems like people are going to notice having to handle what are essentially nulls - ideally they wouldn't exist, but sadly they often do. But I guess maybe long-term this could encourage people to create dense arrays.

authors: caitp domenic jcrben


text:
Low level optimizations for contiguous sequences

Description
Adds low level optimizations to address #57
Optimizations

[x] std::memset with fill()
[x] std::memcmp with equal()
[x] std::memcmp with compare()
[x] std::memchr with find()
std::memmem with search()

@tcbrindle I filled this PR to see if I'm on the right track (any feedback much appreciated) and also to make it know that the work is in progress for that particular issue.

Thanks for working on this! It looks like there's a syntax error which is tripping up the non-Windows builds, but the general approach looks good to me 👍

I've noticed that with the any_of move, split() seems to have broken? I'm getting an exception with this code in test_split.cpp
{
    auto sv = "the quick brown fox"sv;

    auto split = flux::split(flux::ref(sv), ' ');

    using S = decltype(split);

    static_assert(flux::multipass_sequence<S>);
    static_assert(flux::contiguous_sequence<flux::element_t<S>>);

    static_assert(flux::multipass_sequence<S const>);
    static_assert(flux::contiguous_sequence<flux::element_t<S const>>);

    STATIC_CHECK(check_equal(std::move(split).map(to_string_view),
            std::array{"the"sv, "quick"sv, "brown"sv, "fox"sv}));
}

Just looking for an initial round of feedback; I'll have to address the build issues.

I've noticed that with the any_of move, split() seems to have broken? I'm getting an exception with this code in test_split.cpp
{
    auto sv = "the quick brown fox"sv;

    auto split = flux::split(flux::ref(sv), ' ');

    using S = decltype(split);

    static_assert(flux::multipass_sequence<S>);
    static_assert(flux::contiguous_sequence<flux::element_t<S>>);

    static_assert(flux::multipass_sequence<S const>);
    static_assert(flux::contiguous_sequence<flux::element_t<S const>>);

    STATIC_CHECK(check_equal(std::move(split).map(to_string_view),
            std::array{"the"sv, "quick"sv, "brown"sv, "fox"sv}));
}

This is caused by the new specialisation of find (which split uses) returning the wrong thing in some cases. See the review comments above (the any_of thing is just a coincidence).

I believe I've addressed most, if not all of your comments. Unit tests are also all passing for me. Please take another look when you have a moment. Thanks!

Whoops! I missed that, thanks!

Great!
Is there a need for more unit tests to make codecov happy?

Looking at the CodeCov complaints, most of them seem to be  because it doesn't understand std::is_constant_evaluated() This is technically a runtime branch, but we can't ever test it in a way that will make CodeCov happy so we'll just ignore it.
The other complaint is that we're not testing the short-circuit case in equal when both sequences are sized but their sizes differ... but that definitely looks like it's being tested so my guess is that the compiler has inlined the it into the test function, so as far as CodeCov is concerned the line is never executed.
So I think we're fine :)

Done! No problem at all. But note that tests now fail. Do we need to take into account flux::empty<> sequences?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test-libflux.exe is a Catch v2.13.7 host application.
Run with -? for options

-------------------------------------------------------------------------------
drop
-------------------------------------------------------------------------------
flux/test/test_drop.cpp(104)
...............................................................................

flux/test/test_drop.cpp(104): FAILED:
due to unexpected exception with message:
  flux/include\flux/op/equal.hpp:62: Fatal error: assertion
  'flux::data(seq2) != nullptr' failed

===============================================================================
test cases:  74 |  73 passed | 1 failed
assertions: 556 | 555 passed | 1 failed

Done! No problem at all. But note that tests now fail. Do we need to take into account flux::empty<> sequences?

Thanks! I'd completely forgotten about flux::empty... so much for "nullptr should never happen"! (But it's good that we caught it)
So I guess what we really need to do is check the size of the sequence first... if that is zero then we can exit early, as there's no work to do. Otherwise, we get the data pointer and assert that it's not nullptr, and then finally call the C library function. That is, something like:
auto size = flux::usize(seq);
if (size == 0) {
    return;
}
auto data = flux::data(seq);
FLUX_ASSERT(data != nullptr);

memset(data, val, size);

(adjusted as appropriate for each case).
This turned out to be more complicated than I thought!

Sounds good, I'll get to work on that.
How would you like to handle the different cases in compare()? What would make the most sense if both sequences are empty? Or if only one sequence is empty?
Maybe I should just look at the unit tests 😅

How would you like to handle the different cases in compare()? What would make the most sense if both sequences are empty? Or if only one sequence is empty?

For compare(), I think we get the right behaviour if we do something like:
auto const seq1_size = flux::usize(seq1);
auto const seq2_size = flux::usize(seq2);
auto min_size = std::min(seq1_size, seq2_size);

int cmp_result = 0;

if (min_size > 0) {
    auto const data1 = flux::data(seq1);
    FLUX_ASSERT(data1 != nullptr);
    auto const data2 = flux::data(seq2);
    FLUX_ASSERT(data2 != nullptr);

    cmp_result = std::memcmp(data1, data2, min_size);
}

That is, we only call the C function if the number of bytes is greater than zero, having first asserted that the data pointer is not nullptr.
This is getting messier and messier, sorry!

Ok I think this is ready now and all tests pass for me!

I was able to add some tests, but not sure if I covered everything you had in mind. I also address all (I think) your feedback from the latest review. Sorry for the silly oversights at times and thanks for all the feedback!

Looks like I didn't cover all the cases for compare(). Some help with this would be appreciated.

Done!

It's done!! 🎉
Thanks so much!

repo: tcbrindle/flux


text:
JavaScript Capstone Project Kanban Board Review

Here is the link to our JavaScript Capstone Project Kanban Board:
https://github.com/tchasinga/API-capstone-project/projects/1
There are two students on our team.
Student A: @tchasinga
Student B: @henokkhm

Hi @henokkhm,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Highlights

Kanban board usage ✔
Project assigned ✔

Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

authors: Olamarx henokkhm

repo: tchasinga/API-capstone-project


text:
fixed typo in pr_master_cg

Hi, I just tried to run the code and found a small typo in the pr_master_cg function. It should be s_k instead of its preconditioned counterpart st_k, which should only be used in the preconditioned variant pr_master_pcg.

sorry for the long delay. Thanks for catching this!


text:
go.work generation improvements

should look at .gitignore

create gitignored folder
run script
expected folder to not appear in output

only relevant for local dev


text:
Surface dead links in results output

Show number of dead links found
Make it easier to see dead link URLs when link check finishes by
grouping them at end of output

Hello @tcort! Thank you for writing such a tidy link checker, it's been working well for me. I thought I'd share some additions to the program that have helped me spot dead links when dealing with a lot of output. My apologies if the implementation is less than elegant; my JS has gotten a touch rusty. ^^;

repo: tcort/markdown-link-check

license: isc


text:
Relaxing fzaninotto/faker dependency requirements

Hello @schmengler
I am using your awesome library in a few projects. I was able to install latest version (0.10.0) on Magento 2.3.5 and everything works excellent.
When I switched to another installation (Magento 2.3.3) I was stuck on version 0.8.0, because of dependency fzaninotto/faker. It blocks update. You require version ^1.9.0 and magento 2.3.5 has it already installed with version 1.8.0. It would be great to relax it, because upgrade of magento is not always possible just in time. Clients have different upgrade policies or just want to pay for something other. I miss useful order and invoice builders on 0.8.0  version :)

Please doublecheck what locks fzaninotto/faker to version 1.8.0 in your project. In a vanilla M2 installation, I can only see magento/magento2-functional-testing-framework requiring the package in ^1.6 – which includes version 1.9.0 so there should not be a problem.


text:
MtprotoHeader lang_pack value

What value is set there? Is there a way to control it?

See documentation for "localization_target" option at https://core.telegram.org/tdlib/options.

How can I set these options? I use C# client with C++/CLI tdlib.

Use the method TdApi.SetOption.

Ok. It's confusing that in C# Execute is a static method while Send is instance method. So the difference is not just in being synchronous but in global/instance state.

authors: AqlaSolutions levlam

repo: tdlib/td


text:
🛑 send.artemislena.eu is down

In 9062e66, send.artemislena.eu (https://send.artemislena.eu) was down:

HTTP code: 0
Response time: 0 ms

Resolved: send.artemislena.eu is back up in 1b70ea1 after 7 minutes.

repo: tdulcet/send-instances-status


text:
Change redirect_uri secret to be more flexible

Applies to both OAuth2 and OpenID Connect.
With this the developer can provide either the full URL or the URL up to the AuthPlug path. If the suffix is already there we won't add it again.
Should make it easier to get it on the first try.

Yeah, hit it hard :)


text:
elasticsearch新建索引功能异常

如题，新建索引时，mapping字段只能是默认值，不支持修改。

补充版本信息
window客户端，v2.6.13

有时间可以试下新版本，修改该问题了

authors: team-ide yohoph

repo: team-ide/teamide


text:
converted headers to charlists

Consul is complaining with request to Consul failed!: {:headers_error, :not_strings}, upon inspecting endpoint.ex the :httpc.request/4 call the Request has url as charlists but the headers not which produces that error, with the headers as charlists as well the problem seems to be fixed

Closing, it got implemented in #6

authors: hmatinho szajbus


text:
🛑 PMS Application - https://app.staging.greyfinch.com/ is down

In 2684c0d, PMS Application - https://app.staging.greyfinch.com/ (https://app.staging.greyfinch.com/) was down:

HTTP code: 503
Response time: 116 ms

Resolved: PMS Application - https://app.staging.greyfinch.com/ is back up in 80d6106.

repo: teamgreyfinch/staging-status


text:
Change regular expression in PathParms middleware to avoid replacing port in url

When PathParams middleware replaces the path params, it fails if the url contains the host with port (http://localhost: 7473/my_path/:whatever)
** (ArgumentError) argument error
    :erlang.binary_to_existing_atom("7473", :utf8)
    (stdlib) erl_eval.erl:680: :erl_eval.do_apply/6
    (stdlib) erl_eval.erl:888: :erl_eval.expr_list/6
    (stdlib) erl_eval.erl:411: :erl_eval.expr/5
    (stdlib) erl_eval.erl:273: :erl_eval.expr/5
    (elixir) lib/regex.ex:731: Regex.apply_list/5
    (elixir) lib/regex.ex:726: Regex.apply_list/5
    (elixir) lib/regex.ex:668: Regex.do_replace/4

Problem
It's unavoidable when using BaseUrl, Telemetron.Instrumenter.Tesla and PathParams. There is no order possible.
Telemetron needs BaseUrl to metric host, PathParams needs to be executed before BaseUrl because otherwise it would parse the port and Telemetron needs to be executed before PathParams because otherwise it would provoke high cardinality in metrics.
Solution
Change regular expression to avoid considering numbers

What about :my_param_123 ?

You're right. Would it be acceptable if we force to start by character?
Something like: :([a-zA-Z]{1}[\w_]+)
Otherwise we could opt by another approach:
defp build_url(url, nil), do: url

  defp build_url(url, params) do
    Enum.reduce(params, url, fn {k, v}, u ->
      String.replace(u, ":#{k}", to_string(v))
    end)
  end

Please see https://github.com/teamon/tesla/pull/270#issuecomment-447933951 on why String.replace is not a good solution.
:([a-zA-Z]{1}[\w_]+) will not match single letter param.

Please see #270 (comment) on why String.replace is not a good solution.

I see, thanks for this! Fair enough.

:([a-zA-Z]{1}[\w_]+) will not match single letter param.

Arg, right! I forgot this! So, what about :([a-zA-Z]{1}[\w_]*)?

Thanks! How about some tests? :)

Thanks! How about some tests? :)

Sure, sorry! 🤦♂
Now it's done! Let me know if you think it covers all the cases we've discussed :)

Note: After adding a few additional tests the pipeline failed because of a test not related (apparently) to my tests.

Well, after adding a last commit it passed the checks again 🤷♂

Thanks! 🙇

authors: asniaire teamon

repo: teamon/tesla


text:
Raising Capybara::Poltergeist::ClickFailed even when the click is possible

Hi @jonleighton,
I'm receiving that error:
1) ContributionImprovements create a new contribution_improvement
     Failure/Error: within_tab 'Itens de Custo' do
     Capybara::Poltergeist::ClickFailed:
       Click at co-ordinates [234.5, -247] failed. Poltergeist detected another element with CSS selector '' at this position. It may be overlapping the element you are trying to click.
     # ./spec/support/capybara.rb:20:in `click_link'
     # (eval):2:in `click_link'
     # ./spec/support/helpers.rb:87:in `block in within_tab'
     # ./spec/support/helpers.rb:86:in `within_tab'
     # ./spec/requests/contribution_improvements_spec.rb:76:in `block (2 levels) in <top (required)>'

  2) ContributionImprovements update an existent contribution_improvement
     Failure/Error: within_tab 'Itens de Custo' do
     Capybara::Poltergeist::ClickFailed:
       Click at co-ordinates [234.5, -247] failed. Poltergeist detected another element with CSS selector '' at this position. It may be overlapping the element you are trying to click.
     # ./spec/support/capybara.rb:20:in `click_link'
     # (eval):2:in `click_link'
     # ./spec/support/helpers.rb:87:in `block in within_tab'
     # ./spec/support/helpers.rb:86:in `within_tab'
     # ./spec/requests/contribution_improvements_spec.rb:194:in `block (2 levels) in <top (required)>'

I can't reproduce that issue in isolation but this is a real issue :P
The failing scenario looks like that:
within_tab 'Itens de Custo' do
  ...
end

The helper:
def within_tab(locator)
  within ".ui-tabs" do
    click_link locator

    within ".ui-tabs-panel:not(.ui-tabs-hide)" do
      yield
    end
  end
end

Reducing the complexity:
  1) ContributionImprovements update an existent contribution_improvement
     Failure/Error: click_link 'Itens de Custo'
     Capybara::Poltergeist::ClickFailed:
       Click at co-ordinates [234.5, -247] failed. Poltergeist detected another element with CSS selector '' at this position. It may be overlapping the element you are trying to click.
     # ./spec/support/capybara.rb:20:in `click_link'
     # (eval):2:in `click_link'
     # ./spec/requests/contribution_improvements_spec.rb:194:in `block (2 levels) in <top (required)>'

click_link 'Itens de Custo'

I tried a sleep to check for a strange timeout but didn't work:
sleep 10

click_link 'Itens de Custo'

But, if I render the page, the scenario magically pass!
page.driver.render('/tmp/file.png')

click_link 'Itens de Custo'

It's consistent, all the time I ran these two scenarios, they fail.
All the time I ran with sleep, they also fail.
All the time I ran with page.driver.render, they pass.
I guess this is the useful piece of debug:
{"name"=>"find", "args"=>[".//a[./@href][(((./@id = 'Itens de Custo' or normalize-space(string(.)) = 'Itens de Custo') or ./@title = 'Itens de Custo') or .//img[./@alt = 'Itens de Custo'])]"]}
{"response"=>{"page_id"=>4, "ids"=>[88]}}
{"name"=>"visible", "args"=>[4, 88]}
{"response"=>true}
{"name"=>"visible", "args"=>[4, 88]}
{"response"=>true}
{"name"=>"click", "args"=>[4, 88]}
{"error"=>{"name"=>"Poltergeist.ClickFailed", "args"=>[nil, {"x"=>234.5, "y"=>-247}]}}
{"name"=>"reset", "args"=>[]}
{"response"=>true}

Calling page.render before the click_link:
{"name"=>"render", "args"=>["/tmp/file.png", false]}
{"response"=>true}
{"name"=>"find", "args"=>[".//a[./@href][(((./@id = 'Itens de Custo' or normalize-space(string(.)) = 'Itens de Custo') or ./@title = 'Itens de Custo') or .//img[./@alt = 'Itens de Custo'])]"]}
{"response"=>{"page_id"=>4, "ids"=>[91]}}
{"name"=>"visible", "args"=>[4, 91]}
{"response"=>true}
{"name"=>"visible", "args"=>[4, 91]}
{"response"=>true}
{"name"=>"click", "args"=>[4, 91]}
{"response"=>true}

Note: seems like the position of link changes after calling render.
What you think?
Do you need some information about my application (I can send in private)?
Note: it works fine on selenium and the rendered image is exactly what I expect to see at this moment.

Its still failing for me :( Unable to click with success ! Help

authors: narendra-chandratre sobrinho

repo: teampoltergeist/poltergeist


text:
网页拖动滑块

在使用hover('元素id')后，如何拖动这个滑块，使用r.mouse_x()、r.mouse_y()获取到的是当前鼠标的位置，不是这个元素的位置，我看在第一次hover('元素id')后鼠标并没有移动过去

r.hover('//*[@id="slider"]')
r.mouse('down')
r.hover(r.mouse_x() + 30, r.mouse_y())
r.mouse('up')

r.mouse_x()没有获取到slider元素的位置

Hi @491933243 I know why. If you use hover() with element ID it does not move mouse to web element. It only moves in the browser's backend memory. To actually move the mouse, use hover('image.png') where image.png is an image snapshot of the web element. This will actually move the mouse on the OS level to do what you want.

Okay, got it, I also planned to try before, but it didn't success. Which folder should I put the image.png in

Can put in the same folder as your python script / current working directory in Python

repo: tebelorg/RPA-Python


text:
Allow using log rotation

As it is possible to create log, having the ability to use logrotate could help managing log.

Could you provide some details of why Logrotate doesn't function now? I'll check into this for myself as well, but anything you could provide would be helpful.

There might be a better solution than that, to have the file closed each time a log is written, then open it whenever something needs to be logged. It might not be the best solution, but I'll check into it and see if something like that will work.


text:
SICF services

Hi Rahul,
Can you try adding the SICF services for the web dynpro applications to the repository? Object type = SICF should appear in ZABAPGIT for the repository. Then the applications should be possible to start right after installing via abapGit.
Also for your information I've added issue https://github.com/larshp/abapGit/issues/121 for abapGit

Hi,
Can you try updating abapGit and commiting the files again? this should solve some diffs in TABL + sorting for WDYN
It looks like there is an issue in abapGit regarding
ACCESSIBILITY_DESCR
will look into this after you've updated the files

Unable to add SICF node to ABAPGIT repo. Details at https://github.com/larshp/abapGit/issues/121

update to latest abapGit version and try again

Thanks. Will get back once done. Happy new Year!
On Mon, Dec 28, 2015 at 9:34 AM, Lars Hvam notifications@github.com wrote:

update to latest abapGit version and try again
—
Reply to this email directly or view it on GitHub
https://github.com/techaware/wdalv_config/issues/1#issuecomment-167608603
.

--
Rahul Aware

After updating the latest ABAPGIT - I was able to add SICF nodes to the GIT repo.

authors: larshp techaware


text:
Make saving atomic in fs adapter

This writes to a temporary file then calls rename to replace the
original.
Doing this prevents corruption in cases where a program improperly ends
during a write sequence.

Hey @ags131, I think when writeFile invokes your callback function it must be setting 'this' to something else.
Can you create a local variable before calling writeFile like :
var self=this;

and then when you call fs rename change that to :
self.fs.rename(tmpdbname,dbname,callback);

That should fix the TravisCI build and the fs.rename should actually work.
(When fixed) I am guessing this will not be considered a 'breaking' change as it leaves your filesystem in the same state and filesystem operations should be in the same directory so permissions should not be an issue.  I also think it might be useful if the database fails to save that it will leave the old as backup.

Fixed, sorry about that, I'm spoiled to arrow functions where 'this' is carried over from the outer scope,

Thanks

@obeliskos When this PR is supposed to be released on npm? If there is data corruption involved, then it seems to be a quite critical hotfix.

Whenever @techfort gets a chance to update this... we are at a good point to do this so maybe he can find time over the holidays.

Well, I will say that having a critical bug that results in corrupted data sitting here for almost 30 days has made me significantly less likely to use this project.

As I understand it, loki might be doing an async save when user code throws exception exiting the process.  The solution offered merely keeps a backup of the original database until the save is complete and then overwrites original in an atomic fs rename.  So the 'critical' bug would be in user code and this a protection measure.  @ags131 can correct me if that is not correct but I assume his own p.r. satisfied his own concerns that the problem was external to loki and a backup was sufficient.  If there is a reproducible problem internal to loki then please provide a gist.
@techfort has been extremely busy of late but hopefully he can update npm in the next week or so.

@obeliskos This does help in that situation, however, the main goal was to prevent corruption during power loss or program termination (Such as Ctrl+C or SIGTERM)
In these cases, writeFile() is interrupted and ends with either a partial JSON or a 0 byte file.
using the temp file prevents this as renames are atomic and performed at the OS level. If a write is interrupted, the rename would never occur thus preserving the original data. Since rename is atomic, it will always result in either success (File renamed) or failure (file not renamed). In the case of failure the original file remains.
I don't know of a way to make a reliable example or test case as its very timing specific, but I have seen corruption happen many times from quite a few users in the screeps community. We have a mod that manually creates the adapter with this patch that has mitigated most instances of corruption. A new npm release would obsolete that mod and help prevent corruption for unsuspecting users.

Ah ok thanks.. that is screeps mmo game right?  Looks really well done...  I will have to find some more time soon.
If you are listening to any emitted events make sure to try/catch within them, especially db "close".  If you are using autosave make sure your interval is not too low.  If you need more help diagnosing let me know.
Your p.r. did raise issue (referenced above) of whether we should try catch listeners ourselves but for some events like insert this would kill performance so we are currently opting not to do so.  Not sure if that is related to your problem but that is one area where external code and loki interoperate.
I am unable to update loki npm so that is why I have not updated it myself.

@techfort has updated lokijs npm package to current (1.4.2).

@ags131 (and others) another issue/pr.commit (#526 , 613db681d4f85b2a364f65c12f83a8988bc83357) to be aware of in the event that you receive any instability from loki attempting multiple, simultaneous async io operations conflicting with each other :
A new throttledSave loki constructor option has been added that will hopefully alleviate conflicting save requests.  This is the (only?) area where lokijs could potentially have been -contributing- to instability... through lack of coordination of those requests.
We intend to allow users to test this before making the option default so if you think it may of relevance to you, please do try it to see it helps.   This is not yet on npm but once we verify it we can get techfort to update npm.

authors: ags131 artch obeliskos tedivm

repo: techfort/LokiJS


text:
Catch api limit errors, without dying

When an api limit is reached the response body is not Poison decodable.
This will allow clients to handle the errors themselves rather than
raising the error
Example of darksky response
%HTTPoison.Response{
   body: "daily usage limit exceeded\n",
   headers: [
     {"Date", "Wed, 22 Aug 2018 19:50:15 GMT"},
     {"Content-Type", "text/plain"},
     {"Transfer-Encoding", "chunked"},
     {"Connection", "keep-alive"},
     {"Cache-Control", "no-store"},
     {"X-Response-Time", "2.137ms"},
     {"Vary", "Accept-Encoding"}
   ],
   request_url: "https://api.darksky.net/forecast/SECRETKEY/36.4225400751601,-73.6386049164739,1504281780?lang=en&units=us",
   status_code: 403
 }

👍

Thanks @anthonyfalzetti https://hex.pm/packages/darkskyx/0.1.5 is released

Excellent thank you!

authors: anthonyfalzetti jasonnoble techgaun

repo: techgaun/darkskyx


text:
customer is not listed in the customer dropdown under advance search of invoice

issue closed

repo: techgebra/polosys-books-mobile

license: Unlicense


text:
some characters interpreted as markdown characters

if the post contains characters like ** they may be interpreted as markdown characters, e.g. star will be bold star.

fixed in latest

repo: technicat/fedicat


text:
Enhance config options

[x] Add every config and advanced config option to MQTT (JSON)
[x] Separate config state from config actions in MQTT (same as lockstate/action and keypad codes/action)
[x] ACL for every separate config option
[x] Make some config/advanced config options more human readable
[x] Allow modifying every config and advanced config option through MQTT
[x] Modify existing config Home Assistant auto discovery topics
[x] Add new config Home Assistant auto discovery topics
[x] Update README
[x] Enable/disable all button for ACL options in WebCfg
[x] Final minor adjustments and testing
[x] Update Arduino Core to 2.0.15 (won't build otherwise using Actions/Dockerfile)

NOTE: Breaking change as the existing configuration MQTT topics can not be used for changing settings if this is merged.
Closes #327

@technyon This PR needs the most recent changes in I-Connect/NukiBleEsp32. Can you sync nuki_ble with upstream?

Hi,
Sorry I didn't see your comment. nuki_ble is now updated.
One more thing: Since there are breaking changes in this PR, could we have a discussion on github? Not that I'm against it, I'd just like to hear some more opinions.

Binary available for testing from the Github Actions artifacts: https://github.com/technyon/nuki_hub/actions/runs/8644273771/artifacts/1404437356

Binary available for testing from the Github Actions artifacts: https://github.com/technyon/nuki_hub/actions/runs/8644273771/artifacts/1404437356

@iranl Before merging, could you post a binary for testing on discord?

As requested, also posted on Discord.
nuki_hub-8.34-pre-2.zip

Converted to draft because of issues reported in #327

Added fixes for stability issues with the combination of an opener and lock.
nuki_hub-8.34-pre-3.zip

Hi. There are a lot of changes in this PR, and some potential stability issues have been reported. We should to some thorough testing before merging. Is the -pre-3 binary up-to-date?

Pre-3 is not up to date.
Do you want to include #340 in 8.34?
#340 is a pretty minor addition which is basically a copy of the JSON keypad control.
If so I will build Pre-4 after merging #340 from master + this PR.
If not I will build Pre-4 from the current state of this PR.

Hi,
I've merged your other PRs. Could you update and build an up-to-date binary

Binaries for pre-4:
esp32dev-assets.zip
esp32-s3-assets.zip
esp32solo1-assets.zip
esp32-c3-assets.zip
Will run the ESP32 and ESP32-s3 ones for 24h and post them on Discord if I have no issues.
Please note that the merged binaries for Webflash (nuki_hub_esp32[dev/s3/c3/solo1].bin) can't be used for upgrading.
OTA upgrade still needs to be done using the nuki_hub.bin binary from the asset package for the respective ESP version.

@katiuskt: I've pushed an update to the W5500 code to change the pinout for the AtomPOE on the S3 to 5/7/8/39 instead of 19/22/23/33
Can you try esp32-s3-assets.zip?
Note: Will still show 8.34-pre4

I've taken a goed look at the pinouts and it seems the following pinouts translate to the different models:

Func
Atom S3 lite ESP32-S3
Atom lite ESP32

CLK
6
19

CS
5
22

MISO
7
23

MOSI
8
33

In my first try I  assumed the pinout G5/G6/G7/G8/G38/G39 translated to G19/G21/G22/G23/G25/G33.
Please try esp32-s3-assets.zip
You can try debugging using the serial console with a program like hterm

Good to hear the Atom POE now works on the S3.
As for the maintenance/reset button I agree, this is also the way I have recently implemented the query buttons.
The choice to expose maintenance/reset through a switch was made a while ago and changing it would mean a breaking change for people using this switch in an automation. The pros of changing this behaviour don't outweigh the cons of a breaking change at this time in this case imho.

authors: iranl technyon


text:
Please add Denver, CO [we want to specifically address Senate Bill 217]

Subject: We Demand a People's Budget
Emails:
districtone@denvergov.org
kevin.flynn@denvergov.org
Jamie.Torres@denvergov.org
kendra.black@denvergov.org
DenverCouncil5@denvergov.org
paul.kashmann@denvergov.org
jolon.clark@denvergov.org
christopher.herndon@denvergov.org
district9@denvergov.org
stacie.gilmore@denvergov.org
kniechatlarge@denvergov.org
ortegaatlarge@denvergov.org
alex.valdez.house@state.co.us
julie.gonzales.senate@state.co.us
Erin.Reynolds@state.co.us
leroy.garcia.senate@state.co.us
rhonda.fields.senate@state.co.us
leslie.herod.house@state.co.us
serena.gonzales-gutierrez.house@state.co.us
vicki.marble.senate@state.co.us
senatorsonnenberg@gmail.com
bob.gardner.senate@state.co.us
dennis.hisey.senate@state.co.us
rob.woodward.senate@state.co.us
bob.rankin.senate@state.co.us
jeni.arndt.house@state.co.us
kcbecker.house@state.co.us
adrienne.benavidez.house@state.co.us
Shannon.bird.house@state.co.us
jeff.bridges.senate@state.co.us
janet.buckner.house@state.co.us
bri.buentello.house@state.co.us
yadira.caraveo.house@state.co.us
james.coleman.house@state.co.us
lisa.cutter.house@state.co.us
jessie.danielson.senate@state.co.us
kerry.donovan.senate@state.co.us
monica.duran.house@state.co.us
daneya.esgar.house@state.co.us
tony.exum.house@state.co.us
stephen.fenberg.senate@state.co.us
rhonda.fields.senate@state.co.us
Detailed message:
I am a resident of Denver. I am writing to demand that the Denver and Colorado adopt a People’s Budget that prioritizes community wellbeing and redirects funding away from the police.
We will no longer accept empty gestures and suggestions of “reform.” This includes the statewide Senate Bill 217, being referred to as the “police accountability” bill. This bill does not do enough to address our systemic policing problems in our state and Denver. The bill will increase police budgets by $1.4 million, and will most likely increase spending on police departments even more in the future.
We are demanding that our voices be heard now, and that real change be made to the way this city allocates its resources. We demand to drastically reduce the Denver Police Department’s budget. DPD is overfunded and holds responsibility over community issues that they are fundamentally unable to address.  They have shown to be consistently racist and abusive ways towards Denver’s residents.
We demand that the City Council meaningfully defund the Denver Police Department. We join the calls of those across the country to #DefundThePolice. We demand a budget that adequately and effectively meets the needs of at-risk Denver residents during this trying and uncertain time, when livelihoods are on the line. We demand a budget that supports community wellbeing, rather than empowers the police forces that tear them apart.
We must divest from policing funds, and invest in a people’s budget. We are in the midst of a pandemic with severe economic consequences. Colorado unemployment is at historic highs, with more than 430,000 unemployment claims filed and processed since March 14th, 2020. The evictions and economic insecurity caused by COVID-19 will demand strength and resolve in our communities. Divesting from DPD and investing in our communities has never been more important.
I am eager to see how you will address these issues, which I will fight for until they are meaningfully addressed.
Thank you for your time,
[YOUR NAME] [YOUR ADDRESS] [YOUR EMAIL] [YOUR PHONE NUMBER]

Working on this!

Completed! PR #296

Thank you! I know this might be a silly request and if you can't change it,
no big deal. But I did notice a typo in the second sentence, "I am writing
to demand that the Denver and Colorado adopt a People's Budget that
prioritizes community wellbeing and redirects funding away from the police"
needs "the" taken out before Denver.
Not a big deal if it's not an easy change!
On Fri, Jun 5, 2020 at 2:18 PM Dora Zhao notifications@github.com wrote:

Completed! PR #296 https://github.com/teddywilson/defund12.org/pull/296
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/teddywilson/defund12.org/issues/272#issuecomment-639778175,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP256AHRT63TX3TDWHM6DQ3RVFHJRANCNFSM4NUY2AQQ
.

--
Shelby Rahe https://shelbyrahe.cargo.site/
303-945-1330

Yes it should be fixed now! :)

#316

Hello, could I please have Jared Polis added to my email. His email is
governorpolis@state.co.us
Thank you!
On Fri, Jun 5, 2020 at 9:58 PM Sarah notifications@github.com wrote:

Closed #272 https://github.com/teddywilson/defund12.org/issues/272.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/teddywilson/defund12.org/issues/272#event-3414111862,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP256ACEG6ZAPHL3JVQRBUTRVG5F3ANCNFSM4NUY2AQQ
.

--
Shelby Rahe https://shelbyrahe.cargo.site/
303-945-1330


text:
Val err details

I've added more detail to the ValidationError.

ValidationError::source_type field stores the name of the source type
ValidationError::message stores an error message.
ValidationError::new::<T>(message) fills in the source_type name based on T and stores the message.
I've removed PartialEq (you should always pair PartialEq and Eq) as it was only being used for equality comparisons in the integration tests. Using assert_matches! allows you to avoid equality tests as the pattern matching system does not use equality tests.

Looks like my merge went completely wrong.

I reverted the mis-merge of the master branch.

Maybe this closes #5 ?

It looks like you're deleting .github/workflows/rust.yml

Why not use assert!(matches!(...)) instead of assert_matches!(...)? I kind of like the first variant more

I wonder if the fields of the ValidationError should be public. Perhaps we should make it private and use only for the message?

I also think we should add value: Option<T> field. It could be used by Guarded<_>::new to return provided value in case of fail. Reference:
https://github.com/PabloMansanet/tightness/blob/master/src/core.rs#L95

Although all of this is starting to be a bit messy. Looking from a UX point of view, the error should say something like failed to create Username from "   ": provided value is invalid. For this we need 1) the name of the source type 2) provided value. In case of Guarded<_>::new it should also probably return provided value back (as it owns it)....

Another idea: we can create two separate default errors for construction/mutation:

ConstructionError<T>(T). Possible message: failed to construct Username("  "): provided value is invalid. It should also contain the value, so the user can take the ownership back.
MutationError<T>. Possible message: failed to mutate Username("valid name") to Username("  "): provided value is invalid.

It looks like you're deleting .github/workflows/rust.yml

I'll sort this out later today, I'm just starting my day here :wink:

Why not use assert!(matches!(...)) instead of assert_matches!(...)? I kind of like the first variant more. And it needs no dependency.

assert_matches! outputs a clearer assertion message, assert!(matches!(...)) just outputs that the match fails.

I wonder if the fields of the ValidationError should be public. Perhaps we should make it private and use only for the message?

I was wondering the same. I see this code as a first draft. In the case of this type, making the fields private makes sense as who knows how we want to represent the source_type in future. I also think the we may want to make the message field type String so that it's plays better with format! and constructing messages in general.

I also think we should add value: Option<T> field. It could be used by Guarded<_>::new to return provided value in case of fail. Reference:
https://github.com/PabloMansanet/tightness/blob/master/src/core.rs#L95

I'll take a look at your proposed solutions later on. But one way or the other having access to the input value is critical for a decent error message.

I'll sort this out later today, I'm just starting my day here 😉
Of course :)
assert_matches! outputs a clearer assertion message, assert!(matches!(...)) just outputs that the match fails.
Fair.
I was wondering the same. I see this code as a first draft. In the case of this type, making the fields private makes sense as who knows how we want to represent the source_type in future. I also think the we may want to make the message field type String so that it's plays better with format! and constructing messages in general.
I thought about the String too. We need to think about the use-cases

Another idea: we can create two separate default errors for construction/mutation:
1. `ConstructionError<T>(T)`. Possible message: `failed to construct Username("  "): provided value is invalid`. It should also contain the value, so the user can take the ownership back.

2. `MutationError<T>`. Possible message: `failed to mutate Username("valid name") to Username("  "): provided value is invalid`.

I like the idea of separate errors for the separate actions. I'll take a look at adding the value now.

With the current arch of the validate fn and the ConstructionError the usage is quite clunky if you don't want to make a custom error.
prae::define! {
        pub Username: String
        validate |u| -> Option<prae::ConstructionError::<String>> {
            if u.is_empty() {
                Some(prae::ConstructionError::new("Username", u.clone()))
            } else {
                None
            }
        }
    }

I think that the validate closure should return a Result<(), Err> as that is idiomatic and means that the ? operator can be used in the closure.
use prae;

#[derive(Debug)]
pub struct UsernameError;

prae::define! {
    pub Username: String
    validate |u| -> Result<(), UsernameError> {
        if u.is_empty() {
            Err(UsernameError{})
        } else {
            Ok(())
        }
    }
}

I think prae::Guarded::new should always return a ConstructionError.
The signature should change to pub fn new<V: Into<T>>(v: V) -> Result<Self, ConstructionError> {.
When the user wants to use a custom error it's simply made the std::error::Error::source of ConstructionError.
I would like to capture errors returned from the validate closure of type String and concat that onto the existing ConstructionError message.
lazy_static! {
    static ref SOME_REGEX: Regex = Regex::new(r"^[a-zA-Z0-9 \-]{1,100}$").unwrap();
}

prae::define! {
    pub Username: String
    validate |u| -> Result<(), String> {
        if SOME_REGEX.is_match(s) {
            Ok(())
        } else {
            Err(format!("match failed for regex {}", regex))
        }
    }
}

That would generate an error:
failed to create Username from \"\": provided value is invalid
match failed for regex ^[a-zA-Z0-9 \-]{1,100}$

I think that the validate closure should return a Result<(), Err> as that is idiomatic and means that the ? operator can be used in the closure.

Good point. I agree.

I think prae::Guarded::new should always return a ConstructionError.
The signature should change to pub fn new<V: Into<T>>(v: V) -> Result<Self, ConstructionError> {.
When the user wants to use a custom error it's simply made the std::error::Error::source of ConstructionError.

I don't think it should. The reason why it's generic is because it's meant to be as flexible as possible and return any error. The ConstructionError and MutationError are just convenient default errors. Anyway, it's late in my area, so I'm gonna read your proposal again in the morning.
Also, I have an idea about possible design that will allow user to return custom messages, but I didn't finish it so I also do it a bit later (haven't much time today :)). Anyway, thank you for your help, we'll finish it soon :)

I don't think it should. The reason why it's generic is because it's meant to be as flexible as possible and return any error. The ConstructionError and MutationError are just convenient default errors. Anyway, it's late in my area, so I'm gonna read your proposal again in the morning.

All good, get some rest :wink: We'll talk about it soon.

So, I looked at it and it seems to me that bringing ConstructionError and MutationError is just impossible with the current code. I don't want to break the usage of the validate with Error::source as its usage will be inconvenient.
Possible solution will be to split the Guarded into EnsureGuarded and ValidateGuarded (as it was in the beginning, if you look at commits history), where EnsureGuarded will explicitly return ConstructionError and MutationError, but it will complicate both the API and the implementation of the macro.
I think right now we can just revert to the HEAD and add information about the type to the ValidatationError, like so:
pub struct ValidationError<T> {
    _ty: PhantomData<T>,
}

impl<T> fmt::Debug for ValidationError<T> {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        writeln!(
            f,
            "failed to construct/mutate {}: provided value is not valid",
            std::any::type_name::<T>()
        )
    }
}

impl<T> fmt::Display for ValidationError<T> {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        <Self as fmt::Debug>::fmt(self, f)
    }
}

impl<T> std::error::Error for ValidationError<T> {}

And change the tests to use assert_matches instead of directly comparing it.
I propose to focus on another topics right now and return to this later. The fact that a user will see the message failed to construct/mutate Username: provided value is not valid is nice for now.
What do you think?

Although we could probably define ConstructionError<E> and MutationError<E> that are generic over some error E, which can be custom error, define in validate, or just a &'static str for the default error with ensure. In case of custom error, these errors can implement Into<E>, which should allow to use ? to cast them with the Result<..., E> (not sure, didn't test it). Then we can use them in all cases

So, I looked at it and it seems to me that bringing ConstructionError and MutationError is just impossible with the current code. I don't want to break the usage of the validate with Error::source as its usage will be inconvenient.

Agreed for the increase in complexity doesn't justify the value of having a MutationErrorthat provides the value you're mutating. I would argue that knowing the value you're try to mutate to is all you really care about anyway.
I'm happy with the implementation as it is, a single ValidationError that allows me to see the alias name and the value that failed to validate.

Although we could probably define ConstructionError<E> and MutationError<E> that are generic over some error E, which can be custom error defined in validate, or just a &'static str for the default error with ensure. In case of custom error, these errors can implement Into<E>, which should allow to use ? to cast them with the Result<..., E> (not sure, didn't test it). Then we can use them in all cases

I think this is also needless complexity for the value of having two Errors types. Let's keep it to one Error type until the need arises to make two.

I would like to implement validate returning a Result<(), E> in a separate branch so that this change is just enough to fix #5.

Perfect!

authors: ObsceneGiraffe teenjuna

repo: teenjuna/prae


text:
Operator projects using the removed APIs in k8s 1.22 requires changes.

Problem Description
Kubernetes has been deprecating API(s), which will be removed and are no longer available in 1.22. Operators projects using these APIs versions will not work on Kubernetes 1.22 or any cluster vendor using this Kubernetes version(1.22), such as OpenShift 4.9+. Following the APIs that are most likely your projects to be affected by:

apiextensions.k8s.io/v1beta1: (Used for CRDs and available since v1.16)
rbac.authorization.k8s.io/v1beta1: (Used for RBAC/rules and available since v1.8)
admissionregistration.k8s.io/v1beta1 (Used for Webhooks and available since v1.16)

Therefore, looks like this project distributes solutions in the repository and does not contain any version compatible with k8s 1.22/OCP 4.9. (More info). Following some findings by checking the distributions published:

teiid.0.1.1: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["virtualdatabases.teiid.io"])
teiid.v0.2.0: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["virtualdatabases.teiid.io"])
teiid.v0.3.0: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["virtualdatabases.teiid.io"])
teiid.v0.4.0: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["virtualdatabases.teiid.io"])
teiid.0.0.1: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["virtualdatabases.teiid.io"])
teiid.0.1.0: this distribution is using APIs which were deprecated and removed in v1.22. More info: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22. Migrate the API(s) for CRD: (["virtualdatabases.teiid.io"])

NOTE: The above findings are only about the manifests shipped inside of the distribution. It is not checking the codebase.
How to solve
It would be very nice to see new distributions of this project that are no longer using these APIs and so they can work on Kubernetes 1.22 and newer and published in the community-operators collection. OpenShift 4.9, for example, will not ship operators anymore that do still use v1beta1 extension APIs.
Due to the number of options available to build Operators, it is hard to provide direct guidance on updating your operator to support Kubernetes 1.22. Recent versions of the OperatorSDK greater than 1.0.0 and Kubebuilder greater than 3.0.0 scaffold your project with the latest versions of these APIs (all that is generated by tools only). See the guides to upgrade your projects with OperatorSDK Golang, Ansible, Helm or the Kubebuilder one. For APIs other than the ones mentioned above, you will have to check your code for usage of removed API versions and upgrade to newer APIs. The details of this depend on your codebase.
If this projects only need to migrate the API for CRDs and it was built with OperatorSDK versions lower than 1.0.0 then, you maybe able to solve it with an OperatorSDK version >= v0.18.x < 1.0.0:

$ operator-sdk generate crds --crd-version=v1
INFO[0000] Running CRD generator.
INFO[0000] CRD generation complete.

Alternatively, you can try to upgrade your manifests with controller-gen (version >= v0.4.1) :
If this project does not use Webhooks:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role  paths="./..."

If this project is using Webhooks:

Add the markers sideEffects and admissionReviewVersions to your webhook (Example with sideEffects=None and admissionReviewVersions={v1,v1beta1}: memcached-operator/api/v1alpha1/memcached_webhook.go):

Run the command:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role webhook paths="./..."

For further information and tips see the comment.

Would be possible to mark this project as deprecated to make it clear to its users and provide this info in the README?
@asmigala could you help with that?

repo: teiid/teiid-operator


text:
per-keyboard profiles

It's not clear if it's possible to support different profiles for different keyboards.  For instance, on my Laptop I'd only like to make caps lock act as esc, but on my windows keyboard that I usually hook up I want to also swap command and option keys.  Is this possible?

I think there are a bunch of issues already open for this:

https://github.com/tekezo/Karabiner-Elements/issues/138
https://github.com/tekezo/Karabiner-Elements/issues/67
https://github.com/tekezo/Karabiner-Elements/issues/31

@Ghazgkull you're right, closing this one

authors: Ghazgkull rustyrazorblade

repo: tekezo/Karabiner-Elements

license: unlicense


text:
Question: Move to trash

Hello.
Is it any way to use Delete key for "Move to trash" action in Finder?

Please use new setting by this private.xml:
https://github.com/tekezo/Files/blob/master/Karabiner/private.finder_delete_to_move_to_trash/private.xml
How to use private.xml:
https://pqrs.org/osx/karabiner/document.html#privatexml

It's doesn't work. But Cmd+Delete doesn't work too. And I don't know why :(

Does you mention the forward delete key as "Delete key"?
What result of EventViewer when you pressed delete key?
https://pqrs.org/osx/karabiner/document.html.en#eventviewer

Thank you for the help and super fast answers. It was not DELETE but FORWARD_DELETE key.

Please use "Use Forward Delete key as Delete Files" in prepared settings.

Perfect. Thank you again.

repo: tekezo/Karabiner


text:
Question: volumeClaimTemplate

Is there a way to define a volumeClaimTemplate without the tekton-controller adding a suffix to the name? like in this pipelinerun spec
workspaces:
  - name: shared-data
    volumeClaimTemplate:
      metadata:
        name: abc
        labels:
          app: abc
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 2Gi

Like this it will create a PVC with the name "abc-7w25332d129" , i would like a PVC with the name "abc"

@zppinho The name of the generated PVC is available in the workspaces.<workspaceName>.claim variable - does that help?
What is your use-case for a name without a suffix?
Today it is not possible to control the suffix. Not having the suffix would mean in most cases that subsequent runs of the pipeline run could fail unless the previous one has been cleaned up.

The use case would be to use this pvc as a permanent storage for the pipeline, each pipeline would have its own workspace that is deleted at the end of the run and a workspace that some tasks could use to store "whatever" in it permanently

If I understand correctly, you'd like to have two kind workspaces:

one ephemeral, which is deleted at the end of the run
one permanent, where tasks can store files that should last beyond the single pipeline

For the former, you can use volumeClaimTemplate.
For the latter, you need to pre-provision a volume (before pipeline run execution). You can then bind that volume to any pipeline run execution, the ownership won't be set on the volume, so it won't be cleaned up.

Yes im doing this, also quick question is there way i can define a volumeClaimTemplate to be deleted at the end of the pipelinerun without needing to delete the run , right now I'm using a finally task that deletes it.

It's not possible today, the PVC is only deleted when the owner PipelineRuns is deleted

authors: afrittoli zppinho

repo: tektoncd/pipeline


text:
The default TaskRun timeout is too short.

Expected Behavior
A user shouldn't have their TaskRuns killed in 10 minutes if they haven't specified a larger PipelineRun timeout.
Actual Behavior
The TaskRuns do get killed.
Steps to Reproduce the Problem

Kinda obvious, really. =)

Additional Info
We should bump this up to something more reasonable. Also relates to #978.

@abayer I feel there is two things we could do :

Bump the timeout to something more reasonable (as a default), like 25min or sthg
Make it possible to configure the default Pipeline timeout on the controller side

@vdemeester The latter would be fantastic.

/assign @houshengbo

@vdemeester @bobcatfish @abayer
First, I'd like to increase the internal default timeout to 60 mins. Is that OK so far?
Then, since the timeout is not limited to taskrun only, I am thinking of creating a new YAML of a new ConfigMap under config dir, e.g. config-default.yaml for the configuration of a configurable timeout key called: defaultTimeoutMinutes.
If defaultTimeoutMinutes is not set, we fall back to the system internal timeout 60 mins. If it is set, we will use defaultTimeoutMinutes as the default timeout across all the tekton resources, if timeout is needed, but not specified.
How does it sound??

Sounds reasonable to me!

Makes sense!

OK, I will implement as described.

authors: abayer bobcatfish houshengbo vdemeester


text:
Add default for condition

The default for condition is not doing anything. This
will add to apply defaults for param in condition
Add test
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[ ] Includes docs (if user facing)
[x] Commit messages follow commit message best practices

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Add default for condition

/test pull-tekton-pipeline-integration-tests

@vdemeester Added test for the scenario.

/test tekton-pipeline-unit-tests

/lgtm
/cc @jerop

authors: dibyom piyush-garg


text:
Fix link to "why arent pipelineresources in beta"

Changes
These are the criteria that every PR should meet, please check them off as you
review them:

[n/a] Includes tests (if functionality changed/added)
[x] Includes docs (if user facing)
[n/a] Commit messages follow commit message best practices
[x] Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

/kind documentation

/lgtm
the following link is broken as well 🤪
To ease migration away from `PipelineResources`
[some types have an equivalent `Task` in the Catalog](#pipelineresource-equivalent-catalog-tasks).

authors: bobcatfish pritidesai


text:
default service account

Changes
Pipelinerun can specify service account name in the specification. If its not specified, controller reads default-service-account from config-defaults ConfigMap. And if config-defaults is also missing default-service-account, service account is set to default. Before this PR, this default value was set in creds-init.go just before creating the Pod. So the pod is created with default service account but pipelinerun/taskrun spec is not made aware of this change. Instead of delaying this decision/set until a pod is created, this PR is setting the service account as part of pipelinerun/taskrun spec. This brings consistency from the controller perspective while choosing the default service account when not explicitly specified in ConfigMap.
To summarize, controller reads service account from config-defaults ConfigMap and sets it in the pipelinerun/taskrun spec if spec is missing service account. And now (with this PR) if service account is also missing from config-defaults, controller sets the service account to default in the spec.
This was discovered while working on issue #2815 and PR #3160.
/kind bug
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[x] Includes tests (if functionality changed/added)
[x] Includes docs (if user facing)
[x] Commit messages follow commit message best practices
[x] Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
Service account when missing from pipelinerun/taskrun spec and ConfigMap, controller sets it to default in the spec.

/retest

/approve

/test

/retest

/test pull-tekton-pipeline-unit-tests

/retest

/retest

/retest

/lgtm cancel

(temporarly removing them from the merge queue to unlock some)

/test check-pr-has-kind-label

/restest

/lgtm

/lgtm cancel
@pritidesai can you rebase and push to unblock this ? I can't force-unblock it as it jobs for this do not appear anywhere anymore (see here)

/test all

/test pull-tekton-pipeline-build-tests

/lgtm

/test pull-tekton-pipeline-integration-tests

:tada:

authors: afrittoli bobcatfish pritidesai vdemeester


text:
🛑 Site web de Tela Botanica is down

In 9bf1842, Site web de Tela Botanica (https://www.tela-botanica.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Site web de Tela Botanica is back up in a4249b8.

repo: telabotanica/status


text:
DougeCoin Verified and Not Verified at the same time

Describe the bug
This contract appears to be verified but is not showing the code. Instead, it says it is not verified.
To Reproduce
Steps to reproduce the behavior:

Go to https://www.teloscan.io/token/0xc6BC7A8dfA0f57Fe7746Ac434c01cD39679b372c?tab=contract
See error

Expected behavior
It must be consistent
Screenshots

It does not seem to be properly verified in Sourcify and according to @poplexity, it is the only known case, so I am going to close it.

repo: telosnetwork/teloscan


text:
Allowing more granular control of spot instances in environments

Having spot instances for cache and database systems go down in staging has previously been a pain. Developers need production like data in their staging database, having these systems go down means that when they spin up new staging boxes they have to reimport data from production. This halts release flow and costs teams time. We can save all this time by instead having 2 boxes in the staging environment not on spot instances.
I tested this out using a test project in development, staging, and production. The test project had two boxes; application, database.
Dev = both spot.
Staging = database not spot, app spot.
Prod = both non spot.
Please let me know what you think.

In staging:
+use_spot_instances_for_roles:

aggregator

applicationapi

applicationq

build

logs

metrics

preview

can spots be the default in staging for everything and just override in a specific project?

@pkandathil why regular instance for applications in staging?

You could just override always_use_spot_instance_for_roles with an array that does not contain the database inside the project playbooks.

@kkwoker nah, that wouldn't do anything. the array doesn't contain database in the first place.

Echoing my comments from Slack into this thread, for context:
It's concerning to see flags introduced to support flawed processes, rather than putting the emphasis on fixing the process itself. Cost is a small part of the role Spot Instances play in the infrastructure. A significant aspect is how it drives recovery strategy and application development. The looming threat of "this will be wiped out at some point, with little to no warning" offers (among other benefits):

Enforces the need for applications to degrade gracefully.
Promotes repeatable deployment process.
Reduces the viability of undocumented environment changes.
Ensures that all relevant state is reflected in the playbooks.
Keeps people honest, by breaking things in non-production environments when these things are not done.

These things in turn reduce the maintenance burden of these systems through a consistent recovery process. This allows a small team to support many projects, and knowledge of support practice from any project to transfer to any other project, expanding the pool of people who can support things.
If redeployment of a DB is painful, I'd recommend putting in the time there to make it easier to deploy.
Pet systems should be kept to a minimum. All systems can and will fail. Build around that, and focus on improving recovery, not avoiding failure.
Every pain point in redeploying staging is a pain point in recovering production in the event of a failure.

I think we should automate bringing spot instances back up on a fallback instance type whenever a spot instance goes down

Good idea Kinan! So only have spot instances, if you can immediately bring them back when they go down.

Although, i'm working on clustering mongodb, it may solve your immediate problem

That does solve the DB problem but not the part where an app server goes down while I am doing a testing for a prod release. Our prod releases on commerce are time sensitive and sometimes we get very little notice to make changes before we have to live. We cannot schedule this in advance.

I see

@kkwoker That still doesn't address the root issue, which is that deploying the application in question is cumbersome. Automation helps, but you need a good process in place already.
Taking the "fall back to non-spot" approach introduces additional complexity, in that you now need to assess when it is viable to redeploy on spots. That will require something to track current pricing across instance types and AZs, and to orchestrate the reprovisioning. If you had that in place, you instead use it to deploy to an alternate spot instance type, or a different availability zone.
Alternatively, there may be some merit to revisiting offline development environments with Vagrant. The networking issues that initially rendered that problematic have largely been solved, through fixes in Virtualbox and improvements to proxy detection scripts and such.
@pkandathil Reprovisioning an instance as either spot or on-demand has negligible impact on time, so improving the deployment process is really your best option to preserve momentum in that rare case.

@pkandathil we discussed as a team a little more in depth and kind of decided that a global scale for this kind of change is solving a non-issue really, since most teams don't have too much issue with servers going down in staging. I can disable spot instances for the staging environment for a project that you're having issues with. Are you okay with this decision?

I agree with that. We can have my project as an exception. That is perfect.
On Dec 2, 2015 11:31 AM, "Ben Visser" notifications@github.com wrote:

@pkandathil https://github.com/pkandathil we discussed as a team a
little more in depth and kind of decided that a global scale for this kind
of change is solving a non-issue really, since most teams don't have too
much issue with servers going down in staging. I can disable spot instances
for the staging environment for a project that you're having issues with.
Are you okay with this decision?
—
Reply to this email directly or view it on GitHub
https://github.com/telusdigital/ansible-aws-infrastructure/pull/39#issuecomment-161407784
.

Awesome. Ill close this issue now.

Thank you.
On Dec 2, 2015 11:34 AM, "Ben Visser" notifications@github.com wrote:

Awesome. Ill close this issue now.
—
Reply to this email directly or view it on GitHub
https://github.com/telusdigital/ansible-aws-infrastructure/pull/39#issuecomment-161408683
.

authors: colstrom kkwoker noqcks pkandathil stevenharradine

repo: telusdigital/ansible-aws-infrastructure


text:
Update 20230825155903_add_shared_preload_libraries_table.sql

Added credcheck to list.

@EvanHStanton for this change, you can either create a new migration file or add the record directly to the database. I can show you how to do either of those.

Closed as this list can be updated via Tembo Cloud.

authors: EvanHStanton ianstanton

repo: tembo-io/trunk

license: PostgreSQL


text:
Adds phone number validator.

@brendt - This adds a fairly hefty dependency, but I believe it might be worth it to support phone number validation natively.
Related to #3.

Nice!

authors: aidan-casey brendt

repo: tempestphp/tempest-framework


text:
🛑 Secret Site2 is down

In 0e4e5d4, Secret Site2 ($SECRET_SITE_2) was down:

HTTP code: 404
Response time: 109 ms

Resolved: Secret Site2 is back up in fc8efbe.

repo: templain/mywatcher


text:
standalone template retriever

we had the need to provide a standalone CLI utility scripts for template download.
this basic script wraps the python module and provide a CLI interface
maybee it will be usefull for templateflow users
regards
Eric

Hi @EricDeveaud, do you have the bandwidth to take this over the finish line?

hello,
unfortunatly currently not.
sorry for the delay
Eric

Closing in favor of #123.

authors: EricDeveaud oesteban

repo: templateflow/python-client