text:
fixed issue #6 and #8

This fixes  #6 by saving the active and focused workspaces prior to renaming them, then re-activates and re-focuses them using the new names assigned to them. Also combines all i3 commands into a single string so that order of activation is preserved, otherwise the wrong workspace may be focused at the end of the rename function. Thanks again for the awesome script @cboddy - it's fantastic for me now that #6 is fixed. I'll be happy to continue assist in maintaining in the future.

fixed issue number 8 in the second commit by using the leaf name in the event that the leaf does not have a class.

This fixes #6 by saving the active and focused workspaces prior to renaming them, then re-activates and re-focuses them using the new names assigned to them. Also combines all i3 commands into a single string so that order of activation is preserved, otherwise the wrong workspace may be focused at the end of the rename function. Thanks again for the awesome script @cboddy - it's fantastic for me now that #6 is fixed. I'll be happy to continue assist in maintaining in the future.

@kensand thanks for taking the time to do this, your help is most welcome!

sorry, missed one change in that last commit, will fix in just a sec

I believe I changed everything you requested. Sorry for some silly mistakes, and thanks for going through my code. Let me know if there's anything else you'd like changed!

It looks like i3 messages are limited to a max length of 2^32 bytes or ~4 gigs according to section 2 of https://i3wm.org/docs/ipc.html so I don't think command message length will be a concern.

Thanks for checking that @kensand .
I've been testing (running i3 with) this version for the past few days without issue so I think it's good to go, thanks!

authors: cboddy kensand


text:
SteamVR "The Lab" Slingshot button?

Anyone gotten the "Slingshot" game in SteamVR's "The Lab" to work?
For some reason, I can't grab the slingshot.
I can with my Leap Motion controller when I use that, but not with the PS Move. Everything else works and I can "Grip" things in other games... just not the slingshot for some reason. Is it mapped to a different button?

I hadn't tried the Slingshot game myself. You might have to grab using the "grip" button which is mapped to "square" button on the psmove controller.
Here are the default button mappings for SteamVR:
From https://github.com/cboulay/PSMoveService/wiki/Steam-VR-Setup:
   "psmove" : {
      "ps" : "system",
      "move" : "touchpad",
      "trigger" : "trigger",
      "triangle" : "application_menu",
      "square" : "grip",
      "circle" : "a",
      "cross" : "button_8",
      "select" : "button_9",
      "start" : "button_10"
   }

You can change the button mappings in steamvr.vrsettings if you want to assign "grip" to something else.

"grip" itself doesn't appear to work in The Lab.
It does seem to function in the SteamVR interface, although it can be hard to tell as there's nothing specifically to "grip"... it does go "up a level", which is what Leap Motion appears to do as well.
In The Lab, the "grip" function appears to be nonfunctional with PS Move.
"grip" in Leap Motion does work in The Lab.
Both of these are true not only in the Slingshot game, but in the Lab in general. I can pick up objects on the desk with the Leap, but not with the PS Move "grip"... I can with "trigger". "trigger" however does not function as a "grip" in the Slingshot game.
With the Leap, when I'm close to the Slingshot device, the Leap controller glows yellow indicating that I can grip. With the PS Move, it does not.
I can successfully remap buttons on PS Move but it doesn't fix the problem unfortunately.
It's a strange disparity.

I can 'grab' the hanging control thing to the right of the sling shot however I cannot do anything with it once I have it - I imagine it wants to use the tactile pad as a quandrant'ed button.
My config below.
"psmove" : {
"circle" : "a",
"cross" : "button_8",
"move" : "touchpad",
"ps" : "system",
"select" : "button_9",
"square" : "grip",
"start" : "button_10",
"triangle" : "application_menu",
"trigger" : "trigger"
},

For me it works only the first time with the trigger. Other items in the room seem to work well too. However for some reason the slingshot stops interacting with my PSMove controller after the first shot.
The Lab also crashes pretty frequently on me, specially on the Longbow stage. Seems it has something to do with PSMoveService, but I don't know why. I'm going to build from the latest source which has some bugfixes and try again.

Closing old support issues. If this is still a problem please post a request to the google group:
https://groups.google.com/forum/#!forum/psmoveservice

source: gharchive/issue

authors: HipsterSloth ReallyDiskun cheddle jimrooney

repo: cboulay/PSMoveService

license_type: permissive

license_source: bigquery


text:
CLEyeMulticam.dll is missing even with the cl cam software installed on my computer

Hi, I'm currently trying to get the psmoveservice.exe (of the release) to run on my computer but whenever I do, it show me this error even with the cl cam software installed on my computer :  CLEyeMulticam.dll is missing on your computer..
edit: fixed by manually downloading the dll and paste it into the psmoveservice folder.

@HipsterSloth I guess this needs to be added to the release. Do you have a script for making releases or was it done manually? I made a Python script for creating releases for a different project. See here. Do you think the structure of our release has settled down enough that it's worth making a script to automate it?

@nalf3in I am having the same issue with missing the CLEyeMulticam.dll, could you please link to where you where able to download it?

Here's the official link (from this github)  : https://github.com/cboulay/PSMoveService/raw/master/thirdparty/CLEYE/x86/bin/CLEyeMulticam.dll
I got the advice from reddit : here's the link if you are interested: https://www.reddit.com/r/virtualreality/comments/4no4mz/update_on_using_the_ps_move_on_pc_for_virtual/

Are you SirJoe? Please create another issue in GitHub for your camera problem. It's almost definitely a driver issue, but I'll say more in the new issue.

@cboulay I updated the cmake install action to copy the CLEyeDriver to the /win32/bin folder. For the moment by process for building a release is to build from source, build the INSTALL project, and zip up all the binaries, scripts and data in the /win32/bin folder. I think it's a good time to make a proper release script. That python script you have looks it'd be perfect to adapt. In the mean time I'm going to post a release later to day that includes the CLEyeMulticam.dll.

Please close this issue as soon as you make a new release.

Fixed in Alpha release 2

authors: HipsterSloth StagZealot cboulay nalf3in


text:
Update scala-library to 2.13.10

Updates org.scala-lang:scala-library from 2.13.1 to 2.13.10.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (2.13.1).
You might want to review and update them manually.
.travis.yml
build.sbt

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala-library" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.scala-lang", artifactId = "scala-library" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Superseded by #340.

source: gharchive/pull-request

repo: ccadllc/cedi-dtrace


text:
Use YJS as CRDT

Tasks

[ ] Sync $svelteStore to calculator.getExpressions()
[ ] Add alternative data types for annotations, names, etc.

This probably isn't going to happen, unless I find another way to track changes in the Desmos graph.
For example, I could look at the Desmos graph source code (mathquill)

Edit as of June 23: figured out how to use Yjs

Fixes #1

repo: ccaven/multiplayer-desmos

license_source: github-api


text:
Create 0000-01-02-cchocou.md

primer archivo

Hecho

repo: cchocou/github-slideshow

license: MIT


text:
🛑 MRSpec Portal is down

