Difficult to read (Linux/Firefox)

The light grey text in https://perldoc.pl/ is not easy to read
Any chance of changing css so that it renders in black ?

What browser/OS are you using? There's no light grey text for me...

Thanks for super-quick reply

Screenshot of https://perldoc.pl/ attached

Screenshot of https://perldoc.pl/

Thats Mozilla Firefox 52.0.2 (32-bit)
running on  Ubuntu 12.04

On 06/25/2018 08:47 AM, Dan Book wrote:

What browser/OS are you using? There's no light grey text for me...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Grinnz/perldoc-browser/issues/2#issuecomment-399849125,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADrMv-73w9nZBUeB1p-MDnrDqKZZCoqiks5uAId3gaJpZM4U1ijf.

Screenshot lost in transmission:- trying again

I can confirm the issue, this seems to be an issue in font rendering in Firefox on Linux. As a workaround I can make the text darker in code blocks but it still does not look good, I'm not sure there's anything else I can really do about it.

Again - thank you for your quick reply.
I dont pretend to understand CSS
but fyi CTRL-SHIFT-C in my Firefox
says of the line « perl   Perl»
in the above screen shot    "color:#222;" ...
Perhaps a bit pale?
Full result of CTRL SHIFT C -
#wrapperlicious pre > code {
color: #222;
font: 0.9em Consolas, Menlo, Monaco, Courier, monospace;
line-height: 1.5em;
text-align: left;
text-shadow: #eee 0 1px 0;
white-space: pre-wrap;

#222 is nearly black. It used to be #4d4d4c, which looks like this in Chrome on Linux:

For Linux/Firefox I think it looks nice like this

by simply doing
``
#wrapperlicious pre > code {

    font: 0.9em Consolas, Menlo, Monaco, Courier, monospace;
    line-height: 1.5em;
    text-align: left;
    text-shadow: #eee 0 1px 0;
    white-space: pre-wrap;
  }

I don't see any difference here in Firefox by removing that color setting, as it then simply inherits the color #212529 from bootstrap CSS, which is just about the same as #222. But if your browser renders it better for some reason I see no harm in doing so.

Please let me know if there are still font rendering issues.

This is still a problem for me on Firefox 84.0.2 (64 bit) under Ubuntu 20.04.  In particular, comment lines in perl examples are very light gray, making them quite hard to read.  See the attached screenshot.

This is still a problem for me on Firefox 84.0.2 (64 bit) under Ubuntu 20.04.  In particular, comment lines in perl examples are very light gray, making them quite hard to read.  See the attached screenshot.

Thanks for the report. I am in the process of considering a new syntax highlighter which will likely change the colors used in these blocks, and will revisit after.

Thanks for the report. I am in the process of considering a new syntax highlighter which will likely change the colors used in these blocks, and will revisit after.

Sounds good.  Thanks for the quick response!

Sounds good.  Thanks for the quick response!

The new syntax highlighter has been deployed and is currently using the stack overflow light theme. Please let me know if this corrects the issue.

The new syntax highlighter has been deployed and is currently using the stack overflow light theme. Please let me know if this corrects the issue.

===============================================
                        Bruxelles
                         2021_01_22
                         My ref 61868

 Thank you. Now looking good; thats now
 Mozilla Firefox 52.0.2 (64-bit) running on Ubuntu 12.04

