Introduce "usingAdapter/Transformer" feature

While browsing #1127 I got an idea about some generic solution to the problem of comparing 2 similar but different classes.
A comparison strategy similar to usingComparator that allows comparing equality of different classes by using defined class casting via adapter
Example
    LocalDateTime date = LocalDateTime.of(2017, 1, 1, 2, 3, 4); // ... 2017-01-01 02:03:04
    XMLGregorianCalendar calendar = XMLGregorianCalendarImpl.createDateTime(2017, 1, 1, 2, 3, 4); // ... 2017-01-01 02:03:04
    Function<LocalDateTime, XMLGregorianCalendar> adapter = (LocalDateTime dateTime) -> XMLGregorianCalendarImpl.createDateTime(dateTime.getYear(),
                                                                                dateTime.getMonthValue(),
                                                                                dateTime.getDayOfMonth(),
                                                                                dateTime.getHour(),
                                                                                dateTime.getMinute(),
                                                                                dateTime.getSecond());
    Assertions.assertThat(date).usingAdapter(adapter).isEqualTo(calendar); // true

If you think it is a good idea I could work my way on it.

I'm not sure this is a use case that happens so frequently, if it does a helper method would likely do like areLogicallyEqual(date, calendar).


07/19/2018 05:56 : Create Pull Request for branch prTesting_2018071905 -> master

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/updateTestCon.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Change confusion matrix dtype

The accumulation of the confusion matrix produces overflows if you have a large data set.
Matrix is currently stored as int32.
If you have a dataset with 10^5 images and 10^5 pixels per image (480*360=172800) the maximum true positive number is 10^10 > 2^32 ~ 10^9.
Changed the dtype of the matrix to int64 to solve the problem.

I changed it to x.astype(np.int64)

Merged, thanks for the PR!


Implement All Atomic Objects

Implement All Atomic Objects

Create a Impl Directory inside the sub-library Atomic directory.
Implement the following Atomic Objects:

String
Integer
UnsignedInteger
Long
UnsignedLong
Char
UnsignedChar
Short
UnsignedShort
Size_t
Ptrdiff_t
Float
Double

Then, you can create collections:

Array
List

Do not start working on this issue, until further investigation.


s3-hostname-updated

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/approve

[APPROVALNOTIFIER] This PR is APPROVED
Approval requirements bypassed by manually added approval.
This pull-request has been approved by: gagansk, leihchen
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Scrollbar fix is not working.

This is now fixed with  1.13.1.
As you fixed the issue ,I have Installed the latest version but still the scrollbar is visible.Or can you provide any css props to hide it or just change the color of it to transparent.
package.json
  "dependencies": {
    "react": "^17.0.2",
    "react-chrono": "^1.13.1",
    "react-dom": "^17.0.2",
    "react-router-dom": "^6.2.1",
    "react-scripts": "5.0.0"
  },

Originally posted by @prabhuignoto in https://github.com/prabhuignoto/react-chrono/issues/214#issuecomment-1013730870

are you setting this prop
scrollable={{scrollBar: false}}

Yes

can you try removing the scrollable prop altogether?

Yes

did removing the prop solved the issue


Is OCPI provided from stations?

Hey,
I want to ask about OCPI as I didn't find any resource over the internet, who implements the OCPI?
There are two parties, the station provider and the mobile app provider. should the station provide the APIs to the provider or the opposite? are there any resources to read from?

Would be great if you could provide any resources to read about OCPI

Hello @Aazme,
This repository contains the latest spec sheet which holds everything you need to know if you are planning on implementing the OCPI protocol: https://github.com/BitzArt/OCPI.Net/blob/main/docs/OCPI-2.2.1.pdf
And here is the original repository of OCPI protocol: https://github.com/ocpi/ocpi
When you are mentioning two parties, I believe you are referring to CPO (Charge Point Operator) and eMSP (e-Mobility Service Provider). If you are planning on connecting two such parties with OCPI, both of them have to implement the protocol. The spec sheet contains detailed requirements on which parts of the protocol each party should implement.
Hope this helps.
You can also reach out to me directly if you have further questions<EMAIL_ADDRESS>

Thanks, @YuriyDurov  for your quick reply! I am developing an eMSP app and the CPO tells us they are implementing the OCPI. so I should only follow the OCPI and the APIs and contracts are the same right? only URL change?

@Aazme I suggest that first of all you review the document I mentioned. It contains all the necessary information if you want to implement an eMSP. It would give you a more comprehensive view on what you should be doing in order to achieve your goal.
As for your question: CPOs and eMSPs use the same contracts, but perform different functions and behave differently. These differences, as well as the contracts, are described in OCPI documents like the one I mentioned. I will not be able to guide you on all the details of OCPI implementation as this is too big of a topic, so you should refer to the documentation.
Keep in mind that this particular document is for OCPI version 2.2.1, so first I would suggest that you ask your CPO which particular version of OCPI they implement. Maybe you will need a different one, for the specific version of OCPI that they use.
The nuget package OCPI.Net can provide you with the contracts needed for both the CPO and the eMSP, as well as some basic functionality necessary for every party implementing OCPI protocol. Feel free to use it and reach out if you have any issues with it or if you think it lacks important functionality. I am currently working on extending the package's feature set, so feature suggestions are welcome.

@YuriyDurov  Thanks so much for your response & support and sure will get back to you and even contribute if I could! :)


Quick Find Settings for Dataverse Search

Hi there,
as we found out by testing, merely adding columns that should be indexed in the relevance search to the "Find columns" of a quick find did not lead to these fields being available for filtering.
In our test, we used a field of type Two Options / Boolean.
As we found out by your definition from the page:
"The Find Columns on a Quick Find View define the searchable fields in the Dataverse search index. Text fields such as Single Line of Text and Multiple Lines of Text, Lookups, and Option Sets are searchable. Find Columns of all other data types are ignored."
We really needed to filter for boolean fields and added a boolean field to the find columns as well as to the view columns of our quick find.
Suddenly filtering on boolean columns became possible as well.
Can you comment on whether the feature is just not yet documented?
Kind regards

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

ID: f8f4b53c-095c-4bf9-46dd-62299f2568e5
Version Independent ID: 92a06c7b-d9b6-1a85-fb46-8378273a5994
Content: Configure Dataverse search to improve search results and performance - Power Platform
Content Source: power-platform/admin/configure-relevance-search-organization.md
Service: power-platform
Sub-service: admin
GitHub Login: @sericks007
Microsoft Alias: sericks

Thanks for your comment, @DigitalFlow. This issue has been assigned to the doc author for review.


Update cats-effect to 3.3.2

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

Applied Scalafix Migrations

org.typelevel:{cats-effect,cats-effect-laws}:3.3.0 (created no change)

github:typelevel/cats-effect/v3_3_0?sha=series/3.x

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel", artifactId = "cats-effect" } ]

labels: library-update, early-semver-minor, semver-spec-minor, scalafix-migrations, commit-count:1

Codecov Report

Merging #286 (b26e68b) into master (52cb181) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #286   +/-   ##
=======================================
  Coverage   66.66%   66.66%
=======================================
  Files          19       19
  Lines         561      561
  Branches       22       21    -1
=======================================
  Hits          374      374
  Misses        187      187

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 52cb181...b26e68b. Read the comment docs.

Superseded by #287.

Superseded by #287.


Unexpected Chunk Generation Request

egenerate, Deleting chunks within the .mca files, unloading chunks without or with saving them and doing the same. I think I've had pretty much all combinations trying to prevent chunkfails from happening while trying to regenerate an custom structure.
I have made an more detailed request on: http://forum.mctcp.com/t/support-for-unexpected-chunk-generation-request/1510
I would be a verry happy terrain creator if this could be added. Thanks a huge lot in advance!

@NLBlackEagle Is this still occuring in latest build?


Add routing to UKIS

What is the context of this PR?
To add the routing rules into the UKIS schema.
How to review
Using the google slides, check that routing is going to the expected blocks. N.B the hiding of sections in 7-9 has not been implemented in this PR

Spurious exception during logging fixed

Rebased, squashed and ready to merge

Passed QA on branch


Mixed Chart Multiple yaxis with negative value behaviour

I am trying to make a mixed chart with 2 lines and 1 bar chart with multiple yaxis. I want the bar chart to have the negative value behavior starting from the middle using the second yaxis (0%).
Still no luck.
How the yaxis min and max function works?
Any clue?

  series: [{
	  name: "test1",
	  data: [100000, 105000, 107000, 101650, 97650]
	},
	{
	  name: "test2",
	  type: 'bar',
	  data: [100000, 104000, 107500, 101650, 97650]
	},
	{
	  name: 'test3',
	  data: [95000, 99750, 101650, 99750, 97650]
	}
  ],
  chartOptions: {
	chart: {
	  height: 672,
	  type: 'line',
	  zoom: {
		enabled: false
	  },
	},
	dataLabels: {
	  enabled: false
	},
	stroke: {
	  width: [5, 0, 5],
	  curve: 'smooth',
	  dashArray: [0, 0, 5]
	},
	xaxis: {
		categories: ['01 Jan', '02 Jan', '03 Jan', '04 Jan', '05 Jan'
		],
		tickPlacement: 'between',
	},
	yaxis: [
		{
		seriesName: ['test1', 'test2'],
		  min: 85000,
		  max: 115000,
		  tickAmount: 6,
		  labels:{
			  formatter: (value) => {
				return '$' + numberWithCommas(value);
			  },
			}
		},
		{
			seriesName: 'test3',
			min: 85000 || function(min){return (min - 100000) / 10000},
		  max: 115000 || function(max){return (max - 100000) / 10000},
		  tickAmount: 6,
		  show: true,
		  opposite: true,
		  labels:{
			  formatter: (value) => {
				return (value - 100000) / 10000 + '%';
			  },
			}
		}
	],
	colors: ['#546E7A', '#4CAF50', '#FF0000'],
	fill: {
		opacity: [1, 0.2, 1]
	},
	grid: {
	  borderColor: '#f1f1f1',
	},
  },
}````

Please do not post questions as feature request and also do not double post. You posted this same question in discussions.

any answer?

No answer in discussion and got closed abruptly also in this thread.
No good developer in this repo?
Only hostile people here?


Fix command line argument process

There are several bugs/issue in client command line argument processing, for example
hyper run -t

or
hyper build -t "myrepo/myimg"

the above incorrect command line will lead to client panic.
The other problem details include:
Parse or ParseArgs
In short Parse() process os.Args[1:] and ParseArgs(args []string) process args
The commands have args in command line, such as
func (cli *HyperClient) HyperCmdBuild(args ...string) error

when user types  hyper build -t "myrepo/myimg"

the args will be -t, myrepo/myimg
the os.Args should be hyper, build, -t, myrepo/myimg

if we use
args, err := parser.Parse()