In 368c3fd, MRSpec Portal (https://mrspec.ccm.sickkids.ca) was down:

HTTP code: 500
Response time: 122 ms

Resolved: MRSpec Portal is back up in 6148295 after 12 minutes.

repo: ccmbioinfo/status


text:
Change United_States-U.S._Virgin_Islands -> United_States-US_Virgin_Islands

The Virgin Islands in the US_Places.csv file uses United_States-US_Virgin_Islands instead of United_States-U.S._Virgin_Islands (no periods).  This causes joins to fail.  Also, these rows had the Virgin Islands listed as a state instead of a territory (trivial, but thought I'd change it for consistency with the rest).

Thanks for catching this. This month's validation will start soon.

repo: cdcepi/zika


text:
手动推送后一直没反应

以前，即使推送失败，也会在“投递日志”页面有显示。
但是今天手动推送尝试了一晚上了，投递日志页面没有任何信息。
也没有推送成功。
需要怎么排错？

@miaowm5 跪求方法
比如怎么看日志，怎么重启

进入 GAE 后台
另外 GAE 每日有限制，你可能用完了每天的服务器配额，建议24小时之后重新再试试

@miaowm5 怎么进入呀。。。。。

你KE首页最下方就有进入的网址啊……

repo: cdhigh/KindleEar


text:
chore(deps): upgrade compiler dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-compiler-dependencies-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 3012

Questions ?
Please refer to the Backport tool documentation


text:
chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-k8s-30-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 4894

Questions ?
Please refer to the Backport tool documentation


text:
Component type files fixed up

Component types files are still a work in progress. This contains no changes to anything other than the types/components dir. So, should not interfere with anything. This was mainly to properly import non-native types. It's important to note that if https://github.com/cdmoro/bootstrap-vue-3/pull/407 is not merged, that some of the type exports from the fixed index file of types/index.ts will not exist.

Just a note. Can we use import type ... in Vue files? There should be no reason why not as it will be solved by vue-tsc. I've just noticed that it's never included in any Vue files, while being included in declaration files.

import type can be used and should be used, certain ts configurations will complain if you import a declaration without specifying import type... good catch.
Looks good

import type can be used and should be used, certain ts configurations will complain if you import a declaration without specifying import type... good catch.
Looks good

In reference to the other PR, while going around replacing to src/types in the (probably next PR), I'll also make sure any Vue files importing types uses import type

Hmm, there are conflicts now. I'm not sure which is the proper syntax to solve them (main / setup). Would you please have a look?

Hmm, there are conflicts now. I'm not sure which is the proper syntax to solve them (main / setup). Would you please have a look?

My bad. Fixed.

In the latest, and possibly final additions to the component types files, I have added the last two additions, b-row and b-col. Inside these components, they use a function "getBreakpointProps". This is going to be an odd case as those props are defined during runtime through the function. This shouldn't be an issue, as the new type interfaces in src/types/BreakpointProps . However, it makes the function not useful, and, as the function was to reduce some typing, instead, we must declare each property individually. (As I don't know of any way we could implement this type of dynamic behavior in pure TS interface). Subsequently, as rowColsProps (and the equivalent in b-col) are now types, that makes the getClasses function also invalid. At this time, I don't have any ideas on how to make these utility functions work again. The components should be functional if one hardcodes in the values, These two cases are the only components that behave like this. Finally, could someone could review the src/types/BreakpointProps.d.ts file to make certain that those are the correct values that come from the getBreakpointProps function, I have only reviewed their behavior in code and cannot be 100% certain.

I have only reviewed their behavior in code and would like an extra pair of eyes to be certain.

Looks good to me at a glance. Thanks!

authors: aceofwings kwiksilver3441 mariusa


text:
[Question] How can i setup fail2ban?

code-server version: Docker Latest
OS Version: Ubuntu 18.04.3 LTS

Description

I want setup Fail2Ban With Docker
Fail2Ban, nginx reverse proxy is located host.
code-server only running docker.

We're going to add rate limiting to code-server. See #1320

repo: cdr/code-server


text:
Extension storage

Where is the extensions stored in the containerised code-server?

The default should be /home/coder/.local/share/code-server/extensions.

authors: AbhishekTaparia code-asher


text:
Task Kill Extension Request

[ ] Extension name: Task Kill
[ ] Extension GitHub or homepage: https://github.com/shy2net/vscode-taskkill

Thank you for your request! The extension is now live in the code-server extension marketplace.


text:
Missing "encore" in log in codes page FR

Discrepancy on https://staging.covid-hcportal.cdssandbox.xyz/fr/backup-codes
Not the same as Figma screens: https://www.figma.com/file/znPqLTQQDcUkaNjdDcShiz/Exposure-Notification-Health-Portal?node-id=7627%3A52695
...qui n'ont pas **encore** été utilisés...

closing - low priority and copy works fine as it is. Figma updated to reflect this.

authors: EliseKa anikbrazeau

repo: cds-snc/covid-alert-portal


text:
Enable COVID-19 Exposure prompt displayed in EN when in FR (iOS)

iPhone XR and iPhone 8
Newly download.
Selected FR as language and went through the onboarding screens - clicked done.
From where are you located - I clicked Skip
prompted with the Enable COVID-19 Exposure Logging and notification pop up Text displayed is EN.
Expected result: should be in FR.

Will need to confirm once this PR is merged
https://github.com/cds-snc/covid-shield-mobile/pull/311

We should reconsider our experience because the language impacts can potentially by confusing. @katewilhelm and @EliseKa can we have a conversation about this? We cannot change the language of the OS prompt and the pathway can introduce multiple language screens connected.

this is the OS language setting.

authors: JuliannaR mmiron-HC timarney

repo: cds-snc/covid-shield-mobile


text:
Ensure header component is up to date in figma

To Do:

[x] Ensure header subcomponents fit into the new grid system (internal assets)
[x] Make sure the mobile variants for the header subcomponents are up to date and fit in the new grid system. (internal assets)
[x] Publish the changes so they can be accessed in the main file (internal assets).
[x] Make sure the mobile variant for the main header is pulling in the new changes.
[x] Make sure this components aligns properly with Footer component on large and small screens after changes.

Header + Footer Branch for review
https://www.figma.com/file/mh2maMG2NBtk41k1O1UGHV/branch/UunlAOOFqYCYbwG4G0ALcA/Canadian-Digital-Service
---GC-Design-System?type=design&node-id=2043-5684&mode=design&t=n5723dHCNqcRmRVa-0

subcomponent work
https://www.figma.com/file/7HNtNYzWNmcxjYtG8UlnBz/Internal-assets?type=design&node-id=301-5230&mode=design&t=0BBb2vxCOLIj0Bm3-0

authors: adorayi nmakuch

repo: cds-snc/design-gc-conception


text:
Matching URL paths to page titles

Issue/opportunity
Currently page URL and title don't always match up. Something to consider for future is aligning the language in all of these to be consistent.
Screenshot

What would be preferred thinking
- /signup/create-account
- /auth/sign-in
- /auth/sigh-out

or move everything under an account directory
- /account/create
- /account/sign-in
- /account/sigh-out

There's other urls for register and account created, policy and resetpassword.
Thinking this should be moved out to another release given the current target release already has a large surface area.

^ Thanks for the input, @timarney . Since it's not a showstopper/something that heavily impacts usability, I'll prioritize it in the PB for another release.

authors: Abi-Nada anikbrazeau timarney

repo: cds-snc/platform-forms-client


text:
Create documentation for support staff on Deactivating accounts

Anik will lead the creation of the documentation.
Work with Stevie-Ray, Sarah, Ramya, and Jimmy to define and document the manual steps needed to deactivate an account.
Acceptance criteria:

[x] Request to remove a form or deactivate an account

[x] Who will we allow to tell us to take a form down? - The supervisor or manager of the form holder (the secondary contact they provided, or someone who has replaced the supervisor or manager) (Runbook)
[x] Inform the product team that a request to deactivate an account has come in. (Runbook)
[x] If an outside team from the account holder requests for the account to be deactivated or a form to be taken down, we will inform the account holder of the name of the person/team and ask them to get in contact. We won't provide their account information. (Canned response)

[x] Breach of terms incident (Runbook)

[x] How do we reach out to other people in their organization to initiate a transfer? (Order of contact: Account holder, named out of office, secondary contact, ATIP team)
[x] Incident commander and operations lead responsibilities
[x] Support team responsibilities
[x] Documentation on how to transfer a form to one of the people above

[x] Breach of terms unresolved incident (Runbook)

[x] Contact the departmental ATIP team for instructions on who to deliver the responses to or delete them.
[x] Product manager responsibilities
[x] Support team responsibilities
[x] How to handle responses to confirm them
[x] How to deliver encrypted responses
[x] Canned email to client with responses and terminating service.
[x] How to deactivate an account on the interface

Reference material:

Journey in FigJam
Flows in Figma
Escalation path in Docs
Responses Content in Docs
Whiteboard sketches in Miro
Knowledge Base in Freshdesk

Update:
English documentation drafted: https://docs.google.com/document/d/1mrtlVYWJLWmQXimHSPlBD-ATj0NVN0xHXrULh_cfh0o/edit
Next steps:
Gathering feedback
Testing in the context of a tabletop exercise
Iterating to make it clearer and more complete.

Setting up meeting with Jimmy et al. to go over initial process and gather feedback.

Update
Met with Abi, Carolyn, Jimmy, Sarah and Stevie-Ray to go over the process
Next steps
Clarify document and resolve comments where possible
Ensure alignment and consistency with escalation path and policy guidance

Updating based on Tabletop exercise #2299

authors: anikbrazeau connorscarolyns


text:
release: Alpine API image and dependency updates

Summary
Releases the Alpine API Docker image and past week's dependency updates.
Related

Closes #370

Closes #460

repo: cds-snc/scan-files


text:
Safari pinned iOS App links to Home / Permission denied

Visiting my Babybuddy with safari on iOS and pinning it to the Homescreen of my iPhone works. Taping on that nice babybudy icon on my Homescreen leads me to a page with a breadcrumb: Home / Permissions Denied. Switching back to Safari im still loged in. In menu there is a AnnonymousUser loged in that if i press logout leads to a switch over to Safari where i land on the login page.
Did someome ever noticed that?

I did. I'm going to try to investigate and fix this now.

authors: HorizonXP novski

repo: cdubz/babybuddy


text:
执行自动签到时出错 RangeError: Invalid key length

Node.js版本：16.14.2，Windows Server 2019 Dataserver，初次导入配置文件
执行自动签到时出现如下错误
RangeError: Invalid key length
    at Cipheriv.createCipherBase (node:internal/crypto/cipher:116:19)
    at Cipheriv.createCipherWithIV (node:internal/crypto/cipher:135:3)
    at new Cipheriv (node:internal/crypto/cipher:243:3)
    at Object.createCipheriv (node:crypto:138:10)
    at AES.encrypt (file:///C:/Users/Administrator/AppData/Roaming/npm/node_modules/cea/node_modules/@ceajs/core/lib/src/utils/encrypt.js:13:31)
    at login (file:///C:/Users/Administrator/AppData/Roaming/npm/node_modules/cea/node_modules/@ceajs/core/lib/src/crawler/login.js:73:47)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async loginAndStoreCookie (file:///C:/Users/Administrator/AppData/Roaming/npm/node_modules/cea/node_modules/@ceajs/core/lib/src/index.js:22:20)
    at async handleLogin (file:///C:/Users/Administrator/AppData/Roaming/npm/node_modules/cea/node_modules/@ceajs/core/lib/src/index.js:41:17)
    at async file:///C:/Users/Administrator/AppData/Roaming/npm/node_modules/cea/node_modules/@ceajs/core/lib/src/index.js:14:13 {
  code: 'ERR_CRYPTO_INVALID_KEYLEN'
}

腾讯云函数在导入执行时也出现类似的错误(Node版本12.16)

看起来是登录时的适配问题，没有获取到正确的 pwdSalt，导致加密不了密码
请试试 #20 的方法 @junpaku

报错信息这边其实可以优化的，所以我 Reopen 一下

!TODO: 对 saltKey 长度做精确判断，再抛出合理的错误提示

https://github.com/ceajs/cea/issues/50#issue-1213220653

authors: beetcb junpaku

repo: ceajs/cea


text:
biorxiv.org

https://www.biorxiv.org/search/abstract_title%3Aautism abstract_title_flags%3Amatch-all limit_from%3A2017-11-21 limit_to%3A2017-12-21 numresults%3A100 sort%3Apublication-date direction%3Adescending format_result%3Astandard

https://www.biorxiv.org/search/abstract_title%3Aautism abstract_title_flags%3Amatch-all numresults%3A100 sort%3Apublication-date direction%3Adescending format_result%3Astandard

repo: ceberous/AutismMastadonBot


text:
🛑 tanecni-divadlo.cz is down

In 3952b18, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 28ba20b.

repo: cebreus/upptime


text:
🛑 tanecni-divadlo.cz is down

In b6c4e28, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 5dc4a98.


text:
🛑 tanecni-divadlo.cz is down

In 70f3137, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 502
Response time: 22726 ms

Resolved: tanecni-divadlo.cz is back up in 25ad05a.


text:
🛑 tanecni-divadlo.cz is down

In d9cb1bd, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 59ed85d.


text:
🛑 tanecni-divadlo.cz is down

In 1ffe1fc, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 89434ec.


text:
🛑 tanecni-divadlo.cz is down

In fceb62b, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 876ea91.


text:
🛑 tanecni-divadlo.cz is down

In 4356c58, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in bbe4e5e.


text:
🛑 CDN is down

In b26dbf7, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 522
Response time: 15745 ms

Resolved: CDN is back up in 63f4001.

repo: ceccun/status


text:
🛑 CDN is down

In 222cb98, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 522
Response time: 15441 ms

Resolved: CDN is back up in 60d1b92.


text:
🛑 CDN is down

In 37ba7bf, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 502
Response time: 486 ms

Resolved: CDN is back up in 40cd2c1.


text:
🛑 CDN is down

In f8d40c0, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 522
Response time: 15626 ms

Resolved: CDN is back up in 0a7db90.


text:
🛑 CDN is down

In 2e5a35d, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 525
Response time: 274 ms

Resolved: CDN is back up in d88a902 after 27 minutes.


text:
chore(main): release 0.40.5

:robot: I have created a release beep boop
0.40.5 (2024-10-27)
Bug Fixes

bump @babel/core from 7.25.9 to 7.26.0 (#914) (527d2b5)
bump @babel/preset-env from 7.25.9 to 7.26.0 (#913) (14c076d)
bump cedricziel/faro-shop-php from 8.4.6 to 8.4.7 (#915) (44e54f3)
bump php from 8.3.12-fpm-alpine to 8.3.13-fpm-alpine (#909) (04a15f0)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

0.40.5
:sunflower:

repo: cedricziel/faro-shop


text:
feat(validator): allow to use custom validator

PR Type
New feature
BC Break
Yes, see CHANGELOG file
Description
Allow end user to define a custom validator
Sample
PhoneFormField(
  validator: (PhoneNumber? phoneNumber) {
    if (phoneNumber == null) {
      return null;
    }
    final PhoneParser parser = PhoneParser();
    if (!parser.validate(phoneNumber, PhoneNumberType.mobile)) {
      return 'not a mobile line';
    }
    if (!parser.validate(phoneNumber)) {
      return 'invalid format';
    }
  },
);

In your example you use the PhoneParser with the phoneNumberType.
I assume that's just an example you picked to be explicit. However I'm still wondering what's the use case where you'd not want the validation to happen by this lib. I can see one:

The validation that happens in the library is faulty

Not only, in my case I want 2 différents messages depending on invalid or not expected type. I picked up this from my real project :)

I see the need. I've one question: In your current project would it make sens to use a BasePhoneFormField as it would be mostly UI, and do the validation, formatting manually ?

Another common use case is to set this field required as well as a phone number validator.
We can even to expose a validator class, so that it can used as follow:
PhoneFormField(
  // message argument is optional
  validator: PhoneValidator.compose([
    PhoneValidator.required(context, message: "This field is required"),
    PhoneValidator.invalid(context, message: "Invalid phone number"),
    PhoneValidator.type(context, PhoneNumberType.mobile, message: "Not a mobile phone number"),
  ]),
)

This way, end user may use multiple validators depending on the use case and define a specific message for each type if wanted. Inspired by flutter_form_builder validation

I've done the changes PARTIALLY :

PhoneValidator is created with defaults error messages, no localization texts added for now.
I don't change the phoneNumberType usage for now.

This may be confusing to have phoneNumberType, errorText message, and validator, I can see 2 ways of handling this :

perform an assertion on PhoneFormField constructor to check that phoneNumberType and validator cannot be defined simultaneously, and then internally :

when neither phoneNumberType nor validator are supplied : create the invalid validator (using errorText if supplied)
when phoneNumberType is supplied : create the type validator (using errorText if supplied)
in all case : remove the default errorText value and let property be nullable as this is now handle by the validator itself

remove the phoneNumberType & errorText and let user defines it own navigator if needed, otherwise add a default invalid validator

In both case above, I suppose it makes sense to always add an invalid validator when user does not explicitly set a validator.
In rare case where the user don't want this default validator, it can be disable by adding a fake validator : (PhoneNumber? p) => null
IMHO I think that solution 2 is more reliable : less conditions to test, less tests to write, less complexity, so less code and less bugs. (Keep in mind, that solution 2 is however a BC break change)
Any ideas, recommandations before I perform these latests changes ?

In your last message, are you using the word navigator incorrectly or is it on purpose ?
For example here

remove the phoneNumberType & errorText and let user defines it own navigator if needed, otherwise add a default invalid validator

A Validator interface could do the work and the user can give a new one (deprecation of old fields). I like the idea of a class, because it would allow for compose method like in your example.

It's an error, should be validator ;)

I'm not against breaking changes as this library is kind of young it's better to do those changes now, with deprecation when possible is the way to go.

My initial use case was to have 2 distincts message for invalid & type not allowed.
But with your remark, I think you're right, and exposing an invalid validator, with an optional type may be sufficient, just a bit less explicit.
Moreover, my original use case is still available like this:
  validator: PhoneValidator.compose([
    PhoneValidator.invalid(context, errorText: "Invalid phone number"),
    PhoneValidator.invalid(context, type: PhoneNumberType.mobile, errorText: "Not a mobile phone number"),
    // ...
  ]),

Is this what you had in mind ?

I want to deprecate the phoneNumberType property to completely remove if in a future release. Or alternatively we could completely remove it now but that introduce a breaking change without warning.

I will update this way. Good practices are good practices, whatever amount of users ;)

What about the errorText property, do you think it makes sense to remove it in a future release too (and thus, deprecate it too) ? My opinion is yes, looking forward to hear yours ;)
Do you want me to write a migration guide ?

But with your remark, I think you're right, and exposing an invalid validator, with an optional type may be sufficient, just a bit less explicit.

May be you tell me what you think of my proposition above when you had time to ?

Sorry for multiple questions in one, as I will be offline in a moment for the next few hours and will try to finish this tonight, this might be helpful for me to have your opinion when I will get back so I can make the changes in the expected way ;)

What about the errorText property, do you think it makes sense to remove it in a future release too (and thus, deprecate it too) ?

Yes, it is now the responsibility of the validator.

Do you want me to write a migration guide ?

In my opinion if the validation is explained in the documentation and the changelog is explicit, then a migration guide is not needed.

But with your remark, I think you're right, and exposing an invalid validator, with an optional type may be sufficient, just a bit less explicit.

Well I'm not sure and I was not sure when writing it either. I hoped the discussion would bring us toward a decision. If we consider the use cases people generally have I'd say they generally want any phone number or a mobile phone only.
In that case PhoneValidator.invalid(PhoneNumberType.mobile, 'Invalid mobile phone number'); might provide a better API.
Or even:  PhoneValidator.invalidMobile & PhoneValidator.invalidFixedLine & PhoneValidator.invalid, which better handles error messages by default.

Wouldn't this work ?
Validators.compose([
  Validators.required(),
  Validators.invalid('Incorrect format'),
  Validators.invalidMobile('This number is not a valid cellphone number'),
])

Or even:
Validators.compose([
  Validators.required(),
  Validators.invalid('Incorrect format'),
  Validators.invalidType(PhoneNumberType.mobile, 'This number is not a valid cellphone number'),
])

I've refactor code according to your advices.
PhoneValidator.required(context, ...),
PhoneValidator.invalid(context, ...)
PhoneValidator.invalidType(context, expectedType, ...)

// convenience method for PhoneValidator.invalidType(context, PhoneNumberType.mobile, ...)
PhoneValidator.invalidMobile(context, ...)

// convenience method for PhoneValidator.invalidType(context, PhoneNumberType.fixedLine, ...)
PhoneValidator.invalidFixedLine(context, ...)

Can you please validate the default message in English so I can make the translations for others languages ? It's quite a repetitive tasks to translate in all supported languages, so I would like to avoid doing it twice as possible ;)
Note that I will use Deepl for this, tell me if you have a better solution/strategy ;)

I have another interrogation about deprecating errorText in BasePhoneFormField.
I did not find another solution than removing default value and make errorText nullable to ensure it will still work on both previous and new manner of handling validator.
However this seems like a breaking change as a standalone BasePhoneFormField ...

without errorText supplied
and a custom validator not properly written (ie: not returning the String that user want to be displayed)

...may not flag a field as invalid if the validator is not properly defined.
But as it seems to be like a bug on previous version (ie: the validator returned value was ignored due to the usage of errorText property), I think this an acceptable BC. Curious to hear what's your opinion about that ;)

Sorry for some reason I did not see your last message:
For your other PR I made a change to the translation files which are now .arb files and need to be generated with the command -flutter gen-l10n . The property keys must be valid dart property names though. So please either rebase on the localization_arb_fix branch or use already valid names so it will be easy for me to make the merge.
Therefor the properties should look like this:
  "phoneNumberRequired": "Phone number required",
  "phoneNumberInvalid": "Phone number invalid",
  "invalidCountry": "Invalid country", // although I'm not sure where that is displayed ?
  "invalidMobilePhoneNumber": "Invalid mobile phone number",
  "invalidFixedLinePhoneNumber": "Invalid fixed line phone number",

For the error text issue, tbh I did not understand exactly what you were saying. Does the field not become invalid when the errorText is not provided by the user ? If the field is marked as invalid when it is invalid I don't see an issue with a BC especially if it's a bug.

Sorry for the delay, this was a busy week.

For the localization strings keys, I will update this. Be aware that it can introduce breaking change for english application as the PhoneFormLocalization was optional to get corrects invalid message. Updating this will make it required otherwise the camelCase string will be used instead ;)

For the errorText,  if the errorText is not provided, it still flag the field as invalid with the previous default errorText as expected. The problem is only with the usage of BasePhoneFormField when supplying validator property. Previously, the validator output was not used because the getErrorText method was returning the widget errorText property and not the errorText state info. I maintain this weird behavior (seems more like a bug imho) to avoid breaking change. This may however create kind of a breaking change if validator was defined manually and not used properly.

Here's an example of a previous code that will be affected:
BasePhoneFormField(
  validator: (...) {
    if (/* check for invalid */) {
      return 'fake message not expected to be used as widget.errorText '
        'was displayed (validator output was ignored)';
    }
  }
  //errorText not defined
)

With the above example :

previously: the default previous constructor argument errorText was returned (ie: Invalid phone number)
now: it will return the fake message above as I have removed the default errorText value and change it to a nullable String

Hmmm, due to the recently introduced localization changes (from localization_arb_fix branch), this PR is already breaking backward compatibility.
Thus, I don't see the interest anymore in deprecating errorText & phoneNumberType, only cons (more complex, more error prone). What's your opinion about this ?

Yeah just go ahead and remove the unnecessary code, let's keep things simple

I don't think translations keys are problematics as they are not reals words anymore. At least in deepl, they aren't translated.
FYI,  at work, according to our team mates who are native from others countries, we use deepl because they find it more efficient and it produces less word by word translations than google translations.

Ouch, I don't think the add-favorites feature should be included here. I've rebased on localization_arb_fix and it seems that this branche includes WIP code. I've squash my commits after rebasing so it looks like only my last commit and yours addressing l10n issues should be included here.
Take a look and tell me if you want me to rebase/squash for a proper git history and/or separated features branches.
I've also updated CHANGELOG & README, don't hesitate to reword for better comprehension/english ;)

