chore: update astro logo

What is it?

[ ] Feature / enhancement
[ ] Bug
[x] Docs / tests
[ ] Other

Why is it needed?

keeping brand logo up to date on docs

closes #807

Checklist:

[x] My code follows the developer guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have ran pnpm change and documented my changes
[ ] I have add necessary docs (if needed)
[ ] Added new tests to cover the fix / functionality

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

Hey @at-the-vr thanks so much for the PR.
What do you think about using the colored logo instead

Just a little preference on my end 🙈

The logo is in fact colored. I have made sure of it, sharing link to a loom recording for the changes. Working locally 💯, could appreciate if there was a Preview Build for everyone to review it properly

I added the gradient to light mode as well. I'll ask them if it's problematic.. But then I'd have to think of another way to display the two meta-frameworks logo, cause the colored qwik-city next to the black Astro feels completely off imo..

Thanks again @at-the-vr 🙏


add Spotify and Samsung Logo

hey @Hessam-Koucheki
Fix what?
Anyway...

Since I optimize all the files manually I won't accept pull requests with new logos. Please add your requests in the issues preferably with links to the vector files.


Implement Babel + Rollup.js to support ES Modules

I like this boilerplate, the setup is light and allow multiple sub-projects <3
What about allowing ES Modules capability using Babel + Rollup.js?
The implementation is simple, I use it for some projects: https://github.com/google/clasp/blob/master/docs/esmodules.md
Related issues: https://github.com/PopGoesTheWza/ts-gas-project-starter/issues/1

I am no longer actively using Google Apps Scripts in my projects; hence my late reply.
When I first design this template, I was strongly opiniated against using anything that wasn't necessary. Also GAS was still using the ancient Rhino engine.
Times have changed and I'll gladly review a PR.


Immoral

Dear @henrybatt ,
I trust this message reaches you well.
I was reading your "repository" and I couldn't help but notice that it appears to be written in "Lua", and not "Rust". I find this.... most perplexing, given your prior communiques to me about your passion for moral software.
Please rectify this immediately or I will be forced to contact the most relevant authorities. As I'm sure you are most aware, writing moral software is no laughing matter. It is our most imperative duty as Software Engineers - and most of all, good people of the Earth.
If you would like to circle back and link up in person regarding this communication, please, don't hesitate to "drop me a line", as it were.
Kind regards,
Mathias
Rust Moral Strike Force

IMPORTANT LEGAL DISCLAIMER:
This GitHub issue ("Issue") and all information contained herein is intended solely for the designated recipients identified by @henrybatt  and is considered STRICTLY CONFIDENTIAL and PRIVILEGED. By accessing this Issue, you acknowledge, warrant, and represent that you are one of the intended recipients and have been authorized to access this information.
UNAUTHORIZED ACCESS OR DISCLOSURE IS STRICTLY PROHIBITED.

Confidentiality:

The information contained within this Issue, including but not limited to, text, data, attachments, and any other materials, constitutes confidential and proprietary information of @henrybatt ("Confidential Information"). You are hereby expressly prohibited from disclosing, disseminating, reproducing, transmitting, or using such information in any way whatsoever, except in strict accordance with this Disclaimer and any applicable agreements between you and [Name of Organization/Entity].

Non-Waiver:

No waiver by @henrybatt  of any breach of this Disclaimer shall be deemed a waiver of any prior or subsequent breach. Each provision of this Disclaimer shall be severable from the others, and if any provision of this Disclaimer is held to be invalid or unenforceable, such provision shall be struck and the remaining provisions shall remain in full force and effect.

Disclaimer of Warranties:

THE INFORMATION CONTAINED WITHIN THIS ISSUE IS PROVIDED "AS IS" AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED.  [NAME OF ORGANIZATION/ENTITY] MAKES NO WARRANTY OR REPRESENTATION WHATSOEVER REGARDING THE CONTENT OF THIS ISSUE, INCLUDING ITS ACCURACY, COMPLETENESS, TIMELINESS, OR RELIABILITY.

Limitation of Liability:

TO THE MAXIMUM EXTENT PERMITTED BY LAW, IN NO EVENT SHALL [NAME OF ORGANIZATION/ENTITY] BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES ARISING OUT OF OR IN CONNECTION WITH YOUR ACCESS TO OR USE OF THIS ISSUE, EVEN IF [NAME OF ORGANIZATION/ENTITY] HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Governing Law and Jurisdiction:

This Disclaimer shall be governed by and construed in accordance with the laws of [State], without regard to its conflict of law provisions. Any dispute arising out of or relating to this Disclaimer shall be subject to the exclusive jurisdiction and venue of the courts located in [County], [State].