Richard H
===============================================
-------- Original Message --------
Subject: 	Re: [Grinnz/perldoc-browser] Difficult to read
(Linux/Firefox) (#2)
Date: 	Thu, 21 Jan 2021 19:55:39 -0800
From: 	Dan Book<EMAIL_ADDRESS>Reply-To: 	Grinnz/perldoc-browser
<EMAIL_ADDRESS>To: 	Grinnz/perldoc-browser<EMAIL_ADDRESS>CC: 	Walckiers<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>  The new syntax highlighter

https://github.com/Grinnz/perldoc-browser/commit/c22fce71ac01de49c413fd7e732a69609563c694
has been deployed and is currently using the stack overflow light
theme
https://github.com/highlightjs/highlight.js/pull/2802.
Please let me know if this corrects the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly,
view it on GitHub
https://github.com/Grinnz/perldoc-browser/issues/2#issuecomment-765103834,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5MZPZD47K2I4CURNQDIETS3DZLXANCNFSM4FGWFDPQ.
     -------- End of Original Message --------

On 22/01/21 04:55, Dan Book wrote:

The new syntax highlighter
https://github.com/Grinnz/perldoc-browser/commit/c22fce71ac01de49c413fd7e732a69609563c694
has been deployed and is currently using the stack overflow light theme
https://github.com/highlightjs/highlight.js/pull/2802. Please let me
know if this corrects the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Grinnz/perldoc-browser/issues/2#issuecomment-765103834,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5MZPZD47K2I4CURNQDIETS3DZLXANCNFSM4FGWFDPQ.

===============================================
                        Bruxelles
                         2021_01_22
                         My ref 61868

 Thank you. Now looking good; thats now
 Mozilla Firefox 52.0.2 (64-bit) running on Ubuntu 12.04

Richard H
===============================================
-------- Original Message --------
Subject: 	Re: [Grinnz/perldoc-browser] Difficult to read
(Linux/Firefox) (#2)
Date: 	Thu, 21 Jan 2021 19:55:39 -0800
From: 	Dan Book<EMAIL_ADDRESS>Reply-To: 	Grinnz/perldoc-browser
<EMAIL_ADDRESS>To: 	Grinnz/perldoc-browser<EMAIL_ADDRESS>CC: 	Walckiers<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>  The new syntax highlighter

https://github.com/Grinnz/perldoc-browser/commit/c22fce71ac01de49c413fd7e732a69609563c694
has been deployed and is currently using the stack overflow light
theme
https://github.com/highlightjs/highlight.js/pull/2802.
Please let me know if this corrects the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly,
view it on GitHub
https://github.com/Grinnz/perldoc-browser/issues/2#issuecomment-765103834,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5MZPZD47K2I4CURNQDIETS3DZLXANCNFSM4FGWFDPQ.
     -------- End of Original Message --------

On 22/01/21 04:55, Dan Book wrote:

The new syntax highlighter
https://github.com/Grinnz/perldoc-browser/commit/c22fce71ac01de49c413fd7e732a69609563c694
has been deployed and is currently using the stack overflow light theme
https://github.com/highlightjs/highlight.js/pull/2802. Please let me
know if this corrects the issue.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Grinnz/perldoc-browser/issues/2#issuecomment-765103834,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5MZPZD47K2I4CURNQDIETS3DZLXANCNFSM4FGWFDPQ.

That is better, though I still wish all of the normal body fonts were darker.  Only bold text has good contrast, but bold is only used in a few places.  The vast majority of the text is still gray-on-gray, as you can see in this screenshot, which still makes it harder to read than it should be.

Compare the two attached screenshots.  You can see that in the second one -- the screenshot of github in which I am writing this comment -- the main text has much better contrast than in the other screenshot.

That is better, though I still wish all of the normal body fonts were darker.  Only bold text has good contrast, but bold is only used in a few places.  The vast majority of the text is still gray-on-gray, as you can see in this screenshot, which still makes it harder to read than it should be.

Compare the two attached screenshots.  You can see that in the second one -- the screenshot of github in which I am writing this comment -- the main text has much better contrast than in the other screenshot.


[3.x] Add horizon specular occlusion

Implements horizon specular occlusion. This helps reduce artifacts where you see the sky on the edges of e.g. tiles bricks etc.
before: GLES3

after: GLES3

before: GLES2

after: GLES2

Note: for some reason GLES2 suffers much less from this particular artifact. With horizon specular occlusion it looks almost perfect. At some point it may be worth exploring what is going on to see if we can improve GLES3 similarly.

Note: for some reason GLES2 suffers much less from this particular artifact. With horizon specular occlusion it looks almost perfect. At some point it may be worth exploring what is going on to see if we can improve GLES3 similarly.

My guess is that the radiance/irradiance map is less detailed in GLES2 (and possibly darker), due to using a more approximate way to generate it. This would make the artifacts less noticeable overall.

Looks great! Does this take SSAO into account as well, or does it even rely on AO maps in the first place? Either way, I think this supersedes #50603.

Ah! I forgot your PR included horizon specular occlusion. This is just horizon specular occlusion and does not touch regular AO at all.
The big difference here is that the horizon specular occlusion is only factored in for the IBL and not for other sources of specular lighting.

Thanks!


Review the README

Description
The README of the nats-manager was merged before the technical-writers were mandatory reviewers, thus the README has not been reviewed fully.
Changes proposed in this pull request:
No real changes, just a PR to review the README as a whole
Related issue(s)

#79

/retest

/retest

/test all

/test pull-nats-manager-build

/retest

/test all

/test e2e


Issue #44

@zerline , I'll be reviewing it next week, thanks!

I'm not sure about the changes on the webpack configuration. No sure if that has any impact with extension installation. I'm tempted to just replicate the changes in the other files.

@mcmartins I'll have a look tonight or tomorrow. Feel free to suggest changes, I'll test them as well :)

@mcmartins I'll have a look tonight or tomorrow. Feel free to suggest changes, I'll test them as well :)

I'm not sure about the changes on the webpack configuration. No sure if that has any impact with extension installation. I'm tempted to just replicate the changes in the other files.

Do you not think useful to update the syntax? It is now much clearer. Of course, it also has to work. I'll give it some more time.