Ho damn, yeah I might have started from your other branch for that fix to see if it fixed your issue.
As you might have seen I'm not a git history maniac. However since this project is growing in size of contributors it will become increasingly important to have a standard clean git strategy.
So for future PR I'll adhere to the standard of squashing for pull request and not mixing things up.
Concerning this one, the git history here just has too many files to do a clean review. If you already rebased, fixed the comments and the test pass I'm okay with either (merging this as is or merge before your rebase).
What I propose though, is merging the other merge request first. The one with validation (I merged it on a separate branch in order to create the flutter issue) but it eventually needs to be merged in dev. That flutter issue has been reproduced by the flutter team btw.

I can merge my last changes done yesterday about favorites countries in this one (I've added few tests), resolve conflicts with current dev branch and ensure that all tests are passing so you have only this PR to accept.
Is this ok for you ?
I hope I can do this in the evening/night or tomorrow at most :)

Yes that would be perfect. Then a new major version could be released beginning of next week. I've a breaking change I need to introduce as well and now is a good time.

My idea is to have favorites countries feature and custom validator feature in this PR. I will perform rebase or cherry pick (I don't really know currently what will be the easiest/secured way) to have a forward history related to current dev branch.

Not sure if it will help but I've refactored the inputs in a branch called refactor_controllers_form_field. If you hit a problem it might be fixed there as it seems it fixed multiple issues.

I haven't work yesterday evening due to lack of sleep. Seing your message, I think this was a good idea, as I would probably had squash the localization_arb_fix to perform a rebase without having to resolve conflicts on each of your commit.
As your new fix branch start from localization_arb_fix, squashing is not an option anymore.
Although it will give me more work, this may be a better strategy to start working from your last development. In this way, if you are confident with latests fixes introduced in your fresh refactor branch, it may be a good idea to merge your code into dev branch, and I will manage to update my code from this new starting point.
However those last changes will produce a lot of friction with my current development. I don't know how it can be addressed easily. I won't surprised if it forces me to refactor lots of the new features code.

Oh, you don't have to rebase on my latest fixes dude, my plan was to wait for your PR, I just did some prepary work to see if my refactor idea could work.
I was just letting you know that there is a new branch  where the code is a bit easier to understand. I'll do the merge after don't worry. Of course if you want to rebase anyway you are welcome to do it but that's certainly not a requirement

I just notice that the BasePhoneFormField is not a FormField anymore in your last refactored branch. I'm not sure of the consequences of this change, but I'm very worried about this and usage of this widget inside a form, as well for submitting data and retrieving it, data validation, autovalidation features, and all the handling previously done by form field.
The validation I've add seems almost useless, at least obsolete with this way of handling data. Either the package/widget name are pretty confusing too. Sure you wan't to refactor this in the upcoming next version ? (I think this needs more tests in a Form context to ensure that the package will still be usable)

Before PhoneFormField was a StatefulWidget and base was FormField now it's the opposite. Making them both FormField is an option though.
No the refactor does not have to be in the upcoming version.

I miss the fact that it has been swapped between PhoneFormField and BasePhoneFormField.
Thanks for this clarification ;)