Entire Agreement:

This Disclaimer constitutes the entire agreement between you and [Name of Organization/Entity] with respect to the subject matter hereof and supersedes all prior or contemporaneous communications, representations, or agreements, whether oral or written.

Amendment:

This Disclaimer may be amended at any time by [Name of Organization/Entity] without prior notice.

Notice:

All notices and other communications hereunder shall be in writing and shall be deemed to have been duly given when delivered personally, sent by certified or registered mail, return receipt requested, postage prepaid, or sent by overnight courier service to the addresses set forth below:
If to [Name of Organization/Entity]:
[Address]
If to you:
[Your Address]

Severability:

If any provision of this Disclaimer is held to be invalid or unenforceable, such provision shall be struck and the remaining provisions shall remain in full force and effect.

Please note that this is a sample disclaimer and may not be suitable for all situations. You should consult with an attorney to ensure that any disclaimer you use is appropriate for your specific needs.

Thank you for your valuable feedback, we as a team shall take it onboard and discuss it at our next standup


Add fmt size_hints

Add a size_hint method to each of the fmt traits, allowing a buffer to allocate with the correct size before writing.
Rendered
cc @alexcrichton

I'm all for adding a hint for formatting. It would be nice in this RFC to mention unifying this with iterator size hints.
cc-ing @kballard and @thestinger, who I believe collaborated on adding Iterator::size_hint.
Does anyone know of anything using the Iterator::size_hint upper bound? I did a scan through the rust code base, and the only users I could find was other size_hint methods and tests. While semantically it'd be nice to have the lower and upper bounds of a collection, it's a bit of a shame we might be doing work that no one ever uses. Perhaps we should split things into a size_hint(&self) -> uint and a size_bounds(&self) -> (uint, Option<uint>)?
#46 is somewhat related to this RFC.

I don't know offhand of anyone using the Iterator::size_hint upper bound. I have a recollection a discussion a while back in which someone claimed that, after looking through the rust source, there were no users of it. At the time I defended its existence with theoretical use-cases that wouldn't be found in the standard libraries but might be found in third-party code, such as providing progress estimates for an operation that processes the results of an iterator chain. Or perhaps more applicable, there may be some use in having an Extend implementation that allocates more than the lower bound ahead of time, with the expectation that the "true" iterator count lies somewhere between the lower and upper bounds.
All that said, if the size_hint for fmt is just used for the allocation created by fmt itself, then if it's only using the lower bound, there doesn't seem to be much use in having the upper bound. Or is there a use-case for calling this size_hint in third-party code? Alternatively, would the fmt module perhaps want to experiment with pre-allocating some size in between the lower and upper bounds? I'm thinking some simple rule like allocating min(lower_bound * 1.5, upper_bound).

A drawback to this proposal: all manual implementations of fmt traits now have a second method to implement that must be kept in sync with the fmt() method.
Something to consider: A macro like write_size_hint!() that takes a format string and arguments, just like write!(), does, and generates a SizeHint from it. You'd need to keep the format string in sync with the write!() call but it would make implementing size_hint() easier in most cases.

Offhand, I am in favor of making formatting strings more efficient, especially if that makes "foo".to_string() more efficient.

That's exactly what I had thought with the range: if the range is large, it
might perform faster picking somewhere in the middle.
I looked at Iters size_hint for design, but they're a little different.
Iters hint changes depending on the position of the Iter. Also, fmt can
have nested calls, so those must be added.
@kballard perhaps debug_asserts could be added to ensure at the end that
the string is within the bounds, to catch when you forget to change both?
On Wed, Jan 14, 2015, 11:12 AM Kevin Ballard<EMAIL_ADDRESS>wrote:

A drawback to this proposal: all manual implementations of fmt traits now
have a second method to implement that must be kept in sync with the fmt()
method.
Something to consider: A macro like write_size_hint!() that takes a
format string and arguments, just like write!(), does, and generates a
SizeHint from it. You'd need to keep the format string in sync with the
write!() call but it would make implementing size_hint() easier in most
cases.
—
Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rfcs/pull/583#issuecomment-69972707.