Hi Manuel
I've run this building again. I still get an error but it might be related to my own environment.
Regards,

Hi Manuel
I've run this building again. I still get an error but it might be related to my own environment.
Regards,

I constantly get this error (below, for ~20 files in francy dependencies)
Yet it seems to work .. Need to check.
ERROR in ./node_modules/francy-renderer-vis/src/canvas.js 20:2
    Module parse failed: Unexpected character '@' (20:2)
    You may need an appropriate loader to handle this file type.
    |   }
    |
    >   @Decorators.Data.requires('canvas')
    |   async render() {
    |     const canvasId = `Canvas-${this.data.canvas.id}`;
     @ ./node_modules/francy-renderer-vis/index.js 1:0-34 9:10-16
     @ multi babel-polyfill francy-renderer-vis

Hi @zerline, that error is because webpack cannot find the Babel modules required for the transpiration of decorators etc... you need the module.rules.loaders on the lab extension as well.
Cheers.

Hi @zerline, that error is because webpack cannot find the Babel modules required for the transpiration of decorators etc... you need the module.rules.loaders on the lab extension as well.

Hi @mcmartins
Yet @babel/plugin-proposal-decorators is there in package.json + in webpack.config.js. What else should be done?

Cheers.

Thanks, same to you

Many things changed since this, and I tried to address everything on #88


download_web_deps, CURLOPT_TIMEOUT too low

It seems like there is bug in curl libraries which prevents it from fetching the URL within the timeout specified in download_web_deps when a system doesn't have IPv6 connectivity and IPv6 is enabled (even IPv6 locallink), it takes more than 5 seconds to resolve.
Workaround :
$curl->setopt(CURLOPT_TIMEOUT, 15);
But then this makes it really slow to download the files needed. Other workaround is to disable IPv6 at the host.

can we run curl --4 ?

--4 works just fine. I should have specified.

Closed with a2fbfd7527eebad9716c6cce76ce0c80ffba44e3


assertObjectEquals ignores negative array indexes

This issue was imported from Closure Library's previous home at http://closure-library.googlecode.com
The link to the original issue is:
https://code.google.com/p/closure-library/issues/detail?id=418

This issue is being closed as a preparation step before archiving the repository.  See the README for more detail.


Bump version to 1.26.0

In preparation for the scheduled release tomorrow.

Failures:

https://github.com/grpc/grpc/issues/20677
https://github.com/grpc/grpc/issues/21221
https://github.com/grpc/grpc/issues/19726
https://github.com/grpc/grpc/issues/21230


Summary Data not shown when only 1 version

If we have 2 possible versions and only 1 is available, the metrics service currently returns a null for the summary metric:
      "SummaryOverTransactions": [
         {
            "Version": 0,
            "Count": 148,
            "Mean": 45.70898656756755,
            "StdDev": 27.50946164746194,
            "Min": 1.840404,
            "Max": 99.833308
         },
         null
      ],
      "SummaryOverUsers": [
         {
            "Version": 0,
            "Count": 56,
            "Mean":<PHONE_NUMBER>7142855,
            "StdDev": 86.54687524133293,
            "Min": 2.246336,
            "Max":<PHONE_NUMBER>0000005
         },
         null
      ]

Grafana does not handle this. No summary is shown. Can this be fixed in Grafana or does the metrics service need to change?
Histograms are fine.

This seems easiest to fix in the metrics server. Let me see what is possible in Grafana, though.


delayClickOutsideInit not working

I'm trying to use the directive to handle clicks outside images in a gallery. In my scenario, when user clicks on the image, it creates a overlay in the image. The problem is that when the overlay is active and the user clicks in this image/overlay, the directive detect as an outside click. I tried to use  [delayClickOutsideInit]="true", but didn't work. Here is my code:

		  Selected

I also tried to set excludeBeforeClick to true, but without success. Am I doing it in the right way?

I had similar problems using the directive in the following HTML structure (simplified):

I don't know why this is happening but the solution was to remove the most inner *ngIf and just hide this element instead using a binding to the hidden attribute:

The drawback of this solution is that the element will not be removed from the DOM. It's not a problem until you have many elements ore bindings inside the *ngIf / hidden element.

Some weeks trying to find a better solution without use hidden attribute, but I failed. However, hidden atributte is enough for me. Thanks for your help.


Fix update external generators

Previously, the cookiecutter externsion was raising an exception for every attempt of --update, which is not nice now that we have built-in support for version update.
This PR fix this behavior, by ignoring the extension and just displaying a warning to the user instead.
The django extension was changed accordingly.
Additionally, there is a workaround for #197.

Coverage increased (+0.02%) to 97.708% when pulling 2d0c237719a4606355fa5ff843441605d887b8d6 on abravalheri:fix-update-external-generators into 3589a599a5f1498f1aa050876d3fbc61f42c84bb on blue-yonder:master.


The sample code provided in this document does not work

Type of issue
Sample code doesn't work
Feedback
Is there a complete working project to assemble the code pieces?
Page URL
https://learn.microsoft.com/en-us/windows-hardware/drivers/devapps/print-support-app-design-guide
Content source URL
https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/devapps/print-support-app-design-guide.md
Author
@barrygolden

@victor8hpy, thanks for filing an issue with the Windows Driver Developer Documentation team.
There is no complete standalone code sample available for a Print Support App. However, I'll pass along the request for a standalone sample to the Print platform team.
Can you provide any additional information about where in the topic you hit a problem? Any additional details such as what versions of Windows and the SDK you are using could prove helpful in diagnosing the problem you hit in building a Print Support App. Also, any error messages in your build output could be useful as well.
You might also have success in posting your questions and comments in the following forums, where other driver developers and Microsoft engineers can be found.
Microsoft Q&A: Windows Hardware development
OSR Developer Community

Also, please note that GitHub issues will be discontinued on this repo on March 20, 2024. See issue #3808 for more information.

Closing this issue due to inactivity, please reopen if still needed.


Fix Race condition in tablename

Fixes https://github.com/jinzhu/gorm/issues/1407

I issued another PR with mutex in the proper scope.

fixed with https://github.com/jinzhu/gorm/pull/2022

@jinzhu #2022 does not resolve this race condition within TableName solved for in this PR (and #1958). The race condition resolved by this PR is due to the reading and writing of the defaultTableName attribute on the ModelStruct. #2202 provides no protections around this. Please consider opening and merging this PR in to resolve the issue of concurrent reads to TableName with an unset defaultTableName


XXE in XML Parser

The Issue
An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.
Where the Issue Occurred
The following code snippet displays the usage of XMLReader without disabling entities:
https://github.com/gchq/stroom/blob/336fa676d502cc38305fb0a97f8a5e407e8315a1/stroom-core-server/src/main/java/stroom/entity/util/XMLUtil.java#L114-L117

Fixed in v6.0-beta.8


Added bower install option

Still needs to be registered: e.g. bower register randexp git://github.com/fent/randexp.js.git

Thank you!

Wait hmm. I'm not sure I registered it correctly. After I ran bower install randexp, the downloaded folder doesn't include the build. I'm guessing because it's not in the repo.

Yeah… you'll need to release a new version (tag) in order to be picked up by Bower.

Ah ok. New tag added and seems to be working. Thanks for the help.

Glad everything works now. Also thanks for the quick merge! :-)