Is that okay if I merge this on a lateral branch to apply the fixes on it myself or have you started ?

I don't understand the produced diff, a lots of files are fully modified but contents is the same. Did you change formatting ? spaces/tabs ?

I have merged the changes from this branch onto my other branch. There is just 2 files with errors regarding validation.
I ve done it on that branch validation_favs, does that help ?

When I switch onto validations_favs I've got 16 errors on my side

there should be 5 now

Got 6 ;) but I'm still on flutter 2.2.3 because my work app cannot be upgraded until all dependencies have been updated.
Currently upgrading to 2.5.1 for this project only...

What dart sdk version are you on ?

[✓] Flutter (Channel stable, 2.2.3, on macOS 11.3 20E232 darwin-x64, locale fr-FR)
    • Flutter version 2.2.3 at /Users/emri/fvm/versions/2.2.3
    • Framework revision f4abaa0735 (3 months ago), 2021-07-01 12:46:11 -0700
    • Engine revision 241c87ad80
    • Dart version 2.13.4

I notice that you have removed usage of the light parser in the validator class, but not the arguments useLightParser is this present. just a missed point or volontary ? ;)
Noticed too, that I forgot to remove a comment I made to validate a test (phone_validator.dart:61-62) ;)

That is a missed point. light parser is not used anymore. Actually in the way it was included it never was.

https://gitter.im/cedvdb/phone_form_field I've created a gitter for discussion


text:
fxi(nodebuilder/swamp): ignore leveldb panic in swamp tests

LevelDB may panic after test is over. This happens due to leveldb being closed before node client is closed. This is temporary fix to make swamp tests more stable until swamp tests shutdown order is fixed.

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

Project coverage is 46.50%. Comparing base (2469e7a) to head (84f3ed5).
Report is 311 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3774      +/-   ##
==========================================
+ Coverage   44.83%   46.50%   +1.67%
==========================================
  Files         265      314      +49
  Lines       14620    17989    +3369
==========================================
+ Hits         6555     8366    +1811
- Misses       7313     8601    +1288
- Partials      752     1022     +270

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

Not needed

authors: codecov-commenter walldiss

repo: celestiaorg/celestia-node


text:
Which service does the extension use to validate?

Is it official https://validator.w3.org/ or?

Hi @Cmeem, you can learn more about w3c here
They do provide this validator for free and it directly derive from the standards they have defined.

authors: Cmeem celian-rib


text:
Add fluent API for #async

Does this make sense? The first thing I tried while learning #async was to chain calls, but it didn't work because of the nil return value. See examples/stack.rb. (Are my comments there correct?)

Merging and patching example with slight/safe API behavioral tweak.

authors: digitalextremist vjoel

repo: celluloid/celluloid

license: mit


text:
End-to-end mobile test should only run if mobile-related code has changed

Expected Behavior
End-to-end mobile test doesn't run on PRs that do not touch it
Current Behavior
End-to-end mobile tests run on every PR

Work for this has been done.

Work for this has been done.

authors: asaj jeanregisser

repo: celo-org/celo-monorepo


text:
Add view call to compute currency pair identifier

Description
The PR adds a view call in SortedOracles which can be used by other contracts that need to consume on-chain rates for arbitrary currency pairs. Essentially a contract can do:
address celoBtc = sortedOracles.getCurrencyPairIdentifier("CELO/BTC");
(uint256 medianRate, uint256 numRates) = sortedOracles.medianRate(celoBtc);

With getCurrencyPairIdentifier being a pure function:
function getCurrencyPairIdentifier(string calldata currencyPair) external view returns (address) {
  return address(bytes20(keccak256(abi.encodePacked(currencyPair))));
}

There is one problem with this. As we are transitioning away from using an actual token address to reference rates in favour of these identifiers mapped 1:1 to human readable pairs like CELO/BTC, we are still left with the CELO/USD pair which uses the StableToken cUSD.address as the identifier.
One way of approaching this would be to treat this edge-case in getCurrencyPairIdentifier on chain so that consumings contracts would be able to do:
address celoUsd = sortedOracles.getCurrencyPairIdentifier("CELO/USD");

And get back cUSD.address which that's the case and then get back identifier("CELO/USD") when we make the switch. The problem with this approach is that we would need to link SortedOracles to the Registry or introduce an extra state variable which holds the cUSD.address. The former would add too much bloat while the latter would feel hacky even if temporary.
If we leave things as is, contracts that consume rates from SortedOracles will need to treat CELO/USD differently on their own by passing in cUSD.address instead of computing the identifier. When/If we move away from reporting to the token address they would need to upgrade, or we could keep reporting to both cUSD.address and identifier("CELO/BTC") but that would be a waste of gas.
Tested
Added specs for new view function
Related issues

Fixes #6485

Backwards compatibility
New functionality fully backwards compatible.

@bowd What do you think is the path forward? Intuitively, a unified API for consumers seems important

@bowd What do you think is the path forward? Intuitively, a unified API for consumers seems important

@bowd What do you think is the path forward? Intuitively, a unified API for consumers seems important

Yeah I'm leaning towards that myself but I wanted to see if there are other ideas on how to achieve that, because like I mentioned, including the Registry in the SortedOracles contract seams to bloated, or at least from my understanding it's bloated, would we have to include the UsingRegistry contract or can we just make calls to the registry which afaik is 0xce10? Or maybe hardcoding the cUSD.address isn't as bad as it sounds my head as a temporary means to bridge the gap until we move reporting to identifier(CELO/USD).
What are your thoughts on the options?

@bowd What do you think is the path forward? Intuitively, a unified API for consumers seems important

Yeah I'm leaning towards that myself but I wanted to see if there are other ideas on how to achieve that, because like I mentioned, including the Registry in the SortedOracles contract seams to bloated, or at least from my understanding it's bloated, would we have to include the UsingRegistry contract or can we just make calls to the registry which afaik is 0xce10? Or maybe hardcoding the cUSD.address isn't as bad as it sounds my head as a temporary means to bridge the gap until we move reporting to identifier(CELO/USD).
What are your thoughts on the options?

Hmm, not sure I understand how the Registry falls into place here. I first understood the unified API to be a special case in the getCurrencyPairIdentifier function that calls back to cUSD.address for CELO/USD?

Hmm, not sure I understand how the Registry falls into place here. I first understood the unified API to be a special case in the getCurrencyPairIdentifier function that calls back to cUSD.address for CELO/USD?

Yeah that's basically it getCurrencyPairIdentifier would need to return the address of cUSD instead of actually computing an identifier. My question is from where to get that address and I cam up with:

Expose the contract to the registry so that I can do registry.getAddressForOrDie(STABLE_TOKEN_REGISTRY_ID)
Add a storage variable inside of SortedOracles and as part of the next upgrade write the address for cUSD inside of that storage variable

Is there another cleaner way to have access to the cUSD address inside of getCurrencyPairIdentifier?

Yeah that's basically it getCurrencyPairIdentifier would need to return the address of cUSD instead of actually computing an identifier. My question is from where to get that address and I cam up with:

Expose the contract to the registry so that I can do registry.getAddressForOrDie(STABLE_TOKEN_REGISTRY_ID)
Add a storage variable inside of SortedOracles and as part of the next upgrade write the address for cUSD inside of that storage variable

Is there another cleaner way to have access to the cUSD address inside of getCurrencyPairIdentifier?

@bowd Ahh I see now. Hmm yeah that is a good question. Could you just abstract it away completely? I.e. have both identifiers apply?

@bowd Ahh I see now. Hmm yeah that is a good question. Could you just abstract it away completely? I.e. have both identifiers apply?

@bowd Ahh I see now. Hmm yeah that is a good question. Could you just abstract it away completely? I.e. have both identifiers apply?

Yeah I added that as an option as well but it would mean sending reports from the oracle to both cUSD.address and identifier("CELO/USD") and that would be a bit wasteful gas wise. Or it just moves the problem of transforming identifier("CELO/USD") to cUSD.address when reading rates, and then it's the same problem of knowing the cUSD address there.

@bowd Ahh I see now. Hmm yeah that is a good question. Could you just abstract it away completely? I.e. have both identifiers apply?

Yeah I added that as an option as well but it would mean sending reports from the oracle to both cUSD.address and identifier("CELO/USD") and that would be a bit wasteful gas wise. Or it just moves the problem of transforming identifier("CELO/USD") to cUSD.address when reading rates, and then it's the same problem of knowing the cUSD address there.

I assume by  it's the same problem of knowing the cUSD address there., you mean in the reading function? That doesn't sound that bad to me?

I assume by  it's the same problem of knowing the cUSD address there., you mean in the reading function? That doesn't sound that bad to me?