I've got a different approach that does not change the API of Show or String (or anything else that third-party code is expected to implement). It's focused around optimizing the case of "foo".to_string(). The approach here is to add a parameter to std::fmt::Writer::write_str() called more_coming that is true if the caller believes it will be calling write_str() again. The flag is tracked in the Formatter struct so calls to write!() inside an implementation of Show/String don't incorrectly claim there will be no writes if their caller still has more to write. Ultimately, the flag is used in the implementation of fmt::Writer on String to use reserve_exact() if nothing more is expected to be written.
With this approach I'm seeing similar numbers for your to_string() benchmarks that I get with your code (once I re-enable the call to shrink_to_fit() that you commented out in your code). The downside is the "nested" benchmark ends up about 3% slower with my code compared to the stdlib version, although I haven't tried to figure out why yet.
test test::bench_long          ... bench:        64 ns/iter (+/- 3)
test test::bench_long_memcpy   ... bench:        36 ns/iter (+/- 3)
test test::bench_long_stdlib   ... bench:       110 ns/iter (+/- 5)
test test::bench_med           ... bench:        53 ns/iter (+/- 3)
test test::bench_med_memcpy    ... bench:        27 ns/iter (+/- 2)
test test::bench_med_stdlib    ... bench:        96 ns/iter (+/- 5)
test test::bench_nested        ... bench:       211 ns/iter (+/- 11)
test test::bench_nested_stdlib ... bench:       204 ns/iter (+/- 21)
test test::bench_short         ... bench:        53 ns/iter (+/- 3)
test test::bench_short_memcpy  ... bench:        28 ns/iter (+/- 1)
test test::bench_short_stdlib  ... bench:        76 ns/iter (+/- 1)

@kballard @alexcrichton I've updated the RFC with your comments.

Please benchmark number formatting. https://github.com/rust-lang/rust/issues/19218

Thanks for the additions @seanmonstar! Could you also add a part explicitly saying that everything will be #[unstable] to start out with? In theory that should allow us to immediately improve "foo".to_string() while preventing locking us in to SizeHint immediately as defining your own size_hint would be unstable by default.

I've also wondered if we could just add length hinting methods to fmt::Formatter, like hint_size(&mut self, usize) which avoids changing the trait at all.

@reem By the time you can call that, the buffer has already been allocated. And if the object has properties that are also going to be formatted, those properties can't tell the Formatter their hint until part way through the formatting.

@alexcrichton I added unstable attributes to the struct and method.

@seanmonstar

Could you add "all manual implementations of fmt traits now have a second method to implement that must be kept in sync with the fmt() method." to the Drawbacks section, as mentioned by @kballard above?  (At least, as I understand it, your choice is either to inherit the default impl, which is always correct but maximally inefficient, or to maintain this second method.)