the args will be build, and if we check if it is empty, it will never be empty,
because it always has a build here even if we forget to provide the path
And if we use
args, err := parser.ParseArgs(args)

We will get an empty array, through which we can find the input error.
As we have already provide args as the method parameter, we should use
ParseArgs
Should not check args len at the very beginning
we checked len(args) some of commands before argument processing,
for example, the run checked.
However, if we input hyper run -t, it won't find the problem because it has
a -t, the problems will be found by following parameters check. The pre-processing
check is trivial.

LGTM


Issues with Converting YOLOv5 ONNX Model to HEF Format with and without NMS

I have encountered some issues while modifying the official inference codes for (windows/yolov5) and (windows/yolov8) to support image inference. I tested the downloaded yolov5m_nms.hef and yolov5m_no_nms.hef files (both provided by Hailo), and I would greatly appreciate your assistance with the following concerns:

(windows/yolov8) Code:
This code is capable of inferring the yolov8_nms.hef model, so I wondered if it could also infer the yolov5_nms.hef model. After replacing the model, I found that this code can indeed work with both models. However, I am not sure how to convert my trained yolov5m.onnx model into an HEF model with NMS. The official yolov5m.yaml configuration file seems to be for an older model, and even after modifying the nodes in yolov5m.yaml, I am still unsure if the provided yolov5m_nms.json is compatible with my model. During the conversion, I encountered the error The layer named conv84 doesn't exist in the HN. Could you kindly guide me on how to generate a yolov5m_nms.hef model with NMS? My model conversion command is:
‘hailomz compile --ckpt yolov5m.onnx --calib-path my_data/chunxin_image --model-script yolov5m.alls --classes 1 yolov5m’

(windows/yolov5) Code:
I noticed that this example uses a yolov5.hef model without NMS, and this model type is Multi Context. To convert the yolov5m.onnx model for a custom dataset, I modified the yolov5m.alls and removed the content related to using the nms.json file. The modified yolov5m.alls content is as follows.

However, when I performed inference with the code, the drawn bounding boxes were incorrect, as shown below:

The bounding boxes for the generic model yolov5m_no_nms.hef were correct, as shown below.

Could you kindly advise me on how to generate a yolov5m_no_nms.hef model without NMS?
Thank you very much for your assistance.
Best regards

Hi @pcycccccc,
To answer your questions:

when running hailomz compile, the MZ goes through the 3 Datafllow Compiler steps - parsing, optimization and compilation.
In the optimization step, the MZ take the alls defined in the relevant YAML file or, as you did, a specific defined alls script.
In the alls script, for the NMS on Hailo to be applied, you either define a path to the JSON config file or use a prebuilt option. For example, it can be:
nms_postprocess(meta_arch=yolov5, engine=cpu)
Or
nms_postprocess('config_file_path', meta_arch=yolov5, engine=cpu)

Since your model in custom, you need to use the second option and update the relevant JSON, meaning you need to take the yolov5m_nms_config.json file in the MZ, and change it according to your model:

You can have different number of classes, different anchors, different thresholds and different convolution layers that attached to the NMS ops.

The yolov5 Windows example is pretty old and needs to be updated to support the NMS on Hailo. This is something that is in out tasks list. Regarding your question  - it might be different anchors for your model that cause the bbox to shift. The multi context is not relevant to the accuracy of the model as it is just a way to have a large model, that exceeds the Hailo device's resources, run on the device.
The way you created the HEF without NMS is the correct way to do it.

Regards,

Thank you for your response. I now understand why the model conversion with NMS was causing errors. The main reason was that several node names in the JSON file did not match my model. I rewrote the yolov5.alls file based on the yolov8.alls file, and during the model conversion process, I checked the hn file generated from the har file. I then modified several nodes in my nms.json. The model conversion was successful, and I obtained the correct inference results。


Fix Haiku OS ASCII logo

The Haiku OS ASCII Logo Does not look good
Neofetch version: 7.1.0
Screenshot

Original logo (source)

Is anyone working on it?

You can work on it!

This is what i have come up with
      MM         MM
      MM         MM
      MM      . cmmmm-
      MM  .cMMMLMMM'
"'---cMMMMMMMMM"*lM
      M"*:Mc`"`` MM
      MM         MM
      ""         ""

@C47F15H, I made a slightly upscaled version of that which you can see here. Most distro asciis are 38-40 pixels wide

looks nice, but can the leaf colour be replaced with light green?

Yeah, you'd just use ascii color 10 instead of 2
Here's what it looks like

nice, but can you send that part of the neofetch with the c{x}'s?

Sorry, I mixed up the two issues I'm working on.  I really like your leaf stem (in blue), while my version focused on the notches in the leaf (i.e. the red circles).

The last leafcut is not needed. the ascii logo will look still represent Haiku even if it does not exist because it is very minor detail.
                                                                          this ⬇

Okay, I have removed the last leafcut. Here is the current ascii running in the Haiku terminal. I changed the H color to black since the default terminal has a white background

the leaf petiole needs to be a bit more visible
,
 `*o._,ccM

maybe like this

the theme for the information can be set to this - 1 3 7 2 and the ${c1} can be changed ${c3} and ${c2} can be ${c4}

So here is the logo with the new petiole

As for your other comment, I'm very confused. Colors 1 and 3 are red and yellow, and those aren't in the logo. I went ahead and changed ${c1} -> ${c3} and ${c2} -> ${c4}, and here is the result

Also, color 2 is the light green, and you said before that you don't like it. Here is the same thing with color 10 (dark green)

This is probably the closest we're going to get to the logo with ascii art. Are you ready to do a pull request?

@C47F15H, is this version acceptable for a pull request?

Okay, so I just noticed that you said "information" and I think I know what you're talking about. You want the text colors to be 1 3 7 2, right? In other words, is this close to what you'd like?

Line 5, 6, 7 & 8
.ciO|/YMMMMM*"

.coMMMMM|/MMMMM/'

,iMM|/

Fix the ${cX}'s too:
MMM/`${cX}.MMM

