Clarify process

Initially not clear whether you submit each title individually or whether you submit the whole task consisting of all titles.
Not clear whether to include all forms of entertainment or just plays.
Not clear whether to include more information than the title if the leading article is included in the announcement text, or whether to cut off the article. E.g.
"Will present a new comedy called The
Way to get Married"

These are more good examples of things we need to improve in out tutorial/FAQ text.

We're going for all selections on a page, then submit. Hopefully this will be a bit more clear once the 'Confirm on Submit' function is added (see https://github.com/LibCrowds/vue-pybossa-frontend/issues/150).

To include only plays or other performances: we have actually discussed this one quite a lot and I'm still unsure on the choice of language. Should we call them plays, performances, events etc., and do we want to deal with only the plays for now or the other 'performances'. There are so many strange things in there - a performance by a dog was spotted recently - that we decided to keep things 'simple' and focus on just the plays for now. We might need to have another look at this.

In the end this isn't hugely important as the selections are primarily so that people know what to transcribe later (although we might also try to use them for OCR training). But again, pointing out anything unclear is all really useful to help us write our tutorial text.

It's also not clear if you want the punctuation included such as final full stop or quotation marks.
What is the point of this text on the front page "see The Way To Get Married; or perhaps you may just prefer to see The Romp? There’s something of the Kent coast in Ways and Means; or A Trip to Dover."

Again, in terms of drawing the selection boxes, it's not really important as these essentially just lead into a subsequent set of tasks where we ask people to transcribe the marked titles. It's a way of breaking down the huge amount of info on the page into far smaller tasks. In the transcription tasks we are currently keeping things simple and asking people to just type what they see. We can always run a cleanup process later if we decide we don't want punctuation etc.
It's a difficult balance between writing guidance that is thorough enough for those that think of these things and that which gets incredibly complex and potentially intimidating for others (only include the semi-colon if it preceeds an alternative title, including exactly one space after the semi-colon and only capitalising the next word if it's a proper name...and so on).
I'm not sure I know what you mean by 'the point' of the text...I suppose to give people a sense of what they might discover while contributing to the project, the full text being:

Mark the titles of plays in historic playbills. Look out for playbills for comedies and farces; see The Way To Get Married; or perhaps you may just prefer to see The Romp? There’s something of the Kent coast in Ways and Means; or A Trip to Dover.

I was considering changing these to a more direct description of the task objective (and probably prefer that option)!

Ok, thanks. Re: text. I don't understand the point of including that text and would agree that changing it to a more direct description of the task objective would be better.

It gets my vote! We'll have a chat about this on our end. I think it basically came from trying to squeeze some contextual text onto that page but it does seem to confuse things a bit.

@alexandermendes we need to sort out the category descriptions cos they're not really working - one of the artefacts of changing architectures, so exactly the kind of issue that we were hoping would surface in asking for feedback. If we can have more than 100 characters in the description it'd be a lot easier.

@alexandermendes how much text can we include in the task description?

Thanks @Ada1000 @corined - I've submitted a pull request (https://github.com/LibCrowds/project-iiif-annotate/pull/40 i.e. made some changes that could be updated onto the live site) with some tweaks based on your comments. This is exactly the useful kinds of feedback we were hoping for, so thanks for taking the time to respond!

@mialondon so the category descriptions were intended to be a per volume description (category = volume, project = collection of tasks). We're now trying to force them in to the project descriptions just to make use of the text, which I'm not really convinced by. I think these should basically be the task objectives - "draw rectangles around the titles etc.", rather than "Look our for title x".
You cou can have 255 characters in the project descriptions. No limit on the category descriptions.

Also remember that we will have a tutorial that we can fill with as much detail as we like. I'm getting a bit wary of including every detail in those task objectives. It now says don't include song titles but what about comedic interludes, or addresses of thanks? If we include everything here it's going to quickly fill the screen!

@alexandermendes information always invisible on the screen is a gazillion* times more accessible than information in a tutorial or help screen. Usability testing will help us work out the minimum text needed to cover most situations and what text can be delegated to help for those who really need the details. *technical term
If we can sort out how volume descriptions display then that puts less emphasis on the project descriptions, but similarly, anything hidden behind a mouseover is much less likely to be seen. The model is still https://transcription.si.edu/browse?filter=all but we're not there yet!

Ok, so a couple of weeks ago we did have the category descriptions always appearing at the top of the screen but we changed this to bring the project list further up to the top (see https://github.com/LibCrowds/vue-pybossa-frontend/issues/110).
The new model is to show category descriptions like this:

So how should we display them now?
Remember that the difference with that Smithsonian model is that they only have one project per volume, whereas we (potentially) have many, which is one of the core reasons we redesigned this whole thing, to be able to bundle things up by category, then specific task sets.
We will have a browse all feature soon.

P.S. this was the old model! https://github.com/LibCrowds/vue-pybossa-frontend/issues/27

Notes moved to trello board.


2D tensor changed to 3D tensor, runtime error

I tried to change 2D tensor into 3D tensor, so it can be feed into 3D Conv. The code are shown as follows:
y = self.con1x1(x) # 2D tensor
y = y.view((-1, 96, 16) + y.size()[2:]) #2D tensor changed to 3D tensor
error:

Thank you so much for you kind help.

@ZealACMer Are you sure that the number of samples is 16? 3161088 is not equal to batch96162828. I  think it's better to check the shape of "y" after 2D tensor and figure out the problem. Let me know if you still didn't find the problem.


Repeat Direct Payments

I'd like to add support for repeat payments.
This uses RelatedVendorTxCode, RelatedVPSTxId, RelatedSecurityKey, RelatedTxAuthNo in exactly the same way the refund does.
Before I do that, I'd like to get your input on which way you'd prefer this to be done. I see two options:

Create new request for repeat. So DirectAuthorizeRepeatRequest and  DirectPurchaseRepeatRequest etc.
Make the DirectAuthorizeRequest and  DirectPurchseRequest able to accept a transactionReference like RefundRequest does.

Option 1 would obviously be most stand alone but I think 2 probably fits most into the spirit of Omnipay with the way this has been done in, for example, Stripe.
@judgej let me know which you'd prefer and I'll get on with it and open a PR.

I think it makes more sense to allow the related data to be sent as part of the DirectAuthorizeRequest and DirectPurchaseRequest (option 2). As you mentioned other gateways are already doing this method.

Perfect. I'll go with that approach.

:+1:

Support has been added for this in PR #66, which is now merged into master, so this issue should now be closed.

The version in PR #66 takes the other approach: creating a new message for repeat payments rather than piggy-backing on the existing DirectPurchase giving us a $gateway->repeatPayment() method.
Q: should that have been repeatPurchase() to keep the OmniPay terminology?
Q: does a repeatAuthorize() make any sense here?

Sage Pay supports both a REPEAT and REPEATDEFERRED transaction type. This translates to an OmniPay Purchase and Authorize, but using the saved credit card details of the previous transaction. So:
a) A repeat payment is not the whole story - we have repeat authorisations too, that need to be released (captured) later.
b) Since we have repeat authorisations, that would presumably be called repeatAuthorize then it makes sense for the authorize+capture to be repeatPurchase (OmniPay terminology) rather than repeatPayment (Sage Pay terminology).
The currency is also hard-coded in PR #66 to GBP and that certainly needs to change.
In addition, many of the details in the original transaction can be changed for the repeat transaction, for example a different delivery address (but not customer details, since they are linked to the card), or a new basket (needed if the repeat amount is different, or if needing to sync the basket with a back-end accounting package). I think those items need to be supported by the repeat transaction.
PS #66 may be working in production, but it is limited in scope so works in a very specific environment, and IMO needs to be extended a little. What is there is fine so far, so there is no need to revert, but I would deprecate repeatPayment() for repeatPurchase().

Some of the features of PR #60 could be merged in with PR #66. For example, if calling Direct purchase() with a previous transactionReference then there is no reason why it can't return a DirectRepeatPurchase message automatically, instead of a DirectPurchase message. So we could have the best of both worlds. Keeping them as separate messages (purchase and repeatPurchase) makes sense due to the different set of parameters that are supported or are required vs optional.

I've created a PR to cover some of the above points. It does not yet include the addition fields that REPEAT and REPEATDEFERRED support (new shipping address and ItemBag/cart/basket).

So, PR #66 + PR #68 covers everything PR #60 covered. It does not extend DirectAuthorizeRequest and DirectPurchaseRequest because it supports a smaller subset of the parameters that those messages support. It provides repeatAuthorize and repeatPurchase.
Feel free to try it out and give feedback - hopefully we can get a release number fore this soon, as there is a backlog of other changes to go in.

transactionReference needs to go in as an alias for relatedTransactionReference, with the latter deprecated.

Don't know how I missed it, but there are four other related* methods there too. I should do the same with those.

In release 2.4.0


Pin httpx to latest version supporting proxies

@MatteoEgmont do you think the fact that #11 run successfully  means that the fix worked?

@platisd yes, I tested in a repo where we use your action, running with
    steps:
      - uses: platisd/openai-pr-description@175d40a9cfe9c0e9809139ce28f7dc16147a1717

and the execution was successful

Nice, will merge then. Thanks for the help.


allow for marking acquisitions completed

and outputting these to a new sheet with metadata about acquisition (uid from bluesky, timestamp minimum), remove option to delete acquisition, make this the default option.  also remove plan history potentially?

as with the current bar object, I think we will need to store 'completed_acquisitions' as a special key in each sample, and loop through them as we do with acquisitions to output to a separate sheet.

this will certainly need some tweaks to the main rsoxs code as well - in fact most of the changes may be in that repository - but it is easier to track as part of this project

Hey Eliot, adding my notes from our conversation re: this: to your list above:
Goal: Revision to spreadsheet ingest/output scheme for workflow improvements.
Desired Qualities:

Reformulate spreadsheet as a 'living' document that only gains information as scans progress (no deletion)
Successive versions of the sheet should either preserve the initial formatting/rules or be easy to copy/paste back into the initial sheet format
Enhance output metadata with information about scans that have run already

Possible Task List and ideas for Implementation:

[ ] Revise Sample Spreadsheet Format to include new sheet "CompletedAcquisitions". (Possibly rename "Acquisitions" to "PlannedAcquisitions") Also may be a good time to address #17

[ ] Define the list of all the metadata columns that will be input or output. I suggest these just be added into the spreadsheet "SheetRulesAndMetaData" as new rows so that the documentation exists for users to understand what they mean.

[ ] A possible implementation:

in defaults.py, make 3 template dicts of metadata parameters that you will either import or export for each acquisition and provide default values (blank string or whatever).

When building the dict for import or export start by initializing it to the defaults value.

When exporting, set the excel writer to append mode and export in two stages. (1) First use df.to_excel(columns=list([relevantDefaultDictionary])) to output the columns that need to match the input spreadsheet in order. Then  (2) use df.to_excel() again for any extra columns (will require you sub-setting out the already exported columns)

so we need a blank default xlsx file that we can copy and append to?  this would contain all of the header stuff on bar and acquisitions, the instructions sheet and the lookup sheet, with all of the validation rules already intact?

I'm not sure I see how that could work to be honest.

So two ways to do it I think:
Easy way is to have the users manually fill in the first sheet as we do now.
Then the code outputs sheets WITHOUT the fancy excel rules, but the columns in the same order.
Then the users copy-paste the data cells into the formatted rule spreadsheet and proceed from there.

OK, I can definitely see how to 1.) put columns in the same order as the example dictionary 2.) add extra columns that are not in the default dictionary, but do have information that will populate if you add them.

If i understand it correctly, when you do list(dictionaryName) it gives you a list of keys in the order they were added.
So if you are careful about how you add the columns in the first place, then always do df.to_excel(columns=list(dictionaryName)) it should give you all columns exported in order.
You could probably actually just do the export in one step then.

well, I can't get a default order to work, cause it has to be identical for each, which means every acquisition is wrong.  I tried to get the column order in the pandas dataframe to match the input order, but that doesn't seem to propagate through.  I might try again later

Ok!  I figured out how to fix the order and make the columns the same as the input.  also, acquisition marking rather than deleting is done.  I think I will close this unless we can think of a way to add in the rest of the instructions and stuff somehow

I think this is good for the indefinite future, given that this will be replaced eventually with the queue server etc. scheme.
If the excel sheet survives past 2023-3, it would be worth revisiting the rest of instructions etc.

Just leaving that there....


Hyprland workspace buttons can't remove padding

Summary
The workspace module on my waybar seems to be occupying too much height. I have exclusively set the padding and margin to 0. And the only margins that I can see on css are applied are on the x-axis, which should not be affecting height. The code I am using for module config and styling is below. Module is within the left panel.
I want the buttons to be having zero padding within them.
Code
"hyprland/workspaces": {
        "disable-scroll": true,
        "all-outputs": true,
        "warp-on-scroll": false,
        "format": "{icon}X",
        "format-icons": {
            "urgent": "",
            "active": "",
            "default": ""
        }
    },

* {
    /* `otf-font-awesome` is required to be installed for icons */
    font-family: FontAwesome, Roboto, Helvetica, Arial, sans-serif;
    font-size: 9px;
    padding: 0;
    margin: 0;
}
#workspaces {
    background: #555555;
}
#workspaces button {
    margin-right: 2px;
    color: #ffffff;
    padding: 0;
    margin: 0;
}

#workspaces button:hover {
    background: rgba(0, 0, 0, 0.2);
}

#workspaces button.active {
    background-color: #64727D;
}

#workspaces button.urgent {
    background-color: #eb4d4b;
}

#window,
#workspaces {
    margin: 0 4px;
}

/* If workspaces is the leftmost module, omit left margin */
.modules-left > widget:first-child > #workspaces {
    margin-left: 0;
}

/* If workspaces is the rightmost module, omit right margin */
.modules-right > widget:last-child > #workspaces {
    margin-right: 0;
}

Screenshots:
With hyprland workspaces module

Without hyprland workspaces module

Something from hyprland/workspaces might have a min-height. Try setting * { min-height: 0; } in your css.
If that doesn't work, you can look at the css properties with env GTK_DEBUG=interactive waybar.

@jramrath
Thanks a lot that solve the issue for me we should be good to close this now.


[Bug]: Buy XOR widget is not displayed until you open edit view when we restart the app

Preconditions
Buy XOR is ON
Steps to reproduce

Launch the app
Check the availability of Buy XOR widget
Go to the edit view
Go back and repeat the second point

Actual behavior
Buy XOR widget is not displayed until you open edit view when you restart the app.
https://github.com/user-attachments/assets/b13122ab-2245-41e0-b156-ce6635b01f17
Expected behavior
Buy XOR widget should always be displayed until we hide it in the view details.
Environment
{"label"=>"Development"}
OS version
17.7
Additional context
No response

This issue is still repro on 3.8.7(2) version.


Fix(web, web-twig): Checkbox indeterminate

Description

In the demo, there were incorrect IDs in the JavaScript to target the checkboxes

Additional context

coverage: 96.838%. remained the same
when pulling de57cddb160d11d2613406e6d90a2f19e346b75d on fix/demo-checkbox-indeterminate
into 15530707adbb58e785d141abd6fb29da2b0b5896 on main.

coverage: 96.838% (+19.1%) from 77.727%
when pulling a65141351987ac6c76ee61adbed4bc313f239615 on fix/demo-checkbox-indeterminate
into 2d35aeed69259521f527f7d092c2f800f3bce198 on main.

coverage: 77.727%. remained the same
when pulling a65141351987ac6c76ee61adbed4bc313f239615 on fix/demo-checkbox-indeterminate
into 2d35aeed69259521f527f7d092c2f800f3bce198 on main.

Commit: Fix(web): Id of Checkbox component indeterminate demo


Update Identity Flows for IntelliJ and Authorization Code credentials

Fixes IntelliJ Auth flow when issues are encountered with parsing AuthMethodDetails.json file.
Fixes Authorization Code auth flow when client secret is specified.

API change check
API changes are not detected in this pull request.


[Feature request]

can we bring responsiveness using material design concept or bootstrap in hyperapp. It would be an awesome combo.

How is this even remotely fitting the scope of hyperapp?

You have mentioned the word "UI applications" . You are telling "modern applications" and not even considering Elements of UI design!

UI here means how to construct and manage state for a UI. The Design aspects are up to the developer to sprinkle in. Hopefully that makes sense 😄
Vue/React/Inferno/Elm/etc.. are ways of constructing a modern UI (trigger an event on the DOM, state changes, dom updates).
Architecture vs. Design
From the React website:
React
A JAVASCRIPT LIBRARY FOR BUILDING USER INTERFACES

@vikaskyadav can we use material design or bootstrap with hyperapp?

Sure! You should be able to use any CC framework you like with HyperApp. Here is a trivial example with Bootstrap.
Let me know if this answers what you were asking.

@selfup . Yeah, I misinterpeted UI for designing framework. Understood ! Thanks. :)
@jbucaran Thanks man. That sums up the utility of hyperapp. Awesome job people ! :)

@vikaskyadav Thanks for the kind words :)
Think we can close here?


TT Bundling example doesn't compile

This page has an example. It doesn't compile when I click "run". So if the example doesn't compile, then what's the point with reading the example? What's the point with reading about something that doesn't even work?
Please fix the example so that it actually compiles, and then the reader may actually start learning something from that example.

Next time you report an issue be aware of your tone. The wording of this issue is completely unacceptable and if it wasn't a technical one I wouldn't have considered fixing it given how rude you were.

Next time you report an issue be aware of your tone. The wording of this issue is completely unacceptable and if it wasn't a technical one I wouldn't have considered fixing it given how rude you were.

I'm sorry if I came across as being rude. That wasn't my intention. My intention was to clearly communicate what the problem is and why it's a problem and what I think should be done to solve it, and why my proposed solution would be valuable to the reader. If you could rewrite the issue report that I made, how would you formulate it instead?

Asking What's the point comes over as very aggressive, you are basically questioning why the chapter was written in the first place somewhat implying the chapter being completely pointless, thats what made it rather rude to me.

Please fix the example so that it actually compiles,
is a very commanding tone

and then the reader may actually start learning something from that example.
This goes back to my first point, implying the chapter as written is pointless

Asking What's the point comes over as very aggressive, you are basically questioning why the chapter was written in the first place somewhat implying the chapter being completely pointless, thats what made it rather rude to me.

Please fix the example so that it actually compiles,
is a very commanding tone

and then the reader may actually start learning something from that example.
This goes back to my first point, implying the chapter as written is pointless

Thank you for the advice. Due to my personality (INTJ), I have low awareness of when I'm being rude, and high awareness of flaws in systems, and high focus on pragmatism and low focus on emotions (especially that of other people). I appreciate your feedback and explanation to help me increase my awareness in this area. Please don't feel like I don't value the content you're producing. It's very valuable, but the more I focus on what can be improved, the harder it is to focus on the things that are already good. And the former is my primary focus due to my personality.
I will try not to say "what's the point" in the future. If I say something in the future that you perceive as rude, then:

understand that I have no bad intentions and I have a naturally low awareness of these things
feedback and explanations on what I can do better in this area are appreciated, as is the work that you do with the Little Book of Rust Macros


Add SQL transactions support

This should be implemented in Sql::Query.
Here's the related Sequel documentation: http://sequel.jeremyevans.net/rdoc/files/doc/transactions_rdoc.html
I'd say to not support/document Sequel::Rollback. Using exceptions for control flow is always a poor choice. If an exception is raised as side effect, the transaction should be rolled back.
transaction do
  raise `Sequel::Rollback` # this will rollback anyway because of Sequel, but it's a poor style that we shouldn't encourage
end

transaction do
  some_dangerous_method! # if this raises an exception, the transaction should be rolled back
end

The second style is the one that we should encourage/document.
/cc @stevehodgkiss @joneslee85

something like that using sequel like the link provided:
def transaction(options = {})
   DB.transaction(options) do
      yield # if a exception is raised here, then the rollback is fired.
   end
end

@AlfonsoUceda yes, but we don't have a DB constant. SqlAdapter holds an instance variable called @connection, which is the same Sequel type of DB.

Because the only high level object that we expose to developers is a repository, we should consider to add that method there. Example BookRepository.transaction { ... }.

@jodosha can you assing to me please? I'm going to do a PR later or in this weekend

@jodosha I have a dude with the implementation, If you use the Repository.transaction I think you will use the repository inside, isn't it? I give you 2 examples but I think it should be explicitly done.
what do you think?
UserRepository.transaction { UserRepository.first }
# or
UserRepository.transaction { first }

@AlfonsoUceda It should be a public method and context free (first option in your example).
A bit of explanation, this can be useful for complex scenarios where several entities needs to be persisted atomically, and eventually rolled back in case of error.
class Signup
  def initialize(params)
    @user = User.new(params[:user])
    @account = Account.new(params[:account])
  end

  def call
    AccountRepository.transaction do
      AccountRepository.create(@account)
      UserRepository.create(@user)
    end
  end