Commonalities version missing in the YAML

Problem description
the Commonalities version in the YAML is missing. In the info object under the version field (c.f. API-design-guidelines.md#info-object for an example):
x-camara-commonalities: 0.4.0
Expected behavior
add the version in the YAML

Addressed with: https://github.com/camaraproject/CallForwardingSignal/pull/67

new discussion on this topic: https://github.com/camaraproject/CallForwardingSignal/issues/72#issuecomment-2255132923

Fixed with: https://github.com/camaraproject/CallForwardingSignal/pull/68


Add ImageCache Actions color actions submodule.

Changes

I forgot to enable the imagecache_coloractions submodule in #4092, resulting in an error on the pitch page. This adds imagecache_coloractions dependency to enable the "Change file format" action.

Fixes #4130. For review: @aaronschachter

:+1:


[gh-pages][ZEPPELIN-990] Add header anchor to gh-pages branch

What is this PR for?
I applied header anchor to Zeppelin's docs website with #995 . It'll be good if gh-pages also has this header anchor.
What type of PR is it?
Improvement
What is the Jira issue?
ZEPPELIN-990
How should this be tested?
Run this branch locally as described in here and hover the mouse over any titles.
Screenshots (if appropriate)

Questions:

Does the licenses files need update? no
Is there breaking changes for older versions? no
Does this needs documentation? no

Tested, When i anchor click the link, that goes under the menubar. I think that need to be adjusted.

@Leemoonsoo Yeah didn't noticed that. I fixed it in my last commit. Could you check this out again? :D

Tested and LGTM

Merge if there're no further discussions.


Generate accesstoken based on keyvault config

Added extension method to generate access token by fetching certificate from keyvault

Description

Related Issue(s)

#{issue number}

Verification

[ ] Your code builds clean without any errors or warnings
[ ] Manual testing done (required)
[ ] Relevant automated test added (if you find this hard, leave it and we'll help out)
[ ] All tests run green

Documentation

[ ] User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

This involves keyvaukt integration and i'm bit confused on what kind of test will be sensible here. Any suggestions?

The issues I pointed out in my review has not been resolved and the pull request is very old now. Assuming that the feature is unnecessary and that you found an other way to support the use of KeyVault.
The feature request is still registered, so we might return to this at a later time.


Improve Error Messaging by Getting Rid of Resource Name

This is starting to get tedious and should have other ways to capture in the error message.

This issue is outdated, not applicable in 2.0.


Improve documentation for get_animation()

Resolves #65005

Updated doc for AnimationLibrary.get_animation() and AnimationPlayer.get_animation().
Made AnimationLibrary.get_animation() error message the same as AnimationPlayer's, with the requested animation name in the message.

Thanks!


Start development of project planning methodology and documentation

Build on the Commons Project Planning document to begin the development of our project planning methodology and the documentation surrounding it.

Recommendations that came out of the FAST metadata project retrospective: https://docs.google.com/document/d/1u87pyu2kqG1XYmEZkdFz9OhpryFq2j8fx8gDCp2wSvQ/edit?usp=sharing

A project brief template has been created based on the recommendations that came out of the FAST project retrospective:
https://docs.google.com/document/d/1bOPCBzC7B2QH-JDlDH8DzPrUp3gJNB682vIizZn0SEc/edit?usp=sharing


Added writer.wait_merging_threads call

Per advice in https://github.com/quickwit-oss/tantivy-py/issues/359#issuecomment-2430441432

I hope it's ok me stopping by, I just wanted to do a quick check on the merging_threads addition.

hopefully this doesn't hurt performance

In your code, it will definitely hurt async concurrency, but probably not data throughput for indexing. I don't know whether your application is sensitive to the concurrency impact or not.  Handwaving some numbers, if your application usually serves say 10k concurrent connections, a little blocking code like the writer interactions you have could drop that to, say 1k if it was in a hot path. It probably isn't, but using these made up numbers, but that's the kind of impact blocking code has inside async event loops.  (OTOH if you have very few concurrent IO-bound tasks/users then it probably doesn't matter)
wait_merging_threads makes it worse, but you already are doing blocking operations with the writer so this is an existing issue.
        async def _add_document() -> None:
            if not await self.filecheck(index_doc["file_location"], index_doc["body"]):
                try:
                    writer: IndexWriter = (await self.index).writer()
                    writer.add_document(Document.from_dict(index_doc))  # type: ignore[call-arg]
                    writer.commit()
                    writer.wait_merging_threads()

                    filehash = self.filehash(index_doc["body"])
                    (await self.index_files)[index_doc["file_location"]] = filehash
                    if document:
                        docs_index_dir = await self.docs_index_directory
                        async with await anyio.open_file(
                            docs_index_dir / f"{filehash}.{self.storage.extension()}",
                            "wb",
                        ) as f:
                            await f.write(self.storage.write_to_string(document))
                    self.changed = True
                except ValueError as e:
                    if "Failed to acquire Lockfile: LockBusy." in str(e):
                        raise AsyncRetryError("Failed to acquire lock.") from e
                    raise

The issue is that all interactions with the writer that touch disk are blocking, and wait_merging_threads is especially blocking. It doesn't normally take a long time, but even hundreds of milliseconds are going to tank your asyncio concurrency.  To resolve this, you would have to perform the writer operations inside a thread or a subprocess.  I had a quick look in the tantivy-py source and I don't think the writer operations release the GIL, which means you'll probably need a subprocess. This can be set up with run_in_executor.
It might look something like this (pseudocode):
def writer_stuff(index_path, index_docs):
    writer: IndexWriter = Index.open(index_path).writer(heap_size=1000 * 1000 * 1000)
    for index_doc in index_docs:
        writer.add_document(Document.from_dict(index_doc))  # type: ignore[call-arg]

    writer.commit()
    writer.wait_merging_threads()

And then at the call site
async def _add():
    ...
    index_docs = ...
    exe = concurrent.futures.ProcessPoolExecutor()
    loop = asyncio.get_running_loop()
    await loop.run_in_executor(exe, writer_stuff, index_path, index_docs)
    ...

This kind of code is annoying to write, because any parameters that cross the interprocess boundary do so in a pickle and that's why I pass the index_path instead of an index instance.   It may already be pickleable, I'm not sure.

(fyi @mskarlin @jamesbraza )

Hello @cjrh sorry we had some stuff that delayed me a bit on a response. Thanks for your thoughts/time here, it's much appreciated, and actually this PR turns out to be a massive win:

Index file count: 1000X smaller (21004 to 22 files)
Index size: 40% smaller (650 to 389 MiB)
Index build time: ~2X longer (anecdotally)
Runtime tantivy.Searcher.search performance: unchanged

So it turns out by not calling wait_merging_threads, we were missing out on tons of compaction.
I might suggest to tantivy-py to somehow tweak the interface on IndexWriter to make this more seamless, so other people don't miss out on this same gain.

Per your comment on multiprocessing/GIL, that is a great suggestion. I opened https://github.com/Future-House/paper-qa/issues/646 to make sure we track this possibility

good to hear 👍🏼
22 files sounds much more like what I was expecting.  You should no longer be seeing the memory error.


Update the UI of the website

Describe the feature to be enhanced
Currently, the website uses basic CSS and HTML, the Issue is set up so as to alter the background image as well update the navbar using Bootstrap and other tools.
Tasks
The website has to be appealing visually and must use Bootstrap and apply it for all the pages
Expected behaviour post enhancement
The expectation is for the website to be easy to use and great looking.
Going above and beyond would definitely help with getting brownie points.
Bounty rules

Bounty points -> If you have completed the tasks ( 40-70 points depending on how many features and how good looking it is)
Brownie points -> If you have added an extra feature that was not mentioned (15 points)
Enthusiasm points -> Added in the end if a PR has gone above and beyond (10 points)

can i work on this

can i work on this

can i work on this?

yeah, @siddarthpai  @xzov i have assigned you the issue, you can work on it now !! all the best


Popup Lookup

I need a lookup editor so that users can select record by filtering certain search criteria. (Popup looks like serenity main grid).
In serenity, Is it possible to use a grid as lookup?
Regards

Not possible with default lookup. You need to use bootstrap pull down or a dialog to show grid for selection, but i dont have a sample.

I want to show a icon at right of dropdown  just like inplace add. how can i do that?
After that how to show a dialog.

Check DateTimeEditor source for a sample


[Request] sendcoins all / openchannel all

Reason: Currently, if I want to spend 100% of my funds onchain OR spend 100% of my funds to a channel, I need to dance back and forth by overshooting it and seeing the error message telling me how much I need, subtract, then send the exact amount.
Flow

User specifies in the args that "I want to send as much as possible accounting for fees" ( ALL in place of the local_amt etc.)
lnd calculates the fees for the opening channel transaction normally, and subtracts that from available witness outputs (for openchannel) or all inputs (for sendcoins) and performs the send operation without interaction from the user.

I will give it crack!

@t4sk are you actively working on this?

@githubsands I am planning to work on this weekend but I am also happy to hand it over to you :)