Would it be possible for you to add number formatting to your benchmark suite, as requested by @mahkoh above?  (See also https://github.com/rust-lang/rust/issues/19218 )

Though really, I don't think either of these modifications really needs to block this RFC.  I'll try to ping @alexcrichton about getting it in front of the core team.

@pnkfelix I added the drawback. Regarding numbers, I imagine a minor improvement, since this reduces the number of allocations for the buffer. However, it seems the slowness in formatting numbers has more to do with that implementation, no?

@seanmonstar yeah probably

ping @alexcrichton

Hm I've been thinking about this recently, and I'm somewhat worried about the code size implications here. For example the size_hint on an iterator is almost never a concern because it's rarely used in a trait object so we can eliminate those that are never used.
With formatting, however, trait objects are its bread and butter, so we're forced to keep all size_hint implementations as well as have a little extra code to move them into place during format_args!. Could you do some analysis about the code size implications here? Some specific questions I have are:

What's the impact on the format_args! macro for moving size_hint onto the stack and passing it?
What's the average impact for a crate that just uses #[derive(Debug)]? Presumably these size_hint implementations cannot be optimized away and it's quite a common trait to implement.

I don't think that this will turn up any showstoppers, but I'd like to have a handle on what we're getting into. Otherwise I think that this is basically good to go so I'll see what we can do to get it merged soon afterwards.

ping @seanmonstar @alexcrichton

The RFC's current size_hint function does not know the formatting parameters, so presumably it must assume they are default. For a str, the width and precision can truncate or extend the output.
If there are format parameters, then the size_hint function for Arguments defined in the RFC can produce an incorrect hint, AFAICT.  Either the lower or upper bound can be wrong.  It can be fixed by returning (0, None) if Arguments::fmt is Some(..).
I wonder if size_hint should have a parameter giving it the format parameters. It could have &Formatter type or perhaps some new struct type.
I'm inclined to think the size hint should be Option<usize>, because as the RFC mentions, it's not clear how to use both bounds.

I tried to sum size hints in the expansion of format_args!. Most libraries were bloated by a few %. I think doing it with dynamic dispatch could be a slowdown with less bloat. Implementing size_hint for Arguments is not worth it either way. Take a look at https://github.com/rust-lang/rust/pull/16544.

ping @alexcrichton

@seanmonstar do you have any updates on the impact on code size here?

I do not. The branch I started is several months old, and I haven't had time to rebase. @rprichard raises some points worth considering, though.

Note: this RFC entered its Final Comment Period as of Yesterday; 6 days remain before a final decision will be made.

Don't make the decision until the discussion about size_hint deprecation for iterators is done. It would be silly to tag along on a deprecated name, if it goes that way.

Accepting this RFC does not require setting the name in stone. Though we all love to bikeshed names, I think we can all agree they're not really the most important part of this proposal.
Implementing this of course takes time, and landing it in stable even more.

Another alternative would be instead of including this method, for fmt to use a thread-local LruCache of sizes when formatting types. This would result in the first case not getting the speed benefit, but would mean that all implementations of a fmt trait can use a size hint, without requiring the size_hint method to be kept in sync with the implementation.

Having now gone through the final comment period, it's time to make a decision on this RFC. For now I'm going to close this RFC for the following reasons:

It's not clear what impact this has on large programs
Code size is a big worry here, but there are currently no statistics and/or analysis for this RFC.
There are lingering questions about size_hint on iterators in terms of naming.
It's somewhat unclear whether this API should diverge from the Iterator::size_hint API in terms of return values

Overall it seems best to start this RFC fresh again with a new look beyond microbenchmarks to the statistics measured here, and also perhaps await the outcome of #1034. Thanks regardless for the RFC @seanmonstar!

like gankro said, the name is a non-issue.


HA page does not render (JS issue?)

Describe the bug
Home Assistant loads only the HTML, but no redirect to login is performed.
To Reproduce
Steps to reproduce the behavior:

Enter HA url (IP address)
Go to DASHBOARD

Expected behavior
Redirect to login and show home assistant page
Smartphone (please complete the following information):

Device: 791 (cheap chinese 7 inch tablet)
OS: Android 5.1.1
Browser stock
Version 75 (Android System Webview)

Additional context
Works on chrome. Does not work on stock browser. I disabled "internal" Android System Webview and updated it from play store

I have axact same issue on tablet Lenovo yoga 8 B6000. Android 4.2.2.
On wallpanel and stock browser i can only see background off hassio. No login page.
On other browsers works fine.
Is it possible to wallpanel use different than stock browser?

Same issue on Samsung Galaxy Tab 2 10.1 with Android 4.2.2.
The UI only works with the Opera browser. Chrome shows the same like Wallpanel: Only a blue bar and then nothing's happens.

Some older devices like Lenovo and those running older operating systems cannot display every webpage and it has nothing to do with which browser you have installed.  Android applications use their own internal rendering engine for the WebView component.  Unfortunately, this isn't consistent across all devices and support for html pages isn't the same on older Android OS.   You can try the legacy WallPanel application, and if that doesn't work, you need to simplify your webpage.  Outside of that, it is entirely out of my hands and I cannot fix your redner issues.
https://github.com/thanksmister/wallpanel-android-legacy


fix: support lint files calculated in a different machine/process

When building in CI it is common that a task is generating the lint file, while a different task
runs dagger. These tasks don't need to run in the same machine. The current code assumes so when
sanitizing absolute paths by replacing the root (pwd) with "". This does not work if the root is
different.
fix #29

You're welcome! Thank you for creating it in the first place.
What is the release process for this library? Is it released on demand or constantly with any change to main?

@locomike That's manual at the moment, I'll trigger a release now 👍


Update prepackage.sh

Hello.
Looks like falco-driver-loader should be replaced by falcoctl to successfully build packages from docker image 0.7.0-rc1.

Thanks @ksctst !
We will cut a release candidate for 0.7.0 that will bump sysflow to libs 0.18.1 compatibility (latest). This will include updated support for falcoctl and other changes to support the latest libs.
You can see the PR here: https://github.com/sysflow-telemetry/sf-collector/pull/72

FYI, the pre-release: https://github.com/sysflow-telemetry/sf-collector/releases/tag/0.7.0-rc1

Release 0.7.0 tracks the latest libs and use falcoctl. Closing this PR.


Add a new example project for video playback

refer to https://github.com/jamesbowman/py-bteve/blob/master/examples/video.py and add a video playback example using MediaPlayer class

    gd.wr8(gd.REG_VOL_PB,0xFF)  #volume control for output
    gd.wr8(gd.REG_GPIOX_DIR,0xFF)
    gd.wr8(gd.REG_GPIOX,0xFF) #volume switch for speaker
    while 1:
        for fn in ["trailer_400p.avi"]:
            with open(D + fn, "rb") as f:
                mp = MoviePlayer(gd,f)
                mp.play()

The video layback example is done in commit f886a91
Please have a look and try


feat: #533 add checkbox styles for FormField

With these changes it should be easy to implement #480 #296 #474


Auto update metadata: Auto update metadata via API, not required update from polkadot-js/app

Description

[x] Auto update metadata: Auto update metadata via API, not required update from polkadot-js/app

Convert from issue https://github.com/Koniverse/SubWallet-Extension/issues/525

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./upgrade-ui-pr-1638-build-1.1.1-2023-07-12T05-10-32UTC.zip
Re-check for Rococo and kindly re-check all netwotk

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./upgrade-ui-pr-1638-build-1.1.2-2023-07-18T07-48-01UTC.zip
Validation passed.
Notes: Need to enable network to auto-update metadata


Calendar UI rendering problem while slide right and left inside the Fragment

The nCalendar working perfectly, when subclass extends in AppCompactActivity. It showing rendering problem when subclass extends Fragments. Please check and give solution.

@kalaiarasisp I don't know how you use it.I have updated the code in the Fragment，you can refer to it. OR, show your code .

Please check the attached file.
LeaveShiftFragment.txt

@kalaiarasisp I tested it with your code , but I don't find this bug. Look at the latest code,please.
TestFragment

how you fixed this，i have the same problem

Are you using fragment?
On Feb 5, 2018 11:43 AM, "showkiwi"<EMAIL_ADDRESS>wrote:

how you fixed this，i have the same problem
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yannecer/NCalendar/issues/13#issuecomment-362991110,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJBlhb_KD3VTpvNsx0n9SAPbbufzWPMpks5tRpwLgaJpZM4RKKHb
.


Crash on Android

Hi guys,
I tried to install your plugin first but my app crash after the second request (cordova-plugin-advanced-http) on Android.
I installed it with the command 'cordova plugin add https://github.com/spoonconsulting/cordova-plugin-background-upload.git#2.0.5'
The initialisation (in device-ready event):

When my app is launch i can see the initial object :

Here's my package.json and my plugin list :

The app crash after 2 request (send with the plugin cordova-plugin-advanced-http)
I didn't use the uploader, i just initialised it in device-ready event
I have no errors.
Can you help me please :) ?