end


[W08H02] added behavioral and structural tests

Added structural behavioral tests which include the Artemis tests and examples aswell as own edge cases

@Mauri2070 can you take look at the structural tests?
Originally the README states

To ensure the solution is not getting revealed, the tests should be Input/Output-Tests only.

However, we've deviated from this statement in some exercises. Since this is yours I suggest you should decide.
As far as I've seen the structural tests only test methods/attributes that are required by the assignment anyway so I personally don't see why this should be a problem.

Thanks for the tests! 🎉
Have you used auto-format for the code? I'm using VS Code and I could format some files. It would be great to have all files formatted so that when someone else makes a new change and uses auto-format not the whole file is formatted.
Otherwise, LGTM 👍

Thanks for the review! 🙏
And yep, i've auto-formatted the code, but I used IntelliJ's formatting (and additionally a custom Code Style) which might deviate from VS Codes.


mitotic cell cycle arrest phenotype

I was looking fro a term for cell cycle arrest  with 2N DNA.
I  got mitotic cell cycle arrest phenotype, and none of the children fit, so I though the term mustn't exist.

then I searched on 2N and found the term I wanted
abnormal mitotic cell cycle arrest with replicated DNA
so which term is it under here?  (I checked them all now I think, but they all seemed a bit wrong)
For this phenotype it is G2 arrest, but I'm not sure how you could be sure about that from the experiment. This could be just because I'm rubbish at reading flow cytometry data. Isn't it possible the cells could be in interphase  but not yet in anaphase, wouldn't that look the same as a G2/M transition block?

FYPO:0000444 is intended precisely for those cases where you know DNA is fully replicated but you can't nail it down any more specifically.
I'll have to have a closer look at links next time I'm doing ontology work - probably something I hoped would be reasoner-inferred isn't, so I'll review manually asserted links.

similarly, I couldn't locate
abnormal cell cycle arrest in mitotic metaphase
under
mitotic cell cycle arrest phenotype

Added link 'abnormally arrested mitotic cell cycle progression' is_a 'mitotic cell cycle arrest phenotype' (FYPO:0000502 is_a FYPO:0004040), which will give FYPO:0000444 a path.
The second example already had a path to 'mitotic cell cycle arrest phenotype' via 'cell cycle arrest in mitotic interphase', but will now have another.
edit file: b6f863a875ac7c9704d2ffe278d196a9a4e8b7de
release: 9154d65b31275615b2675821e618d59e667f3b83


table_notify function causing slow perfomance on large data inserts

PGSync version: 1.1.27
Postgres version: 12.6
Elasticsearch version: 7.11.1
Redis version: 5.0.3
Python version: 2.7.16
Problem Description:
Large data sets are causing the INSERT query in Postgres to take quite a long time to complete, due to the trigger that is being called after every row insert.
With Trigger + notifications, 11,000~ rows takes approximately 9 seconds
Without trigger + notifications, 11,000 rows takes approximately 1 second
This grows quite exponentially with large data sets being imported.
Schema and pgsync configuration can be found in #88
Error Message (if any):

Good to know thr performance has improved.
This log statement has been causing a bit of confusion lately I admit.
Polling db sq: 108,308 item(s) is simply a log indicating that 108,308 records have been synced so far from db to es.
Perhaps we should re-word this in a different way

Closing this for now. Feel free to reopen if you feel there is an area that needs attention. There is potential for other performance improvements in future


Improve behavior around compose box closing when scrolling

Apparently, if you open the compose box via touching a message, and then scroll around, it doesn't close, but if you open it with the pencil icon and scroll around, it does.
I think we probably want the scrolling behavior of closing the compose box to be consistent across different ways of opening it, BUT we want to have the compose box stay open in the event that the user has actually hand-written any text into it (whether it be a stream, topic or message body).  So I think we maybe just need to use a slightly different state machine for tracking whether the compose box should be closed.

Hi! I would like to work on this bug.

Go for it!

Looking forward to your pull request, @reached-ankita! Please come visit us in https://zulip.tabbott.net/#narrow/stream/android if you're having any trouble submitting it. :)

Hi! I made a pull request here ! https://github.com/zulip/zulip-android/pull/198


CancellationToken implicitly converts to a boolean

There is an issue with this rule as passing the token can cause it to be implicitly converted into a boolean, resulting in a wrong overload of a method being chosen, having a major issue with DbContext.SaveChangesAsync(cancellationToken) resulting in a call to DbContext.SaveChangesAsync(bool acceptAllChangesOnSuccess, CancellationToken cancellationToken = default) resulting in either a stackoverflow or a duplicate execution of a Save function i'm trying to override.
CancellationToken's implicit convertibility to a boolean is a pretty major design flaw considering most things have it as an optional parameter meaning any immediately preceding overloads with bool type can cause major headaches.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: a66f369e-7e07-7a55-3366-f9da375dac55
Version Independent ID: 1db27eb6-fd57-c668-0af9-3588b117c731
Content: CA2016: Forward the CancellationToken parameter to methods that take one (code analysis) - .NET
Content Source: docs/fundamentals/code-analysis/quality-rules/ca2016.md
Product: dotnet-fundamentals
GitHub Login: @carlossanlop
Microsoft Alias: calope

CancellationToken's implicit convertibility to a boolean is a pretty major design flaw

That's true, but it's also true that this convertibility (neither implicit nor explicit) is implemented within .NET. See sharplab, which results in compiler errors.
Or when looking at this sharplab you can see that the correct overload is picked.
So can you please show a code example that demonstrates the problem you are stating, as (at least) I can't follow to what you are refering too.

After looking it again after this, the issue i was experiencing was in fact a case of the virtual base function without the boolean calling the one that has it with true.
For regular use no problem, but if you override them or worse yet have a partial class that overrides it, calling it with base.SaveChanges will infact result in two calls to save.
This is resolved by implementing the overrides for the boolean:less overloads calling your own override manually copying the behaviour of the base virtual function.
So it isn't as much a bug but a confusing design issue that can arise with redirecting virtual functions.


Expose setAuthenticator method of HttpURLConnection for Java 9+

Author: Nancy Bosecker<EMAIL_ADDRESS>Date: Fri Sept 18 16:24:00 2020
For Java 9+, allow clients to set an authenticator on HttpURLConnection class, which allows clients to avoid use of the default Authenticator whose cache is hidden and cannot be cleared. See https://bugs.openjdk.java.net/browse/JDK-8169495
Signed-off-by: Nancy Bosecker<EMAIL_ADDRESS>

Started from scratch, still getting the failure even though I add the info to the commit message.

For ECA check to pass the git committer email and Signed-off-by should match the email ID registered with Eclipse. Your committer email is currently set to your company email id. Use git log to verify this information.
To fix the current PR follow the below steps:
git commit --amend --author="Nancy Bosecker<EMAIL_ADDRESS>--no-edit
git push --force-with-lease

This will amend the commit with the correct email id and push the changes to your fork.

Done! Thanks for your help.

Doesn't seem like this failure is related to my changes - how can I re-run?

Thanks for the feedback. Updated by using a utility class with static method, no-op for JDK 8 and set code for JDK9+.

Any feedback on this?

Updated the formatting and the version number, thanks for your help.


Move padding to Python

Utilizing the efficient of numpy, the execution time of padding a matrix from 4096x4096 to 8192x8192 only takes 0.06 s.

It now speeds up much by rewrite the paddingInput (in a261e1c). No need to modify the architecture


Update istat-menus to 5.32

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if updating a cask:

[x] If the sha256 changed but the version didn’t,
provide public confirmation (How?): https://www.virustotal.com/en/file/d3a2e7121e8fedba6310c1c66b09a8dfd3d0f42b3daa66de3854246a6ec7dfdd/analysis/1502171454/

@Maarc I've updated your PR to include codesigning verification via VirusTotal.


RPC Call in Blender for AnimHost

As a developer, I want to be able to Trigger functionality in AnimHost from Blender, so I can trigger generation of animation, transmission etc.
Acceptance criteria:

[ ] Implement RPC call sending in the Blender TRACER Plugin
[ ] Implement buttons sending an animation request as RPC call to AnimHost as a stream
[ ] Implement buttons sending an animation request as RPC call to AnimHost as a block

Github Issues

[ ] #18
[x] #20
[x] https://github.com/FilmakademieRnd/VPET/issues/80

Use:
SceneID: 255
SceneObject ID 1
Parameter ID: 0, value 0 --> stream, value 1 --> block


Adds the byte string flag to a test condition.

This fixes tests in Windows  when username preceded by \ would result in escape sequence, for example starting with 'x'.
This is a very low priority PR because it only affects RF acceptance tests. However it could serve as an example for a fix in a particular situation. After this fix, there are only three failed tests (one of then due to lowercase/uppercase comparison in a Windows path).

Admin, can CI be enabled?