So let me take a step back cose I think I got a bit lost.
We have a contract where our oracles we can report prices for <base>/<quote> pair.
We have a pure function that can transform <base>/<quote> to an identifier encoded as an address.
We've been reporting CELO/USD rate to the address of our cUSD stable token - which is misleading in itself (cUSD vs USD) + implies that we need a token address for the quote currency.
We want consumers to be able read rates both off-chain (through contractkit) and on-chain (from other contracts).
Off-chain was solved by exposing some union types and providing a enum-like collection of report targets, where one can do:
const celoBtcRate = await sortedOracles.getMedianRate(OracleCurrencyPair.CELOBTC)
const celoUsdRate = await sortedOracles.getMedianrate(OracleCurrencyPair.CELOUSD)

Which hides the complexity of the CELOUSD edge case in the implementation and if/when we move away from reporting to cUSD.address the change in contractkit will not affect consumers (as long as they updated).
On-chain we're trying to solve it in this PR and in order to hide that complexity as well we need to decide if it makes sense to encoding this logic in the SortedOracles contract - which would provide the best API but adds a really specific bit of logic to an otherwise general purpose contract. Or move that complexity to the consumer which would need to be aware that from this point onwards we're reporting rates to identifier("<base>/<quote>"), EXCEPT for CELO/USD where we report to cUSD.address which means that contracts which consume this prices on-chain need to know and treat this logic.
If we move it to the consumer we keep the contract clean, but the API inconsistent.

After thinking about it I see a 3rd option that's a bit cleaner but would require adding some more state to the contract. Basically we could have an identifier override that works like this:
mapping(address => address) identifierOverride;

function setIdentifierOverride(string calldata currencyPair, address override) external onlyOwner {
  identifierOverride[buildCurrencyPairIdentifier(currencyPair)] = override;
}

function getCurrencyPairIdentifier(string calldata currencyPair) external view returns (address) {
  address identifier = buildCurrencyPairIdentifier(currencyPair);
  if (identifierOverride[identifier] != address(0)) {
    retrun identifierOverride[identifier]
  }
  return identifier
}

function buildCurrencyPairIdentifier(string calldata currencyPair) internal pure returns (address) {
    return address(bytes20(keccak256(abi.encodePacked(currencyPair))));
}

And we would include a sortedOracles.setIdentifierOverride("CELO/USD", cUSD.address) in the upgrade.
That way it's backwards and forwards compatible one can consume using getCurrencyPairIdentifier("CELO/USD") and when we stop reporting we can remove the indirect.
This also adds logic to the contract but in a more general way.

So let me take a step back cose I think I got a bit lost.
We have a contract where our oracles we can report prices for <base>/<quote> pair.
We have a pure function that can transform <base>/<quote> to an identifier encoded as an address.
We've been reporting CELO/USD rate to the address of our cUSD stable token - which is misleading in itself (cUSD vs USD) + implies that we need a token address for the quote currency.
We want consumers to be able read rates both off-chain (through contractkit) and on-chain (from other contracts).
Off-chain was solved by exposing some union types and providing a enum-like collection of report targets, where one can do:
const celoBtcRate = await sortedOracles.getMedianRate(OracleCurrencyPair.CELOBTC)
const celoUsdRate = await sortedOracles.getMedianrate(OracleCurrencyPair.CELOUSD)

Which hides the complexity of the CELOUSD edge case in the implementation and if/when we move away from reporting to cUSD.address the change in contractkit will not affect consumers (as long as they updated).
On-chain we're trying to solve it in this PR and in order to hide that complexity as well we need to decide if it makes sense to encoding this logic in the SortedOracles contract - which would provide the best API but adds a really specific bit of logic to an otherwise general purpose contract. Or move that complexity to the consumer which would need to be aware that from this point onwards we're reporting rates to identifier("<base>/<quote>"), EXCEPT for CELO/USD where we report to cUSD.address which means that contracts which consume this prices on-chain need to know and treat this logic.
If we move it to the consumer we keep the contract clean, but the API inconsistent.

After thinking about it I see a 3rd option that's a bit cleaner but would require adding some more state to the contract. Basically we could have an identifier override that works like this:
mapping(address => address) identifierOverride;

function setIdentifierOverride(string calldata currencyPair, address override) external onlyOwner {
  identifierOverride[buildCurrencyPairIdentifier(currencyPair)] = override;
}

function getCurrencyPairIdentifier(string calldata currencyPair) external view returns (address) {
  address identifier = buildCurrencyPairIdentifier(currencyPair);
  if (identifierOverride[identifier] != address(0)) {
    retrun identifierOverride[identifier]
  }
  return identifier
}

function buildCurrencyPairIdentifier(string calldata currencyPair) internal pure returns (address) {
    return address(bytes20(keccak256(abi.encodePacked(currencyPair))));
}

And we would include a sortedOracles.setIdentifierOverride("CELO/USD", cUSD.address) in the upgrade.
That way it's backwards and forwards compatible one can consume using getCurrencyPairIdentifier("CELO/USD") and when we stop reporting we can remove the indirect.
This also adds logic to the contract but in a more general way.