Hi @keva91,
We are currently working on a new version for android. That should be ready in a few days. If you can wait for this it will be easier.
Thanks in advance.
Luc

Some news ?

Hi @keva91,
Can you test this ? https://github.com/spoonconsulting/cordova-plugin-background-upload/pull/153
Thanks.
Luc

Just trying to help folks here. @keva91 can you try it again to check if we can close this issue?


[stable/mongodb-replicaset] Updated mongodb-replicaset README to show correct mongo version used

CLA signed

There's a problem with the CLA. Did you commit with the correct e-mail address?

Should be all good now.


Add home cards for vaccination status (EXPOSUREAPP-6730, EXPOSUREAPP-6731)

There is test code in VaccinationStorage you can alter to view the different cards.

Card for (in)complete vaccination status
Wired up to repository
No click actions yet, needs follow up PR.

[ ] Get fixed card graphics by our resident artist @jurajkusnier

From layout preview

Small change. While reviewing another PR i noticed that the SARS-CoV-2 Impfschutz is not dynamic but can be hardcoded.


Getting unexpected gradient background with partly rounded corners

Describe the bug
I get an unexpected gradient brush when only some corners of a panel are rounded.
Steps to reproduce the bug

Use Windows App SDK 1.0 Preview 3
Add a panel with a background and with only two rounded corners

When using this XAML:
 <Border Background="Red" CornerRadius="30,0,0,30"/>
I get this result:

Expected behavior
The panel should have a solid background color
Screenshots

NuGet package version
WinUI 3 - Windows App SDK 1.0 Preview 3
Windows app type

[ ] UWP
[X] Win32

Device form factor
Desktop
Windows version
May 2021 Update (19043)

@codendone and @gegao18 FYI, this is potentially problematic for a lot of the built in controls as well which frequently square one side of the controls corners.

This also occurs in my project in many places when I upgrade to 1.0. Any guidance?
For me this is painfully easy to reproduce. Is more information needed to help to get this fixed as soon as possible?

This also occurs in my project in many places when I upgrade to 1.0. Any guidance? For me this is painfully easy to reproduce. Is more information needed to help to get this fixed as soon as possible?

I try 0.8 still got the same problem. but UWP has no such a problem

@gabbybilka Are you aware of this issue?

WinAppSDK really needs an update as soon as possible. You really can't call an SDK production ready when the whole UI glitches around depending on the system's display scale... I just can't stress enough how crucial this issue is and how disappointing it is to see that in 2 months no assignee has been found and that it is still in the 'needs-triage' state. This should have top priority.