That r actually turns the name to a raw string, not a byte string. In a raw string backslash has no special meaning and it thus works well with Windows paths (r'c:\temp) and regexps (r'\s*\d+').
Although adding the r fixes the problem, a better solution here is using $outputname in the expression. This way the code works correctly also if ${outputname} is None. I can do that myself.


Erlang error: :socket_closed_unexpectedly not reported to Sentry

Environment

Elixir version (elixir -v): Elixir 1.8.2
Erlang/OTP version (erl): Erlang/OTP 22
Sentry version (mix deps): sentry 7.0
Operating system: macOS Mojave

Description
The project, I integrated sentry with, uses a custom elixir package that connects to Rabbitmq with amqp connections. Sporadically we can get errors like:
Erlang error: :socket_closed_unexpectedly
But they're not reported to Sentry. We used to use Honeybadger beforehands and they were reported normally, just trying to figure out what can be missing.
Expected Behavior
Error Erlang error: :socket_closed_unexpectedly reported to Sentry
Actual Behavior
Nothing is reported
Steps to Reproduce
A lib that connects to rabbitmq with amqp connections, connection management fails.

@islamhamdi thanks for opening an issue!
Sentry should report any crashed process, but without information on which library is being used, it is difficult to troubleshoot.
Can you link me to the library you are using?

Going to close this issue for now, but happy to reopen and investigate further with more information 🙂


spirv-opt: Loop unroller doesn't support OpConstantNull

shader.txt
If you try to execute spirv-opt <attached file> -o out.spv --loop-unroll on the attached file, the tool will crash. The reason is that LoopUnroller optimization pass doesn't support OpConstantNull instructions.
Note that the attached file demonstrates the case when the initial value of the counter
is an OpConstantNull. The same bug can be observed if we try to use OpConstantNull to limit the number of iterations or as a step of an iteration (ids %7, %13, %21 in the attached file).
The code that causes these crashes is as follows.
https://github.com/KhronosGroup/SPIRV-Tools/blob/b78f4b1518e0052491f4e7e01ace4ee915cb5de2/source/opt/loop_descriptor.cpp#L687-L688
https://github.com/KhronosGroup/SPIRV-Tools/blob/b78f4b1518e0052491f4e7e01ace4ee915cb5de2/source/opt/loop_descriptor.cpp#L712-L713
https://github.com/KhronosGroup/SPIRV-Tools/blob/b78f4b1518e0052491f4e7e01ace4ee915cb5de2/source/opt/loop_descriptor.cpp#L194-L195

@s-perron @alan-baker ping

Yes, this is a common error.  The null constant is not an "IntConstant", so it needs special handling.  We have since added functions in the constant class to be used.  These code patterns should be:
type = upper_bound->type()->AsInteger();
if (type) {
  if (type->IsSigned()) *value = upper_bound->GetSignExtendedValue();
  else *value = upper_bound->GetZeroExtendedValue();
}

This will work for integers up to 64-bit, signed and unsigned, and work with OpConstantNull.

@s-perron, added a PR.


The method of describing how to connect to a HANA server (type in ServerXYZ:30015) is out of date

The connection UI has been updated to use a port dropdown

Hi, @AdamBJ -- thanks for your observation. Is this the article you're referring to?
https://docs.microsoft.com/en-us/power-bi/desktop-sap-hana
Assigning to that author on that assumption.

Thanks! I've removed the dated screen and updated instructions.


New package: RadiationPattern v1.0.0

Registering package: RadiationPattern
Repository: https://github.com/akjake616/RadiationPattern.jl
Created by: @akjake616
Version: v1.0.0
Commit: 4e58cbbca93aad4f4d6f684f5675e81bea4ff105
Reviewed by: @akjake616
Reference: https://github.com/akjake616/RadiationPattern.jl/issues/1

[noblock] Generally, the recommendation is for Julia packages to have pluralized names. I would recommend renaming to RadiationPatterns. See the FAQ for how to rename a package.

[noblock] Generally, the recommendation is for Julia packages to have pluralized names. I would recommend renaming to RadiationPatterns. See the FAQ for how to rename a package.

Thanks for the comment. I've renamed the pacakge accordingly.

Closing in favor of https://github.com/JuliaRegistries/General/pull/112490


Add conversions between Uri and Url

Add Request::target method to get request URL.
The Uri is always turned into a string before parsing as a Url and vice versa. So this only improves ergonomics but not performance. This can be a later PR.
Open question: The URL crate has a number of dependencies on its own. Should this be an optional feature?
cc @carllerche

I believe I've read comments from Servo devs of wanting to release a 2.0 of the url crate. If so, I'd hate for the http crate to inherit that breakage. It's also kind of a big crate, which causes me hesitation about including it as a dependency here.
Is there difficulty in providing these conversions in a separate crate?

It should definitely be a feature flag, probably not on by default.
Re: 2.0, could you provide a link? It would also be possible to add conversions for multiple versions of the url crate.

Is there difficulty in providing these conversions in a separate crate?

First they are harder to find. And second they can’t use the HttpTryFrom trait as it not public.

Ah, soonish HttpTryFrom can be replaced with TryFrom! It was almost stable, it just had some last minute conversion error bugs found, I believe. When that's done, then external types can implement the trait.

When that's done, then external types can implement the trait.

I don't think so. If the crate uri-url-convert wants to implement TryFrom for url::Url and http::Uri rustc will complain as it only allows to implement traits for types from the same crate:
error[E0117]: only traits defined in the current crate can be implemented for arbitrary types
    |
    = note: the impl does not reference any types defined in this crate
    = note: define and implement a trait or new type instead

Do you see a way around this?

Good catch, it seems that specific implementation wouldn't be possible.
It would still be possible for another crate to provide conversions, though, wouldn't it?

wouldn't it?

I think so.

Closing as there is no interest from the crate authors.


Agenda for 11/25/2017 Meeting

Topics
Status Updates (30 min)

OpenAPI Update

init pr in 12/15

Validation Update

not much work
init pr after basic framework (within 2 days)

Configuration Update

PR cli pkg and README(https://github.com/caicloud/nirvana/pull/37)
flag-gen
remaining work: viper integration
a struct definition for all flags (from @liubog2008)

Instrumentation Update

need rewrite, pending issue

Tracing Update

what do we want to trace?
groups/123/configs -> groups/{gname}/configs
next Friday, tracing demo

PR Discussion (20 min)

Basic framework

more detail and status
suggestion on moving forward

Task assignment

log @zoumo
errors @walktall

Action Items

Next Meeting Time

12/01/2017

Action item created and proposal updated.
Our next meeting time is 12/01/2017


No Address Clustering

The 2 files generated at towards the end ie. entities.csv & rel_address_entity.csv do not map addresses which were input to the same transaction as a single entity. I generated the files for blocks 0-1500 and found that the addresses that were inputs to the same transaction as indicated in the file input_addresses.csv were assigned to different entities in rel_address_entity.csv.
eg. The transaction with Id [8897ea9ceaf18a546cdc513b9179bae31a462ee5bf47818eb7ba909082d11777] has 10 inputs, two of which are : [15fLMPJUAyiuc28gscdmRnVu1zUC1TXHtz] , [17c6L9JUGVenn6CfqXuB93L3Tk8Tbzefui]. However, both are assigned to different entities: [213] & [798] respectively.
The main problem seems to be with the com function : compute_entities() in the file : entities.py. The problem is with address grouping.
 This means that the UNIX sort (with LC_ALL=C) is not working in your environment as expected. Which operating system are you using?

I am using Cygwin on windows 10. I had to remove the "LC_ALL=C" from the call to make the sort execute as otherwise it would fail. I will try running the sort on UNIX and use the generate address file to find clusters. Thanks for the help !!


Code generation is creating warnings

Contact Details
<EMAIL_ADDRESS>What happened?
We are generating code with gradle
id "org.openapi.generator" version "7.5.0"
This points out to problems with the file.
build.log
Steps To Reproduce
Just generate code from the file.
What did you expect?
No warnings
Version
No response
Optional Screenshots
No response
Relevant log output
No response

https://github.com/diggsweden/sdk-docs/pull/3


Tensorflow2 Compile error with input concatenation layer

Hi unfortunately I get the following error when compiling my model.
[UNILOG][FATAL][XCOM_ITEM_UNDEFINED][The requested item was not found or defined!]
Judging from my testing, the compiler is having problems with my concatenated layer, however I can't find an error in my code.
I have attached a corresponding test model including quantization, in which the error occurs.
I'm currently using the v2.5 but also in v2.0 I got the same error, only the spelling of the error text has improved.
My compile command:
vai_c_tensorflow2 -m quantized.h5 -a /opt/vitis_ai/compiler/arch/DPUCVDX8G/VCK190/arch.json -o output -n netname

Python code:
#!/usr/bin/env python
# coding: utf-8

import pathlib
import pandas as pd

import tensorflow as tf
from sklearn.model_selection import train_test_split
from sklearn.datasets import make_regression
from sklearn.preprocessing import StandardScaler

# In[38]:

X, y = make_regression(n_samples=1000, n_features=20, noise=0.5, random_state=42)
X = StandardScaler().fit_transform(X)
y = StandardScaler().fit_transform(y.reshape(len(y),1))[:,0]
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25, random_state=42)

inp_list=[tf.keras.layers.Input(shape=(1,), name=str(i)) for i in range(20)]
cat_layer = tf.keras.layers.Concatenate()(inp_list)
dense_0 = tf.keras.layers.Dense(10, activation='relu')(cat_layer)
dense_1 = tf.keras.layers.Dense(1, activation='linear')(dense_0)
model = tf.keras.models.Model(inp_list, dense_1)

model.compile(
    optimizer=tf.keras.optimizers.Adam(learning_rate=.01),
    loss='mean_squared_error',
)

X_train = pd.DataFrame(X_train)
X_train.columns =[str(i) for i in X_train.columns]
X_test = pd.DataFrame(X_test)
X_test.columns =[str(i) for i in X_test.columns]
history = model.fit(dict(X_train), y_train, epochs=50, verbose=2, validation_split=0.2)
hist = pd.DataFrame(history.history)
hist['epoch'] = history.epoch

print(model.summary())

tf.keras.models.save_model(model, 'concat_model.h5')
pd.DataFrame(X_test).to_csv('concat_model/X.csv', index=False)
pd.DataFrame(y_test).to_csv('concat_model/y.csv', index=False)

# In[45]:

model_dir = pathlib.Path("concat_model")
model = tf.keras.models.load_model("concat_model.h5")

#X = pd.read_csv(model_dir / "X.csv")
X = pd.DataFrame(X)
X.columns =[str(i) for i in X.columns]
#y = pd.read_csv(model_dir / "y.csv")

print(f"mean_squared_error: {model.evaluate(dict(X), y)}")

from tensorflow_model_optimization.quantization.keras import vitis_quantize

model = tf.keras.models.load_model("concat_model.h5")

quantizer = vitis_quantize.VitisQuantizer(model)
calib_dataset = dict(X.iloc[:10])

quantized_model = quantizer.quantize_model(calib_dataset=calib_dataset, include_cle=True, cle_steps=10, include_fast_ft=True)
quantized_model.save("quantized.h5")
quantized_model.compile(loss=tf.keras.losses.MeanSquaredError())
quantized_model.evaluate(dict(X), y)
quantizer.dump_model(quantized_model, dataset=dict(X.iloc[0:1]), dump_float=True)

Hi, can I help you with troubleshooting in any way? Feel free to contact me if you have problems reproducing the error.

Hi, the compiler didn't consider concatenated layer so many inputs, and the problem is fixed in the new released patch.
please refer to for details: https://github.com/Xilinx/Vitis-AI/blob/master/docs/quick-start/install/Vitis AI 2.5 Aug 2022 Patch.md.

Closing since no activity for more than 2 weeks, please reopen if you still have question, thanks


[CI] Ubuntu CC  is still "Expected — Waiting for status to be reported" after 14 days.

It is strange. Let's see the operation status of Tensorflow CI on  PR #27466.  The work status of Ubuntu CC  is still "Expected — Waiting for status to be reported" even though 14 days is passed after the contributor submitted PR #27466. Why does not Ubuntu CC  report the result either PASS or FAILURE? Why Ubuntu CC is still running for 14 days?

https://github.com/tensorflow/tensorflow/pull/27466

Above all, lots of PRs do not have got the execution result of Tensorflow CI.  Please see the red circles below. Why these situations have repeatedly generated?

@leemgs The yellow dot essentially means that not all checks have run. We don't run all the checks until a reviewer has approved the PR. Hope that clarifies it.

We don't run all the checks until a reviewer has approved the PR. Hope that clarifies it.

Is it mean that the CI system does not report any results until a reviewer has approved the PR? It's weird. It is not helpful to the reviewers because the CI system works as one of the reviewers. In general, the major goal of the CI system is to help the reviewer (without the final approver of the PR).


Documentation improvement

Address this issue https://github.com/MicrosoftDocs/azure-docs/issues/63304

@pioardi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@pioardi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@pioardi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@pioardi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@pioardi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@mattchenderson  thanks for your review and clarification, I accepted your suggestion on the ASE part and remove the KeyVault version part.
Should be good now , thanks !

Apologies for the delay - took some vacation last week and didn't get to this before leaving. Thank you again for the contribution! This looks good to me.
#sign-off

I should note the conflict will need resolution first before this can be merged. Not sure what is causing that specifically, but I'm hoping whoever looks at this now that it has the ready-to-merge label can help out.

@mattchenderson I resolved the merge conflict. The alert was upgraded to "important" in master; I merged that change into the PR. I'll merge it now. Thanks!


tfcth calculated inconsistently

In PROCESS/examples/csv_output_large_tokamak_MFILE.DAT, tcfth is output twice.  The first output is wrong - it shows the initial value, not the final value after iteration.
tfcth____________________________________________________ (itvar032)____________________      1.2000E+00

TF_coil_inboard_leg_(m)__________________________________ (tfcth)_______________________      8.6482E-01 ITV

This probably results from incomplete implementation of Issue #515.  Note that in this run thkcas is also an iteration variable:
Inboard_leg_case_inboard_"nose"_thickness_(m)____________ (thkcas)______________________      2.2965E-01 ITV

In #515 I recommended that we should remove the option of having tfcth as an iteration variable, but this obviously hasn't been done.  I recommended that we should use thkcas and thkwp as iteration variables instead.  There are of course many ways to solve this problem, but over-determining tfcth is not one of them.
This is another high priority issue since it could make PROCESS behave erratically and might prevent convergence.
@jonmaddock @jmorris-uk @timothy-nunn @ajpearcey

Tim, If you are going to look at this I would suggest we get some comments from @ajpearcey , @jmorris-uk and @stuartmuldrew.

I am looking at the magnet dimensions as this is inter related with the cable pack problem.

Yes, there is a connection between the overall dimensions of the TF coil cross-section (winding pack and case) and the dimensions of the conductor inside it.
However, I suggest trying to keep these topics separate as far as humanly possible.

I am going to add a check to stop PROCESS if tfcth (inboard TF coil thickness, (centrepost for ST) (m)) is selected as an iteration variable when the TF coil is superconducting (as proposed in Issue #515).


POST Body Field Not working

The following code does not let the user enter name-value pairs into the request body. The request is sent without any name-value pairs. Also, when you click on the Model Schema, the model does not display in the body field.
I am working with java code.
@POST
    @Path("/video/geolocation")
    @Produces({"application/json"})
    @Consumes("application/x-www-form-urlencoded")
    @ApiOperation(value = "Lookup Basic Geolocation", notes = "", response = Geolocation.class)
    @ApiImplicitParams(value = {
            @ApiImplicitParam(name = "body", value = "Enter name-value pairs.", required = true, dataType = "string", paramType = "body")
            })
    @ApiResponses(value = {
            @ApiResponse(code = 400, message = "Invalid IP detected"),
            @ApiResponse(code = 404, message = "Geolocation not found")
    })
    public Geolocation getGeoSOLR(MultivaluedMap<String,String> values){
        return getGeoProcess(values, true);

Is there an example I can view?
Thanks,
johnh

Which version of swagger-core do you use?

com.wordnik
swagger-jaxrs_2.10

swagger-jaxrs_2.10-3.10.jar in Maven /lib.

Swagger-core 1.3.X (which is the one you use) doesn't support Maps.
I see you assume this is to take form parameters and not really a body parameter. In that case, you'd have to describe each form parameter separately. If you require arbitrary input, you cannot do that with swagger-core 1.3.X. In 1.5 you can, if this is a body parameter, but not if it is form parameters.

Perhaps it is the version of the core I am using, but ... Let's say I just provide form parameters instead of arbitrary input. I tried doing that but the body field continues to show up in the UI. It is not needed with specific form params. It is confusing. How can I get rid of it?

I assume it shows up because your method accepts a parameter which is automatically treated as a body parameter. You'd have to filter it out.

Hmmm. Is there some swagger annotation that allows me to filter it out? or must I do the filtering in the API java?

No annotation. You need to use a SwaggerSpecFilter for it.

@jharter - My bad, completely forgot. You can set @ApiParam(hidden=true) on it and it should hide it.

Seems that "@ApiParam(hidden=true) is not supported in my version of the core. I suspect. IntelliJ marks it red, can 't resolve method. As you pointed out, I am using Swagger-core 1.3.X. I need to update, I guess, but don't know what to update to. I am using plain vanilla Java and using Maven for building. I put the Swagger jar file in the Maven lib directory and register it. Plus change my pom.xml file to point to the Swagger file. Could you point me to the correct Swagger download?
Thanks. johnh

Well, the problem is I don't know exactly which version you use as the version is not specified in the dependency snippet. If you don't want to upgrade to 1.5, then the latest version of 1.3 is 1.3.12.

I see no reason not to upgrade to 1.5, unless you see an issue. Where can I download it?

Maven :) Which jax-rs implementation do you use?

Hmmm. I don't know where to find that information. I am awaiting an email from the folks who set up the project. I know: JAVA_VERSION="1.8.0_40". Maven Version = 3.2.5. That's probably not helpful. Sorry, but I need to await an email from a colleague.

I just want to refer you to the correct guide, that should help you integrate 1.5 easily with your code. So let's see what the response to the JAX-RS implementation would be.

I think the answer is 2.4.1, but here is the Maven dependency:tree response.
org.codehaus.jackson:jackson-jaxrs:jar:1.9.11:compile
com.wordnik:swagger-jaxrs_2.10:jar:1.3.12:compile
com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.4.1:compile
com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.4.1:compile
Thanks.

I am really hoping that a new version of the core with @ApiParam(hidden=true) works because now the body field is displaying in my GET methods. It used to only display in the POST.

None of these are related to the JAX-RS implementation. It'd be difficult to offer more support without that information.

Hi.
Apparently there was a parent pom.xml, and the version of jax-rs (in apache cfx) is 2.2.3.
Does that help?
Thanks.

Yes, it most certainly does. Unfortunately, we don't have a guide ready for CXF integration.
However, we released today a general migration guide from 1.3 to 1.5 that may be enough (and it would be great to get some feedback).
The guide is located here - https://github.com/swagger-api/swagger-core/wiki/1.3--1.5-Migration.
For the guide, you should know that the dependency name you need to use is swagger-jaxrs and the version is 1.5.1-M2.
Can you give it a shot?

Yes, I will give it a shot. Thanks so much.

Is there a jar file for this? Where would I find it? I need to add it to Maven.

That's the dependency. Right now you probably have:
        <dependency>
            <groupId>com.wordnik</groupId>
            <artifactId>swagger-jaxrs_2.10</artifactId>
        </dependency>

So you need to replace that with:
        <dependency>
            <groupId>com.wordnik</groupId>
            <artifactId>swagger-jaxrs</artifactId>
            <version>1.5.1-M2</version>
        </dependency>

Thanks for your help. My first attempts at using this were unsuccessful. Unfortunately I need to push my project with this one bug due to time constraints. I will work with this new version in a week or so and give you any feedback I have. Thanks for all  your help.


Vectorized functions

Fixes #52

@ritzvik Vectorized the necessary functions. Probably needs little more testing.

Hi @pmk21 ,
Thanks a lot for your Pull Request! As you see, the Quality tests are failing! In that case, you might want to run black on these two files as in the CI Logs:
would reformat /home/circleci/repo/src/einsteinpy/utils/coord_transforms.py
would reformat /home/circleci/repo/src/einsteinpy/utils/bl_coord_transforms.py
All done! 💥 💔 💥
2 files would be reformatted, 28 files would be left unchanged.
Exited with code 1

Just use black coord_transforms.py and black  bl_coord_transforms.py after cding into utils.
Once quality checks pass, I would do a thorough review.

The CI will not fix as the numba guys do not have the wheels for python 3.5!

@shreyasbapat I wrote two separate tests to check it and it worked well with the new tests as well as old ones. The changes are good to go.
Thanks for the contribution @pmk21 .
As as with the new tests, I think they should go the same PR. Should I make a PR on @pmk21 's fork?

@shreyasbapat sooner or later we have to do something about the CI thing.

@pmk21 add the following test snippets to the end of files.
in tests/test_utils/test_bl_coords_transforms.py add these lines at the end

@pytest.mark.parametrize(
    "vec, a",
    [
        (
            np.array(
                [
                    [21.0, 300, 0.33, 4.0, 1.0, -10.0, -1, -2],
                    [1.0, 3, 0.1, 5.0, 1.0, 100.0, -11, 2],
                    [1.0, 3, 0.1, 0, 1.0, 0, -11, 2],
                ]
            ),
            0.4,
        )
    ],
)
def test_BL2C_8dim(vec, a):
    list1 = list()
    for v in vec:
        nv = np.hstack(
            (
                v[0],
                utils.BLToCartesian_pos(v[1:4], a),
                v[4],
                utils.BLToCartesian_vel(v[1:4], v[5:8], a),
            )
        )
        list1.append(nv)
    arr1 = np.array(list1)
    arr2 = utils.BL2C_8dim(vec, a)
    assert_allclose(arr1, arr2, rtol=0.0, atol=1e-5)

in tests/test_utils/test_coords_transforms.py add these lines at the end

@pytest.mark.parametrize(
    "vec",
    [
        (
            np.array(
                [
                    [21.0, 300, 0.33, 4.0, 1.0, -10.0, -1, -2],
                    [1.0, 3, 0.1, 5.0, 1.0, 100.0, -11, 2],
                    [1.0, 3, 0.1, 0, 1.0, 0, -11, 2],
                ]
            )
        )
    ],
)
def test_S2C_8dim(vec):
    list1 = list()
    for v in vec:
        nv = np.hstack(
            (
                v[0],
                utils.SphericalToCartesian_pos(v[1:4]),
                v[4],
                utils.SphericalToCartesian_vel(v[1:4], v[5:8]),
            )
        )
        list1.append(nv)
    arr1 = np.array(list1)
    arr2 = utils.S2C_8dim(vec)
    assert_allclose(arr1, arr2, rtol=0.0, atol=1e-5)

and kindly remember to apply black to both files.
Thanks again

Yes, I will work on it soon @ritzvik .

No problems, love contributing. How can I be of help or contribute more?

How can I be of help or contribute more?

You can help us solve any of the issues !
Thanks a lot!


Solve PR Changes for Revision #8

Please @acamino check this PR.

This one is a really nice implementation. Thanks @EliuX!
Beside the comment I left (please address it) LGTM. 🚢
Please, make sure the tests are green before merging it. :smirk:


Adding basic Dockerfile.

The dockerfile doesn't allow you to pass in any config besides the token, but I'll add more later.

Hi there! I know it's been literal years, but thanks for your contribution! I'm sorry I never merged it. I haven't worked on RPBot in quite some time.
I'm actually completely rewriting the bot in Rust now, which I aim to be pushing to a stable state very soon. This PR was auto-closed since I replaced the "master" branch with "main" to follow my usual modern conventions, but also it will definitely be incompatible with the new code regardless.

Hah, amazing! No worries, I get it.


upgrading module from 0.4.0 to 0.9.1 causes cycle dependency error

Hello,
I tried to upgrade this module from version 0.4.0 to 0.9.1. It causes a cycle dependency error
(Exec[download_package_elasticsearch] => Class[Elasticsearch::Package] => Class[Elasticsearch::Config] => File[/opt/elasticsearch] => File[/opt/elasticsearch/swdl] => Exec[download_package_elasticsearch])

My associated code didn't change.
It is composed of a common 'profile' definition (more Puppet code is in there, like java version, collectd plugins and /etc/security/limits.conf management)
class { 'elasticsearch':
    package_url     => 'https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.4.4.deb',
    datadir         => '/opt/elasticsearch',
}

and a node definition like
include profiles::elasticsearch::base
elasticsearch::instance { 'clustername':
    init_defaults   => { 'ES_HEAP_SIZE' => '6g' },
    config          => {
                        'cluster.name'              => 'clustername',
                        'node.name'                 => 'nodename',
                        'node.master'               => false,
                        'bootstrap.mlockall'        => true,
                        },
}

The error message looks like:
Could not apply complete catalog: Found 1 dependency cycle:
(Exec[download_package_elasticsearch] => Class[Elasticsearch::Package] => Class[Elasticsearch::Config] => File[/opt/elasticsearch] => File[/opt/elasticsearch/swdl] => Exec[download_package_elasticsearch])

The associated cycles graph is https://i.imgur.com/mQPbG8r.png

I do have a system test that installs the package via the package_url and never seen this dependency cycle.
Can you confirm the upgrade of the module is successful?

Ah wait, i think i see the issue. you have selected /opt/elasticsearch for the data directory but we manage /opt/elasticsearch/swdl separately but /opt/elasticsearch is automatically selected as a dependency causing the dependency cycle.
Must admit i have never tested for this use case.
You could try to set the package_dir to something else then /opt/elasticsearch/swdl or change the datadir.

in fact, changing package_dir to be outside datadir solved my problem. Strange edge case :)

Must admit i haven't thought about this situation.
Perhaps i need to move the default pkg dir to something else, or find an other solution for this.
Any idea's are welcome :-)

Hi
Just to give an update on this.
I haven't been able to come up with a solution for this so far.
I think this is such an edge case we can ignore it for now unless it comes up again.
What are your thoughts about it?

Closing as no alternative solution could be thought up, considering this as an edge case.
Might review in the future.


active_if appears not to be respected

Code to reproduce issue attached. The active_if decorator appears to not be respected?
import ruffus as ruffus
from ruffus import *
RUFFUS_INPUT = "./file.input"
BOOL_IS_DATA_EMPTY = False

starting_files = [RUFFUS_INPUT]
@ruffus.transform(starting_files,
            ruffus.suffix(".input"),
            ".stage1")
def stage1(input_file,
                    output_file):

    pd_input = []
    global BOOL_IS_DATA_EMPTY
    if (len(pd_input)==0):
        BOOL_IS_DATA_EMPTY =  True
        return
    else:
        f= open('file.stage1','wb')
        f.close()
        print 'non empty data..run all'

@active_if(not(BOOL_IS_DATA_EMPTY))
@ruffus.transform(stage1,
            ruffus.suffix(".stage1"),
            ".stage2")
def stage2(input_file,
                      output_file):
    print 'run stage 2'
    f= open('file.stage2','wb')
    f.close()

@active_if(not(BOOL_IS_DATA_EMPTY))
@ruffus.transform(stage2,
            ruffus.suffix(".stage2"),
            ".stage3")
def stage3(input_file,
                      output_file):
    print 'stage3'

    f= open('file.stage3','wb')
    f.close()

@active_if(not(BOOL_IS_DATA_EMPTY))
@ruffus.transform(stage3,
            ruffus.suffix(".stage3"),
            ".stage4")
def stage4(input_file,
                       output_file):
    if((BOOL_IS_DATA_EMPTY)):
        print 'why is this running when there is no data??'

def runChain():
    f = open('./file.input','wb')
    f.close()
    ruffus.pipeline_run(target_tasks=[stage4])

if __name__ == "__main__":
    """

    """
    runChain()

What is happening is that you are telling the pipeline at setup whether you want the tasks to be active or not. If you want this to be a dynamic decision, modifiable as you run the pipeline, you can use a call back function. In your code, just adding the following will work
    BOOL_IS_DATA_EMPTY = False
    # call back function
    def is_data_empty():
         return BOOL_IS_DATA_EMPTY

Remember to change the ``@active_if``` to use the callback as well:
   @active_if(not(is_data_empty))
   @ruffus.transform(stage1,
             ruffus.suffix(".stage1"),
            ".stage2")
    def stage2(input_file,output_file):
        pass

The long explanation
@active_if（BOOL_CONDITION） is the exact equivalent of calling the object method task.active_if(BOOL_CONDITION). Because the decorator is at global scope, the function call happens as soon as the pipeline is set up (when task decorator is called).
The BOOL_CONDITION is interpreted and saved by the task at this point.
Python is not like c++ where scalar variables (such as booleans) can be passed by reference and then have the referred-to (changed) value accessed later. The only way to do this is to use a callback (or if you are being sneaky and obscure, a list).


Please add support for combined libLLVM

Problem
libLLVM can either be built as component libraries or as combined libraries, see
https://wiki.gentoo.org/wiki/Project:LLVM/Shared_libraries
When LLVM is built as combined library, there is only libLLVM.so, and building
oslexec fails, as it uses LLVM_MCJIT_LIBRARY:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LLVM_MCJIT_LIBRARY
    linked by target "oslexec" in directory /home/stefan/Documents/Sources/OpenShadingLanguage/src/liboslexec

Expected behavior:
LLVM_MCJIT_LIBRARY should be set to a useful value. When using llvm-config, the correct library is returned:
$> llvm-config --libfiles mcjit
/usr/lib64/libLLVM.so
llvm-config --libs mcjit
-lLLVM

The issue can be worked around by setting "-DLLVM_MCJIT_LIBRARY='' " when running cmake.
Versions

OSL branch/version: 1.9.3, master
OS: openSUSE TW 20190109
C++ compiler: gcc 8.2
LLVM version: 7.0.0
OIIO version:

Hello.  I have the same issue on Fedora 29 here : everything is bundled in libLLVM.so.  Adding the above code right at the end (before the message(...)) did solve the issue.  However the handy confifuration variables to change the library to use in ccmake/cmake-gui disappear which I guess is can issue on windows where one often install dependencies to a custom location.

I proposed #976 before noticing this old issue which it should fix. I didn't do it quite the way you suggest, but @StefanBruens can you try out #976 and see if it looks ok and/or works for you?

Woops, spoke too fast.  The solution presented hear makes me have a bunch of link errors with a test executable and LLVM at compilation.  I do not advise it.

@laerne, can you also check #976, which is a slightly different approach to solving this problem?

Fixed by #976


--debug option

On one of my project, retest seems to run fine once and then doesn't trigger a new build unless I wait a really long time. The process running it seems to take a lot of CPU resources. Never encountered this problem on another repository. The repository is 8 years old.
It would be nice to add a debug/verbose option to print some debug statements and identify where it's blocked.
The next step is to fix the issue with that new tool.

The wrong issue is described here.
Sometimes retest picks up a change only after several seconds.
I don't have this issue currently, deleting it until it resurfaces.


Common base script for rollup configs

Each package in this mono repo has its own rollup configs at the moment.
While this is fine for the auto generated packages, because they use the same format due to the code generation, this is troublesome in terms of maintainence for the rest of the packages due to differences in the way we configure rollup.
This issue is to explore if we can get a common base script for rollup config which can then be extended by individual packages for further customization.

Currently blocked on an upstream bug in @rollup/plugin-commonjs: https://github.com/rollup/plugins/issues/743
Migrating to rollup 2 and the newer versions of plugin-commonjs will ease the transition to the shared rollup configuration.

Currently blocked on an upstream bug in @rollup/plugin-commonjs: https://github.com/rollup/plugins/issues/743
Migrating to rollup 2 and the newer versions of plugin-commonjs will ease the transition to the shared rollup configuration.

I have not been catching up here, but I think this is already done isn't it? @witemple-msft @deyaaeldeen have been working on a common rollup script. is this still needed and if so what's left to do?

@maorleger we have a shared rollup config in https://github.com/Azure/azure-sdk-for-js/blob/main/common/tools/dev-tool/src/config/rollup.base.config.ts that was created by @witemple-msft.

We do have issues to track individual packages being updated to use the shared rollup
Unless there is more work to do here apart from updating individual packages, we can close this.
I'll leave it to @witemple-msft to decide

Sounds good, thanks! FYI I am moving packages over as part of fixing #14292 so I will link the PR to any issues that I resolve in https://github.com/Azure/azure-sdk-for-js/issues?q=is%3Aopen+is%3Aissue+author%3Ajeremymeng+"use+shared+roll+up"

Closing in favor of #17807


Request Parameter Instrumentation

Adds option to set request parameter as span attributes and additionally add them to the corresponding beacon.

Also: Fix Tracer instrumentation to read serviceName property


pythonPackages.faker: fix build

Motivation for this change
pythonPackages.faker no longer builds
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Assured whether relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@worldofpeace yep I noticed that after a little bit, I've fixed that locally but have now run into a problem that I don't know how to solve. Faker depends on more-itertools<6.0.0 which I can handle here, but then I run into an issue that pytest depends on more-itertools too and will cause a clash because its using the packaged 6.0.0. I'm stumped on how to fix.
Pushing what I have now.

You could try feeding the checkInputs an ad-hoc pytest which has been overridden with your more-itertools5:
(pytest.override { more-itertools = more-itertools5; })
and if pytest won't accept more-itertools5 as it's too old you could try your luck with pytest_3. If you do this you'll probably need to thread this new pytest back in to the pytestrunner you use.

@worldofpeace yep I noticed that after a little bit, I've fixed that locally but have now run into a problem that I don't know how to solve. Faker depends on more-itertools<6.0.0 which I can handle here, but then I run into an issue that pytest depends on more-itertools too and will cause a clash because its using the packaged 6.0.0. I'm stumped on how to fix.
Pushing what I have now.

more-itertools is just a testing dependency if I'm understanding this correctly.
What kind of failures would result if we used the 6.0.0, assuming that's why they've enforced the pin.
I'm partial to just patching this away because it's just for tests. Also note we've already patched the pin for pytest in postPatch so we couldn't do worse.

patched to ignore the version specifier (with some notes). @worldofpeace PTAL.

done @worldofpeace thanks for help!

done @worldofpeace thanks for help!

You're very welcome. Thanks for contributing :sparkles:


include param documentation does not match the example

I think it's the case that the prose says that the parameter should be a 3 dimensional array, but the example  shows a 2 dimensional array which omits the second dimension, depth, described in the prose:
https://github.com/fortunejs/fortune/blob/master/lib/index.js#L333-L336

Nope, the prose is correct. To see it more clearly:
[['comments', ['author', { ... }]
^^ .                  ^
12                     3


Vet clinic database: create animals table

In this PR we have done the following:

[x] Created vet_clinic database
[x] Created animals table
[x] Inserted data into animals' table
[x] Query animals table

The screenshot of the results is attached to this PR:

@kifle23 would you fix mit broken link and remove unnecessary sections like live demo and client & server from teck stack to have a professional readme


ProfileService not getting called

So I'm having an issue with the IProfileService's method GetProfileDataAsync. I've set up the following in my Startup.cs
 public void ConfigureServices(IServiceCollection services)
        {
            services.AddDeveloperIdentityServer(
                    options => { options.AuthenticationOptions = new IdentityServer4.Configuration.AuthenticationOptions(); })
                .AddInMemoryScopes(Scopes.GetScopes())
                .AddInMemoryClients(Clients.GetClients());

            services.AddTransient<IResourceOwnerPasswordValidator, ResourceOwnerPasswordVlidator>();
            services.AddTransient<IProfileService, ProfileService>();

            var connection = @"####";
            services.AddDbContext<ColorBrawlContext>(options => options.UseSqlServer(connection));

            services.AddMvc();
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {
            loggerFactory.AddConsole();
            loggerFactory.AddDebug();

            JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
            app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
            {
                Authority = "http://localhost:15812",
                ScopeName = StandardScopes.OpenId.Name,
                RequireHttpsMetadata = false
            });

            app.UseIdentityServer();

            app.UseMvc();
        }

And I can login using my database as expected with the ResourceOwnerPasswordVlidator class. But it never calls GetProfileDataAsync in my ProfileService.
It's a new project where all I have done is added the IdentityServer4.
I have looked around but can't find any answers

It's only called if you ask for scopes that have additional claims.

How do I do that?

Docs: https://identityserver4.readthedocs.io/en/release/configuration/scopes.html

I'll try it out. Thanks!


Fix recipe for version 0.2.0

Due to the release_name variable in meta.yaml, the recipe was still
packaging v0.1.0 instead of v0.2.0. This is now fixed by using
version variable to determine the URL of the source tarball.
Furthermore, fasttext changed its license to MIT.

Checklist

[X] Used a fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[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.


pre-mainnet fixes

Updates code blocks to work a bit better
Better empty state in blocks
some misc env var changes

:tada: This PR is included in version 1.4.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.4.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Update Careers “emea/lead-product-designer”

Automatically generated by Netlify CMS

Thanks @abelhancock ! ❤


fix: install cli from crates.io instead of github

related issue: https://github.com/DioxusLabs/deploy-action/issues/4

dioxus cli is installed from crates.io instead of github
removed the parameter toolSource

I think we should keep toolSource, and add a flag install from crates.io, because toolSource can help user use other cli version.

but I will merge your PR first, and make toolSource in next version.

Thanks


Catching Up Tasks

If we use the DB to store task completion info, we can also see if we need the "catch-up" a task.
For example, the server could have been down for a few hours and miss a task's scheduled time.
We could look at the database and see if a scheduled time was missed and run that task when the server starts.

Is the order of tasks important?
When if multiple times for the same task (which are currently actually multiple tasks) are missed? Only one should catch-up.

Implemented in a series of commits that ends with 5e394a0eee7b41add808d0dd22fe7c7bcfdfec4b.


Could not install PyPortfolioOpt on Anaconda

Operating system, environment, python version
Windows10, conda 4.8.3 version  (I recently moved to conda-forge because I could not install cvxpy otherwise),  python3.7.6
What you tried
pip install pyportfolioopt from both Jupiter (it runs forever) and from anaconda shell in which gives error
I also tried to download the whl file from pypi and put it inside the folder of anaconda packages C:\Users\Notebook\anaconda3\Lib\site-packages but it is not working
Error message
ERROR: Failed building wheel for cvxpy
Failed to build cvxpy
ERROR: Could not build wheels for cvxpy which use PEP 517 and cannot be installed directly

Please can anybody help?
BR
Luigi

perfect, thanks a lot Robert!!
Luigi


Change str_to_snake_case to handle capitalized words

resolves #213

This is a breaking change. We should mention in changelog that codegen will now prepend digits with underscore.


PoC: Add new "proof reissue" command

PoC implementation for this discussion: https://github.com/crev-dev/cargo-crev/discussions/492
"How to deal with a person leaving an organization?"
This commands allows to find existing proofs
and sign them again with a different id.
This comes in handy when an id is going be revoked but
the trust of the existing reviews should be retained by a new id.
Scenarios:

Old id got compromised
Person leaves an organization, so organization can reissue
existing reviews using a different id to maintain trust level.

Checklist:

[x] cargo +nightly fmt --all
[ ] Modify CHANGELOG.md if applicable

Code is originally based upon the "proof find" code.

To test the code I reissued all 1500+ reviews I had available. That worked fine and I added protection against this "reissue all of them" mode.
One corner case though: The iterator returned by db.get_pkg_reviews_for_source(PROJECT_SOURCE_CRATES_IO) acts funny for one crate + version combination. It's the "default" crate with version 0.1.2. On the first run it returns both existing reviews and reissues them.
One review for this crate has the git "revision" field omitted.
If the command crev proof reissue --no-commit --crate default --vers 0.1.2 is invoked again, the iterator returns just one of the two reviews signed by the new id. I suspect there's some internal hash map keeping just one of the two reissued reviews. What happens that one of the two reviews then gets reissued again on every reissue invocation. I tried to debug the behavior for like two hours but I guess it's better if someone with real knowledge of the internal data structures comments on this minor glitch.

btw: I noticed struct PackageInfo in package_info.rs serializes revision like this:
    #[serde(skip_serializing_if = "proof::equals_default", default)]
    pub revision: String,
    #[serde(
        rename = "revision-type",
        skip_serializing_if = "proof::equals_default_revision_type",
        default = "proof::default_revision_type"
    )]
    pub revision_type: String,

while struct Revision in revision.rs serializes it like this:
    pub revision: String,
    #[serde(
        rename = "revision-type",
        skip_serializing_if = "proof::equals_default_revision_type",
        default = "proof::default_revision_type"
    )]

If I remove #[serde(skip_serializing_if = "proof::equals_default", default)] from pub revision: String in struct PackageInfo, the iterator returned from db.get_pkg_reviews_for_source(PROJECT_SOURCE_CRATES_IO) acts consistent.
I must humbly admit that I have no idea what I'm changing there. :see_no_evil:

:+1: on the idea. One thing that would be probably good to have is adding a prefix to the comment about the whole thing being "reissued". Or possibly maybe an additional field for the purpose altogether, somehow linking to the previous version.
I need to find some more time to look at the issues you've pointed out.

One corner case though: The iterator returned by db.get_pkg_reviews_for_source(PROJECT_SOURCE_CRATES_IO) acts funny for one crate + version combination. It's the "default" crate with version 0.1.2. On the first run it returns both existing reviews and reissues them.

Ok, I think I figured it out by giving the code a fresh look: db.get_pkg_reviews_for_source() operates on package_reviews which is defined as
// pkg_review_id by package information, nicely grouped
package_reviews:
    BTreeMap<Source, BTreeMap<Name, BTreeMap<Version, HashSet<PkgVersionReviewId>>>>,

PkgVersionReviewId is defined as
/// * author's ID
/// * pkg source
/// * pkg name
/// * pkg version
pub struct PkgVersionReviewId {
    from: Id,
    package_version_id: proof::PackageVersionId,
}

Basically the HashMap stores just one review from the same crev id for the same PackageVersionId. Since reviews can be overwritten, the function update_to_more_recent() makes sure to store just the latest one for the "unique" combination above.
How should this be handled when reissuing existing reviews?
The current PoC implementation calling reissue_review.touch_date(); will mess up if multiple reviews for the same crate + version (+ source) combination are available and all get rewritten to the same crev id.
One way to fix this the easy way is to restrict all proofs-to-be-reissued to the same source id. This would avoid the multiple reviews refer to the same PackageVersionId situation completely. The --author argument would then be mandatory.
Regarding the other feedback:

One thing that would be probably good to have is adding a prefix to the comment about the whole thing being "reissued". Or possibly maybe an additional field for the purpose altogether, somehow linking to the previous version.

Good idea. The information is already in the commit message and it would be way more useful to have it in the actual proof. Proofs don't seem to have a uuid, but the Signature seems to be unique per proof. Would that be a good field to use for the reference?
Thanks for your feedback so far and please no rush with this. I might need the feature in many months time only, so lots of time to cook this further. :grinning:

+1 on the idea. One thing that would be probably good to have is adding a prefix to the comment about the whole thing being "reissued". Or possibly maybe an additional field for the purpose altogether, somehow linking to the previous version.

May be like this in the proof yaml format:
----- BEGIN CREV PROOF -----
kind: package review
version: -1
date: 2022-08-27T20:09:44.970188805+02:00
from:
  id-type: crev
  id: 89j3NY-J-XNtcLZeTgOy5Vp1gd1rYPHlCGoytg9wYuQ         <-- current id
  url: https://github.com/owner/repo.git
reissue-for:
  id-type: crev
  id: 6E-JFdHO008HicLRuRBi9TSedIhdscjOAfpokc5Jl0U         <-- old id
  url: https://github.com/other-owner/some-repo.git
  date: 2020-05-25T20:42:42.970188805+02:00               <-- previous review date
..
comment: |-
  Minor changes compared to previous version.

  [Review was reissued by id 89j3NY-J-XNtcLZeTgOy5Vp1gd1rYPHlCGoytg9wYuQ]

Not sure if modifying the comment is a good idea if the information is in the meta data already. The metadata is probably the way.

will mess up if multiple reviews for the same crate + version (+ source) combination are available and all get rewritten to the same crev id.

In crev source + package name + version is an unique key of a review. If the same ID creates a review for the exact package version, the old review is completely overwritten and ignored. There's no need to re-issue such a review.

Reviewes can be keyed only by their checksum to save on space. I would probably go with something more generic than reissue-from, because
original:
  id: <digest of the original>
  comment: "Reissued after X left the XYZ"

?
I could imagine some people making duplicates for some other reasons so a human readable reason is needed.
I'm happy to keep bikesheading the exact names.

I've implemented the original: format and pushed two more commits. Those commits should later on be squashed into the original commit.
Referencing the proof digest was a pita to implement since none of the existing data structures stored it. I conservatively named the new variable "digest_on_load" to prevent future programmers from mistaking this as an up-to-date proof digest after modifications.
The CLI is not very friendly to search by proof digest, so I also included the crev id of the original proof for the human reader. Storing the proof digest now is more or less an investment into the future.
The --author and --comment arguments are mandatory now. Making --author mandatory will avoid the collision when reissuing multiple reviews for the same crate+version from multiple source crev ids. If one needs to reissue reviews for multiple crev ids, I don't see a problem with them calling the tool for each crev id.
This is the output for a reissued review:
----- BEGIN CREV PROOF -----
kind: package review
version: -1
date: 2022-08-28T11:19:35.643176546+02:00
from:
  id-type: crev
  id: 89j3NY-J-XNtcLZeTgOy5Vp1gd1rYPHlCGoytg9wYuQ
  url: https://github.com/intra2net/crev-proofs-playground.git
original:
  id-type: crev
  id: FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE
  proof_digest: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0
  comment: Reissue to replace compromised id from stolen laptop
package:
  source: https://crates.io
  name: default
  version: 0.1.2
  digest: YuxzyXhCHZYMi4__Hj_hCzkQyxRLrZjDqL8usLqA4QY
review:
  thoroughness: high
  understanding: high
  rating: strong
comment: |-
  I'm the author. And this crate is 3 lines of trivial code.
----- SIGN CREV PROOF -----
FimnMpCGMKrjid-q43d_rQ2UQxP4HoTbEALghfw4SwOCoD0XZ9_JyvHc8ICG1OFYq7_nPLvvQ_SZcUZODWEdAQ
----- END CREV PROOF -----

This is how the generated git commit message looks like:
Signed existing review for default v0.1.2 with different id

New id: 89j3NY-J-XNtcLZeTgOy5Vp1gd1rYPHlCGoytg9wYuQ
Previous id: FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE
Previous proof digest: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE

There's one (new) ergonomic problem with the original: field: When one overwrites a review the was reissued previously. Right now the editor doesn't show the "original:" fields, this can be fixed easily.
The questions is: Do we want to keep the original: reference on overwrites or not?
I'm unsure what makes the most sense here.
This is an example of such an overwrite:
----- BEGIN CREV PROOF -----
kind: package review
version: -1
date: 2022-08-28T11:40:06.009446836+02:00
from:
  id-type: crev
  id: 89j3NY-J-XNtcLZeTgOy5Vp1gd1rYPHlCGoytg9wYuQ
  url: https://github.com/intra2net/crev-proofs-playground.git
original:
  id-type: crev
  id: FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE
  proof_digest: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0
  comment: Reissue to replace compromised id from stolen laptop
package:
  source: https://crates.io
  name: default
  version: 0.1.2
  digest: YuxzyXhCHZYMi4__Hj_hCzkQyxRLrZjDqL8usLqA4QY
review:
  thoroughness: high
  understanding: high
  rating: strong
comment: |-
  Just hangin' out.
----- SIGN CREV PROOF -----
jg7aU8fueiBmVfU3tR17nz3UWVCFRUGfzmVm-sCx6KXtDzXwtMLY_3QP4s-ffJQ2xUtGcaqhMg9aXF1jenveDw
----- END CREV PROOF -----

I detected this behaviour by chance while testing the new feature.

An overwrite would no longer be a straight re-signing of the original, I think, so probably no need preserve original.

  proof_digest: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0

Maybe just digest? If not then we use - as separator in other fields already.

Sorry, for throwing you a curveball, but that digest_on_load is not necessary. The digest storing and lookup should go through ProofDB. TheProofDB::add_proof is already handed a Proof that has a digest field. The problem is that I stupidly decided to track stuff in ProofDB by signature which is ... problematic at least. I should have used digest for everything from the start and wanted to fix it sometime soon anyway. So ids_to_trust_proof_signatures would become ids_to_trust_proof_digest and so on. With that looking up digest of something should be easy (feel free to add an additional mapping if you need it).

An overwrite would no longer be a straight re-signing of the original, I think, so probably no need preserve original.

ok, thanks, I'll make sure to clear it on the next improvement round.

  proof_digest: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0

Maybe just digest? If not then we use - as separator in other fields already.

I thought including the "proof-" prefix would help people not to mistake it for the digest of the crate files. '-' as separator is a good idea.
Given that one can see the "digest:" below "package:" in relative distance in the yaml file, I'm not sure if it's an issue at all since people will notice they will differ for sure.
So if you prefer the shorter field name, we can go with that.

Sorry, for throwing you a curveball, but that digest_on_load is not necessary. The digest storing and lookup should go through ProofDB. TheProofDB::add_proof is already handed a Proof that has a digest field. The problem is that I stupidly decided to track stuff in ProofDB by signature which is ... problematic at least. I should have used digest for everything from the start and wanted to fix it sometime soon anyway.

that explains a few things for me ^^ I mentioned this here https://github.com/crev-dev/cargo-crev/pull/493#issuecomment-1229293342 at the end: "Proofs don't seem to have a uuid, but the Signature seems to be unique per proof. Would that be a good field to use for the reference?"
So I was looking for a unique identifier and somehow mistook Signature for it since it's used in a lot of places in the code. :grin:
I will have to stop working on this soon for a while (AFK) but I will come back to this feature since it's the missing puzzle piece for organization use (for me). May be I get lucky and the ProofDb is refactored from Signature to Digest as key by then. Please don't feel rushed or pressured though.
I don't have any problem rebasing my code later on and throw some parts away. That's normal development process and the knowledge I gained from the inner workings let me to fix up https://github.com/crev-dev/cargo-crev/pull/495 in almost no time.

An overwrite would no longer be a straight re-signing of the original, I think, so probably no need preserve original.

ok, thanks, I'll make sure to clear it on the next improvement round.

Implemented this now along with the "proof-digest" field rename. I've rebased the branch on master but didn't squash the commits yet.

Depending how you feel about it, you can just add such mapping and move on

new mapping table has been added. :grin: I also introduced a newtype proof::Digest which can be used in more places in the future and won't be mistaken for a package digest by the code.
Besides may be bikeshedding about some naming or console output here and there I think that should complete the feature?

Everything is perfect. It's just the document format bikesheding.
I'm looking at:
original:
  id-type: crev
  id: FYlr8YoYGVvDwHQxqEIs89reKKDy-oWisoO0qXXEfHE
  proof_digest: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0
  comment: Reissue to replace compromised id from stolen laptop

And maybe we should remove id and id-type. Why? Because the reader of this document doesn't have a good way to verify it anyway (if read by human), and it is redundant (if handled by code). Also - just to save some space.
As for "proof digest", maybe just proof: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0 + comment? No need to say it's a "digest". This is the proof that this is reissuing, here is the id, the end.

And maybe we should remove id and id-type. Why? Because the reader of this document doesn't have a good way to verify it anyway (if read by human), and it is redundant (if handled by code). Also - just to save some space.

the original crev id might help a human fellow to use "proof find" and locate the original review. As it's not too important and the tooling around "search for proof digest" might improve in the future, I've axed it.

As for "proof digest", maybe just proof: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0 + comment? No need to say it's a "digest". This proof is "re-creating" (re-issuing) another proof, here is the id (proof) + human-readable explanation, the end.

good idea.
This is the output from the latest code:
from:
  id-type: crev
  id: Ja1uYcBfo4pxqkHEgaHNAdBtvZdQ667nDGZyhrCkJs0
  url: https://github.com/intra2net/crev-proofs.git
original:
  proof: 3t1MkzxOO_ZY_bt-r5oVeqZUMVS2of0bb7rZK6_xqE0
  comment: Shiny new key
package:
  source: https://crates.io
  name: default
  version: 0.1.2
  digest: YuxzyXhCHZYMi4__Hj_hCzkQyxRLrZjDqL8usLqA4QY

I'm going to clean up the branch now.

Thank you!


⚠ Bofrost.es has degraded performance

In f778736, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1582 ms

Resolved: Bofrost.es performance has improved in f02e4a1 after 8 minutes.


Show notes in the record view page

Sorry to take this long to get back on this, but I finally resolved the comments. PTAL.


Force zoom further 22

I just found this article http://wesmapping.com/blog/zoom-past-maximum-tile-level-with-leaflet/ and I guess it will be helpful to give it a try /cc @jjmata

Indeed!  Nice find ...
There is a Spaniard in London who is a Leaflet-wiz ... we should ask him as well (and Santana as well, of course!)

FYI, we mentioned this to @saleiva in person last week and he seemed to think it would be feasible.  We need to dig a little deeper, and might come up with questions then, Sergio!

ok! :)

Update: Check commit 4ae3678bc5f7efd1f77b36e27262f4a8aaff2d07 and git checkout it to roughly try it out. Forced to level 50.