Line 9
MMMMMMM/`":MM/

And I think we're done.

@torculus you can show a screenshot and then finally make a pull request!

Okay, I put it on a black background just to be certain that these are the colors you're happy with

@dylanaraps , I see that you can set ${c1}, ${c2}, etc. in each distro's set_colors call, but how do you make --colors 1 3 7 10 persistent for each distro?

set_colors 1 3 7 10

Final product, using set_colors 1 3 7 10 and changing ${c1} -> ${c3}, ${c2} -> ${c4}. I think it's looking pretty good!


Tooltip position incorrect if  is relatively positioned

The tooltip is positioned correctly when the page is scrolled all the way up, but if you scroll down partly and activate the tooltip it will be displayed several hundred pixels higher on the page than it should be. Scrolling all the way up causes the tooltip to move into the correct position.

+1 for this, it's been almost 4 months :/

@compwright have you managed to fix this issue?

After some investigation, I think the issue is not about scrollable areas in general. It's specifically about the body tag having an overflow.
This works decently : http://jsfiddle.net/54h4eh4g/3/
The thing is, the body tag is a special tag. When it does not overflow, its overflowY equals the overflow of the window object. But when it does have an overflow of its own, the it's a separate value from the overflow of the window. Tooltipster currently does not try to detect an actual body overflow.
Something might be done to aknowledge this but to me, it seems that provoking an overflow on the body element (as @compwright did in his example) is a conceptual mistake. So I'm not sure Tooltipster should try to deal with it as it's not its job to prevent the user's conceptual mistakes. This is open to debate and I'd be happy to hear other point of views.

I was having a misplacement only on android (nexus 5) when body had the position: relative on it. I fixed by removing it and changing everything else on the page that depended on that. I don't have anything blocking my the body overflow, never had.

Check if you can narrow down your issue to a simple test case, because on my Nexus I only see the issue I described.

I agree with @louisameline. Not sure why you'd put position: relative on the body . Absolutely positioning a child of the body will already act like it's relative to the body.

In case anyone in the future stumbles upon this issue - I was experiencing this issue because I had the body with the following css:
position: relative; left: 50px;
This was done to accomodate for a vertical navbar that had a width of 50px - what happens is tooltipster over-compensates the calculation of the horizontal offset by 50px - the same as the left offset applied on the body.
There is a way to address this - provide a custom positioning function to subtract the offset.
functionPosition: function(instance, helper, position) {             position.coord.left = position.coord.left - 50;             position.target = position.target - 50;             return position;         }
after adding this to my tooltipster options, it corrected the position of all my tooltips.


System.Windows.Forms assembly (WinForms) can no longer be loaded with Add-Type -AssemblyName

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest released version
[X] Search the existing issues.
[X] Refer to the FAQ.
[X] Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce
Related: the ability to load the WinForms assembly via  using assembly System.Windows.Forms has been broken since using  before v7..0:

see https://github.com/PowerShell/PowerShell/issues/11856

Now, even Add-Type -Assembly System.Window.Forms doesn't work anymore:
Add-Type -AssemblyName System.Windows.Forms; [System.Windows.Forms.Form].FullName

Expected behavior
System.Windows.Forms.Form

That is, the assembly should load, and the [System.Windows.Forms.Form] type should be available.
Actual behavior
Add-Type: Cannot find path 'C:\path\to\current\location\System.Windows.Forms.dll' because it does not exist.
InvalidOperation: Unable to find type [System.Windows.Forms.Form].

That is, the assembly is seemingly only looked for in the current location, where it cannot be found.
Using an explicit GAC path to load the assembly does work, however:
# OK, with full GAC path.
Add-Type -LiteralPath C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Windows.Forms.dll; [System.Windows.Forms.Form]

Error details
No response
Environment data
PowerShell Core v7.3.1 (.NET 7.0.0)
PowerShell Core v7.4.0-preview.1 (.NET 7.0.1)
on Microsoft Windows 11 Pro (ARM 64-bit Processor; Version 22H2, OS Build: 22621.963)

Visuals
No response

Assembly loaded, 7.3.1

Mysterious, @237dmitry.
I've updated the initial post with environment details (Windows 11 22H2). Are you on a different version?
Does it still work for you if you run in a pristine session launched with -NoProfile?
I can only get the assembly to load if I use a full path into the GAC.
Once loaded that way, executing Add-Type -Assembly System.Window.Forms works (quiet no-op).

With -NoProfile:

Win 11 22H2.

Can confirm that it also works for me on Windows 10:

Mysterious; thanks for checking.

Does

(Add-Type -AssemblyName System.Windows.Forms -PassThru | Select -First 1 | % Assembly).Location

return a path in the GAC for you?

Is that where the assembly is expected to be loaded from in PS Core too?

What could get in the way of performing a GAC lookup in this case? (It works from WinPS on the same machine).

Core returns: C:\Program Files\PowerShell\7-preview\System.Windows.Forms.dll Windows PowerShell returns: C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_<IP_ADDRESS>__b77a5c561934e089\System.Windows.Forms.dll

Thanks, @MartinGC94.
I think I know what the problem is:
Whether the WinForms and WPF assemblies ship with PowerShell Core depends on the installation method:

YES:

MSI package

NO:

winget install Microsoft.PowerShell
Installation via https://aka.ms/install-powershell.ps1

Do you happen to know if this a known / by-design / documented discrepancy?

Closed in favor of #18858


Alias doesn't work when used in outE / inE

OrientDB Version: 3.0.6
OS: Linux & Windows
Expected behavior
select outE('AliasName') should return a value
Actual behavior
select outE('AliasName') doesn't return a value
select outE('ClassName') returns a value
It works in V2. We are migrating to V3 and we noticed this issue.

Hi @igasparetto
I just pushed a fix for this problem, it will be released with v 3.0.7
Thanks
Luigi

Awesome!
Thanks


Proposal: support insert key with expire time?

Now moka has a global expire time for all keys, can we insert key with expire time to make some keys different?

No. It is not supported yet. It is on our roadmap, and I will schedule it for v0.12.0.

@Millione
I forgot to mention, but until the per-key TTL is implemented, you could workaround by using entry_by_ref(&key).or_insert_with_if(init, replace_if) (doc).
#123

I'm building a cache whose entries have their own standalone TTL. However moka supports global TTL and IDLE only. So I'm here to propose a new method Cache::get_with_if(&self, key: &K, fallback: Fut, cond: Fn(&V) -> bool) -> V
The function works like Cache::get_with(&self, key: &K, init: Fut) -> V, but when the key does not exist or cond(&V) is true, the init clojure will be called to initialize the value.

Note that the Cache::get_with_if has been rename to or_insert_with_if under the Entry API.
You may want to check an actual usage by another user: https://github.com/moka-rs/moka/issues/227#issuecomment-1435510331
A difference between the real per-key TTL and this workaround is:

The real per-key TTL let an expired entry to be evicted as soon as possible (when periodical housekeeping task is executed).
The workaround never removes expired entry but replaces it with a new value when its key is accessed by entry or_insert_with_if.

Got it, thanks. Maybe I can try to implement the real per-key TTL when I'm available.

@tatsuya6502 I have found that the workarounds are not suitable for my scenario. When the cache is full, new keys cannot be inserted because expired keys cannot be cleared in time. Does it take a lot of work to implement the real per key? Desperately needed!

@Millione

When the cache is full, new keys cannot be inserted because expired keys cannot be cleared in time.

That is right.
Another workaround is to use invalidate_entries_if method (doc). It will scan all entries in the cache in background, and remove them when the predicate returns true. You could call it periodically (e.g every 5 minutes) to remove expired entries.

Does it take a lot of work to implement the real per key? Desperately needed!

I would say it will take a week or two if I can work on it 2 hours a day after work.

Implement the per key TTL:

a. Implement a new data structure called hierarchical timing wheels to manage the per key TTL. (e.g. Caffeine's TimerWheel.java)
b. Add test cases for the new data structure.
c. Update sync and future caches to use the new data structure for:

cache write operations such as insert and invalidate.
finding and evicting expired entries.

d. Add test cases for the per key TTL.

Write the documentation for the per key TTL with sample codes.
Update the benchmarking tool and run it.

I was a bit busy recently and could not done anything for Moka in the past few weeks. I am hoping to get back to it soon, but I still have other things to do in Moka before I can start working on this.
I will let you know when I make some progress, e.g. finish 1-a to 1-d so you can start to play with it.

I’m very excited to see progress here. Is there anything I might be able to help with?
We are using the workaround right now that we have an Instant as part of the cache item, and check for that in the replace_if callback.
One very interesting this about that is that the cache performance / hit rate is slowly decreasing over time, which is clearly visible in cache metrics:

Here, the light blue is cache hit, vs medium blue cache miss. And the dent is a fresh deployment, at which we have a good cache hit rate, it then gets worse over the next days or so. No idea why its getting worse so slowly though. We have a hard 1-hour TTL on every entry, so I’m surprised this effect needs a day or so to manifest.

@Swatinem

One very interesting this about that is that the cache performance / hit rate is slowly decreasing over time, which is clearly visible in cache metrics:

Does your workload have a high insertion rate all the time (e.g. more than 1500 insertions/sec)? and also does the cache have the max capacity configured? If so, eviction rate (for evicting expired entries) may not catch up with the insertion rate, and the cache will eventually become full although there are expired entries. Once the cache is full, the hit rate can drop if the admission policy is not suitable for your workload.
You could check if this is the case by tracking entry_count (if weigher is not set) or weighted_size (if weigher is set) in the cache metrics.
As of Moka v0.10.0, the eviction rate is hard-corded and maybe it is too small. Maybe I will make it larger and/or configurable.
In the future, I think the cache should be able to calculate the eviction rate based on the insertion rate and the cache capacity.

I don’t have metrics on the entry_count or weighted_size. We get about ~200 reads/sec and depending on the hit rate around ~50-150 misses (aka writes). Considering the capacity is only around ~500, I would assume it has a lot of pressure.
The capacity is intentionally conservative, as we are storing open mmaps, which both keep a file-descriptor open and, depending on the highly variable file size (a few kilobytes to gigabytes), might contribute a lot to virtual memory usage. It might sure be possible to make that adaptive on the actual size of the mmaped files, which I believe should give us a little better control over the capacity and vmem size.

We get about ~200 reads/sec and depending on the hit rate around ~50-150 misses (aka writes). Considering the capacity is only around ~500, I would assume it has a lot of pressure.

I see. So your cache will be full in a few seconds, and having slow eviction rate of expired entries will not explain why the performance / hit rate is slowly decreasing over time.
Other aspects that will change the hit rate will be:

Write Rate

Higher write rate will increase the hit rate, because it makes the cache to temporary hold more entries than the max capacity.

Moka cache applies writes to the cache policy in a batch. Every 300 ms or when the batch size reaches 512. Until the batch is applied, the cache will hold more entries than the max capacity.
e.g. If the max capacity is 500, and the write rate is 150/sec, the cache will hold 550 entries for 300 ms, and then evict 50 entries. (10% over capacity)
If the write rate is 50/sec, the cache will hold ~517 entries for 300 ms, and then evict 17 entries. (3% over capacity)

Read Access Pattern

If reads pattern prefers popular keys, the hit rate will be higher because of the TinyLFU policy.
If reads pattern prefers recently inserted keys, the hit rate will be lower.

This will be improved when Window TinyLFU policy is implemented.

It will be very possible that access pattern changes over time.

With the current information, it will be hard to identify the root cause. It will be very helpful if we can get access trace data from the production system. Access trace data can be a CSV file, and each line should have the following information:

Duration (milliseconds) since start.
Key, or hash of the key.
Per-key TTL.
If you use weigher, the weighted size of the entry.

Once we have such trace, we can replay it to reproduce he issue and investigate the root cause.

FYI, I started to work on this feature a few days ago: https://github.com/moka-rs/moka/pull/248
I am implementing hierarchical timing wheels now.

a. Implement a new data structure called hierarchical timing wheels (pdf) to manage the per key TTL. (e.g. Caffeine's TimerWheel.java)

I’m very excited to see progress here. Is there anything I might be able to help with?
We are using the workaround right now that we have an Instant as part of the cache item, and check for that in the replace_if callback.
One very interesting this about that is that the cache performance / hit rate is slowly decreasing over time, which is clearly visible in cache metrics:  Here, the light blue is cache hit, vs medium blue cache miss. And the dent is a fresh deployment, at which we have a good cache hit rate, it then gets worse over the next days or so. No idea why its getting worse so slowly though. We have a hard 1-hour TTL on every entry, so I’m surprised this effect needs a day or so to manifest.

Have u ever solved the problem? I had a similar problem recently, but the hit rate dropped faster, in about half an hour.

No, this is not that critical for us, and we are very happy with how the cache is performing in general. I will rather wait for proper per-entry TTL support instead of putting more effort into workarounds for that.

And the dent is a fresh deployment, at which we have a good cache hit rate, it then gets worse over the next days or so.

Maybe you are doing blue/green deployment and traffic will be slowly shifted to the fresh instance during a day? (e.g. AWS CodeDeploy (doc))  Having more traffic could decrease the hit rate as more cache keys will be used by different requests. It will have the same effect to reduce the cache capacity.

FYI, I started to work on this feature a few days ago: ...

OK. It is not quite ready for a release yet, but you can start to play with it. See: https://github.com/moka-rs/moka/pull/248#issuecomment-1501038013

Just FYI, I just published moka v0.11.0 to crates.io.

Hi @phantomhker,

Have u ever solved the problem? I had a similar problem recently, the difference is that the hit rate in my scene dropped faster, in about half an hour after reaching the max capacity.

FYI, @Swatinem reported the problem they were observing was fixed by #348 for v0.12.2.

https://github.com/moka-rs/moka/pull/348#issuecomment-1905985696

You might be affected by the same issue, so please try the latest version (v0.12.4) if you have a chance.


tailwind has JIT enabled but doesn't seem to jit anything have to stop and restart to see changes.

@crazedVic The way this project is set up you don't need to restart the server to see the changes for the CSS/tailwind. As the scss is transpiled to CSS, before the dev or production build is initiated, and the generated global css and tailwind css are directly linked in the app.html, the HMR is not supported for them. But the JIT works only in the prod build, not for local. Build the application and check the generated css files.


add more tests

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#6085  👈
#6081
#6080
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @DonIsaac and the rest of your teammates on  Graphite


Cannot push, compile errors

I've tried this using the latest Katana sample but keep getting compile errors:
https://github.com/friism/KatanaTest
Steps:

Downloaded KatanaTest as a Zip and unpacked

Git Initialised and committed all files

heroku create --buildpack http://github.com/friism/heroku-buildpack-mono.git

git push heroku master

C:\Users\Andrew\Programming\Websites\KatanaTest2>git push heroku master
Counting objects: 16, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (16/16), 5.88 KiB | 0 bytes/s, done.
Total 16 (delta 0), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> .NET app detected
remote: -----> Downloading http://s3.amazonaws.com/mono-dependencies/cedar-14/mono-3.10.0.tar.gz
remote: -----> Compiling Mono application
remote: ERROR building certificate chain: System.NullReferenceException: Object reference not set to an instance of an object
remote:   at System.Security.Cryptography.X509Certificates.X509Chain.get_Roots () [0x00000] in <filename unknown>:0
remote:   at System.Security.Cryptography.X509Certificates.X509Chain.get_CertificateCollection () [0x00000] in <filename unknown>:0
remote:   at System.Security.Cryptography.X509Certificates.X509Chain.FindParent (System.Security.Cryptography.X509Certificates.X509Certificate2 certificate) [0x00000] in <filename unknown>:0
remote:   at System.Security.Cryptography.X509Certificates.X509Chain.BuildChainFrom (System.Security.Cryptography.X509Certificates.X509Certificate2 certificate) [0x00000] in <filename unknown>:0
remote:   at System.Security.Cryptography.X509Certificates.X509Chain.Build (System.Security.Cryptography.X509Certificates.X509Certificate2 certificate) [0x00000] in <filename unknown>:0
remote:   at System.Net.ServicePointManager+ChainValidationHelper.ValidateChain (Mono.Security.X509.X509CertificateCollection certs) [0x00000] in <filename unknown>:0
remote: Please, report this problem to the Mono team
remote: ERROR processing certificate: System.NullReferenceException: Object reference not set to an instance of an object
remote:   at System.Security.Cryptography.X509Certificates.X509Certificate2.get_Version () [0x00000] in <filename unknown>:0
remote:   at System.Net.ServicePointManager+ChainValidationHelper.CheckCertificateUsage (System.Security.Cryptography.X509Certificates.X509Certificate2 cert) [0x00000] in <filename unknown>:0
remote: Please, report this problem to the Mono team
remote:
remote: Unhandled Exception:
remote: System.NullReferenceException: Object reference not set to an instance of an object
remote:   at (wrapper unknown) System.Threading.Monitor:FastMonitorEnterV4 (object,bool&)
remote:   at Mono.Security.Protocol.Tls.RecordProtocol+ReceiveRecordAsyncResult.SetComplete (System.Exception ex, System.Byte[] resultingBuffer) [0x00000] in <filename unknown>:0
remote:   at Mono.Security.Protocol.Tls.RecordProtocol+ReceiveRecordAsyncResult.SetComplete (System.Exception ex) [0x00000] in <filename unknown>:0
remote:   at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (IAsyncResult asyncResult) [0x00000] in <filename unknown>:0
remote:
remote:  !     Push rejected, failed to compile .NET app
remote:
remote: Verifying deploy....
remote:
remote: !       Push rejected to radiant-springs-2071.
remote:
To https://git.heroku.com/radiant-springs-2071.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/radiant-springs-2071.git'

Tried cedar-10

C:\Users\Andrew\Programming\Websites\KatanaTest2>heroku stack:set cedar
Stack set. Next release on radiant-springs-2071 will use cedar-10.
Run `git push heroku master` to create a new release on cedar-10.

C:\Users\Andrew\Programming\Websites\KatanaTest2>git push heroku master
Counting objects: 16, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (16/16), 5.88 KiB | 0 bytes/s, done.
Total 16 (delta 0), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> .NET app detected
remote: -----> Downloading http://s3.amazonaws.com/mono-dependencies/cedar/mono-3.10.0.tar.gz
remote: -----> Compiling Mono application
remote: Installing 'Microsoft.Owin 1.1.0-beta2'.
remote: Installing 'Owin 1.0'.
remote: Installing 'Microsoft.Owin.Diagnostics 1.1.0-beta2'.
remote: Installing 'Microsoft.Owin.Host.HttpListener 1.1.0-beta2'.
remote: Installing 'Microsoft.Owin.Hosting 1.1.0-beta2'.
remote: System.Byte[] doesn't implement interface System.IDisposable
remote:
remote: Stacktrace:
remote:
remote:   at <unknown> <0xffffffff>
remote:   at System.IO.Packaging.ZipPackage.LoadParts () <0x001b6>
remote:   at System.IO.Packaging.ZipPackage.get_Parts () <0x00023>
remote:   at System.IO.Packaging.ZipPackage.GetPartCore (System.Uri) <0x00027>
remote:   at System.IO.Packaging.Package.GetPart (System.Uri) <0x0002e>
remote:   at System.IO.Packaging.Package.PartExists (System.Uri) <0x00019>
remote:   at System.IO.Packaging.Package.LoadRelationships () <0x0012a>
remote:   at System.IO.Packaging.Package.get_Relationships () <0x00023>
remote:   at System.IO.Packaging.Package.GetRelationshipsByType (string) <0x000f0>
remote:   at NuGet.OptimizedZipPackage.EnsureManifest () <0x0007c>
remote:   at NuGet.OptimizedZipPackage..ctor (NuGet.IFileSystem,string) <0x00124>
remote:   at NuGet.LocalPackageRepository.OpenPackage (string) <0x000d5>
remote:   at NuGet.LocalPackageRepository.GetPackage (System.Func`2<string, NuGet.IPackage>,string) <0x000d0>
remote:   at NuGet.LocalPackageRepository/<>c__DisplayClass13.<FindPackage>b__f (string) <0x0002a>
remote:   at System.Linq.Enumerable/<CreateSelectIterator>c__Iterator10`2.MoveNext () <0x0018c>
remote:   at System.Linq.Enumerable/<CreateWhereIterator>c__Iterator1E`1.MoveNext () <0x0021f>
remote:   at System.Linq.Enumerable/<CreateSelectIterator>c__Iterator10`2.MoveNext () <0x00217>
remote:   at System.Linq.Enumerable.First<TSource> (System.Collections.Generic.IEnumerable`1<TSource>,System.Func`2<TSource, bool>,System.Linq.Enumerable/Fallback) <0x000bc>
remote:   at System.Linq.Enumerable.FirstOrDefault<TSource> (System.Collections.Generic.IEnumerable`1<TSource>) <0x00084>
remote:   at NuGet.LocalPackageRepository.FindPackage (System.Func`2<string, NuGet.IPackage>,string,NuGet.SemanticVersion) <0x0037a>
remote:   at NuGet.LocalPackageRepository.FindPackage (string,NuGet.SemanticVersion) <0x000c8>
remote:   at NuGet.PackageRepositoryExtensions.FindPackage (NuGet.IPackageRepository,string,NuGet.SemanticVersion,NuGet.IPackageConstraintProvider,bool,bool) <0x00319>
remote:   at NuGet.PackageRepositoryExtensions.FindPackage (NuGet.IPackageRepository,string,NuGet.SemanticVersion) <0x00048>
remote:   at NuGet.DataServicePackage.EnsurePackage (NuGet.IPackageCacheRepository) <0x002f6>
remote:   at NuGet.DataServicePackage.get_Package () <0x0002a>
remote:   at NuGet.DataServicePackage.GetFiles () <0x00014>
remote:   at NuGet.PackageManager.ExpandFiles (NuGet.IPackage) <0x00069>
remote:   at NuGet.PackageManager.OnExpandFiles (NuGet.PackageOperationEventArgs) <0x00029>
remote:   at NuGet.PackageManager.ExecuteInstall (NuGet.IPackage) <0x000f4>
remote:   at NuGet.PackageManager.Execute (NuGet.PackageOperation) <0x0018e>
remote:   at NuGet.PackageManager.Execute (NuGet.IPackage,NuGet.IPackageOperationResolver) <0x000a8>
remote:   at NuGet.PackageManager.InstallPackage (NuGet.IPackage,System.Runtime.Versioning.FrameworkName,bool,bool,bool) <0x00101>
remote:   at NuGet.PackageManager.InstallPackage (NuGet.IPackage,bool,bool,bool) <0x0003b>
remote:   at NuGet.Common.PackageExtractor/<>c__DisplayClass1.<InstallPackage>b__0 () <0x00031>
remote:   at NuGet.Common.PackageExtractor.ExecuteLocked (string,System.Action) <0x00076>
remote:   at NuGet.Common.PackageExtractor.InstallPackage (NuGet.IPackageManager,NuGet.IPackage) <0x001aa>
remote:   at NuGet.Commands.RestoreCommand.RestorePackage (NuGet.IFileSystem,string,NuGet.SemanticVersion,bool,System.Collections.Concurrent.ConcurrentQueue`1<NuGet.IPackage>) <0x0036d>
remote:   at NuGet.Commands.RestoreCommand/<>c__DisplayClass5/<>c__DisplayClass7.<ExecuteInParallel>b__2 () <0x00054>
remote:   at System.Threading.Tasks.TaskActionInvoker/FuncInvoke`1<bool>.Invoke (System.Threading.Tasks.Task,object,System.Threading.Tasks.Task) <0x0004f>
remote:   at System.Threading.Tasks.Task.InnerInvoke () <0x0006c>
remote:   at System.Threading.Tasks.Task.ThreadStart () <0x0034b>
remote:   at System.Threading.Tasks.Task.Execute () <0x0000c>
remote:   at System.Threading.Tasks.TpScheduler.TaskExecuterCallback (object) <0x00049>
remote:   at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>
remote:
remote: Native stacktrace:
remote:
remote:         mono() [0x4a7470]
remote:         /lib/libpthread.so.0(+0xf8f0) [0x7f65da5098f0]
remote:         /lib/libc.so.6(gsignal+0x35) [0x7f65da1a4845]
remote:         /lib/libc.so.6(abort+0x180) [0x7f65da1a8390]
remote:         mono() [0x634519]
remote:         mono() [0x6345a7]
remote:         mono() [0x6346f3]
remote:         mono() [0x4a9e2b]
remote:         mono() [0x4aacec]
remote:         mono() [0x4ab334]
remote:         [0x4022bde6]
remote:
remote: Debug info from gdb:
remote:
remote:
remote: =================================================================
remote: Got a SIGABRT while executing native code. This usually indicates
remote: a fatal error in the mono runtime or one of the native libraries
remote: used by your application.
remote: =================================================================
remote:
remote: /tmp/buildpack_9666220528175e2f55cab399251d611b/bin/compile: line 67:   202 Aborted                 mono ${NUGET_EXECUTABLE_PATH} restore -NonInteractive
remote:
remote:  !     Push rejected, failed to compile .NET app
remote:
remote: Verifying deploy....
remote:
remote: !       Push rejected to radiant-springs-2071.
remote:
To https://git.heroku.com/radiant-springs-2071.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/radiant-springs-2071.git'

Reverted back to cedar-14

C:\Users\Andrew\Programming\Websites\KatanaTest2>heroku stack:set cedar-14
Stack set. Next release on radiant-springs-2071 will use cedar-14.
Run `git push heroku master` to create a new release on cedar-14.

C:\Users\Andrew\Programming\Websites\KatanaTest2>git push heroku master
Counting objects: 16, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (16/16), 5.88 KiB | 0 bytes/s, done.
Total 16 (delta 0), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> .NET app detected
remote: -----> Downloading http://s3.amazonaws.com/mono-dependencies/cedar-14/mono-3.10.0.tar.gz
remote: -----> Compiling Mono application
remote: Stacktrace:
remote:
remote:
remote: Native stacktrace:
remote:
remote:         mono() [0x4b85c8]
remote:         mono() [0x510633]
remote:         mono() [0x423bc2]
remote:         /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fbbec258340]
remote:         mono() [0x544f1e]
remote:         [0x4065f65a]
remote:
remote: Debug info from gdb:
remote:
remote:
remote: =================================================================
remote: Got a SIGSEGV while executing native code. This usually indicates
remote: a fatal error in the mono runtime or one of the native libraries
remote: used by your application.
remote: =================================================================
remote:
remote: /tmp/buildpack_75071da2609c71c827e00308b4bcae00/bin/compile: line 67:   280 Aborted                 mono ${NUGET_EXECUTABLE_PATH} restore -NonInteractive
remote:
remote:  !     Push rejected, failed to compile .NET app
remote:
remote: Verifying deploy...
remote:
remote: !       Push rejected to radiant-springs-2071.
remote:
To https://git.heroku.com/radiant-springs-2071.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/radiant-springs-2071.git'

C:\Users\Andrew\Programming\Websites\KatanaTest2>git push heroku master
Counting objects: 16, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (16/16), 5.88 KiB | 0 bytes/s, done.
Total 16 (delta 0), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> .NET app detected
remote: -----> Downloading http://s3.amazonaws.com/mono-dependencies/cedar-14/mono-3.10.0.tar.gz
remote: -----> Compiling Mono application
remote: Installing 'Microsoft.Owin.Hosting 1.1.0-beta2'.
remote: Installing 'Microsoft.Owin.Host.HttpListener 1.1.0-beta2'.
remote: Installing 'Microsoft.Owin 1.1.0-beta2'.
remote: Installing 'Microsoft.Owin.Diagnostics 1.1.0-beta2'.
remote: Installing 'Owin 1.0'.
remote: Successfully installed 'Microsoft.Owin.Diagnostics 1.1.0-beta2'.
remote: Successfully installed 'Microsoft.Owin.Hosting 1.1.0-beta2'.
remote: Successfully installed 'Microsoft.Owin 1.1.0-beta2'.
remote: Successfully installed 'Microsoft.Owin.Host.HttpListener 1.1.0-beta2'.
remote: Successfully installed 'Owin 1.0'.
remote: XBuild Engine Version 12.0
remote: Mono, Version <IP_ADDRESS>
remote: Copyright (C) 2005-2013 Various Mono authors
remote: :  warning : Default tasks file /tmp/build_42846534974559ef4daeb9b3387651fc/mono/lib/mono/2.0/Microsoft.Common.tasks not found, ignoring.
remote:
remote: Build started 5/3/2015 7:18:56 PM.
remote: __________________________________________________
remote: Project "/tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest.sln" (default target(s)):
remote:         Target ValidateSolutionConfiguration:
remote:                 Building solution configuration "Release|Any CPU".
remote:         Target Build:
remote:                 Project "/tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest/KatanaTest.csproj" (default target(s)):
remote:                         Target CheckPrerequisites:
remote: /tmp/build_42846534974559ef4daeb9b3387651fc/.nuget/NuGet.targets: error : Unable to locate '/tmp/build_42846534974559ef4daeb9b3387651fc/.nuget/NuGet.exe'
remote:                         Task "Error" execution -- FAILED
remote:                         Done building target "CheckPrerequisites" in project "/tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest/KatanaTest.csproj".-- FAILED
remote:                 Done building project "/tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest/KatanaTest.csproj".-- FAILED
remote:         Task "MSBuild" execution -- FAILED
remote:         Done building target "Build" in project "/tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest.sln".-- FAILED
remote: Done building project "/tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest.sln".-- FAILED
remote:
remote: Build FAILED.
remote:
remote: Warnings:
remote:
remote: :  warning : Default tasks file /tmp/build_42846534974559ef4daeb9b3387651fc/mono/lib/mono/2.0/Microsoft.Common.tasks not found, ignoring.
remote:
remote: Errors:
remote:
remote: /tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest.sln (default targets) ->
remote: (Build target) ->
remote: /tmp/build_42846534974559ef4daeb9b3387651fc/KatanaTest/KatanaTest.csproj (default targets) ->
remote: /tmp/build_42846534974559ef4daeb9b3387651fc/.nuget/NuGet.targets (CheckPrerequisites target) ->
remote:
remote:         /tmp/build_42846534974559ef4daeb9b3387651fc/.nuget/NuGet.targets: error : Unable to locate '/tmp/build_42846534974559ef4daeb9b3387651fc/.nuget/NuGet.exe'
remote:
remote:          1 Warning(s)
remote:          1 Error(s)
remote:
remote: Time Elapsed 00:00:00.2839570
remote:
remote:  !     Push rejected, failed to compile .NET app
remote:
remote: Verifying deploy...
remote:
remote: !       Push rejected to radiant-springs-2071.
remote:
To https://git.heroku.com/radiant-springs-2071.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/radiant-springs-2071.git'

Previous step was unable to find .nuget/NuGet.exe, so checked it in and tried again

C:\Users\Andrew\Programming\Websites\KatanaTest2>git push heroku master
Counting objects: 22, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (22/22), 6.75 KiB | 0 bytes/s, done.
Total 22 (delta 4), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> .NET app detected
remote: -----> Downloading http://s3.amazonaws.com/mono-dependencies/cedar-14/mono-3.10.0.tar.gz
remote: -----> Compiling Mono application
remote: Installing 'Microsoft.Owin.Host.HttpListener 3.0.1'.
remote: Installing 'Microsoft.Owin 3.0.1'.
remote: Installing 'Owin 1.0'.
remote: Installing 'Microsoft.Owin.Diagnostics 3.0.1'.
remote: Installing 'Microsoft.Owin.Hosting 3.0.1'.
remote: Successfully installed 'Owin 1.0'.
remote: Successfully installed 'Microsoft.Owin.Host.HttpListener 3.0.1'.
remote: Successfully installed 'Microsoft.Owin 3.0.1'.
remote: Successfully installed 'Microsoft.Owin.Hosting 3.0.1'.
remote: Successfully installed 'Microsoft.Owin.Diagnostics 3.0.1'.
remote: XBuild Engine Version 12.0
remote: Mono, Version <IP_ADDRESS>
remote: Copyright (C) 2005-2013 Various Mono authors
remote: :  warning : Default tasks file /tmp/build_8f65bf5147cb11dd50da4713020fca67/mono/lib/mono/2.0/Microsoft.Common.tasks not found, ignoring.
remote:
remote: Build started 5/3/2015 7:21:03 PM.
remote: __________________________________________________
remote: Project "/tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest.sln" (default target(s)):
remote:         Target ValidateSolutionConfiguration:
remote:                 Building solution configuration "Release|Any CPU".
remote:         Target Build:
remote:                 Project "/tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest/KatanaTest.csproj" (default target(s)):
remote:                         Target CheckPrerequisites:
remote: /tmp/build_8f65bf5147cb11dd50da4713020fca67/.nuget/NuGet.targets: error : Unable to locate '/tmp/build_8f65bf5147cb11dd50da4713020fca67/.nuget/NuGet.exe'
remote:                         Task "Error" execution -- FAILED
remote:                         Done building target "CheckPrerequisites" in project "/tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest/KatanaTest.csproj".-- FAILED
remote:                 Done building project "/tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest/KatanaTest.csproj".-- FAILED
remote:         Task "MSBuild" execution -- FAILED
remote:         Done building target "Build" in project "/tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest.sln".-- FAILED
remote: Done building project "/tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest.sln".-- FAILED
remote:
remote: Build FAILED.
remote:
remote: Warnings:
remote:
remote: :  warning : Default tasks file /tmp/build_8f65bf5147cb11dd50da4713020fca67/mono/lib/mono/2.0/Microsoft.Common.tasks not found, ignoring.
remote:
remote: Errors:
remote:
remote: /tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest.sln (default targets) ->
remote: (Build target) ->
remote: /tmp/build_8f65bf5147cb11dd50da4713020fca67/KatanaTest/KatanaTest.csproj (default targets) ->
remote: /tmp/build_8f65bf5147cb11dd50da4713020fca67/.nuget/NuGet.targets (CheckPrerequisites target) ->
remote:
remote:         /tmp/build_8f65bf5147cb11dd50da4713020fca67/.nuget/NuGet.targets: error : Unable to locate '/tmp/build_8f65bf5147cb11dd50da4713020fca67/.nuget/NuGet.exe'
remote:
remote:          1 Warning(s)
remote:          1 Error(s)
remote:
remote: Time Elapsed 00:00:00.3034500
remote:
remote:  !     Push rejected, failed to compile .NET app
remote:
remote: Verifying deploy...
remote:
remote: !       Push rejected to radiant-springs-2071.
remote:
To https://git.heroku.com/radiant-springs-2071.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/radiant-springs-2071.git'

Updated to the latest Nuget packages (Microsoft.Owin / Microsoft.Owin.Diagnostics / Microsoft.Owin.Host.HttpListener / Microsoft.Owin.Hosting = v3.0.1)

C:\Users\Andrew\Programming\Websites\KatanaTest2>git push heroku master
Counting objects: 27, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (27/27), 279.69 KiB | 0 bytes/s, done.
Total 27 (delta 6), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> .NET app detected
remote: -----> Downloading http://s3.amazonaws.com/mono-dependencies/cedar-14/mono-3.10.0.tar.gz
remote: -----> Compiling Mono application
remote: Stacktrace:
remote:
remote:
remote: Native stacktrace:
remote:
remote:         mono() [0x4b85c8]
remote:         mono() [0x510633]
remote:         mono() [0x423bc2]
remote:         /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f15a9a61340]
remote:
remote: Debug info from gdb:
remote:
remote:
remote: =================================================================
remote: Got a SIGSEGV while executing native code. This usually indicates
remote: a fatal error in the mono runtime or one of the native libraries
remote: used by your application.
remote: =================================================================
remote:
remote: /tmp/buildpack_83508b160944cf6ab0c1a7fdbdfc1f03/bin/compile: line 67:   233 Aborted                 mono ${NUGET_EXECUTABLE_PATH} restore -NonInteractive
remote:
remote:  !     Push rejected, failed to compile .NET app
remote:
remote: Verifying deploy...
remote:
remote: !       Push rejected to radiant-springs-2071.
remote:
To https://git.heroku.com/radiant-springs-2071.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/radiant-springs-2071.git'

Could this be cause by the version of Mono not being compatible with the latest Owin libraries ? I tried with Mono 2.8 which didn't work and Mono 4.0 worked (On my local machine) - I couldn't find Mono 3.2 to try locally.

It could be because the mono that I compile doesn't have required components: https://github.com/friism/mono-builder
I'm not really working on this buildpack anymore - I've spent some time on the new ASP.NET stuff, although I haven't touched that recently either: https://github.com/heroku/dotnet-buildpack

Thanks for your reponse Michael.
ASP.Net 5 / vNext is something which I've been meaning to investigate for a while, but it's good to know that there's a buildpack that's ready and waiting for it. Sadly it's still using Mono 3.10 so for my immediate problem it doesn't resolve it, however.
I think I'll have to fork this project and give Mono 4 a go. I don't have an S3 bucket available so I'll probably modify it to download the binaries from GitHub while I'm at it. Will update this issue with the results.

Sounds good, check this out: https://github.com/SuaveIO/mono-script-buildpack/blob/master/bin/compile
This is how they build: https://github.com/SuaveIO/mono-builder

Sadly using Mono v4.0.1 didn't help, looks like Nuget.exe is now failing to run under Mono. I'm a little out of my depth as I don't have much experience with Mono - Can you offer any suggestions on this issue ?
$ git push heroku master
Counting objects: 27, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (27/27), 279.69 KiB | 0 bytes/s, done.
Total 27 (delta 6), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> .NET app detected
remote: -----> Downloading https://github.com/yngndrw/mono-builder/releases/download/1.0.0/mono-4.0.1.tar.gz
remote: -----> Compiling Mono application
remote: * Assertion at tramp-amd64.c:1115, condition `code - buf <= tramp_size' not met
remote:
remote: Stacktrace:
remote:
remote:   at <unknown> <0xffffffff>
remote:   at System.Text.EncodingHelper.get_UTF8Unmarked () <0x00048>
remote:   at System.Console..cctor () <0x00125>
remote:   at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
remote:   at <unknown> <0xffffffff>
remote:   at NuGet.Program.Main (string[]) <0x0009d>
remote:   at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) <0xffffffff>
remote:
remote: Native stacktrace:
remote:
remote:         mono() [0x4b67e8]
remote:         /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f5003d95340]
remote:         /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x39) [0x7f50039f6cc9]
remote:         /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7f50039fa0d8]
remote:         mono() [0x62b769]
remote:         mono() [0x62b96f]
remote:         mono() [0x62bab6]
remote:         mono() [0x512657]
remote:         mono() [0x4b96f9]
remote:         mono() [0x424e65]
remote:         mono() [0x4ac629]
remote:         mono() [0x4b7065]
remote:         [0x40ba9fa6]
remote:
remote: Debug info from gdb:
remote:
remote:
remote: =================================================================
remote: Got a SIGABRT while executing native code. This usually indicates
remote: a fatal error in the mono runtime or one of the native libraries
remote: used by your application.
remote: =================================================================
remote:
remote: /tmp/buildpack_5fe9530d9b325d2a93c6934971e868d0/bin/compile: line 69:   263 Aborted                 mono ${NUGET_EXECUTABLE_PATH} restore -NonInteractive
remote:
remote:  !     Push rejected, failed to compile .NET app
remote:
remote: Verifying deploy...
remote:
remote: !       Push rejected to mighty-escarpment-7013.
remote:
To https://git.heroku.com/mighty-escarpment-7013.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/mighty-escarpment-7013.git'