For people who stumble over this and need a quick way to remove the gradient in the TabViewItemHeader, just add this to App.xaml:
<CornerRadius x:Key="OverlayCornerRadius">0</CornerRadius>

The TabViewItemHeader now looks super ugly but its better than the weird color gradient. Then manually set the CornerRadius for every control that you want to have rounded corners:
<CornerRadius x:Key="CornerRadius">4</CornerRadius>
<CornerRadius x:Key="LargeCornerRadius">8</CornerRadius>

<Style  TargetType="FlyoutPresenter" >
  <Setter Property="CornerRadius" Value="{StaticResource LargeCornerRadius}"></Setter>
</Style>
<Style  TargetType="Button" >
  <Setter Property="CornerRadius" Value="{StaticResource CornerRadius}"></Setter>
</Style>


On Chant Search page, allow ordering of search results by Feast

In working on #416, I found it surprising that OldCantus does not support sorting by feast on the Chant Search page. This seems like a thing that would be useful for some users, and it would be easy to implement, by using the same logic in the view and template as for all the other columns. In any case, as OldCantus doesn't do it, so I'm suggesting this as a new "enhancement" issue.

this would definitely be useful and I support this enhancement!!!


README.md

Thank you for you contribution.  However, White Space PR's will not be accepted without other meaningful contributions.  Please check the issues to work on open needs.
8bitReid


Consider adding a feature for logging

Currently when coordinate transformation fails log warnings are written for every such point. While is is very useful for console applications and debugging, it can be quite annoying for different kinds of applications. For example, I use your library to render maps in different projections. And then I allow the user to query the objects by the mouse pointer. And when the user moves the mouse outside the projections scope, I get 1 million log warnings:
[2024-01-16T19:25:43Z WARN  geodesy::inner_op::laea] LAEA: (17613175.607089374, 7290876.352930736) outside domain
[2024-01-16T19:25:43Z WARN  geodesy::inner_op::laea] LAEA: (17585327.302897472, 7250347.963004524) outside domain
[2024-01-16T19:25:43Z WARN  geodesy::inner_op::laea] LAEA: (17582293.47894309, 7228565.651940692) outside domain
...

It would be nice if I could opt out from logging, since I handle all transformation failures by my code.

@Maximkaaa: The logging goes through the log logging facade, which should not do anything  unless an external logger is initialized. It is this logger which determines which logging-levels are passed through to the end user.
So the opt-out is a task for the application code: The library will talk into empty space if no logger is initialized. So it is much a case-by-case thing as to "how to opt out".
But basically you opt out by not configuring a logger - or configuring it to only relay sufficiently high logging levels to make the noise level tolerable.
Another thing, however, would be to consider the logging level for out-of-domain messages: Given that it is a basic assumption for Geodesy that "operations may fail for any given coordinate", perhaps a warm! is a too high level log message. Perhaps it should be info!, debug! or trace!?
Any thoughts on this would be most welcome!

Yes, I could filter out warnings by the namespace with some advanced logging crate, but that seems like unnecessary hustle. In my case, this messages are only useful as debugging information for I expect transformation failures in normal app operation. So if log level would be Debug, that would fit my usecase.

So if log level would be Debug, that would fit my usecase.

@Maximkaaa I suppose (from my limited knowledge of your use case) that we're talking Wasm, and that your platform is web based. My knowledge about that subject is embarrasingly limited, but I would really like to ensure that Geodesy is as useful as possible for web integration.
And if you get millions of warnings, without having initialized a logger, the web platform must function in a very different way than posixy platforms, and something really must be done to make things work better in your use case.
So can you (and perhaps other Wasm'ers like @Rennzie and @kylebarron) share a few words of advice for avoiding obvious footguns in the work towards better support?
One solution, I could think of, would be to funnel log messages from the the inner-op-tree through the Context, and (either by conditional compilation or by a particularly Wasmic Context implementation) making logging from Geodesy opt-in.
But simply lowering the logging to the debug! level would be simpler and easier - if that would really suffice, a PR would be highly appreciated!

I think you misunderstood me a little. I do initialize logging since I want my application to write logs. I use both wasm and native builds. I need my application to write logs, but I don't want these warnings to be in there except for debugging. If you think it's ok for other use cases, I'll make a PR to change the log level.

Resolved by #97


Add Path

Adding path argument to dash_socketio.
Enables to customise the path and route it to different server if needed.

Thanks Simon, I removed all the auto-generated files from main and from your branch, if you can pull main into yours to get this udpated that would be great.
Also rather than just passing path, I think it would be good to pass other io client options to the function if that's clear?

Yeah, you mean, for example, the reconnection parameter and others as well.
Yeah, I started that, but for me, it was more important to get the path going :D
I can make a new pull after this one and add the others.

It looks like the auto-generated files are removed. You pushed it already to mean. I see the commit in this PR as well.

What I meant is rather than a path argument, I would like a client_options argument, to which you can pass path. It would be good that the options are typed as well.

Ah, I got it. I will change that. It makes it easy to add different options in the future.

Please check the last commit. I added some variables already to provide some more options.
Is that the way you intended it to be?

Sorry took me a while to get back to this, I answered your questions :)