AFAIK, this issue is still up for grabs!

This would actually be super useful. I might pick it up if nobody else has raised a PR.

For the openchannel case I feel like the main issue here is that the user has to guess the fee. For example the following flow is frustrating:
$ lncli walletbalance
{
    "total_balance": "16768865",
    "confirmed_balance": "16768865",
    "unconfirmed_balance": "0"
}
$ lncli openchannel 03dfb7ad0bda82ecb7b516a57c914bbcb71a58cf4f70d22d313731b33a9a7de3d0 16768865
[lncli] rpc error: code = Unknown desc = not enough witness outputs to create funding transaction, need 0.16776515 BTC only have 0.16768865 BTC  available

We could take the fee from local_amt by default, but the change of behaviour might surprise users. We could also add a new option such as --include-fee that makes it explicit that the local_amt includes the fee.
Finally, do we want to commit 100% to channel balances, or should we reserve a certain amount in case fees increase later on? From BOLT2:

Given the variance in fees, and the fact that the transaction may be spent in the future, it's a good idea for the fee payer to keep a good margin (say 5x the expected fee requirement); but, due to differing methods of fee estimation, an exact value is not specified.

a new option such as --include-fee

This should be sufficient.

do we want to commit 100% to channel balances

This could also be another arg.
So in summary:

Add --include-fee arg to openchannel and sencoins.
Add --ignore-fee-buffer for openchannel (assuming lnd is already calculating some buffer for fees that it is not allowing to be used for openchannel) to ignore the buffer and allow sending all funds to an openchannel.

I was confusing the fee for the funding tx and the commitment tx. In this PR I only really care about the funding tx.

See #2198

I will take a look and try to implement the functionality of this for opening channels.

Will be fixed by #4029.

Will be fixed by https://github.com/lightningnetwork/lnd/pull/6903


Error caused by PR1326

@whitneywhtsang
I got error for models with LoopOp recently. I suspect that the new changes to use new interface is the culprit
loop-test.txt
I attached a simple test case here. It should be named loop-test.mlir.
I tried this several days ago. I remember I got error complaining something like "env for IndexExpr not defined". At that time, I replaced it with an old version of Loop.cpp and it worked.
Today I got the error
Assertion failed: (originalLoops.size() == ubs.size() && "expected same rank"), function iterateIE, file /Users/tongchen/Projects/onnx-mlir/src/Dialect/Krnl/DialectBuilder.cpp, line 98.
Abort trap: 6

Same error are seen on the important medical models, which was compiled correctly after my krnl.region PR#1304.

@chentong319 Is the test for this loop case not yet in the current CIs?