I don't know what could be causing this - again, I recommend working on the ASP.NET 5 stuff instead.

I seem to be getting the same issue with your ASP.Net 5 buildpack. I made my sample using the Visual Studio 2015 RC new web project template:
https://github.com/yngndrw/ASPNetTest
C:\Users\Andrew\Programming\Websites\ASPNetTest>git push heroku master
Counting objects: 18, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (18/18), 4.93 KiB | 0 bytes/s, done.
Total 18 (delta 2), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote: -----> Fetching custom git buildpack... done
remote: -----> ASP.NET 5 app detected
remote: Downloading http://s3.amazonaws.com/mono-dependencies/cedar-14/mono-3.10.0.tar.gz
remote: Downloading http://nodejs.org/dist/v0.11.14/node-v0.11.14-linux-x64.tar.gz
remote: /app/tmp/cache/cedar-14/node-0.11.14/node-v0.11.14-linux-x64/bin/grunt -> /app/tmp/cache/cedar-14/node-0.11.14/node-v0.11.14-linux-x64/lib/node_modules/grunt-cli/bin/grunt
remote<EMAIL_ADDRESS>/app/tmp/cache/cedar-14/node-0.11.14/node-v0.11.14-linux-x64/lib/node_modules/grunt-cli
remote: ├──<EMAIL_ADDRESS><EMAIL_ADDRESS>remote: ├──<EMAIL_ADDRESS>remote: └──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>remote: Downloading kre-mono.1.0.0-beta3 from https://www.nuget.org/api/v2
remote: Installing to /app/tmp/cache/kre/runtimes/kre-mono.1.0.0-beta3
remote: Adding /app/tmp/cache/kre/runtimes/kre-mono.1.0.0-beta3/bin to process PATH
remote: Setting alias 'default' to 'kre-mono.1.0.0-beta3'
remote: Project file configured in .deployment file
remote: Building /tmp/tmp.i7OrmlFBV3/src/ASPNetTest/project.json
remote: Restoring packages for /tmp/tmp.i7OrmlFBV3/src/ASPNetTest/project.json
remote: Stacktrace:
remote:
remote:
remote: Native stacktrace:
remote:
remote:         mono() [0x4b85c8]
remote:         mono() [0x510633]
remote:         mono() [0x423bc2]
remote:         /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7fb6b78f3340]
remote:         mono() [0x5fbcc7]
remote:         mono() [0x5fd2e3]
remote:         mono() [0x5d1599]
remote:         mono() [0x5d6b56]
remote:         mono() [0x5d7069]
remote:         mono() [0x5f3282]
remote:         mono() [0x5f3493]
remote:         mono(mono_array_new_full+0x1ea) [0x5b007a]
remote:         mono() [0x5b1045]
remote:         [0x40def8a4]
remote:
remote: Debug info from gdb:
remote:
remote:
remote: =================================================================
remote: Got a SIGSEGV while executing native code. This usually indicates
remote: a fatal error in the mono runtime or one of the native libraries
remote: used by your application.
remote: =================================================================
remote:
remote: /tmp/buildpack_f0f4b3adec8ec112aebc71837b7605ee/bin/compile: line 89:   354 Aborted                 kpm restore $K_FLAGS --packages ${KPM_CACHE_LOCATION}/.k/packages ${PROJECT_JSON_FILE}
remote:
remote:  !     Push rejected, failed to compile ASP.NET 5 app
remote:
remote: Verifying deploy...
remote:
remote: !       Push rejected to hz-aspnettest.
remote:

Warning: Your console font probably doesn't support Unicode. If you experience strange characters in the output, consider switching to a TrueType font such as Lucida Console!
To https://git.heroku.com/hz-aspnettest.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'https://git.heroku.com/hz-aspnettest.git'

I did also get an error when I had an empty wwwroot folder, but adding a blank .gitignore to ensure it gets committed resolved that:
...
remote: Building /tmp/tmp.gviySLXFEd/./src/ASPNetTest/project.json
remote: Restoring packages for /tmp/tmp.gviySLXFEd/src/ASPNetTest/project.json
remote: Resolving complete, 2520ms elapsed
remote: Installing Microsoft.AspNet.Diagnostics 1.0.0-beta4
remote: Installing Microsoft.AspNet.Server.WebListener 1.0.0-beta4
remote: Installing Microsoft.AspNet.Server.IIS 1.0.0-beta4
remote: Installing Microsoft.AspNet.Loader.IIS 1.0.0-beta4
remote: Installing Microsoft.AspNet.Loader.IIS.Interop 1.0.0-beta4
remote: Restore complete, 2686ms elapsed
remote: The specified wwwroot folder 'wwwroot' doesn't exist in the project directory.
remote:
remote:  !     Push rejected, failed to compile ASP.NET 5 app
remote:
remote: Verifying deploy...
remote:
remote: !       Push rejected to hz-aspnettest.
remote:
...

