text:
Changed pregnancy edit view tab order

Fixes #451

Thank you so much for knocking this out, @MiroFurtado ! Welcome to the project, we're glad to have you!
Looks like this is failing CI with the following errors:
ERROR["test_0001_should alter the information", #<Class:0x007fc458370338>, 10.555818611999712]
 test_0001_should alter the information#UpdatePatientInfoTest::changing patient information (10.56s)
Capybara::ElementNotFound:         Capybara::ElementNotFound: Unable to find field "Secondary person"
            test/integration/update_patient_info_test.rb:69:in `block (2 levels) in <class:UpdatePatientInfoTest>'

 FAIL["test_0004_should let you click to patient information", #<Class:0x007fc458435a20>, 16.93567547299972]
 test_0004_should let you click to patient information#ShowPregnancyInformationTest::clicking between sections to see information (16.94s)
        Expected true to not be truthy.
        test/integration/show_pregnancy_information_test.rb:49:in `block (3 levels) in <class:ShowPregnancyInformationTest>'
        test/integration/show_pregnancy_information_test.rb:48:in `block (2 levels) in <class:ShowPregnancyInformationTest>'

The first one is a legit flag issue, the second one is just our test suite assuming that things are different on page load.

For the first one, we'll need to change which section has the class active on page load from #abortion_information to #patient_information. This is pretty straightforward, just a matter of swapping it out in the respective partials in app/views/pregnancies/{PARTIAL}.

For the first one, we'll want to adjust our tests to reflect the new behavior you're implementing. Specifically, let's adjust should show abortion information on open to show patient information on open, and use capybara to click the abortion information link. Let me know if I can clarify anything about this point.

LMK if I can unstick or clarify anything. Thanks again for popping this in, really appreciate it!

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

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

@@             master       #473   diff @@
==========================================
  Files            23         23
  Lines           355        355
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            353        353
  Misses            2          2
  Partials          0          0

Powered by Codecov. Last updated by [191e157...7a396ad][cc-compare]
[cc-base-branch]: https://codecov.io/gh/colinxfleming/dcaf_case_management/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/colinxfleming/dcaf_case_management/compare/191e1573ff5e8ccd3c8ee3817c00229b406c1037...7a396ad6dd5723354feff0cc641891cb9bd0d882
[cc-pull]: https://codecov.io/gh/colinxfleming/dcaf_case_management/pull/473?src=pr

@colinxfleming Thanks! I think the change should be ready for a pull now.

Thanks a ton, @MiroFurtado ! Will I be able to meet you at the code for DC meeting this week?

@colinxfleming I don't think I have enough experience to throw myself into Code for DC yet. I hardly know ruby.

There are more than a few people on this project who aren't extremely ruby
savvy -- don't feel like you need to be some ascended rails master to hang
out and contribute. (Also, if you're interested in ruby, hanging out is a
pretty good way to start learning.)
On Wed, Jul 6, 2016 at 10:39 AM MiroFurtado notifications@github.com
wrote:

@colinxfleming https://github.com/colinxfleming I don't think I have
enough experience to throw myself into Code for DC yet. I hardly know ruby.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/colinxfleming/dcaf_case_management/pull/473#issuecomment-230792390,
or mute the thread
https://github.com/notifications/unsubscribe/ADsA9Opd1dKt8S5RtgquXYVhBRGtyBUcks5qS74OgaJpZM4JD_45
.

authors: MiroFurtado codecov-io colinxfleming


text:
support variadic parameter with hook

#994

This does exactly the opposite of what you say. The error in your issue was a method name collision.

source: gharchive/pull-request

license: mit

license_type: permissive

license_source: bigquery


text:
Sub Projects aggregation

We're trying to aggregate SimpleCov results from 4 gems that under the same project structure. The purpose is getting Jenkins Code Coverage results, but the thing is Jenkins only accepts one directory for coverage and we wanted to aggregate all 4 sub-gems into the same result.
Is this possible?
P.S.: I've been reading all the way in the web (Stackoverflow, Google, etc...) and i can't find how to do this.

possibly related https://github.com/colszowka/simplecov/issues/501#issuecomment-226802034

Hi there @driverpt !
Does the problem still persist?
FWIW over at shoes/shoes4 we aggregate the results of several gems through running all the tests and giving different invocations different command_names (e.g. spec:shoes and spec:swt) as described in the merging results section. Maybe that helps?

Closing due to no further feedback

source: gharchive/issue

authors: PragTob bf4 driverpt

repo: colszowka/simplecov


text:
[OPIK-63] [New feature] Add segment to Opik Cloud

Details
Issues
Resolves #
Testing
Documentation

Small comment for your consideration (but not to block the PR), technical users like ours generally use adblocks with the rate of 30-50%, and adblocks block the segment domain.
We could get much better success if identify and trackEvent methods send the data to our own backend, and the backend sends it to Segment.
A second aspect would be the name of the backend route – if you avoid something like /analytics or /track but rather call it something inconspicuous, you can avoid even more rules in adblocks.

Small comment for your consideration (but not to block the PR), technical users like ours generally use adblocks with the rate of 30-50%, and adblocks block the segment domain.
We could get much better success if identify and trackEvent methods send the data to our own backend, and the backend sends it to Segment.
A second aspect would be the name of the backend route – if you avoid something like /analytics or /track but rather call it something inconspicuous, you can avoid even more rules in adblocks.

Thanks for your input here. We have the same functionality right now for the main app. So we can change it together in the future

authors: andriidudar robertlacok

repo: comet-ml/opik

license_source: github-api


text:
Should we publish the presentations we're doing in the docs?

Problem: I frequently refer to this presentation by Josef, either for my own reference, or for onboarding people (eg, Ali), or in the context of crafting a tweet.
I think it would be good to convert the presentation in a PDF format and publish it in the docs repo.
Future presentations
Note that

@alijnmerchant21 will hold a workshop at Gateway (June) and potentially presentations at EthParis and HackAtom in Seoul.
I will give a presentation at Gateway

so we will be accumulating a fair amount of interesting material. For education and transparency, it would be beneficial both for our team and our users to open these resources up and make them easily accessible.

Thanks for bringing this up Adi! I resonate with you in the idea of keeping it together in one place for easy access - especially for onboarding & easy reference.
However, I have some hesitance when it comes to sharing it with the public. Here are some of my concerns:

The presentation shared at conferences change very frequently, so maintaining them would be an overhead.
We might announce things at conferences, which might be delayed more than we anticipate. It could be negative for team to not deliver in documented time.
Sharing it in the docs site could be - a little unclean. (Not a biggy, but just aesthetically!)

Here is my solution - we could document this in form of Blogs which could sit on CometBFT / Informal blogs on the website & medium page. Blogs are a great way of sharing updates without people expecting them to be updated.
We could of course reference those blogs from our docs site; would be much cleaner!

maintaining them would be an overhead.

Good point, I didn't think of this. I can see a simple fix: I don't think we should maintain presentations. Like an ADR, a presentation is a snapshot or a record in time. We simply upload each presentation, tag it with the date/time, publish it, and then refer people back to it. Or am I missing something?

We might announce things at conferences, which might be delayed more than we anticipate. It could be negative for team to not deliver in documented time.

Not sure I understand this part. Is this situation the concern?

say we're at a conference and announce releasing feature X at date Y
then date Y comes, but we're not ready.. now we're in a tough place because we broke our own deadline.

How does this situation relate to uploading the slides?

Sharing it in the docs site could be - a little unclean. (Not a biggy, but just aesthetically!)

I imagine it would be a simple download button. Agree it's not idea because there's no "integration" in the website. @aaronmw any thoughts here? We could publish the PDFs at slideshare or slides.com.

We simply upload each presentation, tag it with the date/time, publish it, and then refer people back to it.

On the documentation site, there is a section called Past Presentations (TBD) and in that, we have all PDFs linked there to be downloaded or Slideshare link - Is that what you mean by uploading each presentation?

then date Y comes, but we're not ready.. now we're in a tough place because we broke our own deadline.

My concern was if we had the deadline documented at cometbft docs and did not adhere to it, it would be negative. However, if it's a pdf that is to be downloaded, then it is not a concern.

Thanks for the feedback and concerns Ali!

On the documentation site, there is a section called Past Presentations (TBD) and in that, we have all PDFs linked there to be downloaded or Slideshare link - Is that what you mean by uploading each presentation?

Yes.
Curious if @aaronmw has any thoughts here. Otherwise I think we should go ahead with this in Q2.
To be clear, I don't want to create additional work for us. Instead, this issue seeks to achieve the publishing of work we're doing anyway (presentations at conference, hackatons, demos) with a minimal overhead.

repo: cometbft/cometbft-docs


text:
[Bug]: Bug with modules

Describe the Bug
when I try to change the mod settings, I delete the coordinates section, now I don't know how to make it come back
Steps to Reproduce
make a button to reset the configurations or to make modules come back
Expected Behavior
idk
Screenshots

No coordinates
Modloader Type
Fabric
Modloader Version
0.14.9 1.19
Mod Version
1.3.2
Log Output
No response
Additional Context
No response

Under the F3 + M menu, if you choose the left side, you can add the coordinates module back and rearrange it into the correct location.

license: MIT


text:
1.Key chain has stopped 2. Keyboard AOSP has stopped. Tried Reflashing but get invalid syntax error please advise.

This is following the solution put forward by @VirtuallyChris for these error messages. Trying to flash in fastboot mode with eon-neos.
I'm running ubuntu on windows 10.
Get this when trying to clone (just stays at this point):
skyej944@SkylersHp:~$ git clone https://github.com/commaai/eon-neos.git Cloning into 'eon-neos'...
I downloaded and unzipped, located the folder location and run download.py
skyej944@SkylersHp:/mnt/c/users/skyler/downloads/eon-neos-master/eon-neos-master$ python download.py already downloaded https://commadist.azureedge.net/neosupdate/recovery-f01a55c9ba52ca57668d1684c6bf4118efd31916b04f8c1fcd8495013d3677eb.img already downloaded https://commadist.azureedge.net/neosupdate/ota-signed-5dc2575d713977666a8e14ae1b43a04d7f63123934c80fa10751d949a107653e.zip
Then I run flash.sh and get:
skyej944@SkylersHp:/mnt/c/users/skyler/downloads/eon-neos-master/eon-neos-master$ python flash.sh   File "flash.sh", line 8     if [ ! -f $FASTBOOT ]; then          ^ SyntaxError: invalid syntax
I barely know what I'm doing so I tried:
  File "flash.ps1", line 2     $fastboot = "platform-tools/fastboot.exe"     ^ SyntaxError: invalid syntax
Please help!

Your issue is python flash.sh. Run ./flash.sh instead. I also see flash.ps1 in your pasted outed; that script is only for windows. Stick to ubuntu for the easiest experience.
I'm going to close this though since our issue tracker isn't for support. If you need further help, check out the community discord (https://discord.comma.ai) or support@comma.ai

repo: commaai/openpilot


text:
Verb aliases

Fixes #6
Fixes #517

I wasn't sure how best to update the Help messages generated to indicate the new alias support. If anyone has suggestions for what they'd like to see and I can update

Update verbs here.
Just add ' alias name: ..

Thanks for your work and fixing  #6

Help messages updated and tested. Let me know if you think any changes are needed.

@johnjaylward
Please, rebase PR to develop branch and resolve confliction.
Also, for verb test case, set isDefault: false or remove this line.

@moh-hassan , I finished the rebase, but I don't think I need to remove the "Default Verb" setting. I set up the test case purposefully to take into account a default verb. If I remove that option, I will need to adjust my test cases accordingly.

@moh-hassan , I ended up making a few more test cases which show that it work both with a default verb and without a default verb. Also added a few comments to show intention of the tests.

@moh-hassan I'm working on a PR to introduce sub verbs into the library.
After I rebased/merged that work onto the latest develop several of my tests with help output started failing because certain lines we're being indented/padded differently than before.
Changing the call to OptionSpecification.NewSwitch that was changed in HelpText in this PR to once again pass string.Empty as the short name and concatenating the name and aliases into the long name seems to fix it.
E.g. something like this
OptionSpecification.NewSwitch(
    string.Empty,
    new[] { verbTuple.Item1.Name }.Concat(verbTuple.Item1.Aliases).ToDelimitedString(", "),
    false,
    verbTuple.Item1.IsDefault ? "(Default Verb) " + verbTuple.Item1.HelpText : verbTuple.Item1.HelpText,  //Default verb
    string.Empty,
    verbTuple.Item1.Hidden);

Just thought I'd mention it before 2.9 is released in case it is a problem.

@twaalewijn
I couldn't find OptionSpecification.NewSwitch in the commits of this PR.
Can you point me to the location of this change in the commits  of PR?

several of my tests with help output started failing because certain lines we're being indented/padded differently than before.

Can this may to related to the Configuration of Git to handle line endings?
Can Your suggestion cause some tests to fail?

@moh-hassan
This is the call I am referring to: https://github.com/commandlineparser/commandline/pull/636/files#diff-88c7f4706542a25c9d5ec8b7a7b49bd5R853
As can be seen in the diff the first parameter (short name) used to be  string.Empty and the  verb name was passed as the second parameter (long name).
After passing both the verb name and possible aliases to the long name parameter as shown in my earlier example my expected help text was indented/aligned like it was before this PR.

Can this may to related to the Configuration of Git to handle line endings?

I guess I cannot 100% rule that out but I do not think so.
Sorry if I did not explain it clearly enough, I'm talking about the spacing in the help that is added between the verb and help text:
help  <this added space>  Display more information on a specific command.

Can Your suggestion cause some tests to fail?

It will cause these instances of theory tests to fail:

Issue6Tests.cs - Line 88
Issue6Tests.cs - Line 96
Issue6Tests.cs - Line 163
Issue6Tests.cs - Line 170

But these tests are expecting wrong outputs I think.
It isn't very easy to see in the InlineData of lines 163 and 170 but in the data of lines 88 and 96 you can see that the help text for delete, help and version are not lining up correctly with copy, cp, cpy.
The data of line 88 for example currently looks like this:
[InlineData("--help", true, new string[]
    {
        "copy, cp, cpy    (Default Verb) Copy some stuff",
        "move, mv",
        "delete        Delete stuff",
        "help          Display more information on a specific command.",
        "version       Display version information.",
    })]

But should have looked like this instead:
[InlineData("--help", true, new string[]
    {
        "copy, cp, cpy    (Default Verb) Copy some stuff",
        "move, mv",
        "delete           Delete stuff",
        "help             Display more information on a specific command.",
        "version          Display version information.",
    })]

@twaalewijn, I see. The reason I swapped the verb to the "short" position was to ensure it would always be first in the list. When the verb was in the "long" position, it changed the order to have all the aliases first, which I did not like.
The Issue6Tests were generated for this PR. I'll look at opening a new PR to switch the order back, but that will likely change the help to read like this:
[InlineData("--help", true, new string[]
    {
        "cp, cpy, copy    (Default Verb) Copy some stuff",
        "mv, move",
        "delete           Delete stuff",
        "help             Display more information on a specific command.",
        "version          Display version information.",
    })]

authors: johnjaylward moh-hassan twaalewijn

repo: commandlineparser/commandline


text:
Added  a Dark Theme in Index.html

This is my first pull request, please correct me if I have made any mistakes.

added a button in the navbar.
changed some colors in style.css
made a function in main.js

Attach Screenshots

Attach Screenshots

repo: commclassroom/commclassroom


text:
Improve availability

Disable purchases on unavailable.
Allow to configure stock levels for each threshold.

I'm not so familiar with the structures used in the 1.0.0 branch: Will the new availability behaviour be in a component that can removed/replaced/disabled? (We're using stock information from a third-party service and permit purchases of unavailable items - shipping of presently unavailable items will be delayed, of course.)

Nothing planned yet, this will likely be an epic to improve this on all levels, so any input is welcome and taken into account :)

authors: lauraluiz selo-ecube


text:
Use .lhs for temp files when necessary to match the current buffer

This addresses #311, in which .hs was wrongly used unconditionally.

Good call with the conditional. Thanks @purcell!

Happy to help. If you want to add me as a collaborator for the ease of making occasional little fixes like this to the elisp side of things, that might work.

@purcell Done!

Cool, thanks.

authors: chrisdone purcell

repo: commercialhaskell/intero


text:
0.3.0 RC

This pull request migrates the API to 0.3.0.
It resolves #7, #8 and #9.
It also attempts to improve the API by introducing more idem-potency across the API, with various notes introduced where subjectivity [that is, return results] could vary between nodes.
This is obviously a breaking change with 0.2.0,  but I think that is well understood.

Looks good. A couple of questions:

In https://github.com/common-blockchain/common-blockchain/commit/14f2872ec87ec33f4e7a3db5236f9561391da7db, why include blockHex and txHex? Feels a bit heavyweight, especially blockHex.
In https://github.com/common-blockchain/common-blockchain/commit/d820076ab0fc5599fd2f0e9a3bc2c7b5a8a3fe19, why a single tx hex now and not an array? Presumably simplification? Whatever the case, I like it.

@jprichardson

I'm not seeing what you're referring to?  Can you comment inline?
See closing comments on https://github.com/common-blockchain/common-blockchain/issues/8

LOL, never mind. I was too fixated on a previous discussion that included blockHex and I immediately thought of that without considering the context. My fault.
Makes perfect sense.

Want to move quicker on this,  happy to discuss any of the changes at any step as we go forward.

authors: dcousens jprichardson

repo: common-blockchain/common-blockchain


text:
Incorrect Greek translation of "navigation_item_about"

Summary:
When i press the menu button , and menu shows up , there is an option called 'About' in english. In my case ( that i have greek language ) it's called 'Γύρω Από' , and when i press this button , on the top the name changes to another one called 'Σχετικά' ( this one is the correct by the way ).
Steps to reproduce:
It should have the same 'name' at every location
Device and Android version:
Samsung J7 2017
Commons app version:
2.8.5
Screen-shots:

I can take on this issue.

Hi @athatsakk, thanks for bringing this to our attention.
Translations are managed on translatewiki. This exact string is here:
https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=commons-android-strings-navigation_item_about&group=commons-android-strings&language=en-gb&filter=&optional=1&action=translate
Unfortunately I haven't gone through the translatewiki verification process so I can't edit this yet.
@NicholasWeiner I think you're new to the project so I'd advise reading through https://github.com/commons-app/apps-android-commons/wiki/Translating-the-app. If you edit the Greek strings.xml and submit a PR the @translatewiki account will overwrite it so it does need to be done there.

I got translatewiki rights and have updated this translation. Hopefully we should get changes ported into the app by translatewiki soon. Please reopen this issue if this still happens after the latest update.

authors: NicholasWeiner athatsakk domdomegg

repo: commons-app/apps-android-commons


text:
Implement upload tests

As suggested by @tobias47n9e after the 2.4 upload crash fiasco. We probably need lots of other tests too, but these ones should be a higher priority IMO.

I think #555 will be the first step for that.

@whym agreed. @addshore has mentioned that it isn't merge-ready yet though - could you tell us what is missing at the moment, addshore?

In the process of refactoring related to networking I introduced a class ApacheHttpClientMediaWikiApi and felt the need to at least smoke test to make sure that requests and responses are correctly handled.  I used the MockWebServer (from OkHttp) to serve up canned responses and assert that requests are well formed at a unit-test level.
https://github.com/psh/apps-android-commons/blob/master/app/src/androidTest/java/fr/free/nrw/commons/mwapi/ApacheHttpClientMediaWikiApiTest.java

@psh Thank you for working on that. I like the idea of having a mocked server. While there is #555 which is about using Beta Commons for tests, I believe there is nothing that prevents us from having both kinds of tests.

The XML that I captured came from the API Sandbox

It might be a good idea to leave some links about it as a comment in ApacheHttpClientMediaWikiApiTest.

OK.  PR submitted.  Its not the upload tests themselves, its all the work to set you up for success given the more specific knowledge.  :)
See: https://github.com/commons-app/apps-android-commons/pull/763

We now have the ability to upload to a beta server via the new product flavours #857 , so we can proceed with upload tests. :) This task has been assigned for the IEG renewal.
Question: How/when will we consider this task to be "complete"? What should the target be?

Had a discussion with @misaochan. Am updating the scope of this task for further feedback and suggestions:
(1) write a script that uploads a fake image to the beta server and checks for the result. Ideally we want a test that tests the entire upload process from image selection to checking that the image has been uploaded.
(2) Write unit tests for classes/methods in the "upload" package

This can start after #1091 is closed via #1552 , I think. My previous comment was made before we created #1091 as a subtask of #604 . With that subtask done, we can start writing tests for the single uploads, and then add multiple upload tests when multiple uploads are completed.

Will pick up the upload tests after 2.8.0 release tasks are completed. :)

authors: maskaravivek misaochan psh whym


text:
Build errors

I'm trying to follow this demo.
I've cloned this commit and run cargo clean && cargo build but I receive multiple build errors (pasted below).
I've also tried building against the commit mentioned in the demo writeup, but that also fails with different errors. I'll omit these errors for now in favor of trying to figure out why master HEAD isn't building.
Any ideas?
   Compiling autocfg v1.0.0
   Compiling proc-macro2 v1.0.7
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.13
   Compiling serde v1.0.104
   Compiling byteorder v1.3.2
   Compiling unicode-width v0.1.7
   Compiling abomonation v0.7.3
   Compiling timely_logging v0.11.1 (https://github.com/TimelyDataflow/timely-dataflow#a6b5e3ef)
   Compiling timely_bytes v0.11.0 (https://github.com/TimelyDataflow/timely-dataflow#a6b5e3ef)
   Compiling log v0.4.8
   Compiling timely_sort v0.1.6
   Compiling fnv v1.0.6
   Compiling cfg-if v0.1.10
   Compiling getopts v0.2.21
   Compiling num-traits v0.2.11
   Compiling num-integer v0.1.42
   Compiling num-bigint v0.2.5
   Compiling num-rational v0.2.3
   Compiling quote v1.0.2
   Compiling synstructure v0.12.3
   Compiling serde_derive v1.0.104
   Compiling abomonation_derive v0.5.0
   Compiling bincode v1.2.1
   Compiling uuid v0.7.4
   Compiling timely_communication v0.11.1 (https://github.com/TimelyDataflow/timely-dataflow#a6b5e3ef)
   Compiling timely v0.11.1 (https://github.com/TimelyDataflow/timely-dataflow#a6b5e3ef)
   Compiling differential-dataflow v0.11.0 (https://github.com/TimelyDataflow/differential-dataflow#fbea6a8e)
   Compiling declarative-dataflow v0.2.0 (/Users/ben.grabow/Projects/declarative-dataflow)
error[E0407]: method `minimum` is not a member of trait `Lattice`
  --> src/timestamp/altneu.rs:85:5
   |
85 | /     fn minimum() -> Self {
86 | |         AltNeu::alt(T::minimum())
87 | |     }
   | |_____^ not a member of trait `Lattice`

error[E0407]: method `minimum` is not a member of trait `Lattice`
  --> src/timestamp/pair.rs:68:5
   |
68 | /     fn minimum() -> Self {
69 | |         Pair {
70 | |             first: S::minimum(),
71 | |             second: T::minimum(),
72 | |         }
73 | |     }
   | |_____^ not a member of trait `Lattice`

error[E0576]: cannot find method or associated constant `minimum` in trait `Lattice`
   --> src/domain/mod.rs:165:48
    |
165 |             last_advance: vec![<T as Lattice>::minimum()],
    |                                                ^^^^^^^ not found in `Lattice`

error[E0603]: struct `ActivateCapability` is private
 --> src/domain/mod.rs:7:52
  |
7 | use timely::dataflow::operators::unordered_input::{ActivateCapability, UnorderedHandle};
  |                                                    ^^^^^^^^^^^^^^^^^^

error[E0603]: struct `ActivateCapability` is private
  --> src/domain/unordered_session.rs:12:52
   |
12 | use timely::dataflow::operators::unordered_input::{ActivateCapability, UnorderedHandle};
   |                                                    ^^^^^^^^^^^^^^^^^^

warning: trait objects without an explicit `dyn` are deprecated
  --> src/binding/mod.rs:20:43
   |
20 |     fn required_to_extend(&self, prefix: &AsBinding, target: Var) -> Option<Option<Var>>;
   |                                           ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`
   |
   = note: `#[warn(bare_trait_objects)]` on by default

warning: trait objects without an explicit `dyn` are deprecated
  --> src/binding/mod.rs:24:40
   |
24 |     fn ready_to_extend(&self, prefix: &AsBinding) -> Option<Var>;
   |                                        ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
  --> src/binding/mod.rs:28:35
   |
28 |     fn can_extend(&self, prefix: &AsBinding, target: Var) -> bool {
   |                                   ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
  --> src/binding/mod.rs:42:41
   |
42 |     fn ready_to_extend(&self, _prefix: &AsBinding) -> Option<Var> {
   |                                         ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
  --> src/binding/mod.rs:46:44
   |
46 |     fn required_to_extend(&self, _prefix: &AsBinding, _target: Var) -> Option<Option<Var>> {
   |                                            ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:113:40
    |
113 |     fn ready_to_extend(&self, prefix: &AsBinding) -> Option<Var> {
    |                                        ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:122:43
    |
122 |     fn required_to_extend(&self, prefix: &AsBinding, target: Var) -> Option<Option<Var>> {
    |                                           ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:156:40
    |
156 |     fn ready_to_extend(&self, prefix: &AsBinding) -> Option<Var> {
    |                                        ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:168:43
    |
168 |     fn required_to_extend(&self, prefix: &AsBinding, target: Var) -> Option<Option<Var>> {
    |                                           ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:220:40
    |
220 |     fn ready_to_extend(&self, prefix: &AsBinding) -> Option<Var> {
    |                                        ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:224:43
    |
224 |     fn required_to_extend(&self, prefix: &AsBinding, target: Var) -> Option<Option<Var>> {
    |                                           ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:257:40
    |
257 |     fn ready_to_extend(&self, prefix: &AsBinding) -> Option<Var> {
    |                                        ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:265:43
    |
265 |     fn required_to_extend(&self, prefix: &AsBinding, target: Var) -> Option<Option<Var>> {
    |                                           ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:323:40
    |
323 |     fn ready_to_extend(&self, prefix: &AsBinding) -> Option<Var> {
    |                                        ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/binding/mod.rs:335:43
    |
335 |     fn required_to_extend(&self, prefix: &AsBinding, target: Var) -> Option<Option<Var>> {
    |                                           ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: unnecessary trailing semicolon
   --> src/domain/mod.rs:304:46
    |
304 |                         .collect::<Vec<T>>();;
    |                                              ^ help: remove this semicolon
    |
    = note: `#[warn(redundant_semicolon)]` on by default

warning: unnecessary trailing semicolon
   --> src/plan/hector.rs:731:1
    |
731 | ;
    | ^ help: remove this semicolon

warning: unnecessary trailing semicolon
   --> src/plan/hector.rs:808:1
    |
808 | ;
    | ^ help: remove this semicolon

warning: trait objects without an explicit `dyn` are deprecated
   --> src/lib.rs:543:41
    |
543 |     fn ready_to_extend(&self, _prefix: &AsBinding) -> Option<Var> {
    |                                         ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/lib.rs:547:44
    |
547 |     fn required_to_extend(&self, _prefix: &AsBinding, _target: Var) -> Option<Option<Var>> {
    |                                            ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/lib.rs:777:40
    |
777 |     fn ready_to_extend(&self, prefix: &AsBinding) -> Option<Var> {
    |                                        ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

warning: trait objects without an explicit `dyn` are deprecated
   --> src/lib.rs:784:43
    |
784 |     fn required_to_extend(&self, prefix: &AsBinding, target: Var) -> Option<Option<Var>> {
    |                                           ^^^^^^^^^ help: use `dyn`: `dyn AsBinding`

error[E0046]: not all trait items implemented, missing: `minimum`
  --> src/timestamp/altneu.rs:63:1
   |
63 | impl<T: Timestamp> Timestamp for AltNeu<T> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `minimum` in implementation
   |
   = note: `minimum` from trait: `fn() -> Self`

error[E0046]: not all trait items implemented, missing: `minimum`
  --> src/timestamp/pair.rs:60:1
   |
60 | impl<S: Timestamp, T: Timestamp> Timestamp for Pair<S, T> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `minimum` in implementation
   |
   = note: `minimum` from trait: `fn() -> Self`

error[E0277]: the trait bound `<S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default` is not satisfied
   --> src/domain/mod.rs:596:40
    |
585 |     fn as_singleton_domain<X: Into<A>>(self, name: X) -> ScopedDomain<A, S> {
    |                                                                            - help: consider further restricting the associated type: `where <S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default`
...
596 |             .map(|(data, diff)| (data, Default::default(), diff))
    |                                        ^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `<S as timely::dataflow::scopes::ScopeParent>::Timestamp`
    |
    = note: required by `std::default::Default::default`

error[E0277]: the trait bound `<S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default` is not satisfied
   --> src/domain/mod.rs:588:38
    |
585 |     fn as_singleton_domain<X: Into<A>>(self, name: X) -> ScopedDomain<A, S> {
    |                                                                            - help: consider further restricting the associated type: `where <S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default`
...
588 |         let mut domain = Domain::new(Default::default());
    |                                      ^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `<S as timely::dataflow::scopes::ScopeParent>::Timestamp`
    |
    = note: required by `std::default::Default::default`

error[E0277]: the trait bound `<S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default` is not satisfied
   --> src/domain/mod.rs:636:37
    |
626 |     fn as_singleton_domain<X: Into<A>>(self, name: X) -> ScopedDomain<A, S> {
    |                                                                            - help: consider further restricting the associated type: `where <S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default`
...
636 |         let pairs = self.probe_with(&mut domain.domain_probe);
    |                                     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `<S as timely::dataflow::scopes::ScopeParent>::Timestamp`
    |
    = note: required by `std::default::Default::default`

error[E0277]: the trait bound `<S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default` is not satisfied
   --> src/domain/mod.rs:686:38
    |
683 |     fn as_singleton_domain<X: Into<A>>(self, name: X) -> ScopedDomain<A, S> {
    |                                                                            - help: consider further restricting the associated type: `where <S as timely::dataflow::scopes::ScopeParent>::Timestamp: std::default::Default`
...
686 |         let mut domain = Domain::new(Default::default());
    |                                      ^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `<S as timely::dataflow::scopes::ScopeParent>::Timestamp`
    |
    = note: required by `std::default::Default::default`

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/hector.rs:729:74
    |
729 | ...                   .enter_at(&scope, move |_,_,t| AltNeu { time: t.clone(), neu })
    |                        ^^^^^^^^ expected 3 parameters

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/hector.rs:751:74
    |
751 | ...                   .enter_at(&scope, move |_,_,t| AltNeu { time: t.clone(), neu })
    |                        ^^^^^^^^ expected 3 parameters

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/hector.rs:773:74
    |
773 | ...                   .enter_at(&scope, move |_,_,t| AltNeu { time: t.clone(), neu })
    |                        ^^^^^^^^ expected 3 parameters

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/hector.rs:806:74
    |
806 | ...                   .enter_at(&scope, move |_,_,t| AltNeu { time: t.clone(), neu })
    |                        ^^^^^^^^ expected 3 parameters

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/hector.rs:828:74
    |
828 | ...                   .enter_at(&scope, move |_,_,t| AltNeu { time: t.clone(), neu })
    |                        ^^^^^^^^ expected 3 parameters

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/hector.rs:850:74
    |
850 | ...                   .enter_at(&scope, move |_,_,t| AltNeu { time: t.clone(), neu })
    |                        ^^^^^^^^ expected 3 parameters

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/pull.rs:158:44
    |
158 |                         let e_v = arranged.enter_at(nested, move |_, _, time| {
    |                                            ^^^^^^^^ expected 3 parameters

error[E0061]: this function takes 3 parameters but 2 parameters were supplied
   --> src/plan/pull.rs:331:40
    |
331 |                     let e_v = arranged.enter_at(nested, move |_, _, time| {
    |                                        ^^^^^^^^ expected 3 parameters

error[E0599]: no method named `as_singleton_domain` found for type `((timely::dataflow::operators::unordered_input::UnorderedHandle<T, ((Value, Value), T, isize)>, timely::dataflow::operators::capability::ActivateCapability<T>), differential_dataflow::collection::Collection<S, (Value, Value)>)` in the current scope
   --> src/server/mod.rs:363:57
    |
363 |         let mut scoped_domain = ((handle, cap), tuples).as_singleton_domain(name.into());
    |                                                         ^^^^^^^^^^^^^^^^^^^ method not found in `((timely::dataflow::operators::unordered_input::UnorderedHandle<T, ((Value, Value), T, isize)>, timely::dataflow::operators::capability::ActivateCapability<T>), differential_dataflow::collection::Collection<S, (Value, Value)>)`
    |
    = help: items from traits can only be used if the trait is implemented and in scope
    = note: the following trait defines an item `as_singleton_domain`, perhaps you need to implement it:
            candidate #1: `domain::AsSingletonDomain`

error[E0277]: the trait bound `S: std::default::Default` is not satisfied
  --> src/timestamp/pair.rs:39:9
   |
37 | impl<S: Timestamp, T: Timestamp> Refines<()> for Pair<S, T> {
   |      -- help: consider further restricting this bound: `S: std::default::Default +`
38 |     fn to_inner(_outer: ()) -> Self {
39 |         Default::default()
   |         ^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `S`
   |
   = note: required because of the requirements on the impl of `std::default::Default` for `timestamp::pair::Pair<S, T>`
   = note: required by `std::default::Default::default`

error[E0277]: the trait bound `T: std::default::Default` is not satisfied
  --> src/timestamp/pair.rs:39:9
   |
37 | impl<S: Timestamp, T: Timestamp> Refines<()> for Pair<S, T> {
   |                    -- help: consider further restricting this bound: `T: std::default::Default +`
38 |     fn to_inner(_outer: ()) -> Self {
39 |         Default::default()
   |         ^^^^^^^^^^^^^^^^ the trait `std::default::Default` is not implemented for `T`
   |
   = note: required because of the requirements on the impl of `std::default::Default` for `timestamp::pair::Pair<S, T>`
   = note: required by `std::default::Default::default`

error: aborting due to 22 previous errors

Some errors have detailed explanations: E0046, E0061, E0277, E0407, E0576, E0599, E0603.
For more information about an error, try `rustc --explain E0046`.
error: could not compile `declarative-dataflow`.```

This is probably partly my fault. These are largely the results of differential and timely master moving around a bit in breaking ways. If you haven't, you could try pointing Cargo.toml at the most recent stable releases (0.11, I think). None of these are complicated to fix, but probably take Niko and I sitting down and talking through what changed and why and where the new parts are. I'll ping him and see if we can get on that.

I tried pinning these deps to the latest release tag I could find and I get a fresh new set of errors about timely::dataflow::scopes::Scope.
[dependencies]
timely = { git = "https://github.com/TimelyDataflow/timely-dataflow", features = ["bincode"], tag = "v0.10.0" }
differential-dataflow = { git = "https://github.com/TimelyDataflow/differential-dataflow", tag = "v0.10.0" }

I don't know how Rust/Cargo handles transitive deps, but I see differential-dataflow depends on timely-dataflow HEAD, and not on a specific tag. Would I need to pin differential-dataflow to the same version of timely-dataflow as I'm pinning in declarative-dataflow?

Yes, this will be tricky with github releases (because I always screw those up). Does the world get better if you point a timely and differential 0.11 on crates.io?
https://crates.io/crates/timely
https://crates.io/crates/differential-dataflow
e.g. with
timely = "0.11"
differential-dataflow = "0.11"

Getting closer?
❯ git diff
diff --git a/Cargo.toml b/Cargo.toml
index 8534111..db020bf 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -14,8 +14,8 @@ keywords = ["differential", "dataflow",  "datalog", "graphql", "query"]
 license = "MIT"

 [dependencies]
-timely = { git = "https://github.com/TimelyDataflow/timely-dataflow", features = ["bincode"] }
-differential-dataflow = { git = "https://github.com/TimelyDataflow/differential-dataflow" }
+timely = "0.11"
+differential-dataflow = "0.11"
 serde = "1"
 serde_derive = "1"
 log = "0.4"

~/Projects/declarative-dataflow master*
❯ cargo build
   Compiling autocfg v1.0.0
   Compiling proc-macro2 v1.0.7
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.13
   Compiling serde v1.0.104
   Compiling unicode-width v0.1.7
   Compiling abomonation v0.7.3
   Compiling timely_logging v0.11.1
   Compiling timely_bytes v0.11.0
   Compiling log v0.4.8
   Compiling timely_sort v0.1.6
   Compiling cfg-if v0.1.10
   Compiling fnv v1.0.6
   Compiling getopts v0.2.21
   Compiling num-traits v0.2.11
   Compiling num-integer v0.1.42
   Compiling num-bigint v0.2.5
   Compiling num-rational v0.2.3
   Compiling quote v1.0.2
   Compiling synstructure v0.12.3
   Compiling abomonation_derive v0.5.0
   Compiling serde_derive v1.0.104
   Compiling uuid v0.7.4
   Compiling timely_communication v0.11.1
   Compiling timely v0.11.1
   Compiling differential-dataflow v0.11.0
   Compiling declarative-dataflow v0.2.0 (/Users/ben.grabow/Projects/declarative-dataflow)

<snip warnings...>

error[E0277]: the trait bound `Value: abomonation::Abomonation` is not satisfied
  --> src/plan/hector.rs:80:13
   |
80 | impl<'a, S> IntoExtender<'a, S, Value> for ConstantBinding
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `abomonation::Abomonation` is not implemented for `Value`

error[E0277]: the trait bound `timestamp::altneu::AltNeu<T>: abomonation::Abomonation` is not satisfied
  --> src/timestamp/altneu.rs:63:20
   |
63 | impl<T: Timestamp> Timestamp for AltNeu<T> {
   |                    ^^^^^^^^^ the trait `abomonation::Abomonation` is not implemented for `timestamp::altneu::AltNeu<T>`

error[E0277]: the trait bound `timestamp::altneu::AltNeu<T>: abomonation::Abomonation` is not satisfied
  --> src/timestamp/altneu.rs:69:20
   |
69 | impl<T: Timestamp> Refines<T> for AltNeu<T> {
   |                    ^^^^^^^^^^ the trait `abomonation::Abomonation` is not implemented for `timestamp::altneu::AltNeu<T>`

error[E0277]: the trait bound `timestamp::pair::Pair<S, T>: abomonation::Abomonation` is not satisfied
  --> src/timestamp/pair.rs:37:34
   |
37 | impl<S: Timestamp, T: Timestamp> Refines<()> for Pair<S, T> {
   |                                  ^^^^^^^^^^^ the trait `abomonation::Abomonation` is not implemented for `timestamp::pair::Pair<S, T>`

error[E0277]: the trait bound `timestamp::pair::Pair<S, T>: abomonation::Abomonation` is not satisfied
  --> src/timestamp/pair.rs:60:34
   |
60 | impl<S: Timestamp, T: Timestamp> Timestamp for Pair<S, T> {
   |                                  ^^^^^^^^^ the trait `abomonation::Abomonation` is not implemented for `timestamp::pair::Pair<S, T>`

error: aborting due to 5 previous errors

For more information about this error, try `rustc --explain E0277`.
error: could not compile `declarative-dataflow`.

You'll probably want to change the Abomonation reference to be to a crates version too, if it is not already.

I don't see an Abomonation reference directly in declarative-dataflow so it must be a transitive dep. I haven't tracked it down yet.

Ah well, we'll probably have to wait for Niko to show up then.

Looks like a mismatch in Abomonation versions?
https://github.com/TimelyDataflow/timely-dataflow/blob/master/communication/Cargo.toml#L24
https://github.com/TimelyDataflow/timely-dataflow/blob/master/timely/Cargo.toml#L24

Hey @bgrabow, I'll take a look soon, busy week!

authors: bgrabow comnik frankmcsherry

repo: comnik/declarative-dataflow


text:
UAR-1325 Remove navigate to company authentication page

JIRA link
https://companieshouse.atlassian.net/browse/UAR-1325
Change description
Changes in two places

remove check in the company authentication middleware function
remove check on post function of the previous entity details page

Work checklist

[x] Tests added where applicable
[ ] UI changes meet accessibility criteria

Merge instructions
We are committed to keeping commit history clean, consistent and linear. To achieve this, this commit should be structured as follows:
<type>[optional scope]: <description>

and contain the following structural elements:

fix: a commit that patches a bug in your codebase (this correlates with PATCH in semantic versioning),
feat: a commit that introduces a new feature to the codebase (this correlates with MINOR in semantic versioning),
BREAKING CHANGE: a commit that has a footer BREAKING CHANGE: introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type,
types other than fix: and feat: are allowed, for example build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others,
footers other than BREAKING CHANGE: <description> may be provided.

Changes looking good @mattch1 but I think you need to get AC1 and AC2 removed from the story.
Also, AC5 Then clause mentions a new tab but no new tab is actually opened, so suggest getting this changed too.

repo: companieshouse/overseas-entities-web


text:
Force torque sensor 2

Implementation of Wrench and Inertia class.
Useful for using force/torque sensors and allowing filtering, and gravity compensation of Wrenches.
What type of change is this?

[ ] Bug fix in a backwards-compatible manner.
[X] New feature in a backwards-compatible manner.
[ ] Breaking change: bug fix or new feature that involve incompatible API changes.

@matteo-pacher the Travis build is failing because compas_fab defines a pretty strict dependency with compas. It is currently set to be >=0.8.1,<0.9, but your branch includes a function name that was only updated on 0.9.0.
In principle, you should update the dependency to be >=0.9,<0.10 in this file, but if you do, the build will fail on many other places that are not ready yet for 0.9, so I will take care of updating compas_fab to latest compas in another PR, and then we can merge once that is merged back to master.
Btw, if you want to see the output of Travis, that should always be available if you follow the links on Github, e.g. https://travis-ci.com/compas-dev/compas_fab/jobs/250033076

OK, sounds good to me.
Thank you Gonzalo for clarifying that.

@matteo-pacher @romanarust Now that the build is passing, are we ready to merge or are there still pending things?

merge!

authors: gonzalocasas matteo-pacher romanarust


text:
Rename safe_mode to debug_mode

It’s not obvious what safe mode is, and what limitations it induces. Let’s document that.
EDIT: also, given the significant performance penalty of using safe mode, does it make sense to enable it by default?

Is addressed via #175 and https://github.com/SciML/ADTypes.jl/pull/68 . Will close this when they are merged.

This is going to stay open so that we don't forget to rename to debug mode at some point. I've let @gdalle know that we would like to do this at some point, so when a breaking change in ADTypes next happens, we'll bundle it in with that.

There don't appear to be any breaking released -- ADTypes is still in version 1.x.x.

No, 1.5 -> 1.6 is a minor (feature) release. 1.5 -> 2.0 is a major (breaking) release. See e.g. https://semver.org/ for details.

This is not breaking in major ways, so I won't suggest waiting for ADTypes 2.0.

This is something that you'll have to discuss with @gdalle -- I do not have control over this, and I don't view this as being sufficiently important to really push him to make a breaking release sooner rather than later.

It also only affects Tapir's constructor AutoTapir, so if needed, we can support both constructors AutoTapir(debug_mode=false) and AutoTapir(safe_mode=false) but throw a depreciation warning for the latter.

We could potentially just add a constructor, but we can't change the name of the field from safe_mode to debug_mode (as this is breaking). My preference is to change it all, or change none of it, rather than have two things for users to look out for.

This is definitely also true in Julia -- there have been no breaking releases since 1.0 in the public interface (or, at least, nothing intentional). What kinds of changes are you thinking about in 1.7?

I'm not saying these are major, but it does seem that minor breaking changes do happen from time to time, for good reasons.

Fair point.

I would rather add a new keyword argument and deprecate the old one. Even though it's minor, such a change would break things e.g. for people using Tapir through DifferentiationInterface

I've opened a PR here: https://github.com/SciML/ADTypes.jl/pull/75
It's quite ugly, which in combination with the inconsistency it introduces, makes me think we're better off waiting until ADTypes makes a breaking release to do any of this. @gdalle @yebai please let me know what you think.

Honestly I think we should leave things as they are. Tapir is free to interpret the "safe mode" argument as they see fit, so the renaming is not really worth our sweat.

Thats why I closed the PR. If a v2 of ADTypes ever gets discussed we can revisit this, but that could be literal years away so in the meantime let's move on

Unless I'm mistaken, we did our best to ensure the changes to AutoReverseDiff were not breaking, by preserving the old behavior with the compile field.
It's not a question of package-dependent bar height, it's a question of avoiding breaking changes whenever possible. And renaming a keyword argument because you don't like how it sounds is a very very minimal change, which means you can definitely live with the old kwarg name.

The key difference is that your request is a purely esthetic change, which you can easily live with (whereas the ReverseDiff change had performance implications for static dispatch).
In my view, purely esthetic changes like this one do not justify additional code complexity in a package. ADTypes is a central package and we want to keep it as lightweight and easily maintainable as possible. Every PR is weighed on the cost/benefit tradeoff, and in your case the benefit is basically zero.

The inaccurate terminology was the reason behind https://github.com/SciML/ADTypes.jl/pull/68, which in my view is a good middle ground.
For instance, if you wanted to turn safe/debug mode off by default, I would definitely consider the change because it has performance benefits. But for a simple renaming, I don't think it's worth it.

This was resolved during the renaming process :)

authors: gdalle willtebbutt yebai


text:
Getting Name Error with MSGFplus mzid file

Hi there,
I am using ms2resocre on my msgfplus resulted PSM files.
I am using the following command to execute the ms2resocre
ms2rescore -p Desktop/Demo_data/data/20072102.mzid -s Desktop/Demo_data/data/20072102.mzML -c Desktop/Demo_data/config_file.json
I am running the version 3.0.0
OS: Linux
I am getting the KeyError Name Error.
Herewith I attached the error log
ms2rescore.log.
Please help me with this.
I request you provide a good user manual or documentation for using ms2resocre program. ms2rescore.readthedocs.io isn't so helpful for executing the ms2rescore.
Thank you,
Tulasi

Hi @thulasis,
Thanks for using MS²Rescore! It seems that there is an issue while parsing one of the amino acid modifications from the mzIdentML file from MS-GF+. Could you share the mzIdentML file that generated the issue? That would help us tremendously to fix the issue.
Thanks,
Ralf

Regarding the documentation, do let us know which parts of using MS²Rescore or from the documentation were unclear to you. We are always looking to improve user experiences.

authors: RalfG thulasis


text:
Document the Daniel Hammack algorithm

Overview
Participants in the Data Science Bowl produced several algorithms that we would like to incorporate. To help facilitate this effort, we also want to add documentation so that contributors can make an educated decision when selecting an algorithm to incorporate.
Expected Behavior
This documentation should enable people to:

view the library dependencies and license
understand its pros/cons
evaluate its performance/accuracy
identify which areas of the codebase to target for improvement

Design doc reference: Detect and select
Algorithm info

key
value

team
Daniel Hammack

rank
1

repo
https://github.com/dhammack/DSB2017 & https://github.com/juliandewit/kaggle_ndsb2017

trained models
https://retinopaty.blob.core.windows.net/ndsb3/trained_models.rar

converted branch

ML engine
Keras

engine-version

ML backend
Theano

backend-version

training method

architecture

algorithm

OS
Windows

OS version
64bit

Python version
2.7 & 3.5

CUDA version

cuDNN version

notes

Technical details

This feature should be implemented as a new markdown file in the docs folder

Acceptance criteria

[ ] effective documentation for the above

NOTE: All PRs must follow the standard PR checklist.

I've reached out to the author since he mentions in the README that he knows how to simplify and speed-up his code without major performance loss.

Unfortunately, the author didn't respond so far. @reubano you already wrote that the code runs on Windows 64bit with Python 3.5. From where did you receive this information? I'm a bit confused because I found a lot print statements in the code that don't have parentheses which would throw errors when running with Python 3.

@wgierke turns out this one is actually a combination of two repos and it was the 2nd one that I got the info from. Thanks for pointing that out! I've since updated the description.

@reubano I guess this one can be closed?

@wgierke nice catch!

Don't want to re-open a closed issue, but we are also working on getting some of the DSB models working and have forked this repository and invested some time in getting the keras1.2 model into a standard keras2 model and extracting the py2.7 code and getting it work with py3.5 (https://github.com/4Quant/DSB2017/blob/master/ApplyModel.ipynb). It is quite a hacky bit of work to extract cleanly the models from someone else's code and get everything working

@kmader you may want to take a look here for some inspiration. Also, see #4 and #122.

authors: WGierke kmader reubano

repo: concept-to-clinic/concept-to-clinic


text:
Adding LandWorker method

This adds landworker to the go-concourse api
This change is required to get land-worker into fly

@arwineap Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@arwineap Thank you for signing the Contributor License Agreement!

needed-by concourse/fly#173

Closing since concourse/fly#173 was closed.

authors: arwineap chendrix pivotal-issuemaster topherbullock

repo: concourse/go-concourse


text:
CLI install fails with new UserInfo system

https://github.com/concrete5/concrete5/commit/397ed1749e5cfe6f8190d03f1fe2bb3edd65c8d6 breaks installation of concrete5 via the CLI installation.
This is caused by the use of the DatabaseManager parameter in the new class constructors: we don't use the same DatabaseManager instance used by the Database facade, and the new DatabaseManager instance is not able to connect to the database at install time.

A possible approach to fix this is #3145

It looks to me that we really want connection and not manager at all. We
should be able to just hint on connection here. @mlocati, I want to get
away from using aliases and facades in the core. I know I have been a major
proponent of facades and aliases, and I think that they add some value for
the end user, but we should avoid using them in the core in favor of using
the service locator or dependency injection.
On Mon, Nov 23, 2015 at 2:34 AM Michele Locati notifications@github.com
wrote:

A possible approach to fix this is #3145
https://github.com/concrete5/concrete5/pull/3145
—
Reply to this email directly or view it on GitHub
https://github.com/concrete5/concrete5/issues/3144#issuecomment-158899994
.

I think that such core changes should be done very wisely. First of all, concrete5 is a project targeted to a very large audience; secondarily we can't assume that package developers have to spent most of their time trying to keep their knowledge up to date with rapidly changing core changes.

Couple things:

I made these changes in order to make it much easier to swap out the avatar handling (primarily so we could use concrete5.org user avatars on our documentation sites, but it should lend itself to lots of community improvements.) I also took the opportunity to begin to refactor one of the larger, more irritating classes (UserInfo).
The changes should be completely backward compatible.
Connection should indeed be the variable that we automatically pass in. That was an oversight. Connection is now being passed in (as of the latest commit) and installation via the web browser works as it has.
Sadly, this didn't fix the issue posted about here – mostly because I'm not really sure how the database command line connection naming works. The $connection variable is being automatically passed in, but it's not the instance that is set by the Database::extend() method. This will have to be fixed but I imagine it can be fixed by either reworking Database::setDefaultConnection and/or some additional code in the command line installer.

@mlocati I think it's good that we have people keeping that in mind. To be clear, I am arguing for more DI and not for removing facades. I think facades add a lot of value to c5, I just think that we should be using DI instead where possible (which should be everywhere).

@aembler I'll take a look at that, I might have some commits in my branches that aren't up to date.
In the service provider we tell the application how to resolve an instance based on the FQN of the class. In PHP 5.5+, this looks something like this:
<?php
$app->bind(Connection::class, 'database/connection');

so now when the application sees that Connection is a dependency, it's basically just running $app->make(Connection::class).
I'll get this working.

Yeah I understand all that. I'm doing that throughout all this new code. The problem is that the connection that's being injected isn't the same one being set in the installation command.
Sent from my iPhone

On Nov 23, 2015, at 3:55 PM, Korvin Szanto notifications@github.com wrote:
@aembler I'll take a look at that, I might have some commits in my branches that aren't up to date.
In the service provider we tell the application how to resolve an instance based on the FQN of the class. In PHP 5.5+, this looks something like this:
bind(Connection::class, 'database/connection');
so now when the application sees that Connection is a dependency, it's basically just running $app->make(Connection::class).

I'll get this working.

—
Reply to this email directly or view it on GitHub.

365d6e13b232ef2306fbc8edf6c74b73e218992d fixes this issue, I avoided making the managers singletons when updating the database service provider because we already track singletons of these objects in the facade layer.

authors: KorvinSzanto aembler mlocati


text:
Fix tests on release/8.0.0 branch

Having failing tests is making it a pain to develop and review code for the 8.0.0 release branch, failing tests makes it impossible for me to keep the branch up to date with develop. See https://travis-ci.org/concrete5/concrete5/branches

This is not complete, the tests complain of php7 LSP errors

That's gonna have to be someone else, I'm not running PHP 7.

Last time I checked, the release/8.0.0 branch failed to even install on php7...

991130a fixes install @mlocati. @aembler again comments for these methods would've made these changes a lot easier.


text:
Update league/url to latest 3.x series

Fix problems reported in #2628

As stated by @nyamsprod it's safe to use league/url:3.x-dev

They released a new stable version of league/url (3.3.4): let's use it


text:
[warning] failed package validation and/or copy for commit 807ad2335928e519d0fd631804747532f49d72b2

Hi @conda-forge/binutils! This is the friendly automated conda-forge-webservice!
It appears that one or more of your feedstock's outputs did not copy from the
staging channel (cf-staging) to the production channel (conda-forge). :(
This failure can happen for a lot of reasons, including an outdated feedstock
token. Below we have put some information about the failure to help you debug it.
Rerendering the feedstock will usually fix these problems.
If you have any issues or questions, you can find us on gitter in the
community chat room or you can bump us right here.
output validation (is this output allowed for your feedstock?):

linux-64/binutils_impl_linux-s390x-2.36.1-h0c0cb34_1.tar.bz2: False

copied (did this output get copied to the production channel?):

linux-64/binutils_impl_linux-s390x-2.36.1-h0c0cb34_1.tar.bz2: False

error messages:

output linux-64/binutils_impl_linux-s390x-2.36.1-h0c0cb34_1.tar.bz2 not allowed for conda-forge/binutils-feedstock

Hi @conda-forge/binutils! This is the friendly automated conda-forge-webservice!
It appears that one or more of your feedstock's outputs did not copy from the
staging channel (cf-staging) to the production channel (conda-forge). :(
This failure can happen for a lot of reasons, including an outdated feedstock
token. Below we have put some information about the failure to help you debug it.
Rerendering the feedstock will usually fix these problems.
If you have any issues or questions, you can find us on gitter in the
community chat room or you can bump us right here.
output validation (is this output allowed for your feedstock?):

osx-arm64/binutils_impl_linux-s390x-2.36.1-h3fea60e_1.tar.bz2: False

copied (did this output get copied to the production channel?):

osx-arm64/binutils_impl_linux-s390x-2.36.1-h3fea60e_1.tar.bz2: False

error messages:

output osx-arm64/binutils_impl_linux-s390x-2.36.1-h3fea60e_1.tar.bz2 not allowed for conda-forge/binutils-feedstock

cc @isuruf
We'll have to add this output to this feedstock I guess?

https://github.com/conda-forge/feedstock-outputs/pull/19

Not sure if we'll need to rekick the build.

authors: beckermr conda-forge-linter isuruf

repo: conda-forge/binutils-feedstock


text:
[ci skip] adding user @galipremsagar

Hi! This is the friendly automated conda-forge-webservice.
I've added user @galipremsagar as instructed in #19.
Merge this PR to add the user. Please do not rerender this PR or change it in any way. It has [ci skip] in the commit message to avoid pushing a new build and so the build configuration in the feedstock should not be changed.
Fixes #19

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

There are too few lines.  There should be one empty line at the end of the file.

repo: conda-forge/dask-sql-feedstock


text:
fix: build detectron2 with GPU support

Checklist

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

This fixes an issue where detectron2 was not build with CUDA support. By default the information is not properly relayed via pytorch. This PR fixes this using the same approach as taken by torchvision: https://github.com/conda-forge/torchvision-feedstock/blob/da433bf865b44afa7890aeafa5a34933af129942/recipe/build-torch.sh

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@mxr-conda @ndmaxar @oblute @rluria14 I would love to have you take a peek at this!

authors: baszalmstra conda-forge-linter


text:
Append gmt to the install dir on Windows

Addresses the install path issues pointed out in #62
Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@leouieda I don't think this is the right solution.
Comparing the build.sh and bld.bat, I believe you should add
-D GMT_INSTALL_TRADITIONAL_FOLDERNAMES:BOOL=FALSE

to windows build script.

Good point @seisman, thanks!

We were missing the GMT_INSTALL_MODULE_LINKS:BOOL = FALSE as well. Don't need to create all of the shorthands for GMT4 compatibility.

@seisman what do you think of this?

It looks good to me.

There is always a warning when running gmt on Windows:
gmt: Warning: failed to release lock (Error <158>: The segment is already unlocked.)

I believe this warning can be fixed by setting FLOCK to on, but I know nothing about file locking. Maybe @joa-quim can help here.

I don't think there are file locking's on Windows. Again, I've seen that type of warning before. It happened when gmt tried to delete a temporary file but that file was not yet closed. However, I do not see that warning, so once again I don't know how to help.

@seisman is the warning happening to you locally?

@seisman is the warning happening to you locally?
Yes, it happens locally too.

@leouieda As the file lock warning doesn't affect GMT's functioning, we can ignore it at present. I think the PR is good to merge.

:+1: @seisman I just have to bump the build number. After that, we can merge then.

authors: conda-forge-linter joa-quim leouieda seisman

repo: conda-forge/gmt-feedstock


text:
FIX: Set python_min of Python 3.8

Resolves https://github.com/conda-forge/hatchling-feedstock/issues/47
Required to fix https://github.com/conda-forge/pyhf-feedstock/pull/28#issuecomment-2464060369

Description

Use python {{ python_min }} syntax for the python requirements for noarch python recipes.

c.f. https://conda-forge.org/docs/maintainer/knowledge_base/#noarch-python

Add recipe/conda_build_config.yaml to override the global python_min with hatchling's python_min of 3.8.
Install with recommended --no-deps --no-build-isolation options to ensure build dependencies are correct.
Update to pypi.org.
Bump build number.

Checklist

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

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

No valid build backend found for Python recipe for package hatchling using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.

No valid build backend found for Python recipe for package hatchling using pip. Python recipes using pip need to explicitly specify a build backend in the host section. If your recipe has built with only pip in the host section in the past, you likely should add setuptools to the host section of your recipe.

I assume that build backends are immune from this. I'm not sure if there is some way to indicate to conda-forge that they are self sufficient.

@conda-forge/hatchling this is ready for review.

Thanks @ofek. Can I also get you to :+1: https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/901 ?

authors: conda-forge-admin matthewfeickert

repo: conda-forge/hatchling-feedstock


text:
MNT: Re-render the feedstock

Hi! This is the friendly conda-forge-admin automated user.
I've re-rendered this feedstock with the latest version of conda-smithy (1.1.2) and noticed some changes.
If the changes look good, then please go ahead and merge this PR.
If you have any questions about the changes though, please feel free to ping the 'conda-forge/core' team (using the @ notation in a comment).
Remember, for any changes to the recipe you would normally need to increment the version or the build number of the package.
Since this is an infrastructural change, we don't actually need/want a new version to be uploaded to anaconda.org/conda-forge, so the version and build/number are left unchanged and the CI has been skipped.
Thanks!

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-admin conda-forge-linter

repo: conda-forge/ipaddress-feedstock


text:
Test (do not merge)

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: conda-forge-linter traversaro

repo: conda-forge/irrlicht-feedstock


text:
Update for CUDA 12.1.1

xref: https://github.com/conda-forge/cuda-feedstock/issues/11

Thanks Alex! 🙏

authors: adibbley jakirkham

repo: conda-forge/libnvjpeg-feedstock


text:
Revving build number b/c I may have too quickly merged previous one

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

authors: conda-forge-linter mhearne-usgs

repo: conda-forge/mapio-feedstock


text:
Updated build number to trigger new build to have updated description

New PR because the previous one failed with an HTTP error.
@conda-forge-admin, please rerender
Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Hi! This is the friendly automated conda-forge-webservice.
I rerendered the feedstock and it seems to be already up-to-date.

authors: SekouD conda-forge-linter

repo: conda-forge/mlconjug-feedstock


text:
move build from user repo to conda-forge

@conda-forge/core please copy this build
https://anaconda.org/freecad/occt/files?version=7.4.0
to conda-forge. azure has failed due to missing storage:
https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=192627&view=logs&j=a70f640f-cc53-5cd3-6cdc-236a1aa90802&t=f5d15007-a01c-5ad8-c9ce-4d519d3b275f&l=11217

You can use D: in azure by overriding, azure: settings_win: variables: CONDA_BLD_PATH: "C:\\bld\\" in conda-forge.yml and rerendering.

D: is already used.
https://github.com/conda-forge/occt-feedstock/blob/4374f9e78292e095d03e305cb3549e71d7638cc7/.azure-pipelines/azure-pipelines-win.yml#L17

Sorry, can you use C:?

thx

We don't have this documented. Would you be able to send a PR to add this to docs?

authors: isuruf looooo

repo: conda-forge/occt-feedstock


text:
Add missing yum_requirements.txt

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter stuarteberg

repo: conda-forge/openconnect-feedstock


text:
The windows builds look really suspect

Comment:
I'm wondering why the windows builds were merged in haste without discussions when previous questions were raised to @conda-forge/core regarding their incompatibility with the larger ecosystem.
Lines that download other executable such as this one
https://github.com/conda-forge/openfast-feedstock/pull/46/files#diff-54cf74e113dd3f6d11e092fdb1d888ec82c69bdafbb15cfb6570c83ecad28f33R3

Are not really OK in the conda-forge ecosystem.
I think it would have been important for that build to ping somebody from conda-forge/help-c-cpp  to ensure that things are on the right track.
Please refrain for future merges to the conda-forge repository and lets wait for this particular discussion to be resolved.
Particularly, I am worried about downloading parts that are critical to the windows build in the bld.bat script.

The referenced PR also removes a maintainer from the feedstock without any mentions on "why".

@deslaughter could you please provide some more background here?
Asking as it appears you are the author of PR ( https://github.com/conda-forge/openfast-feedstock/pull/46 ), which is what Mark is asking about above

@jakirkham, @hmaarrfk the OpenFAST developers have struggled for a long time to build this software on Windows using conda-forge. The main difficulty is finding a modern Fortran compiler for Windows as the default one is not compliant with the 2003 standard. Unfortunately, the LLVM Flang compiler, which is used by SciPy, is not yet ready for production use (did not successfully compile OpenFAST because it is missing features). The lack of a Fortran compiler on Windows seems like a known issue (https://github.com/conda-forge/conda-forge.github.io/issues/1044). The best solution that I could find was to use the Intel oneAPI compiler. I agree that downloading the Intel oneAPI compiler in the bld.bat is not the ideal solution, but it will work until Flang is ready to use. Please let me know if there is a better solution available, and I'll be happy to switch to it.
@xhochy the maintainer was removed in the PR because he is no longer active on the project. I should have explained this change.

Thank you for working to address it.
1 year later i find time to reply:
The order in which things is done matters.
You can explain your challenges, then ask if the proposal is OK to merge.
Ultimately, some things are under different licenses and can introduce ABI incompatibility.
When doing things that are strange you can contact @conda-forge/help-c-cpp can get you knowledgeable people in the C/C++/Fortran world.
Please try to communicate challenges in the future.

authors: deslaughter hmaarrfk jakirkham xhochy

repo: conda-forge/openfast-feedstock


text:
Development version 2024.4.0 (20240717)

Checklist

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

@conda-forge-admin, please rerender

repo: conda-forge/openvino-feedstock


text:
Release 3.35.0

Checklist

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

Fixes #119 an closes #120
120 Colundt be rendered since we had two summaries in the recipe. One is removed with this PR

@conda-forge-admin, please rerender


text:
[ci skip] remove user @hadim

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@xhochy FYI as I don't really use that package myself and unfortunately lack bandwidth to maintain it.

authors: conda-forge-linter hadim

repo: conda-forge/pdm-feedstock


text:
Add intel-pti

Checklist

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

@isuruf we want to add libpti to the conda-forge as a part of this repo, but not sure about naming convention.
This one consist of two packages libpti for the headers/development and libpti0 for the library iself.
Here are some variants we've been thinking but not sure which one to chose to in sync with conda-forge best practices:

libpti0, libpti as a name of library
libipti0, libipti - same as above, but i for intel, similarly to impi_rt
libintelptigpu0, intel-pti-gpu - as repository path. However @mschilling0 suggest adding lib/library to the name.

Could you please clarify which path we should go. I have similar question about https://github.com/intel/libipt - what package name should be added to the conda-forge (as a PR to staged-recipes)?

So, intel just released those package and pypi and https://software.repos.intel.com/python/conda . The name is intel-pti. Should we name it then intel-pti and intel-pti0?
cc: @conda-forge/core @oleksandr-pavlyk @mschilling0

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

The outputs section contained an unexpected subsection name. skip is not a valid subsection name.

For recipe/meta.yaml:

Jinja2 variable references are suggested to take a {{<one space><variable name><one space>}} form. See lines [17].

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

Jinja2 variable references are suggested to take a {{<one space><variable name><one space>}} form. See lines [17].

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

Recipe maintainer "mschilling0" does not exist

For recipe/meta.yaml:

Jinja2 variable references are suggested to take a {{<one space><variable name><one space>}} form. See lines [17].

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

Jinja2 variable references are suggested to take a {{<one space><variable name><one space>}} form. See lines [17].

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

authors: ZzEeKkAa conda-forge-admin

repo: conda-forge/pti-gpu-unitrace-feedstock


text:
Release v0.11.1

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

authors: cheginit conda-forge-linter

repo: conda-forge/pygeoogc-feedstock


text:
Update URL

Checklist

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

@conda-forge-admin, please rerender

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: ChristopherHogan conda-forge-linter

repo: conda-forge/pymeep-feedstock


text:
FEAT: Add aarch64/ppc64le

Checklist

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

This summarize the issue with ring. We may contact upstream or test a recipe patch or forego ppc64le support

repo: conda-forge/qcs-sdk-python-feedstock


text:
v2022.9.18

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: conda-forge-linter paulsaxe

repo: conda-forge/seamm-dashboard-feedstock


text:
version bump to v6.12.0

Checklist

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

@conda-forge-admin, please rerender


text:
Update 0 9 4

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

authors: TonioF conda-forge-linter

repo: conda-forge/xcube-cci-feedstock


text:
arm osx migration

Checklist

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

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Fix #7

@xorg-libxrandr this is ready to be merged. Thanks!

Thanks for the review @pkgw - it should be ready to go now.

authors: Tobias-Fischer conda-forge-linter

repo: conda-forge/xorg-libxrandr-feedstock


text:
ENH - Reevaluate environment selection workflow

Context
Derived from https://github.com/conda-incubator/conda-store-ui/issues/269
Right now, conda-store is performing several implicit actions that should be explicit: build a new environment, activate the newly created environment, etc.
Additionally, specific terms and workflows might need to be clearer to new users. (See https://github.com/conda-incubator/conda-store-ui/pull/271#issuecomment-1688568916)
Overall, the whole Edit/Build/Activate workflow (and UI) needs to be revised and improved.
Value and/or benefit

Improved user experience
Changes should be explicit, thus contributing to user's confidence

Anything else?
No response

Related issues:

https://github.com/conda-incubator/conda-store-ui/issues/279
https://github.com/conda-incubator/conda-store-ui/issues/248

Hey all, I wanted to add my recent experience here as a new conda-store-ui user:
I was recently trying to activate a build. When I click on an environment, there's a dropdown menu which shows the various builds for the associated environment.

The fact that there is an "Active" and "Available" label next to each build suggests to the user that there's a way to activate a build for an environment by choosing a build from the dropdown. The actual way to activate a build is to click the edit button on the other side of the page:

and this will reveal a hidden "Change environment version" button next to the dropdown. You can now select a new build and click the button to activate a build:

This might sound ridiculous to an experienced user but I spent a bunch of time trying to figure out if choosing a different item from this dropdown would activate the build. I couldn't tell if the conda-store-server was just taking a while to activate a build, or whether the UI was glitching out and not updating the Active/Available annotations next to each build in the dropdown menu, or whether it was something else. I spent a bunch of time watching the terminal running the conda-store-server before I realized there was just no API call being made that could be setting the active build (though there are a bunch of API calls made to get the list of installed packages when you change the dropdown selection).
I think revealing the hidden "Change environment version" button is harder to find than one might expect because

The dropdown suggests a way to change the build that isn't quite what you need to do.
When I think of editing an environment, I think of changing the packages in the environment, so I didn't immediately click on the Edit button.

As a last piece of feedback - if we are going to have a button to set the active version of an environment, IMO it should use the terminology we have already established for this, i.e. it should say something like "Change active build" or similar.

authors: pavithraes peytondmurray trallard

repo: conda-incubator/conda-store-ui