@chentong319 Thanks for reporting, I will find the PR that causes the failure and revert it first.


feat: DEV-4095: Add last annotation created_at to Data manager

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.


Fix useService hook API docs

The service given to useService should be started with .start(), or else an error occurs.
This may be an obvious step but it took me awhile to realise (after looking at the test suites for react & vue) 😅

Good catch!


Support multiple databases

Hi, great package idea!
I noticed the package appears to only support mysql.
The code is in LogRouteUsage.php
DB::statement(
    "INSERT INTO route_usage
            (`identifier`, `method`, `path`, `status_code`, `action`, `created_at`, `updated_at`)
        VALUES (?, ?, ?, ?, ?, ?, ?)
        ON DUPLICATE KEY UPDATE `updated_at` = '{$date}'",
    [$identifier, $method, $path, $status_code, $action, $date, $date]
);

I think it would be possible to support multiple databases with a change in LogRouteUsage.php
I'll submit a pull request once I've got the tests passing 👍

+1

+1

+1

Hi 👋
I have release 0.4 with support for other databases: https://github.com/julienbourdeau/route-usage/releases/tag/0.4
Thanks for your help and inputs!


[BUG] When a service is binded to the cloud-service-broker-azure-X.X.XX app, we get "Error parsing VCAP_SERVICES: Error finding MySQL tag"

Description
We did a tile installation. So we create a p.mysql database for the cloud-service-broker database. We then create a access-key to that service and used that information in the  database settings of the "Service Broker Config" tab in the tile.
If we then bind a service to the cloud-service-broker-azure-X.X.XX app (Splunk log drain in our case), we get "Error parsing VCAP_SERVICES: Error finding MySQL tag" and the app doesn't start.
It appears like it's trying to find the database information from the VCAP_SERVICES.
If I then bind the cloud-service-broker-azure-X.X.XX app to my mysql database service. It then finds the VCAP_SERVICE information and the app starts normally and enables us to use the splunk log drain.
Expected Behavior
When binding another service, the cloud-service-broker should still use the information provided in the in the tile configuration.
Actual Behavior
When a service binding is present at the app start time, it looks in the VCAP_SERVICE for the mysql database.
Possible Fix
Be able to bind an external service and still use the configured database information and not look in VCAP_SERVICES if those settings are provided by the tile configuration.
Steps to Reproduce

Create a Mysql database
Install the tile and provided the access-key information of the Mysql database.
Bind a external service (ex: splunk log drain)
Restart the cloud-service-broker-azure-X.X.XX app

Context
We had to bind to the database and we must also keep our service-key in order to be able to provide that informaiton to the tile configuration. We then have to make available two set's of credentials to the cloud-service-broker app in order to be able to use our log drain.
Your Environment
Version used: Cloud service broker for Microsoft Azure 0.0.35
Platform (Azure/AWS/GCP): Azure
Applicable Services: Bosh 2.10.1 TAS: 2.10.3
Full error log
2020-09-16T15:18:13.720-04:00 [APP/PROC/WEB/0] [OUT] {"timestamp":"1600283893.719773531","source":"cloud-service-broker","message":"cloud-service-broker.Invalid VCAP_SERVICES environment variable","log_level":2,"data":{"error":"Error parsing VCAP_SERVICES: Error finding MySQL tag: The variable VCAP_SERVICES must have one VCAP service with a tag of 'mysql'. There are currently 0 VCAP services with the tag 'mysql'."}}
2020-09-16T15:18:13.720-04:00 [APP/PROC/WEB/0] [ERR] {"timestamp":"1600283893.719773531","source":"cloud-service-broker","message":"cloud-service-broker.Invalid VCAP_SERVICES environment variable","log_level":2,"data":{"error":"Error parsing VCAP_SERVICES: Error finding MySQL tag: The variable VCAP_SERVICES must have one VCAP service with a tag of 'mysql'. There are currently 0 VCAP services with the tag 'mysql'."}}
2020-09-16T15:18:13.774-04:00 [APP/PROC/WEB/0] [OUT] Exit status 1

@drebake Currently, the broker expects mysql bindings in VCAP_SERVICES if VCAP_SERVICES is present. There is no fallback to the environment variables when VCAP_SERVICES is present but there is no mysql binding found.
Is binding splunk log drain the only way to get splunk to collect logs from the broker?

I haven't investigated but there might be other ways, but that's how we currently have it configured for all our other apps. I think the issue is that the broker sees a VCAP_SERVICES since the log-drain is binded....
Shouldn't the broker look at the type of service binded before simply falling back to the VCAP_SERVICES for the database information?