It's possible to work around nuget problem if you include packages folder in your repository and push it with sources.

I think I might have to, in the process of upgrading the buildpack to the latest ASP.Net DNX runtime I found I was also running into the package update / SSL issue and noticed that "certmgr -ssl https://nuget.org" was saying "*** WARNING: Certificate signature is INVALID ***".
I then found the following thread so it looks like mono isn't going to work with the latest nuget.org certifiate issued on 09/03/2015:
https://bugzilla.xamarin.com/show_bug.cgi?id=19031


Problem with Connect-AzureRM Account

I have a lot of Powershell scripting experience but I have never to use the graphical runbook tool so I started working my way through "My First Runbook". My AzureRM.Profile module did not have Connect-AzureRmAccount but did have Add-AzureRmAccount. However, it kept giving me an error "Name Parameter Not Configured" when I tried to save the runbook. I narrowed it down to the Add-AzureRmAccount commandlet. I selected the ServicePrincipalCertificate parameter set and configured all of the parameters per the instructions. I could not find any place where there was a missing name and after many tries it seemed clear that Add-AzureRMAccount was not going to work. I went back and imported a new AzureRM.Profile module. Now I had a Connect-AzureRMAccount commandlet (no Add-AzureRMAccount) BUT there is now no parameter set name ServicePrincipalCertificate. The closest is ServicePrincipalCertificateWithSubscriptionID.

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

ID: b1683116-76e6-ff15-aba7-54c95eabf882
Version Independent ID: 23274e28-3e28-f4c7-d59d-57ef1c441887
Content: My first graphical runbook in Azure Automation
Content Source: articles/automation/automation-first-runbook-graphical.md
Service: automation
GitHub Login: @georgewallace
Microsoft Alias: gwallace

@jhankins71 Thanks for your feedback! We will investigate and update soon on it.

@jhankins71 Thanks for reaching out.  Yes it looks like the parameter sets have changed.. you chose the correct one ServicePrincipalCertificateWithSubscriptionId.  If you follow the steps but use that parameter set, you will be able to log in successfully.. I will update the doc

thanks, Gearge!
We will now close this issue. If there are further questions regarding this matter, please reply and we will gladly continue the discussion.


fix typo in README.md

If I'm not mistaken, then the initial paragraph wants to say that "Rust [...] normally prevent[s] moving a type that has been borrowed from". Moving from a type I think will always make it unusable. :)

Yes indeed, thanks :)


gateway-config

gateway-config  Traceback (most recent call last):
gateway-config    File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
gateway-config      "main", mod_spec)
gateway-config    File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
gateway-config      exec(code, run_globals)
gateway-config    File "gatewayconfig/main.py", line 77, in
gateway-config      main()
gateway-config    File "gatewayconfig/main.py", line 30, in main
gateway-config      start()
gateway-config    File "gatewayconfig/main.py", line 66, in start
gateway-config      FIRMWARE_VERSION
gateway-config    File "/opt/gatewayconfig/gatewayconfig_app.py", line 31, in init
gateway-config      self.variant_details = variant_definitions[variant]
gateway-config  KeyError: None
What should I do.

he following ENV variables must be set: FREQ, SENTRY_CONFIG, SENTRY_DIAG, SENTRY_PKTFWD, and VARIANT
it must have something to do with it.
can this be??


PR to add new Northern Lights Applet