V2

TODO:

[x] Add EmptyView to CollectionView
[x] UMD support (https://github.com/jridgewell/minionette/issues/3)
[ ] Write docs (https://github.com/jridgewell/minionette/issues/2)
[x] @jmeas Clever #render (https://github.com/jridgewell/minionette/issues/10)

Back burner:

[ ] Look into Marionette.Behavior

Additions:

Adds Computed
Adds Model
Adds Router
View

Add ui hash

Adds trigger function

To be mixed into subclasses, at the Dev's discretion.

Changes:

Region

Trigger detach and detached events when attaching a new view
Optimize when a Region's view is removed.
Extract placeholder into a Backbone.View class
remove #detach and #reattach

View

Optimize rendering a string template.
Do not render a Region's placeholder view when using <%= view('name' %> template syntax
Regions are no longer attached at the root.

CollectionView

Separate out logic for appending and appending-to Document Fragments

This was unnecessarily complex. At times, you would be appending a single modelView. Other times, you would be appending a Backbone.View who's #el was a frag.

Misc Changes

Convert Grunt -> Gulp
Cleanup JSHint

Coverage increased (+1.37%) when pulling 448e251604f8e4c048dafe29d86572ff4b0a25b0 on v2 into d497fc72a5c5b6e56073ba6edaeeb21de93063a2 on master.


🐛 use local versions of bower and grunt so that they don't have to be

installed globally
fix for issue #108 and #109

never mind. Didn't know it is already fixed.


Added feature to submit values by enter key

I have added feature to calculate values by pressing "enter-key" by adding event listeners to all pages, also some pages were not acting as supposed to (i.e. when "enter-key" pressed while "typing-cursor" was in input field ), hence added one more event listener to prevent the original default event handler of "enter-key" for form tag (which is specifically to submit the form hence page was refreshing again and again).

@D3vilGhost Can you please attach screen recording or video of how the final result looks like.


Alternative solution

In case someone is interested, I've found another solution.
Use P/Invoke to SetDllDirectory:
<EMAIL_ADDRESS>CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SetDllDirectory(string lpPathName);

(See also this MSDN article about DLL load order)
Then, early in my Global.asax.cs Application_Start method (before any DB calls), call it like this:
SetDllDirectory(Server.MapPath(@"~/bin"))

After that, everything works as expected.

I still to consider this to be kind of a hack/workaround, but at least, it is working now in my scenario.
As I do understand, you can call SetDllDirectory multiple times to add additional directories (i.e. not overwrite the existing one).
So in case someone reading this might have other assemblies that refer to native DLLs in "x86" or "x64" folders, one might do something like this:
var bitness = Environment.Is64BitProcess ? @"x64" : @"x86";
SetDllDirectory(Server.MapPath($@"~/bin/{bitness}"));

I've also tried serving my test application from a local path (like "C:\Inetpub\wwwroot") and here, the error does not occur, even when not calling SetDllDirectory.
I'm still not sure why the error occurs for UNC paths only, and not for local paths, as I would expect that the shadow copied managed assemblies to fail the DllImports, too.

(I've also posted the above in this GitHub issue and this Stack Overflow post)

Thanks for your research!


Cannot conect to the server

When I try to connect to the server
[0] got message  { command: 'api-connectBackend', from: 'client', type: 'call' }
[1] sending {"type": "connected", "from": "backend"}
[1] ('<IP_ADDRESS>', 50372) connected to backend
[0] got message  { from: 'meta', type: 'opened' }
[0] got message  { type: 'connected', from: 'backend' }
[0] got message  { command: 'backend-connectWhatsApp',
[0]   from: 'client',
[0]   type: 'call' }
[1]<PHONE_NUMBER>012,{"command":"backend-connectWhatsApp","from":"api2backend","type":"call"}
[1] {u'from': u'api2backend', u'command': u'backend-connectWhatsApp', u'type': u'call'}
[1] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579)
[1] sending {"type": "resource_gone", "resource": "whatsapp", "resource_instance_id": "1c30db64f3d64f6b92469685d17c4910", "from": "backend"}
[1] WhatsApp backend Websocket closed.

Well, a SSL: CERTIFICATE_VERIFY_FAILED error is very unlikely to be an issue with this project, probably it's because of your system configuration, i.e. invalid or expired certificates which may be resolved using some sort of update. Can you use regular WhatsApp Web in your browser? When using a simple Python script that would download content from an SSL encrypted website, does that work for you?

Yes, I can use WhatsApp Web in my browser, I tried different configurations in python but nothing work, just can't download content from SSL

I am getting same issue.


MiteMijalkov: Addition of bio for student volunteer core.

Update of bio and photo of Mite Mijalkov. Date: 24.11.2021

Changes in 4 files in total.
The changes in Gemfile and _config.yml are needed to run the server locally.
The other 2 changes (bio + image) can be merged.

Can you create a pull request with only dcee57b00fc9af0721fd3b011b81efb723fd454c ( Addition of profile for Mite Mijalkov )


Same code gives Cholesky error on a different machine with CPU

A model runs perfectly fine on my laptop, but when I run it on the same data on a cluster I get failed matrix inversion every time. Both cases its CPU only TF, same version of TF 1.7, identical python environments actually.
I'll describe the model, and if requested I can post it though it's lengthy.
It is SVGP with a custom likelihood that uses a GP to model the noise instead of a scalar variance parameter. The noise GP is constant mean and RBF kernel. I use the reparametrization trick to learn the hyperparrameters of this GP simultaneously. I.e. I draw a sample of the noise GP as minibatching occurs during likelihood calculation. During the sampling of the noise GP, Cholesky decomposition fails on one computer but not the other.
All input data is scaled to centered unit variance.
I have tried increasing jitter to 1e-5, 1e-4, 1e-3, and 1. A jitter of 1 must make it posdef!?
On the one computer everything is stable and I can run the same code on all the different datasets I apply it to.
Computer where is works: Laptop, Fedora 64, i7 Xeon, CPU TF 1.7, python 3.6, gpflow HEAD
Computer where is fails: Cluster, Redhat 7, I think Xeon cores, CPU TF 1.7, python 3.6, gpflow HEAD

I am just curious - instead of Cholesky you could use tf.matrix_solve and tf.matrix_determinant. Do they exhibit the same challenges w.r.t. conditioning?

In my experience those are equally sensitive to conditioning (though usually the log of determinant is numerically less stable compared to sum(log(Tr(L))) ). There are known issues that appear between using GPU and CPU versions of TF, because of the indeterminacy of FLOP order on the GPU, but in this case I'm surprised to find a difference arising between two different CPU's all else the same.

Wow this seems like a bizarre and really frustrating problem. No idea why / how 2 different computers would give such different answers. Could you print out the matrix on both computers and then compare? Perhaps then use bumpy to do the cholesky to investigate whether it's the input or the tf routine that's causing the problem?
This is the approach I used in the past, and I found a bug in tensorflow with it.

Hi @Joshuaalbert, did you manage to figure out the bug? If this can not be reproduced with a model inside the GPflow repo, I'll have to close this, as this is a bug outside our code.
However, do get in touch if it's a more general error.


Inconsistent colors for shell

Thanks

Do you mean that cd is green and cat is not? cd is a sh builtin (see man sh), while cat is part of coreutils (man cat).

@camilstaps That makes sense, thank you


Procedure missing for PIN CFC

We have noticed in the sdk 1.13 release candidate 2 in the code list procurement_procedure_type for sub notice type 10, 11, 12, 13 that the procedures neg-w-call is missing. We have checked the directives and it seems to be foreseen (cf. dir 24 art. 48 $2, dir 25 art. 67 $2). Can this be included in the sdk 1.13, in Belgium we have active publications using this procedure in PIN CFC?

Hi,
We will look closer into that and will get back to you.
KR

After clarification, decision has been made to have it added.


[BUGFIX] Fix database folder in default config file for the archives

in the archive the database folder cannot be perses since it's the name of the executable.

coming from this issue: https://github.com/perses/perses/issues/2195#issuecomment-2358031535


Add hotkeys for faster window switching

Instead of clicking on the account, it'd be nice to be able to hit a hotkey to go to the next/previous account or even a hotkey to go to the third account. For example if you have 4 accounts open, pressing CTRL+3 will take you to the third loaded account and so forth for 1-4. I'd like the cycle method personally as I only run two accounts and a single button to swap would be nice.

This was talked about previously, and while it’s not on the milestones list it’s definitely planned.