The issue is that Google designed the broker to be installed as a tile (no VCAP_SERVICES) and didn't expect the split config. Since the broker itself is not doing anything with the splunk binding, its only expecting to be bound to a database.
There is no reason to bind these services to the broker, its not going to do anything with any of the credentials in VCAP_SERVICES. There must be some other side effect of the binding that splunk is using to collect logs, because the broker isn't doing anything to help splunk collect logs.
We'll have a look at fixing this issue.

@drebake check TanzuNet for 0.0.39-azure-beta! Closing this issue, but feel free to re-open if you give it a try and it doesn't work as expected.

I can confirm, we can now bind our Splunk drain and restart the broker app with no issues.
Thanks!


PiT 24.4: EndpointControllerConfiguration makes Spring boot based tests fail

Describe the bug
When upgrading to version 24.4.0.alpha3 the demo project hosted in spring project fails when running tests
I have tried to add the maven plugin to the build block as described in this issue, but still failing
***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method csrfChecker in com.vaadin.hilla.EndpointControllerConfiguration required a bean of type 'jakarta.servlet.ServletContext' that could not be found.

Action:

Consider defining a bean of type 'jakarta.servlet.ServletContext' in your configuration.

Problematic code is here
Expected-behavior
tests pass
Reproduction
## clone project and change to the folder `complete`
git clone https://github.com/spring-guides/gs-crud-with-vaadin.git
cd gs-crud-with-vaadin/complete
## Increase version
perl -0777 -pi -e 's|(<vaadin.version>)([^\s]+)(</vaadin.version>)|${1}24.4.0.alpha8${3}|g' pom.xml

## Add prereleases repositories
perl -pi -e  \
  's|(\s*)(</properties>)|$1$2\n$1<repositories><repository><id>v</id><url>https://maven.vaadin.com/vaadin-prereleases</url></repository></repositories>|' \
  pom.xml

perl -pi -e \
  's|(\s*)(</properties>)|$1$2\n$1<pluginRepositories><pluginRepository><id>v</id><url>https://maven.vaadin.com/vaadin-prereleases</url></pluginRepository></pluginRepositories>|' \
  pom.xml

## Run tests
mvn clean test

System Info
Vaadin 24.4.0.alpha3-alpha8

This was fixed a long time ago I think

It is still a problem, if you run the same project in 24.4.0.alpha20 it still fail the test with this error:
***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method csrfChecker in com.vaadin.hilla.EndpointControllerConfiguration required a bean of type 'jakarta.servlet.ServletContext' that could not be found.

Why do you have webEnvironment = SpringBootTest.WebEnvironment.NONE? Then you don't have a web environment and there is no servlet context

I believe webEnvironment = SpringBootTest.WebEnvironment.MOCK is clearly resolving this issue.
@manolo I'm closing this issue, but feel free to reopen if there were any other concerns.


Async operations

(moved from https://code.google.com/p/solrnet/issues/detail?id=120 )
Implement APM (begin/end pattern) for async operations.
APM is supported in .NET 3.5 and Task can easily wrap APM.

Has Async support added yet?

@erandr This issue is still open, feel free to contribute to the solution.

With .NET 4.6 just around the corner, and the TPL library being here to stay, it might be a good time for Solrnet to giving first class support to the current version of .NET instead of trying to support version 3.5.
At the moment, as I see it, the community wants to push this project forward, trying to add features the community desires, while you just pick the pull-request that don't harm your own projects.
Which is your right to do so, but it is a bummer for many potential contributers.
My proposed solution is to branch Solrnet into a legacy branch, which supports .NET 3.5, but have the main branch run ahead full steam.
Your thoughts?

I agree with gjunge's latest comment.
@mausch could you please reply? thanks

I also agree with gjunge opinion. SolrNet is a great project, but we should move forward and and async/await is really useful feature.

My suggestion would be to first take a look and see what are the priorities. So far I am inclined to think they would be:

SolrCloud
Support for newer versions of Solr, including breaking changes
Async support
Multiple .NET versions
NuGet

These are the ones that come to mind. I will put together a quick poll to get feedback and understand what are the priorities according to the users and then we can start working

I agree with you regarding the priorities, yet we have multiple contributors wanting to contribute. So we might be able to work on various items at the same time.
For Async support to be developed , a decision needs to be made on how to do it (support multiple .NET versions, for example like Newtonsoft.Json, or just 4.5 and up).
Hopefully enough people will answer the questionairre, so we can get a view on what .NET versions are in use by the SolrNet users.

Agreed. Will give it a few days to get more feedback.

Some work in progress over here: async-support branch

Closed


Allow for any rather than anyref in request parser

https://github.com/paypal/cascade/issues/86

Weird that the travis build hasn't started yet. Thanks for taking care of this, though. I'm going to go ahead and merge without waiting for the build since this won't make any tests fail and I know it compiles.