This is initialization of the Northern Lights applet into community. The applet displays the current Northern Lights data from the NOAA including the KP index, wind speed, Bz, and a brief summary of the most resent NOAA notifications. This data will show you the current space weather conditions for aurora level estimates.

I have read the CLA Document and I hereby sign the CLA

I have read the CLA Document and I hereby sign the CLA


updated basic calculator using C++

Expand basic calculator  and #3754

Close #3754

Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md

@MohitGupta121 sir kindly review and merge this PR


Fixed #30953 -- Made select_for_update() lock only queryset's model when using "self" with multi-table inheritance.

See ticket-30953, TODO:

[x] release notes,
[x] fix for using parent model's pointer in the of argument (test_for_update_sql_model_inheritance_ptr_generated_of),
[x] add _ptr to the list of choices in FieldError.

Thanks Abhijeet Viswa for the report and initial patch (#12082).
This patch presents two changes in the current behavior:

1st, select_for_update(of=('self',)) will lock a queryset's model instead of a parent model (data loss issue),
2nd, select_for_update(of=('self',)).values(...) won't lock any model when SELECT clause doesn't contain any columns from a queryset's model (this is a side effect of the main fix that is tested in test_for_update_of_self_when_self_is_not_selected, IMO the new behavior is the correct one).

buildbot, test on oracle.


Add Spec for MarketplaceOrdering Agreements APIs

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[*] The title of the PR is clear and informative. This swagger is already approved and merged into -pr by @ravbhatnagar , @dsgouda , PR Link - https://github.com/Azure/azure-rest-api-specs-pr/pull/125
[*] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[*] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[ ] If applicable, the PR references the bug/issue that it fixes.
[*] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[*] I have read the contribution guidelines.
[*] My spec meets the review criteria:

[*] The spec conforms to the Swagger 2.0 specification.
[*] The spec follows the guidelines described in the Swagger checklist document.
[*] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@prbansa,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

This has already been reviewed and approved in private repo. So signing off.

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-ruby

No modification for AutorestCI/azure-sdk-for-node


Missing Sign Textures

Still in the process of testing, but seemingly only getting this crash when placing (and thereby rendering) BM signs. Will update if I get any further info.
Crash Log: https://crashy.net/trZjPAZsJmsPMYXbTRl9

Try the latest version I just uploaded.
https://www.curseforge.com/minecraft/mc-mods/biome-makeover-forge/files/3863095

Yes, but also no. So it's not crashing anymore, but the textures are missing now. :D

That may be related to Sign Tools though? Testing without it... Willupdate

Ah yeah, that makes sense.
Not crashing is pretty good though, at least it's not going to lock anyone out of their worlds.
I'll get a proper fix out this weekend.

I believe this should be fixed in the latest version.
Yell at me if it's not.
https://www.curseforge.com/minecraft/mc-mods/biome-makeover-forge/files/3864585


Don't call GetDirectoryName on empty strings

since we pass empty paths when constructing from file objects.

Fixes #123


Added 3072-bit key length options.

This conforms to current recommendations and best practices for a
128-bit security margin.
2048 is still the minimum recommended, but 2048-bit RSA only aligns to a
112-bit security margin, roughly analogous to 3DES. AES-128, the
minimum recommended cipher, requires a 3072-bit RSA key and a 256-bit digest
(SHA256) to provide an equivalent security level in all cryptographic
components.

Need to further test this.

Additional question: Where are we sourcing the sample DH parameter files from?

This should be split in two: 3072 bits for certificates and 3072 bits for DH. For the latter it may be more favourable to avoid adding a lot of "odd" DH default params to the system, because...
... to answer your question we sporadically provide new parameters and it takes a long time to update them if they grow in number (and bit size).

I know it's a standard, but if I regenerate fr a release it already takes a while, adding more standard sizes will make it even longer, making it less likely to provide new files for the existing ones.

So, more to the point, you should not be generating DH parameters for releases. You should be using the default ones from RFC 7919. If the end-user wants to use custom parameter sets, they should generate them themselves.

So, more to the point, you should not be generating DH parameters for releases. You should be using the default ones from RFC 7919. If the end-user wants to use custom parameter sets, they should generate them themselves.

Fine, so who will do the work necessary to avoid lower security in these circumstances? When will we be switching to a default regeneration of DH parameters and how will it be done? How do we minimise the gap between using default parameters and custom parameters in new installs? Do we have all the code in place or do we need to do more? How much measurable security will we gain from doing what is suggested here?
Besides this my review points still stand... if you want a change merged please split it into Cert and DH parts...

Fine, so who will do the work necessary to avoid lower security in these circumstances?

You're already lowering security by generating your own DH parameter sets with each release. This is woefully at odds with cryptographic best practices. There are reasons that standard DH parameter sets exist: These standard sets have been audited to ensure that weak values haven't been selected as a result of bug/accident/malice. By generating your own and including them as the default sets in the release, you're asking every OPNsense end user to trust you. The simpler response, both technically and administratively, is to ship the standard DH parameters from RFC 7919. The end user is using audited parameters that are widely regarded to be safe (they've been used with IPsec for years), and you don't have to deal with generating parameter sets (a long and tedious process.)

When will we be switching to a default regeneration of DH parameters and how will it be done?

DH parameters aren't keys. They're not private. They don't need to be regenerated unless some issue is found with the parameter set itself. That's another virtue in using standardized parameter sets: if an issue is discovered with a DH group from RFC 7919, it will be widely known and publicized. Having some cron-based regeneration of DH parameters is, at best, unnecessary, and at worst dangerous if the end user's system generates unsafe values for some reason. I'm all for giving the user the choice, though it's not a good idea, but the question here is what values should be included with the release. The answer to that has been given.

How do we minimise the gap between using default parameters and custom parameters in new installs?

The most extreme answer would be "Don't use custom parameters." The default (RFC 7919) parameters are the safest option.

Do we have all the code in place or do we need to do more?

Given the recent commits surrounding this issue, I'd have to go back and look at what was added or removed. At least a portion of my merge request is needed to utilize 3072-bit DH parameter sets.

How much measurable security will we gain from doing what is suggested here?

That depends on your risk profile and tolerance. For most users, this would be a transparent change whose benefits may never be observed. In raw terms, shipping audited and standard values provides an assurance that the values included with the release were not tampered with or poorly-generated. A "nothing up my sleeve" number, if you will.
The Mozilla Foundation states this advice explicitly. Server-Side TLS While the page itself may offer guidance on configuring web servers, the rest of it is fully-applicable to anything participating in TLS connections.

We've been following up on https://weakdh.org/sysadmin.html ever since 2015 and this is the first complaint that it's all wrong. What you state here is therefore news to me. On first glance I cannot find enough info to back up your claims, so I'll park this PR and ask around to give it the benefit of the doubt it deserves and I wish you will do the same for what we have currently in place.

Ah, thanks for the clarification.

I'm going to undo the commits to the DH portions so that the cert parts can go in under this PR, and I'll submit a DH-specific PR later if its agreed upon.

Done.

Merged, thank you.
As for RFC 7919, how about we make them optionally usable? We already have a mode selector in the development version. This also means one day we could switch to them by default in new installation and not take anything away from existing users.

Because we're not making RFC 71919 a default unless the community is willing to support this move. So the community needs to be engaged, best by shipping options to them to try out and discuss further in the forum. :)
Other issue is that 1024 is not provided by RFC, but still of deprecated use in existing installs so you end up with a mixed or broken environment on upgrade if we were to do the switch. As a stopgap we'll be bumping the defaults in OpenVPN to 2048 with 18.1.10 and then give RFC a fair chance on 18.7 so that we could switch to it by default when 19.1 is out.

The "wisdom of crowds" approach is not the correct approach where crypto is concerned. The fact that you accepted a pull request predicated on the idea that periodic regeneration of DH groups is good or necessary is proof of that fact. Do what you will, but this is the wrong approach.

Your mind is set; I have no reason to change it. :)

My mind isn't the issue. I have standards and best practices on my side, reinforced with documentation. You're choosing to ignore that, which is strange to me.
You accepted a pull request regarding DH params with "a couple dudes talked about it on IRC" as support, but you resist this proposal when an actual RFC exists in support of the proposal with the statement of "we're not doing this unless the community supports it." Talk about double standards. I won't be contributing further to this project.

You have:

Asserted that you set your opinion above a community voice in an open source project scope.
You continue to be pushy with no regard for other people's schedules, ideas and explicit questions to give "the benefit of the doubt".
Have failed to realise that 90% of what you asked is already in the development version.

Feel free to not back off, but in any case this is the last you see of me responding.
Thanks,
Franco

Asserted that you set your opinion above a community voice in an open source project scope.

No, I have asserted that I set standards above the community voice, especially when the community has already shown that they don't know how to properly handle crypto.

You continue to be pushy with no regard for other people's schedules, ideas and explicit questions to give "the benefit of the doubt".

Schedules were never discussed. The ideas were ill-formed, either unsupported or predicated on old information. And why should anyone give "benefit of the doubt" when there should be no doubt? You're mishandling crypto, end of story.

Have failed to realise that 90% of what you asked is already in the development version.

Does the development version adhere to standards? No? Then how is this even relevant?

Feel free to not back off, but in any case this is the last you see of me responding.

Again, that's on you. I have the knowledge and expertise to render a judgment on this. It's a shame you choose not to benefit from it.

that they don't know how to properly handle crypto.

Your assertion is wrong and it makes you act like a less than favourable human being. People live and learn, either with you or without you. I'm closing this thread, because you continue to deviate from the topic for attacks because you don't get what you want.


[BEAM-4374] Shortids for the Go SDK

A quick unblocker for current proto changes. Adds Short ID handling for the Go SDK.
There are likely some performance improvements that can go in around the single lock, either moving them to a RW lock or a sync.Map, but this should be fine for Batch cases at present, until we measure differently.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Run Go Postcommit

R: @lukecwik

This code drifts slightly from https://github.com/apache/beam/pull/11184, which removes the OneOf in favour of always using the payload format. This version still uses the oneof, but only populates payload.

A rather large refactoring occurred. For one, I wasn't initializing the maps properly which correctly caused postcommit failures.
Now I've moved that verification to tests, and made the cache easier to test.

Run Go Postcommit

Just as a note, I'll wait until https://github.com/apache/beam/pull/11184 is in, and resolve the merge conflicts on my end before we merge this one.

Run Go Postcommit

Run Go Postcommit

R: @youngoli @lukecwik
I can't wait to get rid of both of the legacy stuff and the older monitoring info listing. That function is becoming crufty.


Inference with mixed precision

Hello, I am wondering if the inference code can run at mixed precision?
For example, if I modify run_pretrained_openfold.py line 254 from
out = run_model(model, processed_feature_dict, tag, args.output_dir)
to
with torch.cuda.amp.autocast(enabled=True):
        out = run_model(model, processed_feature_dict, tag, args.output_dir)