My 2c: IMHO the identifierOverride approach suggested by @bowd feels the cleanest from all angles (consumers of the contract, flexibility for governance and migrating celo/usd later on and long term code quality). Unless there are any concerns with the additional storage I personally would feel better with a few extra lines of code to abstract the identifier logic vs having to hardcode CELO/USD or cUSD.address somewhere in the contract (even if we decided to never migrate CELO/USD for compatibility reasons I'd personally rather have this documentation live off-chain).
Sorry for us pushing these changes very close to the audit cutoff deadline but would love thoughts/concerns (if any) from @asaj @m-chrzan @nategraf

My 2c: IMHO the identifierOverride approach suggested by @bowd feels the cleanest from all angles (consumers of the contract, flexibility for governance and migrating celo/usd later on and long term code quality). Unless there are any concerns with the additional storage I personally would feel better with a few extra lines of code to abstract the identifier logic vs having to hardcode CELO/USD or cUSD.address somewhere in the contract (even if we decided to never migrate CELO/USD for compatibility reasons I'd personally rather have this documentation live off-chain).
Sorry for us pushing these changes very close to the audit cutoff deadline but would love thoughts/concerns (if any) from @asaj @m-chrzan @nategraf

I've added some changes to reflect the overrideIdentifier options which feels best from a API consumer perspective.
It allows us to expose a way of consuming the oracles that our existing users can adopt and which will work for both existing and future logic. And then when we start reporting to the correct identifier we can drop the logic at the expense of sacrificing a storage variable.
And just to reiterate shortly our other options are

Expose a function that's pure which means that calling it with "CELO/USD" will yield the wrong identifier until we change the way we report. So would ask the community to treat the edge case, and we would make it harder to switch because we would need to coordinate with the community and keep reporting to both for a while.
Don't expose anything at all and shift the responsibility of deriving identifiers for currency pairs to the consumers entirely. Which again will make coordinating changes harder.

I've added some changes to reflect the overrideIdentifier options which feels best from a API consumer perspective.
It allows us to expose a way of consuming the oracles that our existing users can adopt and which will work for both existing and future logic. And then when we start reporting to the correct identifier we can drop the logic at the expense of sacrificing a storage variable.
And just to reiterate shortly our other options are

Expose a function that's pure which means that calling it with "CELO/USD" will yield the wrong identifier until we change the way we report. So would ask the community to treat the edge case, and we would make it harder to switch because we would need to coordinate with the community and keep reporting to both for a while.
Don't expose anything at all and shift the responsibility of deriving identifiers for currency pairs to the consumers entirely. Which again will make coordinating changes harder.

authors: bowd nambrot nvtaveras


text:
Fix future message example

Just a quick fix :^)

Great thanks 👍

authors: celrenheit ergl

repo: celrenheit/sandglass


text:
Limit the number of annotations we buffer in SpanData

To avoid leaking memory on long-running spans, we should make sure SpanData has a fixed size regardless of how many annotations have been added. We should add a count of dropped annotations. This should apply to any of the variable sized fields in SpanData (message events, links, etc.).

fixed by #1020 and  #1022

authors: ramonza rghetia

repo: census-instrumentation/opencensus-go


text:
ActionView::Template::Error

Здравствуйте, воткнулся вот в такую проблему
Rendered projects/settings.html.erb within layouts/base (289.0ms)
Completed 500 Internal Server Error in 310ms (ActiveRecord: 28.0ms)
ActionView::Template::Error (undefined method render_intouch_tabs' for #<#<Class:0x0000080c294320>:0x00000813af81e0>):     10:       }     11:     end %>     12:     13:     <%= render_intouch_tabs settings_source, issue_update_tabs %>     14:     15:
     16:   plugins/redmine_intouch/app/views/projects/settings/intouch/common/_settings.html.erb:13:in _plugins_redmine_intouch_app_views_projects_settings_intouch_common__settings_html_erb___37282162228286723_17277706860'
plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb:29:in block in _plugins_redmine_intouch_app_views_projects_settings_intouch__settings_html_erb___273180490908919840_17278191640'   plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb:8:in _plugins_redmine_intouch_app_views_projects_settings_intouch__settings_html_erb___273180490908919840_17278191640'
Environment:
Redmine version                3.3.2.stable
Ruby version                   2.3.3-p222 (2016-11-21) [amd64-freebsd10]
Rails version                  4.2.7.1
Environment                    production
Database adapter               Mysql2
Redmine plugins:
redmine_intouch                0.4.0
redmine_sidekiq                2.1.0
redmine_telegram_common        0.0.14
Пожалуйста, помогите победить?

Здравствуйте.
Вы запускали plugins migrations?

Конечно, инструкцию установки полностью выполнил

Проблема появляется когда я активирую плагин на проекте.
В настройках у самого модуля все нормально работает.

Какая версия ruby используется?

Environment:
Redmine version 3.3.2.stable
Ruby version 2.3.3-p222 (2016-11-21) [amd64-freebsd10]
Rails version 4.2.7.1
Environment production
Database adapter Mysql2
Redmine plugins:
redmine_intouch 0.4.0
redmine_sidekiq 2.1.0
redmine_telegram_common 0.0.14

поставил более новый
redmine_telegram_common        0.0.15

Результат тотже  :(

Нашел временный выход.
Сконфигурировал в настройках плагина шаблон.
потом удалил злополучную строчку
<%= render_intouch_tabs settings_source, issue_update_tabs %>
Вошел в проект и установил ему работу по шаблону.
Вроде все работает.
Но редактировать или создать новый шаблон в таком виде уже не получится.
Поэтому придется возвращать строчку каждый раз, как захочу изменить шаблон.
Вот такой костыль кривой.
Посмотрите пожалуйста почему же может не работать в нормальном виде.

Не сильно спасает, видимо все же надо делать настройки и в проекте, а то индивидуальные сообщения приходят только автору при создании задачи

Проверим и исправим в течение нескольких дней.

Пытаюсь воспроизвести ошибку.

evgarik, опишите подробнее последовательность действий, которая приводит к ошибки. У меня пока не получается ее повторить.

Установил все что необходимо для плагина.
Потом установил сам плагин.
Делаю первичные настройки на странице настройки плагина.
Захожу в настройки проекта.
Подключаю плагин к проекту и и после нажатия на кнопку сохранить, получаю вылет с 500 ошибкой.
Дамп лога на момент ошибки смотрите выше.

@evgarik добрый день!
Попробуйте обновиться из ветки https://github.com/centosadmin/redmine_intouch/tree/render_intouch_tabs_fix
и напишите об итогах

evgarik, получилось решить проблему с помощью этого патча?

Rendered projects/settings.html.erb within layouts/base (53.4ms)
Completed 500 Internal Server Error in 70ms (ActiveRecord: 3.9ms)
ActionView::Template::Error (super: no superclass method project_settings_tabs' for #<#<Class:0x000008160db150>:0x000008162b2ac8>):     1:
<%=l(:label_settings)%>
     2:     3: <%= render_tabs project_settings_tabs %>     4:     5: <% html_title(l(:label_settings)) -%>   plugins/redmine_intouch/lib/intouch/patches/projects_helper_patch.rb:8:in project_settings_tabs'
plugins/redmine_finance/lib/redmine_finance/patches/projects_helper_patch.rb:38:in project_settings_tabs_with_finance'   app/views/projects/settings.html.erb:3:in _app_views_projects_settings_html_erb___2213089126761750582_17343601340'
lib/redmine/sudo_mode.rb:63:in `sudo_mode'

На версии редмайна 3.3.2 удалось повторить ошибку. Исправляю.

Спасибо, очень жду :)

Оу, попробуй redmine_intouch из мастера (не из ветки), а redmine_telegram_common обнови до 0.0.15 - у меня работает.

Processing by ProjectsController#settings as HTML
Parameters: {"id"=>"shoppinggo"}
Current user: Evgarik (id=5)
Rendered projects/_form.html.erb (32.1ms)
Rendered projects/_edit.html.erb (33.6ms)
Rendered projects/settings/_modules.html.erb (11.2ms)
Rendered projects/settings/_members.html.erb (46.4ms)
Rendered plugins/scrum/app/views/projects/settings/_sprints.html.erb (23.8ms)
Rendered projects/settings/_versions.html.erb (11.5ms)
Rendered projects/settings/_issue_categories.html.erb (9.5ms)
Rendered projects/settings/_wiki.html.erb (1.7ms)
Rendered projects/settings/_repositories.html.erb (5.2ms)
Rendered projects/settings/_activities.html.erb (9.4ms)
Rendered plugins/redmine_contacts/app/views/projects/_contacts_settings.html.erb (0.9ms)
Rendered plugins/redmine_intouch/app/views/projects/settings/intouch/common/_settings.html.erb (197.4ms)
Rendered plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb (203.4ms)
Rendered common/_tabs.html.erb (368.6ms)
Rendered projects/settings.html.erb within layouts/base (369.8ms)
Completed 500 Internal Server Error in 396ms (ActiveRecord: 26.7ms)
ActionView::Template::Error (undefined method render_intouch_tabs' for #<#<Class:0x00000815631da8>:0x00000810eada40>):     10:       }     11:     end %>     12:     13:     <%= render_intouch_tabs settings_source, issue_update_tabs %>     14:     15:
     16:   plugins/redmine_intouch/app/views/projects/settings/intouch/common/_settings.html.erb:13:in _plugins_redmine_intouch_app_views_projects_settings_intouch_common__settings_html_erb___2038785820792198554_17362665060'
plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb:29:in block in _plugins_redmine_intouch_app_views_projects_settings_intouch__settings_html_erb__4416107734852471135_17366921860'   plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb:8:in _plugins_redmine_intouch_app_views_projects_settings_intouch__settings_html_erb__4416107734852471135_17366921860'
app/views/common/_tabs.html.erb:17:in block in _app_views_common__tabs_html_erb__1700105805221212334_17281306180'   app/views/common/_tabs.html.erb:16:in each'
app/views/common/_tabs.html.erb:16:in _app_views_common__tabs_html_erb__1700105805221212334_17281306180'   app/helpers/application_helper.rb:325:in render_tabs'
app/views/projects/settings.html.erb:3:in _app_views_projects_settings_html_erb___3915343507054817422_17281388120'   lib/redmine/sudo_mode.rb:63:in sudo_mode'
Вот Инфо о системе и плагины котоыре стоят
Environment:
Redmine version                3.3.2.stable
Ruby version                   2.3.3-p222 (2016-11-21) [amd64-freebsd10]
Rails version                  4.2.7.1
Environment                    production
Database adapter               Mysql2
SCM:
Git                            2.7.4
Filesystem
Redmine plugins:
mega_calendar                  1.4.0
redmine_agile                  1.4.2
redmine_checklists             3.1.5
redmine_contacts               4.0.5
redmine_contacts_invoices      4.1.3
redmine_finance                2.1.1
redmine_intouch                0.4.0
redmine_sidekiq                2.1.0
redmine_telegram_common        0.0.15
scrum                          0.16.2

Добрый день @evgarik
Удалось воспроизвести подобную ошибку, код исправляющий её находится в ветке
https://github.com/centosadmin/redmine_intouch/tree/project-helper-fix
Проверьте как у вас он заработает :)

rocessing by ProjectsController#settings as HTML
Parameters: {"id"=>"shoppinggo"}
Current user: Evgarik (id=5)
Rendered projects/_form.html.erb (19.8ms)
Rendered projects/_edit.html.erb (20.9ms)
Rendered projects/settings/_modules.html.erb (5.4ms)
Rendered projects/settings/_members.html.erb (26.4ms)
Rendered plugins/scrum/app/views/projects/settings/_sprints.html.erb (52.0ms)
Rendered projects/settings/_versions.html.erb (19.7ms)
Rendered projects/settings/_issue_categories.html.erb (9.4ms)
Rendered projects/settings/_wiki.html.erb (1.5ms)
Rendered projects/settings/_repositories.html.erb (5.1ms)
Rendered projects/settings/_activities.html.erb (9.3ms)
Rendered plugins/redmine_contacts/app/views/projects/_contacts_settings.html.erb (1.0ms)
Rendered plugins/redmine_intouch/app/views/projects/settings/intouch/common/_settings.html.erb (127.4ms)
Rendered plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb (132.5ms)
Rendered common/_tabs.html.erb (289.9ms)
Rendered projects/settings.html.erb within layouts/base (290.5ms)
Completed 500 Internal Server Error in 308ms (ActiveRecord: 62.2ms)
ActionView::Template::Error (undefined method render_intouch_tabs' for #<#<Class:0x0000080c6a9820>:0x000008154c55a0>):     10:       }     11:     end %>     12:     13:     <%= render_intouch_tabs settings_source, issue_update_tabs %>     14:     15:
     16:   plugins/redmine_intouch/app/views/projects/settings/intouch/common/_settings.html.erb:13:in _plugins_redmine_intouch_app_views_projects_settings_intouch_common__settings_html_erb__2433141071006856177_17376005200'
plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb:29:in block in _plugins_redmine_intouch_app_views_projects_settings_intouch__settings_html_erb___2775105646420139691_17376698600'   plugins/redmine_intouch/app/views/projects/settings/intouch/_settings.html.erb:8:in _plugins_redmine_intouch_app_views_projects_settings_intouch__settings_html_erb___2775105646420139691_17376698600'
app/views/common/_tabs.html.erb:17:in block in _app_views_common__tabs_html_erb___4521000350432769661_17345217880'   app/views/common/_tabs.html.erb:16:in each'
app/views/common/_tabs.html.erb:16:in _app_views_common__tabs_html_erb___4521000350432769661_17345217880'   app/helpers/application_helper.rb:325:in render_tabs'
app/views/projects/settings.html.erb:3:in _app_views_projects_settings_html_erb___4333300657272221092_17284202200'   lib/redmine/sudo_mode.rb:63:in sudo_mode'

Всё то же самое. Вы плагин из ветки project-helper-fix установили?

1.Удалил старый плагин.
2.Перезапустил редмайн.
3.Поставил плагин
git clone -b project-helper-fix https://github.com/centosadmin/redmine_intouch.git plugins/redmine_intouch
4.Перезапустил редмайн
5.Снял логи tail -f log/production.log

Попробуйте ещё раз из той же ветки обновиться.

без изменений

@evgarik Новый релиз в той же ветке.
Теперь точно должно заработать :) Проверьте пожалуйста.
Если всё ок - оформим релиз.

Работает!
Интересный вариант решения :)

authors: arturtr evgarik ipcross olemskoi


text:
osds: allow passing devices by path

ceph-volume didn't work when the devices where passed by path.
Since it now support it, let's allow this feature in ceph-ansible
Closes: #3812
Signed-off-by: Guillaume Abrioux gabrioux@redhat.com

jenkins test dev-centos-non_container-lvm_osds

jenkins test dev-centos-container-lvm_osds

jenkins test dev-centos-non_container-lvm_batch

jenkins test dev-centos-container-lvm_batch

jenkins test dev-centos-non_container-lvm_batch

jenkins test dev-centos-container-lvm_batch

repo: ceph/ceph-ansible


text:
Remove unmaintained kubernetes versions from testing

Kubernetes maintains the latest minor version, and the two before it. That means with the release of Kubernetes 1.18, version 1.17 and 1.16 are still maintained. Deployments should not use unmaintained versions, so there is no need to test on older versions either.
See supported versions in the k8s documentation.

@nixpanic are you working on the PR ?

authors: humblec nixpanic

repo: ceph/ceph-csi


text:
rgw: add initial rgw wrappers and tests

Signed-off-by: Yang Honggang yanghonggang@kuaishou.com

Checklist

[ ] Added tests for features and functional changes
[ ] Public functions and types are documented
[ ] Standard formatting is applied to Go code

hi @yanghonggang ; so, this is a go binding to librgw?  maybe commit msg/pr could highlight that--took me a minute to see what this actually was

(sorry, wrong repo :)

(sorry, wrong repo :)

I want to add librgw go binding into go-ceph.
make check failed,  I will try to fix these errors...

Hi @yanghonggang, I'm very excited to see this! It wasn't until recently that I was even aware there was a librgw (tucked away in the rados subdir), so I'm enthused to see this come from a new contributor.
That said, I'd like to set expectations: this is a pretty large new chunk of code and we are rapidly coming up on the Christmas & New Years holidays. This is likely going to need thorough review. Many of us who maintain go-ceph do so as part of $dayjob and are taking time off from work. So between these points I caution you to expect this to take some time. Please don't let that discourage you though. I would love to see this be part of our next release as a marquee feature. Please be patient with us. :-)
Now, before we get around to formally reviewing the patches line-by-line here are a few general tips:

Get the CI jobs to pass:

Focus on "check" first, it is pretty easy and fast to run revive locally with our makefile rule (make check)
Once check is passing, work on getting the test suites to pass if the above doesn't automatically resolve the issues

Use the checklist in the PR template to help you ensure documentation and other rules are applied. While revive helps enforce much of this now, it can still help to check items off the checklist once you've double checked them.
It can make review go faster if the commits are smaller. To avoid burdening you a lot I suggest a simple rule to organize by files: one commit for the library code, one commit for the tests, one commit for the "infrastructure" (the makefile, scripts, etc) that glue the code and tests into the CI.
Please provide a PR description. It doesn't have to be long, but it should briefly describe what makes up the PR and why you want to add it. We can certainly tell a lot from the patches and commit messages, but a introduction can help all reviewers get up to speed, esp. if you provide reference links.

Somewhat coincidentally, I am aware we're lacking in a strong contributor's guide and that was a task I plan to take on in the new year. Feel free to ask questions about the process or the structure in go-ceph if anything seems unclear. Anything you ask may help us make a better guide for future contributors!
Thanks, and we'll try to get back to you soon.

Hi @yanghonggang, I'm very excited to see this! It wasn't until recently that I was even aware there was a librgw (tucked away in the rados subdir), so I'm enthused to see this come from a new contributor.
That said, I'd like to set expectations: this is a pretty large new chunk of code and we are rapidly coming up on the Christmas & New Years holidays. This is likely going to need thorough review. Many of us who maintain go-ceph do so as part of $dayjob and are taking time off from work. So between these points I caution you to expect this to take some time. Please don't let that discourage you though. I would love to see this be part of our next release as a marquee feature. Please be patient with us. :-)
Now, before we get around to formally reviewing the patches line-by-line here are a few general tips:

Get the CI jobs to pass:

Focus on "check" first, it is pretty easy and fast to run revive locally with our makefile rule (make check)
Once check is passing, work on getting the test suites to pass if the above doesn't automatically resolve the issues

Use the checklist in the PR template to help you ensure documentation and other rules are applied. While revive helps enforce much of this now, it can still help to check items off the checklist once you've double checked them.

It can make review go faster if the commits are smaller. To avoid burdening you a lot I suggest a simple rule to organize by files: one commit for the library code, one commit for the tests, one commit for the "infrastructure" (the makefile, scripts, etc) that glue the code and tests into the CI.

Please provide a PR description. It doesn't have to be long, but it should briefly describe what makes up the PR and why you want to add it. We can certainly tell a lot from the patches and commit messages, but a introduction can help all reviewers get up to speed, esp. if you provide reference links.

Somewhat coincidentally, I am aware we're lacking in a strong contributor's guide and that was a task I plan to take on in the new year. Feel free to ask questions about the process or the structure in go-ceph if anything seems unclear. Anything you ask may help us make a better guide for future contributors!
Thanks, and we'll try to get back to you soon.

OK, thank you

In case I was too wordy with my last reply and unclear: Please do resolve the CI failures starting with the "check" rule. This should be done before we start looking at the PR in depth. Thanks!

In case I was too wordy with my last reply and unclear: Please do resolve the CI failures starting with the "check" rule. This should be done before we start looking at the PR in depth. Thanks!

In case I was too wordy with my last reply and unclear: Please do resolve the CI failures starting with the "check" rule. This should be done before we start looking at the PR in depth. Thanks!
OK

In case I was too wordy with my last reply and unclear: Please do resolve the CI failures starting with the "check" rule. This should be done before we start looking at the PR in depth. Thanks!
OK

In case I was too wordy with my last reply and unclear: Please do resolve the CI failures starting with the "check" rule. This should be done before we start looking at the PR in depth. Thanks!

@phlogistonjohn
Done

In case I was too wordy with my last reply and unclear: Please do resolve the CI failures starting with the "check" rule. This should be done before we start looking at the PR in depth. Thanks!

@phlogistonjohn
Done

Hi there! I've added a few initial comments on the PR. First off, I want to say that there looks like a lot of good stuff here.
It's a big PR so I didn't comment on everything I think it needs yet, but more of the very high level items that can be improved first.
Please do ask questions or comment back on any items you think are unclear or wish do discuss further!

Thank you for the comments. I will try to fix all these problems.

Hi there! I've added a few initial comments on the PR. First off, I want to say that there looks like a lot of good stuff here.
It's a big PR so I didn't comment on everything I think it needs yet, but more of the very high level items that can be improved first.
Please do ask questions or comment back on any items you think are unclear or wish do discuss further!

Thank you for the comments. I will try to fix all these problems.

Hi @yanghonggang,
Since you haven't updated this PR in a while I was wondering if you'd object to the maintainers (mainly me and possibly a few others) taking small parts of the PR as new separate PRs? I ask because a) it would really be nice to have some basic RGW support in go ceph b) I have been asked about some rgw management apis and having rgw data apis would be good to test those, etc. c) just for the sake of completeness and I would like to see your work bear fruit.
I would want to make sure you are credited in the commits too, of course.
Any thoughts?

Hi @yanghonggang,
Since you haven't updated this PR in a while I was wondering if you'd object to the maintainers (mainly me and possibly a few others) taking small parts of the PR as new separate PRs? I ask because a) it would really be nice to have some basic RGW support in go ceph b) I have been asked about some rgw management apis and having rgw data apis would be good to test those, etc. c) just for the sake of completeness and I would like to see your work bear fruit.
I would want to make sure you are credited in the commits too, of course.
Any thoughts?

@phlogistonjohn
Sorry for the late response. I'm busy finding a new job these days :). Feel free to do this. You can do whatever to this PR.

Understood, thanks for the update. I do appreciate your efforts!
I will discuss the PR itself with the rest of the maintenance team soon.

As per the earlier discussion this PR will be closed.
Until additional requirements or advantages of wrapping the RGW C layer is found we recommend the use of S3 compatible API of RGW with an S3 compatible library in Go for accessing data using RGW.

repo: ceph/go-ceph


text:
fix for version match, 1.3.1 now maps to 0.94.3

fix for version match, 1.3.1 now maps to 0.94.3 instead of the prevoius 0.94.2
Signed-off-by: Vasu Kulkarni vasu@redhat.com

Refer to this link for build results (access rights to CI server needed):
http://jenkins.ceph.com//job/teuthology-pull-requests/1885/
Test PASSed.

authors: ceph-jenkins vasukulkarni

repo: ceph/teuthology


text:
teuthology-results: Be aware of all job statuses

We used to claim that every job that didn't pass or fail had 'hung'. That was a holdover from the pre-paddles era.
Now we can report 'dead', 'running', 'waiting', and 'queued'.
teuthology-results will now require a running paddles instance, but then again, so does scheduling jobs in the first place.

Example of output: http://paste2.org/NFkENFBY

@zmc that output looks much better! Perhaps we should format time to be H:M:S instead of just seconds? An extra line break between the jobs in the running and waiting sections would make that read easier as well, IMHO.

@andrewschoen good suggestions; updated!

authors: andrewschoen zmc


text:
Put ZFS into NixOS for Cerana

Issue Description
Assuming moving forward with NixOS ( #133), get ZFS implemented in NixOS.
Acceptance Criteria (How do we know when this is done?)
ZFS is part of NixOS implementation within Cerana.
Related Tickets
#133 (Dependency)

Additional Requirement:
For the cerana/cerana/zfs package, we rely on the https://github.com/ClusterHQ/zfs/tree/libzfs_core-HEAD fork of zfs containing a new stable ioctl API in combination with the upstream spl. From the cerana travis file:
V_ZFS=0.6.5.5
...
curl -L https://github.com/zfsonlinux/zfs/releases/download/zfs-$V_ZFS/spl-$V_ZFS.tar.gz | tar xz
git clone https://github.com/ClusterHQ/zfs -b libzfs_core-HEAD && (cd zfs && git checkout 2c9b2d6bf312d0ffb4a14c0570fcb8150196a9be)
MAKEFLAGS=-j$(($(grep -c '^processor' /proc/cpuinfo) * 2 + 1))
(cd spl-$V_ZFS && ./configure --prefix=/usr && make && sudo make install)
(cd zfs && ./autogen.sh && ./configure --prefix=/usr --with-spl=/usr/src/spl-$V_ZFS && make && sudo make install)
sudo modprobe zfs

Note that with spl 0.6.5.5, you need to specify the --with-spl flag when building the fork zfs as it expects a different versioned path.

https://github.com/nshalman/nixpkgs/tree/cerana-test4 (specifically https://github.com/nshalman/nixpkgs/commit/e7efbb53675b645cf07a79a3df9c1a89de9bbb13) shows that this can be done.

authors: TauZero nshalman pjnorton

repo: cerana/cerana


text:
20-50% performance increase

We were profiling our application last night with ruby-prof to find out where we could improve the speed of our api calls and found two things in jsonapi resources I think would be an easy fix to increase performance. On simpler api calls the performance was less noticeable, but in our more complex calls the performance was up to 50% faster. I wanted to put the ideas in here and see if you could think of any issues with these ideas, and if not we could create a pull request or you could if you had a better idea in mind how to facilitate these changes.
At a low level, mosts of the costs were surrounding ActiveSupport::Inflector for string names manipulation and finding class objects from strings.
The first easier fix would be to cache two methods that were called frequently and made up 25% of the performance issues in our bigger api call. I monkey patched it to test it, but these changes could be configured better to take into account cache_classes in the config and use rails cache. Only caching if we are looking for performance in staging / production.
class Resource

    class << self

      alias_method :resource_for_old, :resource_for

      def resource_for(type)
        @resources ||= {}
        @resources[type] ||= resource_for_old(type)
      end

    end
  end

  class Formatter

    class << self

      alias_method :formatter_for_old, :formatter_for

      def formatter_for(format)
        @formatters ||= {}
        @formatters[format] ||= formatter_for_old(format)
      end

    end
  end

The second fix was around link generation. To test that it was faster I monkey patched these four link builder methods and returned nil.
relationships_self_link, relationships_related_link, query_link, self_link
Obviously thats not a real solution, but I wanted to test what the profiler saw. Eliminating the link generation also improved performance by 25%. Knowing that area was a performance issue, I feel that  based on the parameters, a caching mechanism could created that generates the link patterns based on the parameters and then the only thing that is changed in subsequent calls is replacing the variables for the resource ids.
For example the first time the method is called, a pattern could be generated like:
https://example.com/api/v1/post/{{id}}/comments

Then on following calls the only thing to replace would be the {{id}} field and the more expensive costs of generating that initial link text could be overcome. Not all links will work for this process, but I believe most will. I need to dig deeper into the link builder generating, but those are my initial thoughts.
Some example images from the performance changes.
Our original api call

Our api after performance optimization (same calls)

This issue could be closed. 😸

authors: aaronbhansen pcreux

repo: cerebris/jsonapi-resources


text:
Add Option for a Favicon

Issue Description
You know, a favicon! Lets get rid of this ugliness and make the site professional-like.
Issue Type

[ ] New Feature
[x] Enhancement
[ ] Bug
[ ] Other

Expected Behavior
Add an icon here:

This was

repo: cerner/terra-dev-site


text:
Allow for empty @argument, @return, and other tags

Currently the parser for docs complains about empty @argument, @return, and possible other tags where it expects some kind of body. Maybe we can allow for this without the parser complaining and simply not have a description for those that are empty

I'm adding a @return to my comments but not seeing that return being parse. The markdown generates a return block but my text isn't picked when the parsing is done.

IdeaFeatureFlagSelector
APIVERSION: 55
STATUS: ACTIVE
"Selector" Class for querying Feature Flag Custom Metadata Records.
Author IDEA Development Team
See https://andyinthecloud.com/2013/09/09/apex-enterprise-patterns-selector-layer/
Fields
sObjectFields → List<Schema.SObjectField>
The below list of fields are always returned whenever this class is instantiated

Methods
static isValidQuery(String query)
Static method that checks whether a provided query is a valid query or not
Parameters

Param
Description

query
Query to validate against

Return
Type
Boolean
Description
Boolean if whether or not provided query is valid
getSObjectType()
Returns the sObject type of this selector
Return
Type
Schema.SObjectType
Description
sObject type
getSObjectFieldList()
Returns the "default" list of fields that this selector class returns
Return
Type
List<Schema.SObjectField>
Description
List<Schema.SObjectField>List of IDEA_Feature_Flag__mdt fields
addSObjectFields(List<Schema.SObjectField> sObjectFields)
Adds additional sObject fields to query (outside of "default" set)
Parameters

Param
Description

sObjectFields
List of IDEA_Feature_Flag__mdt fields

generateQueryString()
Generates a query string from the sObject fields contained in this class
Return
Type
String
Description
Base query string
setQueryCondition(String queryString, String queryCondition)
Appends a condition to a query
Parameters

Param
Description

queryString
Base query string

queryCondition
Conditional string for a query

Return
Type
String
Description
Query string with a provided condition
selectByComponent(Set<String> componentApiNames)
Returns a list of Feature Flag records based on API names of LWCs
Parameters

Param
Description

componentApiNames
Set of API names of LWC components

Return
Type
List<IDEA_Feature_Flag__mdt>
Description
List of Feature Flag records

Classes
IDEAQueryException

Thanks @carrera328
I'll look into this

@carrera328 From your second comment I see the return information there

Is the issue that the text doesn't match what you have or that the current format is not clear?

Hey @cesarParra I see now, my mistake I misunderstood the format. Thanks for clearing this up for me.

repo: cesarParra/apexdocs


text:
🛑 echo-server.madacluster.tech is down

In 40b76cd, echo-server.madacluster.tech (https://echo-server.madacluster.tech) was down:

HTTP code: 0
Response time: 0 ms

Resolved: echo-server.madacluster.tech is back up in 1e92c00 after 9 minutes.

repo: cesarempathy/upptime


text:
Wrong skill requirement on Shades of Mort'ton quest

I have just started the Shades of Mort'ton quest and according to the plugin you only need level 5 Firemaking. However, in order to put the Redwood pyre logs on the funeral pyre, you need to have Firemaking level 95. I hope this can be updated so other people are not being mislead.

One of my friends told me that you can use a different type of wood, and that why the requirement is level 5 firemaking. I didn't know this at the time, so im closing the issue.

repo: cesoun/optimal-quest-guide


text:
Proposal: rename ion-* builds to ioncoin-*

There are several reasons for that.

Launchpad should be inline with snap builds, as we can also build snaps over launchpad, it works.
Some scripts would work better and are easier to deploy.
We use ioncoin already on snap
We want to have same naming on launchpad
Ion exists as a package and it is in higher version than our wallet, but having same naming causes issues for some users during the upgrade

Please discuss.

I'm all for this renaming, but what do we rename and what not?
Just package names I assume? I don't see the need to rename iond to ioncoind based on the argumentation above - because the other ion package has different executable names.

I don't see the need to rename iond to ioncoind based
that was not suggested, it was suggested to that packages are named with ioncoin, not ion, binaries can stay like they are.

does this mean that i need to change the launchpad ion names on my side as well to ioncoin, ioncoin-qt and ioncoin-iond and the Fedora packages to ioncoin, ioncoin-qt, ioncoin-iond and ioncoin-doc? A bit more work on the fedora packages as they are built out of the same SRPM, but doable nonetheless....let me know

we will wait with this change until the move is done to ioncoincore and we will create  IIP about this change. With that I will close this issue, reopen it please when this topic gets to priority list.

authors: FornaxA cevap ckti

repo: cevap/ion


text:
navigation to narrowed value

Given code like:
Object x = "";
if (is String x) {}

Clicking on the second occurrence x takes me nowhere. It should take me to the declaration.

Fixed.

repo: ceylon/ceylon-ide-intellij


text:
No way to iterate through ceylon.net.http.server.Request header fields.

If header fields are unknown for request, current way would be to try to ask all of them (https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Request_fields) one by one.

+1.

Using the well known header names is not a viable work-around either, as many services have their own slew of custom headers.

Another issue is naming - header and headers is confusing. For example, by asking for headers, one would expect to get them all.

To be more precise.
Currently ceylon.http.server.Request class has two methods:
shared interface Request {
    ...
    "Returns a single header with given name."
    shared formal String? header(String name);

    "Returns all headers with given name."
    shared formal String[] headers(String name);
    ...
}

So the most obvious method name for asking for a full sequence of header name/value pairs is already taken: headers
(and the same pattern can be observed with attributes like queryParameters and formParameters)

Oh, it's even worse than this; the ceylon.http.client::Response has shared List<Header> headers and shared Map<String,Header> headersByName, so it's not even consistent between server and client.

yeah ... I guess we should make it consistent.
But that is backwards incompatible change!

Okay, there are few issues brough up here that are somewhat intertwined:

API between ceylon.http.server and ceylon.http.client in inconsistent.
Neither library offers an easy way to enumerate over all header values

Ditto for parameters.

It should be an easy fix, but it will break API compatibility in a big way.
We should have probably fixed this while we moved the API from ceylon.net module to three separate modules, but that boat has sailed for now ...
What's the plan? Break API compatibility again?

According to SemVer

#triggered

Haha
On Mon, Oct 3, 2016 at 11:10 AM, Bastien Jansen notifications@github.com
wrote:

According to SemVer
[image: image]
https://cloud.githubusercontent.com/assets/281528/19032384/b12d7554-8959-11e6-8dcf-2260140ae4b5.png
#triggered
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ceylon/ceylon-sdk/issues/572#issuecomment-251059901,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZhvh58C7UYsIzWYw5k7DahFI7ERjfks5qwMZ6gaJpZM4IbEwi
.

--
Gavin King
gavin@ceylon-lang.org
http://profiles.google.com/gavin.king
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

So I am doing the side-by-side comparison of the client and server API:

authors: bjansen gavinking karlkeskyla luolong tombentley

repo: ceylon/ceylon-sdk


text:
Non-denotable types in Tuple.string

print(type([1, true]));

prints  ceylon.language::Tuple<ceylon.language::true|ceylon.language::Integer,ceylon.language::Integer,ceylon.language::Tuple<ceylon.language::true,ceylon.language::true,ceylon.language::empty>>
But those should be denotable types.

I don't understand. What's wrong with that?

Ah, I thought we didn't allow non-denotable types in Type.string, but it seems we do.

authors: gavinking tombentley

repo: ceylon/ceylon


text:
Selection of elements of certain types is broken (Vector2, Vector3)

Hey there, I can't edit certain types by clicking on them. Unity simply doesn't highlight/activate the field that was clicked on. In this case I am serializing a ReorderableArray<Vector3>. I've only been able to replicate the issue with Vector2s and Vector3s - Vector4s work fine, as do single field types such as strings or floats. Maybe this is because Vector4 elements expand? It could have something to do with the fact that the fields for the Vector3 x y z values are on the same area that can be dragged to move the element. I can tab to those fields to highlight and edit them, but that's rather cumbersome. I'm using Unity 5.5.0f3
Thanks for building this! It's speeding up my workflow quite a bit

I'll get on a fix ASAP. Thanks for Finding

This should be fixed now.

Awesome thank you!

authors: cfoulston samloeschen

repo: cfoulston/Unity-Reorderable-List


text:
Delete unused sheerlike code

Tests still pass, although I'm not sure if any JAC jobs rely on any of this code? There's probably more that can be removed but this seems like a good start.

I'm excited to see this! I do think Owning a Home still uses Queryfinder, etc, though, for instance here:
https://github.com/cfpb/owning-a-home/blob/c4c6fa2bd6859c10c97ac7c9aebbfdfc4102153a/src/process/_process-step.html#L18

Now that Owning a Home has been migrated can this be merged?
cc: @sebworks @virginiacc

@ascott1, no not yet. We still have the rate checker page.

OAH rate checker flag has been flipped in production.

RIP, Sheer. We hardly knew ye 😢

authors: Scotchester anselmbradford ascott1 richaagarwal rosskarchner sebworks

repo: cfpb/cfgov-refresh


text:
Remove enterprise attribution cookies script

This analytics script was complicated and under utilized by the analytics team and after discussing with @kelleyholden we decided to remove it. It also caused errors in MS Edge (reported in New Relic), as well as was flagged for the setting of a client-side cookie by Checkmarx (reported by @lfatty).
Removals

enterprise-attribution-cookies.js analytics cookie tracking.

@ans was this file not executed anywhere?

It's used by google tag manager, but we've removed the tag that uses it.

authors: anselmbradford jimmynotjim


text:
Remove Left Nav from Loan Options

Changes:

Remove left navigation
Added back link to Owning a Home home page
Line up content with the back link

Screenshots:
Desktop:

Medium-sized:

Mobile:

Reviews:
@stephanieosan @huetingj @cfarm @virginiacc

I'm really not a fan of having the content stretch full width, as the line lengths make the text difficult to read. But the only solution I can think of is to have a blank space on the right hand nav where the sidebar would go. That would look like this:

@stephanieosan @huetingj what do you guys think? Also discussed here:
https://github.cfpb.gov/OAH/OAH-notes/issues/996#issuecomment-47446

@sonnakim that looks good to me.

Yeah, let's do that. :+1:

How about these? @sonnakim @stephanieosan @huetingj
Desktop:

Medium-sized:

Mobile:

:+1: Looks good!

@amymok this broke the smoke tests, I forgot to mention here that you need to update the associated browser tests for this left nav now that it's gone.

looks great!

authors: amymok cfarm huetingj sonnakim stephanieosan

repo: cfpb/owning-a-home