I see that the plddt score becomes nan. Is this expected behavior?
I am using protein 7ZCV from PDB.
@gahdritz please share your thoughts.

Hi @gahdritz @sachinkadyan7 Following up on this to see if you have any thoughts?


When will the code be released?

Thank you for your excellent work. May I ask, when will the code be released?

Thanks for your interest. Code released.


Building and install software onto new 4 Arm Windows machines.

Type of Request
bug
Infrastructure Environment
LUCI, Github, Cocoon scheduler, Autosubmit, etc...
What is happening?
Building and install software onto new 4 Arm Windows machines.
Steps to reproduce
Step 1:
Step 2:
..
Step n:
Expected results
I expect to see X when Y is finished.

bots are setup, win-17..20


Custom Message along with the notifications core message

@YOU54F  I think it will also be helpful to certain users, who can actually set some custom static message, which can be passed through the CLI itself?
do you have something like that? and let me know how this feature request sounds like? I can make a PR for that, incase makes sense.

No don't have anything in place for that at the moment.
There are a few different items you can attach to the message, ie snippets etc, but you may just want some additional plain text.
I would definitely look at merging any proposed PR so if you do feel like it, feel free! :)

alright! and thank you. I could not get much time on this, but I feel it will be a great addition.

Heye @saikatharryc
Would you want to replace any of the text, or just add something additional? If so, where would you add it?
https://github.com/YOU54F/cypress-slack-reporter/blob/master/samples/alerts.png
I'm looking to refactor this soon, so will support this as a feature

this all is fine, for me somehow it does not show the branch name.
so , if can pass some additional text dynamically would be great. as header. or initial text. which will/might override Cypress test run failed

@saikatharryc what command are you using to run it and which CI server? I can see you don't have any git info in your message, which would be why the branch isn't showing.
I have a branch I am working on and you will be able to pass --custom-text "your text here" and have it show up 👍🏽 Will let you know when it is out

I have a branch I am working on and you will be able to pass --custom-text "your text here" and have it show up 👍🏽 Will let you know when it is out

That's awesome!!!!
Thanks a lot for this,
and ,
I'm using this command:
"cypress-slack-reporter": "^0.7.1"
npx cypress-slack-reporter --report-dir ./mochareports --vcs-provider=none --ci-provider=custom --custom-url=<MY_CUSTOM_GITHUB_ENTERPRISE_URL>

This is now available on the latest version 1.0.2
	npx cypress-slack-reporter --custom-text "some custom text"

Ahh yeah with vcs-provider set to none, you wont get any git metadata


Bump k8s dependency to 1.27.8

What type of PR is this?

What this PR does / why we need it:
Bump k8s dependency
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

@zirain help review the cluster operator change caused by cluster API upgrade

overall lgmt, CI is failed.

I am concerned the cluster operator upgrade, because we have no env to test now


Unify Windows testing between PR and release jobs

The nightly/release jobs run more Windows builds than the PR job: the PR job only runs windows_testing.py with Visual Studio 2013 and mingw, whereas the nightly/release jobs test with all supported versions of Visual Studio (in 2.2x and 3.x, at the time of writing, that's 2015 and 2017). This is rarely a problem in practice because we rarely change Windows-specific things and we test with the oldest supported version, but it does introduce risk when merging a PR.
The goal of this task is to make Windows testing identical in all CI jobs, without meaningfully reducing the test coverage and without significantly increasing the typical lead time for a run of pr-head.
To keep the load moderate, we may want to do https://github.com/ARMmbed/mbedtls-test/issues/26 first.
Also, to keep the lead time for pr-head low, we may want to run some mostly-but-not-completely redundant tests only in pr-merge (and in non-PR jobs) and not in pr-head.

https://github.com/Mbed-TLS/mbedtls/pull/7462 passed VS2013 (the pull request CI passed) but broke VS2015. This is the first time I remember seeing this happen.


Possibility to display the chart sorted by text field

Hello! First of all, thank you very much for the work and effort you put into this plugin, it's really helpful.
We use Prometheus queries to get the start time and the end time of each task, and according to the Grafana Query Inspector the raw results of the queries are sorted the way we want it, but on the chart itself, it seems that the data is reordered by Start Time.
The question is, is there an opportunity to display blocks of data sorted by the text field (taking as an example the picture from the plugin overview https://grafana.com/grafana/plugins/marcusolsson-gantt-panel to display the blocks not ordered by start time( extract, transform, load), but ordered alphabetically by text field: extract, load, transform )?
Thank you very much!

Thank you for trying out the plugin, and for taking the time to suggest how to improve it!
I don't see any problems adding this 👍


[2.6] Use Norman cloud creds for all the things

Addresses https://github.com/rancher/dashboard/issues/3624 (backport to 2.6)


Optimize FlinkEngineConn abilities of FlinkCodeOnceExecutor and fix some bug.

What is the purpose of the change
Optimize FlinkEngineConn abilities of FlinkCodeOnceExecutor and fix some bug.
Brief change log

Resolve the bug that will cause ExistingSimpleOnceJob throws NPE when get OnceOperators.
Optimize the close logic of OnceExecutor.
Optimize the close logic of FlinkCodeOnceExecutor.
Optimize the job status fetching logic, add the ability of retry.
Change com.webank.wedatasphere.linkis to org.apache.linkis.
Optimize the method visibility scope of RetryHandler.
Resolve the compilation problem of flink EngineConn.

LGTM.


When trying to minify ng-map.js along with other scripts, the application fails. But it is ok with not minified version

Error: [$injector:unpr] Unknown provider: _Attr2MapOptions_Provider <- Attr2MapOptions <- __MapController
http://errors.angularjs.org/1.4.3/$injector/unpr?p0=_Attr2MapOptions_Provider <-Attr2MapOptions_ <-%__MapController
at file:///android_asset/www/scripts/vendor.js:1:2302
at file:///android_asset/www/scripts/vendor.js:1:21642
at Object.d [as get] (file:///android_asset/www/scripts/vendor.js:1:20812)
at file:///android_asset/www/scripts/vendor.js:1:21739
at d (file:///android_asset/www/scripts/vendor.js:1:20812)
at Object.e [as invoke] (file:///android_asset/www/scripts/vendor.js:1:21149)
at l.instance (file:///android_asset/www/scripts/vendor.js:2:11186)
at q (file:///android_asset/www/scripts/vendor.js:2:842)
at h (file:///android_asset/www/scripts/vendor.js:1:29318)
at h (file:///android_asset/www/scripts/vendor.js:1:29341)

our minification works well on version 1.13.15

I have tested it with gulp minifier, and it worked well. Can you give you your instruction how to minify it?

we are using grunt uglify

I ran into a very similar, if not identical issue.
Turns out it wasn't the minification (I use gulp-uglify) at fault.
I needed to update to a newer version of gulp-ng-annotate, which fixed it.
Hope this helps.

sadly, i get the same error with grunt-ng-annonate ^0.2.3 .
Any tips?

It seems upgrading grunt modules is the likely solution, closing this issue.


Bug: shallowMount fails on vue 3.2.32, works on 3.2.31

Describe the bug

When using vue 3.2.31 everything works, but using 3.2.32 tests fail with errors like:
    X is undefined
    jo@webpack:///node_modules/@vue/test-utils/dist/vue-test-utils.esm-bundler.js:7984:5 <- index.js:37:13453
    Oo@webpack:///node_modules/@vue/test-utils/dist/vue-test-utils.esm-bundler.js:7993:12 <- index.js:37:13720
    @webpack:///test/unit/specs/components/rich_content.spec.js:52:21 <- index.js:49:498525

To Reproduce

use shallowMount with a jsx component?
https://git.pleroma.social/pleroma/pleroma-fe/-/jobs/208665
Expected behavior

works with vue 3.2.32
Related information:

@vue/test-utils version: 2.0.0-rc.19
Vue version: 3.2.32
node version: v16.14.2
npm (or yarn) version: 1.19.2

Additional context

Hi @hjri
This is indeed an issue, but we already have a PR to fix this #1418
The fixed version should be released in the next hours.
I'll let the issue open until the release, in case someone else encounters it.

VTU v2.0.0-rc.20 is now out with the support of Vue v3.2.32


Bug in flappy bird demo - No ceiling

I was able to click the spacebar a bunch and fly over all the pipes and beat the game. It seems like there should be an upper level preventing you from doing that.
I used chrome v 91

#85 - I created a PR for this.

Hey! Thanks for the PR, but actually I'd prefer to have it just die if it's too high up: 8c9ee81 (also the 0.001 height rect might not trigger collision because the birdy might move through it between frames)


Redirect http:// to https:// - Chrome tells me constructs.dev is not secure

If users hit http://constructs.dev they need to be redirected to https://constructs.dev

I'm unable to reproduce this on Chrome/Firefox/Safari, and on multiple different devices - I always get redirected to HTTPS pages. I'm wonder why this is? (maybe some difference from default browser settings, etc.)


‼ ZePython: Integrate Partial Refresh

As soon as https://github.com/gdg-berlin-android/ZePython/issues/1 is implemented, update ZeBadge to take benefit of it.
Also build more Apps on ZeBadge that benefit from it. ZeIdleCoder could benefit greatly from it, so does ZeNotes, ZeThings and ZeStuff! Do it all.

This won't happen before Droidcon. We need a new approach, but we ran out of time.


Package.json refers to 'WASP'

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Checked the FAQs for common solutions: https://github.com/digicatapult/dscp-ipfs/blob/main/CONTRIBUTING.md/#FAQs
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Adscp-ipfs

Description
Package.json refers to WASP on lines 4 and 25
Steps to Reproduce

Expected behaviour:

Actual behaviour:

Reproduces how often:

Versions

Additional Information

Fixed by the engineering team


This is an attempt to fix coverall issue with jruby

Coverage remained the same at 98.08% when pulling 8b148303183c1f053c3ce87149316cb1b780f997 on sophiedeziel:coverall_config into ed42fb2717702764473ee88343dec9e46c1931da on kernow:master.

Coverage remained the same at 98.08% when pulling 8b148303183c1f053c3ce87149316cb1b780f997 on sophiedeziel:coverall_config into ed42fb2717702764473ee88343dec9e46c1931da on kernow:master.

Coverage remained the same at 98.08% when pulling 8b148303183c1f053c3ce87149316cb1b780f997 on sophiedeziel:coverall_config into ed42fb2717702764473ee88343dec9e46c1931da on kernow:master.


Inspector project setup

A user should be able to setup an inspector project.

After clicking on "Create project" button in the extension's tab, a user should be given an option to create either "classical" project, or "inspector" project.
User should be prompted to provide a name for the project.
A TypeScript file which contains an entry point of scene's TS program should be created.
An asset package with name set by user at step 2 should be created.

How project types differ?