Add dark mode

Summary:

public/images/monumentsSketch.svg [Switches bg from white to transparent, Changes outline color from #018b87 to #016e6b]
src/app/layout.js [Sets bg color for dark mode]
src/components/Header.jsx [Adds toggle theme icon, Changes for dark mode]
src/components/Hero.jsx [Changes color for announcement text]
src/components/Icon.jsx [Declares toggle theme icon]
src/components/ThemeToggle.jsx [Adds code for toggle theme]
tailwind.config.js [Adds color palette for dark mode]

Issue Link:
fix #4
PR Checks:

[ ] Code is properly formatted (executed make pre-push command).
[ ] No ESLint warnings (verified with make pre-push command).
[ ] UI Changes are responsive (checked in the responsive view).
[ ] Performance is maintained (Lighthouse report reviewed).
[ ] User experience (UX) considerations are met.
[ ] Accessibility is supported (validated with accessibility tools).

Flicker can be fixed, https://www.youtube.com/watch?v=7zqI4qMDdg8

@bhansa I have very limited availability this month, it would be great if anyone else can take it up. Thnx.

Sure, no problem @shivkatira I'll raise a change PR this week.


Problem: links in downloaded pdf version of the chain-doc doesn't navigate to the intended section

e.g.

For anyone interested in joining the Crypto.com chain testnet, please refer to our testnet documentation.

by clicking on testnet documentation, the reader will be navigated to http://<IP_ADDRESS>:8080/getting-started/thaler-testnet

Should be okay now @CeruleanAtMonaco https://crypto-com.github.io/getting-started/

In PDF, it still links to http://<IP_ADDRESS>:8080

@tomtau I see, the issue refers to the links in PDF, the vuepress export plugin is so unmatured, I have submitted PR for itself also, and there is no substitute out there. It's related to the build phase and may cause more time. I will try to fix it later.


Is there a way to create a frameless window？

No, not yet, but it's in the works and will be available at some point. No certain ETA yet though.


[Feature request] define loadfiles path in playlistmanager.conf

Like for the command but path defined in the playlistmanager.conf file.

input.conf
SPACE script-message playlistmanager loadfiles /home/user/Videos

input.conf
SPACE script-message playlistmanager loadfiles /home/user/Videos

Works fine, thanks!
Btw, loadfiles_filetypes doesn't support playlist like m3u, can you add it?

Hello jonniek you added double m3u in loadfiles_filetypes https://github.com/jonniek/mpv-playlistmanager/commit/1b2adbe5d8bc5781a46d28744f464601a5334fe3
And I don't think it's a good idea to add the playlist into it. A m3u file could contains unknown-file-types items, which may break sth.

Yeah seems like I committed a test config too by mistake. I reverted that commit.
I think maybe users can define the m3u to the setting themselves if they want it to be there.

mpv support m3u, there is no reason to not add it.

And I don't think it's a good idea to add the playlist into it. A m3u file could contains unknown-file-types items, which may break sth.

Bullshit, if a media type is not supported by mpv, it's not played, end.

No one would prevent you adding it by the conf file.
And there is no reason to add the the "playlist format" into the "media types". Also a m3u file could use txt as extension name.

It is curious that a script called playlistmanager should not support playlist file.
Maybe, m3u can be defined outside of loadfiles_filetypes.

A so called playlist format could use m3u8 txt pl or something else as extension.

Yes m3u8 should be added as well, but mpv does not recognize txt and pl:
Failed to recognize file format.

That's the another issue. Maybe your m3u doesn't follow the rule.
It works here.

No one would prevent you adding it by the conf file.

This

It is curious that a script called playlistmanager should not support playlist file.

This is fair enough. But it's not a lot of effort to change the defaults. I have been thinking about some way to open saved playlists explicitly, I think that would be better. I think loadfiles will not really avoid duplicates with playlist files so it seems a bit annoying to use.


Operator associativity

<$> and <*> are currently defined as right associative: https://github.com/coq-ext-lib/coq-ext-lib/blob/c0c934cd3c5fe24f55f41981e86a22a77f08f1ff/theories/Structures/Functor.v#L29 https://github.com/coq-ext-lib/coq-ext-lib/blob/c0c934cd3c5fe24f55f41981e86a22a77f08f1ff/theories/Structures/Applicative.v#L16 while they are left associative in Haskell: <$> <*>.
Is it designated on purpose, or is it worth changing them to left associative?
Say that I have:
Parameter parser : Type -> Type.
Instance Monad_parser : Monad parser. Admitted.
Parameter A B C D : Type.
Parameter pA : parser A.
Parameter pB : parser B.
Parameter pC : parser C.
Parameter f : A -> B -> C -> D.

To write a parser for D (without liftA2), I need:
Definition pD : parser D := ((f <$> pA) <*> pB) <*> pC.

where the parentheses are not required if the operators were left associative.

They should be changed. Can you please open a pull request?


Update faucet.md

The faucet amount is dynamic not 10 tokens so make that clear

closing in favor of #1076


WCFIntegrationFacility. I get an exception when moved ContractBehavior implementation into another assembly

I have assemblies
ProductService (refrences ProductService.Interfaces and Common.Interfaces)
ProductService.Interfaces (references Common.Interfaces)
Common.Interfaces
ProductService is ASP.NET project which exposes WCF services which are defined in ProductService.Interfaces
I've got this attibute.
    public class ArchiveSerializerContractBehaviorAttribute : Attribute, IContractBehavior
    {
...
    }

Initially that attribute was in the ProductService.Interfaces. Recently I needed to expose some services which are defined in Common.Interfaces and I have to mark interfaces in Common.Interfaces with that attribute. So I moved it to a Common.Interfaces assembly and as result I received this error:
Server Error in '/' Application.

The value could not be added to the collection, as the collection already contains an item of the same type: 'Common.Interfaces.Wcf.ArchiveSerializerContractBehaviorAttribute'. This collection only supports one instance of each type.
Parameter name: item
  Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 Exception Details: System.ArgumentException: The value could not be added to the collection, as the collection already contains an item of the same type: 'Common.Interfaces.Wcf.ArchiveSerializerContractBehaviorAttribute'. This collection only supports one instance of each type.
Parameter name: item

Source Error:

 An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[ArgumentException: The value could not be added to the collection, as the collection already contains an item of the same type: 'Common.Interfaces.Wcf.ArchiveSerializerContractBehaviorAttribute'. This collection only supports one instance of each type.
Parameter name: item]
   System.Collections.Generic.KeyedByTypeCollection`1.InsertItem(Int32 index, TItem item) +17217335
   Castle.Facilities.WcfIntegration.Internal.WcfUtils.AddBehaviors(IKernel kernel, WcfExtensionScope scope, ICollection`1 behaviors, IWcfBurden burden, Predicate`1 predicate) +299
   Castle.Facilities.WcfIntegration.WcfEndpointExtensions.Install(ServiceEndpoint endpoint, Boolean withContract, IKernel kernel, IWcfBurden burden) +201
   Castle.Facilities.WcfIntegration.ServiceHostExtensions.Castle.Facilities.WcfIntegration.IWcfExtensionVisitor.VisitEndpointExtension(IWcfEndpointExtension extension) +334
   Castle.Facilities.WcfIntegration.ServiceHostExtensions.Install(ICollection`1 extensions, IWcfBurden burden) +110
   Castle.Facilities.WcfIntegration.AbstractServiceHostBuilder.ConfigureServiceHost(ServiceHost serviceHost, IWcfServiceModel serviceModel, ComponentModel model) +931
   Castle.Facilities.WcfIntegration.AbstractServiceHostBuilder`1.Build(ComponentModel model, Uri[] baseAddresses) +50
   Castle.Facilities.WcfIntegration.WindsorServiceHostFactory`1.CreateServiceHost(String constructorString, Uri[] baseAddresses) +273
   System.ServiceModel.HostingManager.CreateService(String normalizedVirtualPath, EventTraceActivity eventTraceActivity) +1451
   System.ServiceModel.HostingManager.ActivateService(ServiceActivationInfo serviceActivationInfo, EventTraceActivity eventTraceActivity) +76
   System.ServiceModel.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity) +901

[ServiceActivationException: The service '/ProductService.svc' cannot be activated due to an exception during compilation.  The exception message is: The value could not be added to the collection, as the collection already contains an item of the same type: 'Common.Interfaces.Wcf.ArchiveSerializerContractBehaviorAttribute'. This collection only supports one instance of each type.
Parameter name: item.]
   System.Runtime.AsyncResult.End(IAsyncResult result) +654324
   System.ServiceModel.Activation.HostedHttpRequestAsyncResult.End(IAsyncResult result) +210877
   System.Web.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar) +166

When I moved attribute back to ProductService.Interfaces. It started to work without any exceptions. The version of WCFIntegrationFacility is <IP_ADDRESS>

@Alex2357 - this issue has not moved for 3 years, OK to close? Ideally we would like to see a pull request raised. Do you feel this is possible?


Add brid.gy support for replies

.
(Originally published at: https://inhji.de/posts/add-brid-gy-support-for-replies-VNaRs)

Test reply to bridgy
(Originally published at: https://inhji.de/posts/test-reply-to-br-NP18R)


Zoom center is center of fingers

Hey,
it's really cool that you fixed the problems from the original library. Many thanks!
Like @Shu-Ji described in YoussefKababe/pinch_zoom_image#6, it would be very nice if there would be the option, that the zoomed center matches the center of both fingers on the original image. So you can zoom on a specific area on the image directly. Basically exact what Instagram does.
Thanks in advance

Okay @SimonIT , when I available I'll fix it :)

+1
It is a needed change in the package,
Looking forward seeing it in a new update

Hello @furkankurt
Thank you very much for this feature.
But it's been a long time now, when will you be correcting the zoom function?
It is not pleasant to zoom into the center of the image.
Thanks

If @furkankurt does not have the time, I will have to do it 😅

I too will have to do it alone. Too much time has passed. I will look for alternative ways.

Sorry guys, I had a lot of problems with my life. That so I couldn't update the repository. But I found a package that can help on your project. I'm sorry again.


import theatre titles

dear @csae8092, before we fill up #213 could you please at some point import the sheet with the works in the same google-sheet https://docs.google.com/spreadsheets/d/1-_WXbdmpLzz_9vBiZ1y9v2tle_26m4tAhPTGzkkin5E/edit?usp=sharing
if you return me the pmb-numbering in the correct order we don't really need the uris to be stored.
thank you!

Can you please create separate gsheet because I can't easily deal with multiple sheets in one gsheet

oopsie, thery you go: https://docs.google.com/spreadsheets/d/1wgLHBHeJECkmgJUIpPdG-JS8F-0ht_LdVTxNmWwW8O0/edit?gid=297726714#gid=297726714

do they have worktype?

doubletten?

schnitzler-theater-interim-titel-284
Der Jourfix

schnitzler-theater-interim-titel-285
Der Jourfix

schnitzler-theater-interim-titel-1895
Beethoven-Zyklus

schnitzler-theater-interim-titel-1896
Beethoven-Zyklus

schnitzler-theater-interim-titel-1897
Beethoven-Zyklus

schnitzler-theater-interim-titel-477
Seidl und Wiesberg

schnitzler-theater-interim-titel-478
Seidl und Wiesberg

No work-type, maybe Dubletten. But I clear that manually

theater-uris.csv

not before I say thank you!


GeoServer plugin

GeoServer plugin

This plugin allows mage to serve out OGC compliant WMS and WFS endpoints as a proxy through GeoServer.

Pull Request Test Coverage Report for Build 416

138 of 946 (14.59%)  changed or added relevant lines in 41 files are covered.
4 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-4.2%) to 39.052%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

api/events/location.js
6
7
85.71%

models/event.js
0
2
0.0%

plugins/mage-geoserver/cname/index.js
0
2
0.0%

api/events/attachment.js
8
11
72.73%

api/events/event.js
8
11
72.73%

api/events/observation.js
8
11
72.73%

models/location.js
7
11
63.64%

plugins/mage-geoserver/authentication.js
0
4
0.0%

routes/events.js
4
8
50.0%

app.js
0
6
0.0%

Files with Coverage Reduction
New Missed Lines
%

plugins/mage-epic/index.js
1
0.0%

plugins/mage-rage/index.js
1
0.0%

routes/events.js
2
43.16%

Totals

Change from base Build 408:
-4.2%

Covered Lines:
2723

Relevant Lines:
6616

💛  - Coveralls


[BUG] /usr/bin/ld: cannot find -lz

Describe the bug
When compiling on a fairly fresh Debian Sid instance, I got the following error upon installation:
/usr/bin/ld: cannot find -lz

Installing zlib1g-dev fixes it. I'd like to add something to the README's installation dependencies to this effect, but wanted to open this issue for feedback first.

Good find. This is seems to be at least because of:
$ cargo tree
ipfs v0.1.0 (...)
| ...
├── libp2p v0.20.1
| ...
│   ├── libp2p-deflate v0.19.2
│   │   ├── flate2 v1.0.16
│   │   │   ├── cfg-if v0.1.10
│   │   │   ├── crc32fast v1.2.0
│   │   │   │   └── cfg-if v0.1.10
│   │   │   ├── libc v0.2.67
│   │   │   ├── libz-sys v1.0.25

Doing cargo update -p flate2 does not solve this. I can't really see why, or because of which feature, the zlib dependency comes along, perhaps not enough coffee. I think this could be documented in the Cargo.toml as well..
Saying "at least because of" because we may have other less visible dependencies on zlib. I am thinking openssl but I guess it was needed openssl would come with some vendored zlib implementation.


Update German translation

Update translation of "Show Goal" and "Hide Goal".

gpg: Signature made Tue 18 Dec 2018 04:04:55 PM UTC using RSA key ID B6FF4DE3
gpg: BAD signature from "Yarn Packaging<EMAIL_ADDRESS>> GPG signature for this Yarn release is invalid! This is BAD and may mean the release has been tampered with. It is strongly recommended that you report this to the Yarn developers.
The command "curl -o- -L https://yarnpkg.com/install.sh | bash" failed and exited with 1 during .

supposedly this caused the travis build to fail but im 99% certain its just a flaky error. ill repush though


feat: add msgpack support

Otherwise, the amount of code that reqwest would need to maintain would keep growing significantly.

Well, seems reasonable!


Certificate Login - New users are created twice

When a new user attempts to log in via cert the system attempts to create that new user twice.
In the logs we see:
creating new user for dn:...
created new profile for user ...
...
creating new user for dn:...

The issue is happening because the front-end on a single machine is doing more than one request that hits the api endpoints. it will hit the _get_profile_by_dn function at the same time on two different gunicorn processes.

the JVM version had this same problem at one time.  It was fixed by catching the resulting DataIntegrityViolationException and retrying the login.  See LoginFilters.groovy in ozp-rest

Thanks rpokorny.
Manny take a look at https://github.com/ozone-development/ozp-rest/blob/master/grails-app/conf/marketplace/rest/LoginFilters.groovy

https://github.com/ozone-development/ozp-rest/blob/master/src/groovy/marketplace/rest/service/ProfileRestService.groovy#L173

Description of what happens:

A user log in to the browser in ozp-center website.

More Image calls from the URLs collected in the GET /api/storefront/
...

Proposed Solution:
Issue number https://github.com/ozone-development/ozp-backend/issues/189 allows for distributed locks between multiple gunicorn thread instances between multiple machines.
#  http://stackoverflow.com/questions/4581789/how-do-i-get-user-ip-address-in-django
def get_client_ip(request):
    x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR')
    if x_forwarded_for:
        ip = x_forwarded_for.split(',')[0]
    else:
        ip = request.META.get('REMOTE_ADDR')
    return ip

with cache.lock('pki-{0!s}'.format(get_client_ip({request})):
    _get_profile_by_dn code

Redis will be used for caching. Redis can also be used as a lock.
http://niwinz.github.io/django-redis/latest/#_locks

Steps:

Use Ansible to install a vm with pki enabled
Install user cert on your local

Testing between
        with cache.lock(remote_ip):
            logger.info('Attempting to authenticate user with dn: {0!s} and issuer dn: {1!s}'.format(dn, issuer_dn))
            try:
                profile = _get_profile_by_dn(dn, issuer_dn)
            except Exception as err:
                logger.error(str(err))
                raise err

and
        #with cache.lock(remote_ip):
        logger.info('Attempting to authenticate user with dn: {0!s} and issuer dn: {1!s}'.format(dn, issuer_dn))
        #    try:
        profile = _get_profile_by_dn(dn, issuer_dn)
        #   except Exception as err:
        #        logger.error(str(err))
        #

How to delete users using python manage.py shell_plus
User.objects.filter(username= 'winston_smith_wsmith').delete()

This ticket is hard to replicate

Proposed Diff:
diff --git ozpcenter/auth/pkiauth.py ozpcenter/auth/pkiauth.py
index f46c11b..fecb3e9 100644
--- ozpcenter/auth/pkiauth.py
+++ ozpcenter/auth/pkiauth.py
@@ -9,6 +9,7 @@ $ssl_client_verify -> HTTP_X_SSL_AUTHENTICATED
 import logging

 from django.conf import settings
+from django.core.cache import cache
 from rest_framework import authentication

 from ozpcenter import models
@@ -64,9 +65,18 @@ class PkiAuthentication(authentication.BaseAuthentication):
             dn = _preprocess_dn(dn)
             issuer_dn = _preprocess_dn(issuer_dn)

-        logger.info('Attempting to authenticate user with dn: {0!s} and issuer dn: {1!s}'.format(dn, issuer_dn))
+        remote_ip = request.META.get('HTTP_X_REAL_IP', None)

-        profile = _get_profile_by_dn(dn, issuer_dn)
+        if remote_ip:
+            remote_ip = 'pki_lock-{}'.format(remote_ip)
+        else:
+            remote_ip = 'pki_lock-global'
+
+        profile = None
+
+        with cache.lock(remote_ip):
+            logger.info('Attempting to authenticate user with dn: {0!s} and issuer dn: {1!s}'.format(dn, issuer_dn))
+            profile = _get_profile_by_dn(dn, issuer_dn)

         if profile:
             logger.info('found user {0!s}, authentication succeeded'.format(profile.user.username), extra={'user', profile.user.username})


Controllers should die if watchdog fails

Description
This PR adds a new launchfile, demo_feeding.launch.py, that launches all the same nodes as demo.launch.py but also launches a watchdog listener and completely terminates the launchfile if the watchdog fails.
Testing
Pull the code from ada_feeding#48
Setup: Sim

Run the dummy FT sensor: ros2 run ada_feeding dummy_ft_sensor.py
Run the watchdog: ros2 launch ada_feeding ada_feeding_launch.xml
Launch MoveIt: ros2 launch ada_moveit demo_feeding.launch.py sim:=mock

Setup: Real Robot

Run the FT sensor: ros2 run forque_sensor_hardware forque_sensor_hardware —ros-args -p host:=xxx.xxx.x.xx

Re-tare the sensor: ros2 service call /wireless_ft/set_bias std_srvs/srv/SetBool "{data: true}"

Run the watchdog: ros2 launch ada_feeding ada_feeding_launch.xml
Launch MoveIt: ros2 launch ada_moveit demo_feeding.launch.py

Tests

Verify that ada_watchdog_listener_node.py works as expected:

[x] Run the dummy FT sensor, the ada_feeding launchfile, the listener node ros2 run ada_watchdog_listener ada_watchdog_listener_node --ros-args --remap ada_watchdog_listener/watchdog:=ada_watchdog/watchdog. Verify that the node stays alive.
[x] Kill the dummy FT sensor. Verify that the node dies.
[x] Re-start the dummy FT sensor and the listener node. Set the dummy FT sensor to be 0 variance in at least one dimension: ros2 param set /dummy_ft_sensor std  '[0.1, 0.1, 0.0, 0.1, 0.1, 0.1]'. Verify that the listener node dies.
[x] Re-start the dummy FT sensor and the listener node. Re-tare the F/T sensor ros2 service call /wireless_ft/set_bias std_srvs/srv/SetBool "{data: true}". Verify that the listener node dies.
[x] Re-start the dummy FT sensor and the listener node and  turn the listener node off ros2 service call /ada_watchdog_listener/toggle_watchdog_listener std_srvs/srv/SetBool "{data: false}". Re-tare the F/T sensor ros2 service call /wireless_ft/set_bias std_srvs/srv/SetBool "{data: true}". Then, turn the listener node on. Verify that the listener node stays alive.

Run the setup steps above. Then, turn off the watchdog listener, re-tare the FT sensor, and re-turn on the watchdog listener. Then: Call ros2 action send_goal /MoveAbovePlate ada_feeding_msgs/action/MoveTo "{}" --feedback and verify that it succeeds.

[x] Sim
[x] Real

Do the above but terminate FT node while the robot is moving, verify that the MoveIt launchfile terminates within 0.1sec.

[x] Sim
[x] Real

Notes / Discussion Points

The watchdog params and remapping for create_action_servers.py are defined in ada_feeding, whereas the same parameters/remapping are also defined in demo_feeding.launch.py. Are we okay with this?
EDIT: This has now been addressed. Note that the order of launches becomes important, because we first have to start the watchdog, then start MoveIt, and then populate the planning scene, whereas right now the watchdog and planning scene are launched together. I'll probably modify ada_feeding#48 to have the planning scene node wait until there is a subscriber on the topic, to address this.

Note: re-taring the sensor causes the F/T readings to be stopped long enough (> 0.1s) to trigger the watchdog. I'll increase it
to 0.5 and try again.

Moved the watchdog listener into this repo and re-ran all tests in sim. Will next test in real.

All tested and it works. Will merge.


Stairs Preview is inaccurate

The Stairs tool's preview/wireframe is limited to a certain quantity of steps rather than the amount of units we have selected, attaching screenshots below:

Inaccurate preview

But blocks generated works fine

Yea this would be nice if it show accurately. Awesome plugin btw


Set non-set parameters to check as 'pass'

This will make it possible to set a subset of parameters to be checked without setting all the others as 'pass'.
This:
@typecheck(int, float)
def foo(a, b, c, d):
    pass

and when issue #4 is done, this:
@typecheck(c=int, d=float)
def foo(a, b, c, d):
    pass

will be the same as this:
@typecheck(int, float, 'pass', 'pass')
def foo(a, b, c, d):
    pass

and this:
@typecheck('pass', 'pass', int, float)
def foo(a, b, c, d):
    pass

Should be functional now.
Need to update the documentation before merging to main.


Fix(control-plane-migration): stuck for hibernated shoots at "Waiting until ManagedResources are deleted"

How to categorize this PR?
/area control-plane-migration
/kind bug
What this PR does / why we need it:
Adds an additional task in the shoot migrate flow that calls DeployGardenerResourceManager which triggers a re-run of the bootstrap logic if needed.
Which issue(s) this PR fixes:
Fixes #7606 with my proposed change.
Release note:
Fixes control-plane migration of hibernated shoot being stuck if shoot was hibernated for 24h

Thanks, that's a nice finding :)
/lgtm
/ok-to-test
/cc @plkokanov

/milestone v1.66


Questions regarding custom CMS element implementation

I'm currently deep diving into custom CMS element development in Shopware 6. I went through the dedicated HowTo and I'm now dissecting the implementation of the built-in CMS elements.
My initial expectation was that for each CMS element I could write a single Vue component which would serve both as the "main component" and as the storefront implementation. This turned out to be not as easy as I thought. I guess it's not even intended to work that way. However, I don't understand the purpose of some design decisions which, I believe, get in the way here. Could you please elaborate on them.
Exemplary, consider the product-box element.
Dependency Injection
What is the benefit of dependency injecting this.repositoryFactory here?
https://github.com/shopware/platform/blob/d1802e10d3ac87bafd6e1f2d230398ea9373b40b/src/Administration/Resources/app/administration/src/module/sw-cms/elements/product-box/config/index.js#L14
From what I have seen repositoryFactory is more or less just a wrapper for the REST API.
Dependency injection here makes the component un-reusable anywhere where the dependency provider is not in the parent component chain. From the Vue docs:

[...] there are downsides to dependency injection. It couples components in your application to the way they’re currently organized [...]

Getting a reference to repositoryFactory like this instead:
import { Service } from 'src/core/shopware'

const repositoryFactory = Service('repositoryFactory')

seems to work fine for me so far.
Prop Mutation in Child Component
When a user changes a config field, the value is stored by mutating the element prop (defined in cms-element mixin). This violates Vue's one-way data flow principle and makes it hard to reason when and how state is shared between components. Couldn't this be solved idiomatically with custom events?
Why initElementConfig/initElementData?
Why do we have to call initElementConfig/initElementData?
https://github.com/shopware/platform/blob/d1802e10d3ac87bafd6e1f2d230398ea9373b40b/src/Administration/Resources/app/administration/src/module/sw-cms/elements/product-box/component/index.js#L76-L84
At least initElementConfig is called in virtually every component and all it does is merging this.element.config with the defaults. Both are provided by the parent component so why is this not happening in the parent component? Also, this is happening multiple times. For example every time I close and reopen the config component popup.
Ideally (as I envision it), I would define my "main component" with one prop corresponding to each config option:
props: [
   'product',
   'boxLayout',
   'displayMode',
   'verticalAlign'
]

It would be the parent components job to pass the correct values, initialized with defaults. It should also fetch the additional data that needs to come with product.
Difference Between config and data
Somewhat related to the previous point, I don't really get the distinction between this.element.config und this.element.data.
Of course this.element.config.product comes with pure configuration fields like required while this.element.data.product holds the data associated with the given product. However, this.element.config.product also has a value field which seems to me perfectly fine for holding the data. They are mostly updated together anyway:
https://github.com/shopware/platform/blob/d1802e10d3ac87bafd6e1f2d230398ea9373b40b/src/Administration/Resources/app/administration/src/module/sw-cms/elements/product-box/config/index.js#L40-L42
I realize that this.element.data.product.value stores a product ID here instead of full product record. I don't understand why though. The ID is included in the product record. I can imagine that this is due to the way configuration is stored in the database. It would be convenient if this ID <-> record translation would happen in the parent component as well.

Hi @gruhn,
for discussions please head over to our forum
If you want to suggest changes please create Tickets for your Ideas here. In our IssueTracker people will be able to vote for issues which makes identifying what the community wants easier.
Sunny Regards
Pantrtxp


[WIP] Feature/checkpoint

Merge tensor and pipeline parallel model states into a single file via Gloo communication

Updated checkpoint saving/loading utils
Added Gloo groups to context
Added ColossalaiModule, and reworked implementation of unified layers
Added custom _load_from_state_dict & _save_to_state_dict for nd tensor parallelisms
Added checkpoint utils for pipeline paralleism

Hi @kurisusnowdeng , can you split this PR?


'Collapse messages' option name changes after choosing the same option twice in a row

Fixed in latest nightly


WebSocket Router

Initialise websocket upgrade with a router. This can be the same router as the one you use for everything else or a separate router, which would be more optimal given you are testing less routes for the upgrade.
let router = Router(context: BasicWebSocketRequestContext.self)
router.ws("/ws") { request,channel in
    return .upgrade([:])
} handle: { inbound, outbound, _ in
    for try await packet in inbound {
        if case .text("disconnect") = packet {
            break
        }
        try await outbound.write(.custom(packet.webSocketFrame))
    }
}

let app = Application(
    router: router,
    server: .webSocketUpgrade(webSocketRouter: router)
)
try await app.runService()

This PR also removes any NIOHTTP1 types from the public interface

Fixed issues with WebSocket upgrade fail not sending response. Solution isn't great, hopefully will get better solution from NIO at some point.


dApp: Add "popup" with randomised message after successful transfer

User Story
As a visitor on EthCC participating in the UX/UI survey I want to see a popup that randomly displays whether I get a t-shirt or a beer after I've completed a transfer.
This will be throwaway code and should therefore be kept simple and a minimum viable effort is sufficient. Should not be considered as a long term addition to the code base.
@DinaBB feel free to add any more details.
Acceptance criteria
dApp should display a popup message with either a t-shirt or a beer.
Tasks

[ ] Could be implemented in a temporary EthCC branch that gets deleted after the conference?

Pop up example:

@weilbith This can be closed, right?


Update syntax to Xcode 7.0 and Swift 2.0

Summary:
Updated the syntax to stop crashing in build time.
Related to this issue.
P.S: Maybe this upgrade to Swift 2.0 could be better, my purpose with this pull request is only stop crashing. Hope it helps.

Cool! Thanks for taking note of this!

It was a piece of cake, thank you for your awesome project :+1:


build epanet libraries using github workflows #690

@Mariosmsk thank you for this contribution, I was not aware of this option. If I understand correctly, for every commit into any branch, the code is compiled into the different DLLs, which can be immediately downloaded. We didn't have such an option so far, and users that weren't able to compile the code had no place to get the DLLs from. This is a great feature.

Perhaps @Mariosmsk could explain to the less informed (like me) exactly what this workflow update is doing. Is what @eladsal said true - I have my doubts since the ccpp.yml has always been included in dev and yet I don't see any listing on the project page where the built libraries for a new commit are available for download. Isn't the workflow used to check that the submitted code compiles correctly and passes any CI tests, using temporary folders to contain all files created from the build process?

@LRossman , I just followed the links @Mariosmsk provided in #690. I ended up here:
https://github.com/Mariosmsk/EPANET/actions/runs/2756587821
There is a download link at the bottom.
Also, note that this PR includes win32.yml and win36.yml.
But an explanation would be nice :)

Hi all, yes @LRossman, what @eladsal said is true. This is the idea of this PR, for every commit, the code is compiled into the different DLLs (win32.yml, win36.yml) and .so (ccpp.yml) files, which can be immediately downloaded. Also, we can do this for dylib for mac with the help of @samhatchett.
The file, ccpp.yml, was always and I added the following code to upload the data on GitHub using the upload artifacts.
Artifacts allow you to share data between jobs in a workflow and store data once that workflow has completed.
More: https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
- uses: actions/upload-artifact@v2
  with:
    name: libepanet-output
    path: /home/runner/work/EPANET/EPANET/buildproducts/

OK, I get it now. Nice work @Mariosmsk .


Pin nest_asyncio to 1.5.1

It seems that nest_asyncio==1.5.2 makes the tests fail with the following error (see https://github.com/erdewit/nest_asyncio/issues/62 for more details):
runtimes/alibi-explain/tests/conftest.py:29: in <module>
    nest_asyncio.apply()
../../.virtualenvs/mlserver-37/lib/python3.7/site-packages/nest_asyncio.py:14: in apply
    raise ValueError('Can\'t patch loop of type %s' % type(loop))
E   ValueError: Can't patch loop of type <class 'NoneType'>

With nest_asyncio==1.5.1, tests still seem to pass, so pinning it for now until we find out more about it.

The only error will be fixed by #404, so we can merge this one.


Refactor notification key generation logic. Fixes #26729

This pull request refines the notification key structure to properly handle both private and group messages in the Zulip messaging application. The changes improve how notification data is organized and enhance the readability of the code.
Fixes: #26729

Screenshots and screen captures:

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions, and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

@timabbott can you please review this


Fork enum for internal Parser state and ParserCallbacks return value

ParserStatus is used both to represent the internal state of the Parser and to signal error to the Parser by return value of ParserCallbacks.  This PR keeps ParserStatus for the former, and forks it to a new enum, CallbackResult, which is used for the latter (first commit).  Unused Paused and Unknown members are removed from CallbackResult (second commit).  resultToInt() can be replaced by a static_cast (third commit); the change here is that invalid values will not trigger PANIC now, but no ParserCallbacks implementation returns an invalid value so this does not change behavior.  Unused ParserStatus members NoBody, NoBodyData and Unknown are removed (fourth commit), this fixes the bug of incorrectly interpreting internal http-parser errors codes 1 and 2, but again this does not change behavior as ConnectionImpl only ever compares ParserStatus to Success (now renamed to Ok) and Paused.

  Thanks!

/retest


dbeaver/pro#1768 High-contrast theme

Please, check that Dark and Classic or Light themes remained unchanged. You can run DBeaver and view that there is no unreadable text anywhere.
What was changed especially:

[x] SQL Editor
[x] Server Output
[x] Data Editor (Text and Chart presentation too)
[x] Panels

Win 11 Desert theme

Win 11 Nigh sky theme

Also breadcrumbs, vertical tabs, tabbed folder list, references panel were fixed

verified


If layer is deleted, app breaks

Looks like this all doesnt have a valid layer. That breaks the app. We should handle this with a better error message.
http://audubon.maps.arcgis.com/apps/GeoForm/index.html?appid=00cf76c87d0545a78528e3cc0b9c2736&webmap=594f7f48c45246acbaa65a0ca50e9b82
 TypeError: Cannot read property 'url' of null {stack: (...), message: "Cannot read property 'url' of null"} "TypeError: Cannot read property 'url' of null
    at null.<anonymous> (http://audubon.maps.arcgis.com/apps/GeoForm/js/main.js:125:36)
    at http://js.arcgis.com/3.12/init.js:177:296
    at Object.g.forEach (http://js.arcgis.com/3.12/init.js:229:285)
    at declare._createGeocoderOptions (http://audubon.maps.arcgis.com/apps/GeoForm/js/main.js:116:23)
    at declare._createGeocoderButton (http://audubon.maps.arcgis.com/apps/GeoForm/js/main.js:1902:32)
    at null.<anonymous> (http://audubon.maps.arcgis.com/apps/GeoForm/js/main.js:1397:22)
    at http://js.arcgis.com/3.12/init.js:177:296
    at c (http://js.arcgis.com/3.12/init.js:76:221)
    at d (http://js.arcgis.com/3.12/init.js:76:10)
    at resolve.callback (http://js.arcgis.com/3.12/init.js:77:350)"

@driskull,
If "this.config.form_layer.id" does not exist in web map layer collection then we  can simply show the message as "Layer does not exist" or "Please configure the layer".
Or you want any other error message.
Thanks!

How about both? "Form layer does not exist. Please configure the application and set the layer."

@driskull
This is how error message will be shown if layer is deleted.

The code is already merged in.
Thanks


added latest Zanata translation fixes

please merge this PR asap - these are Zanata translation fixes

+1 to merge.

Thanks.
6.3.x: aad6231bdd7e6d65fca54f967cb6684ee47bd339


Missing reserved word URL

I cannot find an entry for "URL" on this page however the various Azure migration tools are flagging it as a migration blocker.  Should it be listed here?
Note it is listed as part of the BACKUP command as found in the t-sql example here:
https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-backup-to-url?view=sql-server-2017#Examples

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

ID: f79ec4df-5309-60fc-1c20-f32b219fb9b9
Version Independent ID: 6ee85c34-9a2c-e007-dcda-fb6016b98119
Content: Reserved Keywords (Transact-SQL) - SQL Server
Content Source: docs/t-sql/language-elements/reserved-keywords-transact-sql.md
Product: sql
Technology: t-sql
GitHub Login: @rothja
Microsoft Alias: jroth

@EnjoyinMoss -- Simon, thank you again for your feedback.
@rothja -- Jason, please look into this issue 2794.

@EnjoyinMoss Hello, and apologies for the delay. The definition of a reserved keyword on this page is one that cannot be used in Transact-SQL statements except with a delimiter. So the following fails:
select 'test' as ADD

But you can use URL in this example:
select 'test' as URL

So it would appear from testing that URL is not a reserved keyword in the same way. I'm not sure why it is getting flagged. But you could put delimiters around it possibly just to be clear:
select 'test' as [URL]

Let me know if this makes sense or if you have any other feedback. At this time I am going to close the issue.


[TS migration] Migrate 'WorkspacePageWithSections' page to TypeScript

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/25185
PROPOSAL: https://github.com/Expensify/App/issues/25185#issuecomment-1883126975
Tests

Prerequisite:
Go to Settings > Workspaces > Go to any workspace
Test 1:

On the worksapce page Press Settings option
Verify that Workspace Settings page loads and works as before

Test 2:

On the worksapce page Press Cards option
Verify that Cards page loads and works as before

Test 3:

On the worksapce page Press Reimbursements option
Verify that Reimbursements page loads and works as before

Test 4:

On the worksapce page Go to Reimbursements > Rate
Verify that Rate and Unit page loads and works as before

Test 5:

On the worksapce page Press Bills option
Verify that Bills page loads and works as before

Test 6:

On the worksapce page Press Invoices option
Verify that Invoices page loads and works as before

Test 7:

On the worksapce page Press Travel option
Verify that Travel page loads and works as before

[x] Verify that no errors appear in the JS console

Offline tests

Same as Tests
QA Steps

Same as Tests

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies the form input styles:

[x] I verified that all the inputs inside a form are aligned with each other.
[x] I added Design label so the design team can review the changes.

[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/35371050/fa892bcc-2b0a-4b8b-93f2-b0c8a5266ca7

Android: mWeb Chrome
https://github.com/Expensify/App/assets/35371050/f67b3f55-5cb0-46ff-bc91-bbd944eebaac

iOS: Native
https://github.com/Expensify/App/assets/35371050/5d1f9578-ccf5-46dd-88bf-3a0edfdf62b8

iOS: mWeb Safari
https://github.com/Expensify/App/assets/35371050/77da5a1f-f7fb-40b0-a2b2-bebf096ea5dd

MacOS: Chrome / Safari
https://github.com/Expensify/App/assets/35371050/293a5dbf-0a71-4745-aebd-55e3623a51f4

MacOS: Desktop
https://github.com/Expensify/App/assets/35371050/f9c77c51-b7e0-4322-beb2-928fc17cf134

maybe I messed up with checklist that's why wrong reviewer got assigned, I didn't added a space after the Fixed issues section's $ sign may caused this, I am tagging you manually here @parasharrajat

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to production by https://github.com/thienlnam in version: 1.4.31-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Improvements : Speed

As per our discussion in #2 for speed improvements the following has been suggested

calc coherence & mess in threads
or calc mess for plugins in threads (or some async?)
or something other...

The paths I had in mind was these:

Related to threads idea : use Rayon

Replace HashMap with concurrent DashMap (Current std HashMap implements rayon so not strictly necessary, but might be useful to look into regardless)

~Use replace hashing algorithm used in HashMap~ with FxHash, AHash, HighwayHash

aHash implemented #14

~Replace sort() with sort_unstable()~ #6
~Identfiy preallocation opportunities~. For instance, replace Vec::new() with Vec::with_capacity()

Seems like most current new() cannot really preallocate due to uncertainty. The basic preallocation algorithm is optimized enough that unless we have a strong idea regarding memory access premature allocation is not helpful.

Many of these are low hanging fruit and related to refactoring the code to idiomatic Rust code.
For example, there are many for loops in this code. Iterator based code is more idiomatic, easier to improve with rayon, and interact better with allocation. (pushing items from within a for loop can cause multiple allocs and copies, while collecting an iterator can allow fewer allocations.)

Thank you for issue.

Rayon is undoubtedly a good idea for parallel iterations, it should probably be implemented with feature flag.

Do you mean the hashing algorithm for LRU caching in functions (there are a lot of hashing)?

Why do you think that sort_unstable() will be faster? According to documentation it uses quicksort algorithm (sort uses mergesort). Mergesort has better time complexity in comparison to quicksort, hasn't?

I tried to replace sort() with sort_unstable() and sort_by() with sort_unstable_by(). There is almost no difference in speed, at least for this performance test and benchmark large_datasets.

Do you mean the hashing algorithm for LRU caching in functions (there are a lot of hashing)?

In rust, hashmaps themselves can use an alternative hashing method for speed or other reasons.
The default hasher is siphash1-3 which is ddos resistant, but not fast.

Why do you think that sort_unstable() will be faster than sort()

This is what the documentation says :

When applicable, unstable sorting is preferred because it is generally faster than stable sorting and it doesn’t allocate auxiliary memory. See sort_unstable.

Also sort on vec is timsort and sort_unstable is pdqsort
Unstable sort is only relevant if there are other indexes to consider. Atleast for the sorted indexes it should yield the same result.
In case different results are not desirable, I think it would be a good idea to have a unit or integration test to verify expected behavior.

hm, it looks like I tested it wrongly and unstable sort speed up it for 10-20%.

Yes, I understand. I plan to work on hash function replacement at this time. Rayon will be implemented later, not a goal right now.
Originally posted by @nickspring in https://github.com/nickspring/charset-normalizer-rs/issues/8#issuecomment-1735576667

Some recommendations for hash functions :

FxHash : I don't like it particularly, but I thought i'd share since this is often the first choice in this kind of situation.
aHash : This is not stable (the hash values change from version to version) and only seeks to be the fastest.
highway-rs : This is often overlooked but it is very fast, not cryptographically tested but gone through extensive testing and validation(original paper and Smhasher). It also has sample code on how one might implement it.

use std::collections::HashMap;
use std::hash::BuildHasherDefault;
use highway::HighwayHasher;
let mut map =
  HashMap::with_hasher(BuildHasherDefault::<HighwayHasher>::default());

map.insert(1, 2);
assert_eq!(map.get(&1), Some(&2));

Actually it's good question. I tested standard hasher on big file and it was slow. And I added blake3 hasher (not sure if we need fingerprint, as it is in Python version, at all for comparison, maybe we can compare just decoded_payload)
https://github.com/nickspring/charset-normalizer-rs/blob/4d9fd71bcfe456760cbcce6c0d1d82ab8e380b29/src/entity.rs#L178

#14 implements aHash. For pure speed with little other considerations, it is good enough.
It is an unstable hash, meaning there is no guarantee that there will be same hashes across platforms or versions.
This might become a problem if/when serde becomes a goal, but the way the repo is used currently it won't be a problem. We could implement highwayhash or others when it does become a problem.
As such for short term, further hasher investigations would be lower priority.
To improve from here we would have to implement benchmarks to compare siphash,fxhash,ahash etc.

Hashing is used only for caching, so it doesn't matter that it's unstable. Also, we don't serialize hashes via serde.
I сhose ahash as it's implemented already in cached library as a feature.

I did some experiments with Rayon. At this time it looks like it has high overhead. So I plan to try to rewrite mess measurement code in more efficient way (I have some ideas).

I was looking into the lib.rs Two main loops.
Especially the  named loops 'iana_encodings_loop and 'chunks_loop
Unfortunately, as they are it does not seem like they are easily written into functional Rayon code (if at all)
I agree that some other parts of the code are not good candidates for Rayon due to overhead. Hope you find a good approach!

I'm exploring integrating encoding_rs instead of rust-encoding.
rust-encoding seems to be abandoned and unmaintained. encoding_rs is better supported.
However, they work in fundamentally different ways and encoding_rs does not support many current constructs.
It would obviously take some time.

I'm exploring integrating encoding_rs instead of rust-encoding.
rust-encoding seems to be abandoned and unmaintained. encoding_rs is better supported. However, they work in fundamentally different ways and encoding_rs does not support many current constructs.
It would obviously take some time.

Yes, it doesn't fit to the concept of this library.

It looks like new mess detector approach is faster #31
--> A) charset-normalizer-rs Conclusions
   --> Accuracy: 97.1%
   --> Total time: 1.147958363s
   --> Avg time: 2.806743ms
   --> 50th: 1.044498ms
   --> 95th: 8.228578ms
   --> 99th: 19.302748ms

------------------------------
--> B) chardet Conclusions
   --> Faster than charset-normalizer-rs by 0.6 times
   --> Accuracy: 82.6%
   --> Total time: 2.083252561s
   --> Avg time: 5.093526ms
   --> 50th: 331.699µs
   --> 95th: 2.515793ms
   --> 99th: 16.465157ms

------------------------------
--> C) chardetng Conclusions
   --> Faster than charset-normalizer-rs by 0.9 times
   --> Accuracy: 90.7%
   --> Total time: 1.253477517s
   --> Avg time: 3.064736ms
   --> 50th: 821.598µs
   --> 95th: 8.578877ms
   --> 99th: 24.627836ms

However I broke a lot of idiomatic code in ms.rs.
Tomorrow I will clean code (remove unused functions,  rewrite tests for new mess detector, refactor code).

From the list, only Rayon remains.
Unfortunately the current implementation is streamlined enough that naive parallelization is not helpful.
If there are any ideas, let me know. In the meantime, feel free to close this comment.
I think it would be relevant again when there is a major change in this repo or any upstream dependencies (most of which are also highly optimized)

Yes, I have an idea, to refactor and speed up cd.rs module. I think it's possible.


Add Typography

https://github.com/Jolg42/awesome-typography
I created this list in June 2016, the list now contains +300 resources that are useful when programming with fonts. This repository received multiple PR by third parties and more and more people are using it now!
I just reorganized & cleaned the list following guidelines below. 😇
By submitting this pull request I confirm I've read and complied with the below requirements.
Please read it multiple times. I spent a lot of time on these guidelines and most people miss a lot.

I have read and understood the contribution guidelines and the instructions for creating a list.
This pull request has a descriptive title.For example, Add Name of List, not Update readme.md or Add awesome list.
The entry in the Awesome list should:

Include a short description about the project/theme of the list. It should not describe the list itself.Example: - [Fish](…) - User-friendly shell., not - [Fish](…) - Resources for Fish..
Be added at the bottom of the appropriate category.

The list I'm submitting complies with these requirements:

Has been around for at least 30 days.That means 30 days from either the first real commit or when it was open-sourced. Whatever is most recent.
It's the result of hard work and the best I could possibly produce.
Non-generated Markdown file in a GitHub repo.
Includes a succinct description of the project/theme at the top of the readme. (Example)
The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
Not a duplicate.
Only has awesome items. Awesome lists are curations of the best, not everything.
Includes a project logo/illustration whenever possible.

Either fullwidth or placed at the top-right of the readme. (Example)
The image should link to the project website or any relevant website.
The image should be high-DPI. Set it to maximum half the width of the original image.

Entries have a description, unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.

Should be placed on the right side of the readme heading.
Should link back to this list.

Has a Table of Contents section.

Should be named Contents, not Table of Contents.
Should be the first section in the list.
Should only have one level of sub-lists, preferably none.

Has an appropriate license.

That means something like CC0, not a code licence like MIT, BSD, Apache, etc.
WTFPL and Unlicense are not acceptable licenses.
If you use a license badge, it should be SVG, not PNG.

Has contribution guidelines.

The file should be named contributing.md. Casing is up to you.

Has consistent formatting and proper spelling/grammar.

The link and description are separated by a dash. Example: - [AVA](…) - JavaScript test runner.
The description starts with an uppercase character and ends with a period.
Drop all the A / An prefixes in the descriptions.
Consistent and correct naming. For example, Node.js, not NodeJS or node.js.

Doesn't include a Travis badge.You can still use Travis for list linting, but the badge has no value in the readme.

Go to the top and read it again.

Hi @sindresorhus!
I guess you're busy...! I saw you added some comments to more recent PR and I was thinking that maybe you missed mine.
Let me know if there is something I can do 😉

This doesn't make sense: Hasklig - Hasklig - a code font with monospaced ligatures. Maybe just Hasklig - Code font with monospaced ligatures.
Might want a description: Firefox OS Emojis.
Maybe change the name to awesome-programming-typography? Just a suggestion though.
Add more descriptions please.

What do you mean by that? @gdonnini

To avoid email spam to everyone subscribed to this list, we should
implement standards around appropriate edits / responses / reply-alls
On Thu, May 3, 2018 at 2:31 PM, Joshua Bennett<EMAIL_ADDRESS>wrote:

What do you mean by that? @gdonnini https://github.com/gdonnini
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sindresorhus/awesome/pull/1247#issuecomment-386442826,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADEXEmsZ70qNwkJBNiEUv5Ua-c-QqYmAks5tu3chgaJpZM4StUTQ
.

--
Gabriel Donnini
E-mail<EMAIL_ADDRESS>Cell:<PHONE_NUMBER>

Hi @legodude17 😉
Thanks for the suggestion about Hasklig I'll fix that asap.
About Firefox OS, it was an OS that is now deprecated but somebody forked it more recently I think... So this link is the repository for the emojis designed for that OS. And the emojis are actually part of a font!

I just fixed the Hasklig typo and added a small description for the Firefox OS Emojis entry.
@legodude17 @gdonnini Do you think this list can be added now? 😇

+1

Would love to see this added!

Hey, sorry for the lack of response, please see #1363.

Hi! I've reviewed this submission and it has a few issues.
:white_check_mark: Good!
:x: Needs work!
:grey_question: Not sure, not required, or mixed results
Reviewer comments are in bold after an item.
Awesome Requirements
:white_check_mark: Has been around for at least 30 days.
:white_check_mark: It's the result of hard work and the best I could possibly produce.
:white_check_mark: Non-generated Markdown file in a GitHub repo.
:grey_question: Includes a succinct description of the project/theme at the top of the readme.
The list deals with digital typography; that keyword should probably appear in the description.
:white_check_mark: The repo should have awesome-list & awesome as GitHub topics.
:x: Not a duplicate. Check https://github.com/deanhume/typography#readme.
:white_check_mark: Only has awesome items. Awesome lists are curations of the best, not everything.
:white_check_mark: Includes a project logo/illustration whenever possible. Not required
:white_check_mark: Entries have a description, unless the title is descriptive enough by itself.
:white_check_mark: Includes the [Awesome badge]
:white_check_mark: Should be placed on the right side of the readme heading.
:white_check_mark: Should link back to this list.
:white_check_mark: Has a Table of Contents section.
:white_check_mark: Should be named Contents, not Table of Contents.
:white_check_mark: Should be the first section in the list.
:grey_question: Should only have one level of sub-lists, preferably none. "Tools with GUI" has a sublist, I guess that's okay.
:grey_question: Has an appropriate license. In addition to the linked "Public domain" image, it should be explicitly stated under which license this list is. For example, the original awesome list has

To the extent possible under law, Sindre Sorhus has waived all copyright and related or neighboring rights to this work.

:white_check_mark: Has contribution guidelines.
:white_check_mark: The file should be named contributing.md. Casing is up to you.
:white_check_mark: Has consistent formatting and proper spelling/grammar. :white_check_mark: The link and description are separated by a dash.
:white_check_mark: The description starts with an uppercase character and ends with a period.
:white_check_mark: Consistent and correct naming. For example, Node.js, not NodeJS or node.js.
:white_check_mark: Doesn't include a Travis badge.
Additional Comments
The existence of a web typography list is a bit of a bummer, and there's indeed an overlap (e.g., Typeset.js). Not sure what to do about this.
In addition,
awesome-lint README.md

gives many errors, mostly with trivial fixes.

Thanks a lot for the review @nschloe!
I'll check your report and make the appropriate changes 👍
About the existence of https://github.com/deanhume/typography#readme, the list has a clear focus, see screenshot:

My list is more about tech resources, libraries, tools for digital typography, so both could be listed I think as they are really different.
You also mentioned that there is an overlap but it's only a few links (Maybe 1 to 5?) over +300 awesome resources that are not overlapping.
What do you think?

What do you think?

Just to be clear, I like this list here better than the web-typography one. The best solution would perhaps be a web typography subsection your list. Not sure if this is possible. Admitting overlap is a bit of a slippery slope. Soon enough, somebody will create a retina-typography or a mobile-typography one, all with some overlap.

So if I add a Web-Typography (and a link to deanhume/typography#readme?) section that would mean deleting the other list?
I'm ok with that but I just need a confirmation before updating it :)

Eventually, this is @sindresorhus's call to make.

Can you fix the merge conflict?

Includes a succinct description of the project/theme at the top of the readme. (Example)

❯ awesome-lint https://github.com/Jolg42/awesome-typography
✖ Linting

  README.md:228:124
  ✖   47:120  List item description contains invalid markdown                    remark-lint:awesome/list-item
  ✖   80:54   List item description must start with valid casing                 remark-lint:awesome/list-item
  ✖   93:52   List item link and description must be separated with a dash       remark-lint:awesome/list-item
  ✖  108:65   List item description must end with proper punctuation             remark-lint:awesome/list-item
  ✖  118:59   Text "github" should be written as "GitHub"                        remark-lint:awesome/spell-check
  ✖  167:57   List item description must start with valid casing                 remark-lint:awesome/list-item
  ✖  173:59   Text "OSX" should be written as "macOS"                            remark-lint:awesome/spell-check
  ✖  222:39   List item link and description must be separated with a dash       remark-lint:awesome/list-item
  ✖  228:124  Link to http://pikensoft.com/programs/OpenTypeTemplate.bt is dead  remark-lint:no-dead-urls
  ✖  233:54   Text "Mac OS X" should be written as "macOS"                       remark-lint:awesome/spell-check
  ✖  240:41   List item link and description must be separated with a dash       remark-lint:awesome/list-item
  ✖  242:84   List item link and description must be separated with a dash       remark-lint:awesome/list-item
  ✖  272:118  List item description must end with proper punctuation             remark-lint:awesome/list-item
  ✖  273:80   List item description must end with proper punctuation             remark-lint:awesome/list-item
  ✖  274:48   List item link and description must be separated with a dash       remark-lint:awesome/list-item
  ✖  301:88   Text "Mac OS X" should be written as "macOS"                       remark-lint:awesome/spell-check
  ✖  315:49   List item link and description must be separated with a dash       remark-lint:awesome/list-item
  ✖  316:52   List item link and description must be separated with a dash       remark-lint:awesome/list-item
  ✖  322:56   Text "OS X" should be written as "macOS"                           remark-lint:awesome/spell-check
  ✖  362:2    License image must be SVG                                          remark-lint:awesome/license

  20 errors

https://github.com/sindresorhus/awesome-lint

Closing for lack of response.


Champions program data

Extending from #7. This issue first needs some kind of structured input data from the champions program.

we do have an Airtable for that program :wink: @yabellini


Fix internal link to sample applications

fix link
Checklist

[ ] Changes manually tested
[ ] Automated Tests added/updated
[x] Documentation added/updated
[x] CLA Signed: DataStax CLA

Closing, since its covered in this PR as well.


Ioc

• the university official website URL, if it is different from the domain you are submitting

official website URL : ioc.xtec.cat
<EMAIL_ADDRESS>for example<EMAIL_ADDRESS>• a URL of a page on the official website where a long-term (>1 year) IT related course is offered by the university

https://ioc.xtec.cat/educacio/cfgs-dam
https://ioc.xtec.cat/educacio/cfgs-daw
https://ioc.xtec.cat/educacio/erasmuss#higher
https://ioc.xtec.cat/educacio/attachments/article/531/Erasmus Charter for Higher Education_signed_CP (2).pdf
• a URL of a page or some other proof (.pdf or a screenshot are OK) showing that the university recognizes the domain which you are submitting as an official email domain for the enrolled students.

https://ioc.xtec.cat/educacio/cursos-especialitzacio

@marjosepg I am sorry, I have to close the request without merging, because you made a mistake in a request and requested to merge too many files, most of them do not relate to the organization which you would like to add to this repository. Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


Adding suse ubuntu support

Using the master branch as the base, and adding openSUSE Leap 15 and 42 in for testing (along with variables for SLES and RedHat that I'm currently using).
The main changes here are
variables for almost everything that can be different from system to system
loading the default.yml first, so those are multiple values don't need to be loaded
Changes to the library file to support Ubuntu
Changes to the Dockerfile to support OpenSUSE Leap (enables systemd)
Addition of 4 more images for molecule testing (hope you've got the space...)

still too many unrelated changes, but I pointed this out in the original PR #62 already.

@richm @pcahyna if you all could review this again, I think it's ready for review.

[citest]

ping - any updates?

@chiqomar do you still want use to merge this?  If so, you'll need to rebase and fix the conflicts.

[citest pending]

[citest bad]

[citest pending]


 All CLA requirements met.

 All CLA requirements met.
Originally posted by @microsoft-cla in https://github.com/microsoft/Web-Dev-For-Beginners/pull/271#issuecomment-848483646

python --version


Uncaught SyntaxError: The requested module '/node_modules/graphql-request/dist/index.js?v=1f86a9fa' does not provide an export named 'GraphQLClient' (at index.mjs:2:1)

Any idea what is causing this on the latest Nuxt 3 release RC7?

@procrates Any additional information here would be useful, can you also post the output of yarn nuxi info

Operating System: Darwin
Node Version:     v16.14.2
Nuxt Version:     3.0.0-rc.9
Nitro Version:    0.5.1
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      modules, runtimeConfig
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Build Modules:    -

And btw. With a fresh install:
Uncaught SyntaxError: The requested module '/.nuxt/gql-sdk.ts' does not provide an export named 'getSdk' (at index.mjs:4:1)

Closing for the moment, as this was resolved in an earlier release.


Add fuzzy/fuzzyBy support to accented characters

For example, when the search is "A", the filter would find any of these : "AÂÃÄÀÁÅÆ".
I think this is a complete list of accentes charachters:
ÂÃÄÀÁÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞß
àáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿ
Thank you for your work so far.

After some research I think this is it:
{
"A": "ÁáÀàÄäÂâÃãÅå",
"D": "Đð",
"E": "ÉéÈèËëÊê",
"I": "ÍíÌìÏïÎî",
"O": "ÓóÒòÖöÔô",
"U": "ÚúÙùÜüÛû",
"Y": "ÝýŸÿ",
"N": "Ññ",
"C": "Çç",
"S": "Šš",
"Z": "Žž"
}

Actually found something much more complex http://stackoverflow.com/questions/227950/programatic-accent-reduction-in-javascript-aka-text-normalization-or-unaccentin


Forbid using window properties as global variables

All the properties of window object such as name, self, and status are considered to be global variables because of having browser env in eslint config.
As a result this variables are ignored by eslint for errors such as no-unused-vars when someone uses this variables in their code without the intent of using them as a global variable.
To solve this we'd have to remove browser env  from eslint config and add a list of global variables that are more commonly used. Other window properties are not considered global and requires window. qualifier.
I have added a list of all variables that I think are commonly used as globals in browser env.
Please guide if I have missed something.
How did I test this?
I created a new app with
npm run create-react-app test-app
npm start
Added console.log(status) to index.js file
And it showed error in terminal that status is not defined. (As expected)
But text-editors (Atom)  won't show this as it requires eslint-config-react-app to be installed globally and hence it becomes necessary to update that package globally for this to work.
closes #1834

Are there any common global variables need to be added (such as requestAnimationFrame, XMLHttpRequest)?
I think we can use globals for reference, As I know eslint also use it for its environments.
What do you think?

But I am not sure if we can determine what variables are more common than others considering there are plenty of them.
Eg: I thought we would want location to be used with window qualifier but there it breaks the build as the code uses it without qualifier

Simply, use all window variables with window accessor. Isomorphic app developers will have less trouble!

What about these?

setTimeout
clearTimeout
setInterval
clearInterval
requestAnimationFrame
cancelAnimationFrame
requestIdleCallback
XMLHttpRequest
fetch
console
btoa
atob

I personally never prefix these with window., and I'm certain that I forget others that people often use directly.
Just my 2 cents, but I don't think maintaining another whitelist of global variables is worth ¯_(ツ)_/¯
Anyway, maybe this list can help, it's what eslint uses.

Just remembered about some classes that I see people use without window. prefix:

FileReader
FormData
Worker
SharedWorker

Maintaining this list doesn't seem like best solution as there are too many variables and we can't determine what should be used without window prefix.

But there are too many general variable names in window properties which are considered as globals and ignored by eslint😑.
I think we should blacklist variables that should not be used without window prefix.

I agree, blacklisting seems much simpler.

Whitelist, please. Think about server side rendering.

console
setTimeout
clearTimeout
setInterval
clearInterval

Standard allows only document, console, and navigator without window qualifier. I think it's a reasonable list.
setTimeout and friends aren't affected because they're part of the language.
rAF is affected but is not very commonly used so I'd be fine with using window. for it.

Also we need to add window in globals because without browser env, eslint does not consider it as global.

@gaearon I don't think setTimeout and friends won't be affected by default. Unless they are specified in the whitelist, eslint would complain about them.
I created this repo to reproduce it, I hope it helps.

@gaearon oh, sorry. setTimeout won't be affected because the node env is also included, my bad 😁
But anyway, other things like rAF, fetch and Worker still would produce errors. I really think they should be allowed without window..

@fhelwanger setTimeout won't work if tested in isolation. But as we have node env, setTimeout and others are included in it.

@doshisid yeah thanks! sorry about that, just update the example https://github.com/facebookincubator/create-react-app/pull/1840#issuecomment-288721573

I think with the exception of fetch requiring window prefix would be much cleaner.

I really don't see much code prefixing Worker and rAF with window., but maybe I'm biased ¯\_(ツ)_/¯
Anyway, what I liked about CRA is that it doesn't enforce a code style, and I think requiring this window prefix is some kind of code style in these cases.
That is what I'd like to point out, if you disagree then it's fine 😁

@doshisid can you please fix the kitchensink tests that are failing?
Basically go ahead and prefix usages where needed.
Thanks!

@gaearon per your comment in the export render() issue, we may want to revert this if we're not going to explore SSR in future releases -- imo this is more of a step towards SSR than fixing the original problem

I agree. I’m afraid I am changing my mind here. (Sorry @doshisid for the trouble! Your contributions are appreciated. Sometimes it takes time to figure out what we need.)
I saw a lot of confusion about how to use globals, so I think we should limit the impact of this to as little as possible.
The alternative strategy I suggest is to read through the list of all browser globals, and only forbid lesser-known ones that can reasonably refer to local variables. For example status is a great candidate.

IMO this helps even if we are not going to explore SSR. See https://github.com/eslint/eslint/issues/3959#issuecomment-144591598 .
But in any case, I am happy to help😊

I agree with sentiment in that issue—my proposal is we go through the list and only exclude confusing globals. Needs some human curation but IMO this is okay.

Sorry I misunderstood your suggestion earlier. This seems good. Let me know if I can help.

@doshisid If you could make another PR that blacklists all confusing globals from ESLint browser environment that would help! Now, “confusing” is subjective but I think we can agree that if you can reasonably name your variable this way (e.g. top or self or status), it probably should be disallowed as a global.

To blacklist variables, AFAIK we will have to still remove browser env and add all the browser variables to globals with the exception of the variables we want to blacklist. Correct me if there is a better way to do this.

Yes, this seems fine. I just mean that you can look at ESLint source to find a definitive list of which globals are defined in browser, and use that as a starting point.

Maybe it makes sense to write a custom ESLint plugin which blacklists some names rather than maintaining a whitelist?

I don't think we can blacklist variables using plugins. We'd still have to maintain a whitelist.
But if we export whitelist from a plugin as an env, it would make the main config a lot cleaner.
What should we do here @gaearon

The list of globals that eslint uses for the browser environment is pulled from globals

Sindre has a module for everything imaginable!

We went with https://github.com/facebookincubator/create-react-app/pull/2130 instead.


materialtest: allow maintaining existing elements

I'd sort of prefer Yes/No/Cancel since you're really giving 3 choices, but suddenly cancel means do this thing but with these caveats.

Cancel still means cancel, so should be fine


-Fixture issue #17

As suggested in #18 @devblackops
New pr and cleaner history.

This change is

@GitAMBS,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thanks @GitAMBS. This is much cleaner.


Add error management abilities to interaction methods of Contract interface

When making a call to bundleInteraction with strict flag set to true, multiple kinds of error can be thrown. I experienced two of them: a contract interaction error and a gateway error. The issue is that except for the message attached to their Error object, there is currently no way of telling them apart, and no clear indications on what other kind of error (if any) could also be thrown.
Maybe instead of throwing a generic Error object it could throw a custom one with at least a field (a string literal or an Enum variant ...) that would describe the nature of the error so the code consuming the error would be able to act accordingly? It would also allow users of the library to easily tell what could go wrong within this method or others by looking at said string literal union/enum/... .
Here's how I usually go about for this:
// Define the different kinds of error for a bundle interaction
enum BundleErrorKind {
    InteractionFailed = "InteractionFailed",
    UnrecognizedGatewayStatus = "UnrecognizedGatewayStatus",
}

// Or define the error kind like this, which achieves more or less the same thing while being less verbose:
// type BundleErrorKind = "interactionFailed" | "unrecognizedGatewayStatus";

// Define the custom error object with the "error kind" value attached
class BundleError extends Error {
    kind: BundleErrorKind;

    constructor(kind: BundleErrorKind, message = "") {
        super(`${kind}: ${message}`);
        this.name = "BundleError";
        this.kind = kind;
        Error.captureStackTrace(this, BundleError);
    }
}

// Then we can throw this custom error and attach an "error kind" value to it:
function bundleInteraction() {
    try {
        // some code that calls the gateway and gets a bad status from it
    } catch {
        throw new BundleError(BundleErrorKind.UnrecognizedGatewayStatus);
    }
}

// And eventually, it's easy to see where the error comes from by checking the `kind` field
try {
    bundleInteraction();
} catch (error) {
    if (error instanceof BundleError) {
        switch (error.kind) {
            case BundleErrorKind.InteractionFailed:
                break;

            case BundleErrorKind.UnrecognizedGatewayStatus:
                break;

            default:
                exhaustive(error.kind);
        }
    } else {
        // handle other errors
    }
}

So after doing some research on the subject, I am not satisfied anymore with the pattern I described above for reasons I'm going to explain below.
What I want to achieve with the error handling story in Warp is two fold. It should allow users to easily:

Catch errors coming from the library and tell them apart them
Tell what could go wrong when calling a function from Warp

In the current state of Warp, these two points are not addressed, which is why I suggested an error handling pattern in my previous. However, what I suggested only handles point 1 very poorly and doesn't address point 2 at all. The only way for point 2 to be satisfied would be to manually maintain documentation for every functions that would cause an error either by throwing it themselves or by calling other functions that could throw an error. This means that if the documentation isn't perfectly maintained, it's going to be very hard for the users to know where they should handle what error without having a deep knowledge of Warp's code base. Realistically, I don't think such an error-handling-related documentation can be maintained efficiently. And it's also going to be difficult for anyone developing Warp to keep a mental map of where errors can happen and what kind of error can happen where.
Consequently, while it looks like this solution could, in appearance, easily be integrated into Warp without introducing any significant breaking change, for it to be actually usable in a meaningful way it's going to end up being a big burden on the developers and probably cause a lot of confusion if a bug happens in the error-handling process (a function throw something that isn't described in the function's doc, or the opposite, etc...).
A big part of the problem comes from JS and TS themselves. When we catch an error, the error's type is always unknown, so it becomes the user's burden to find out exactly what is actually being thrown. There is no integration or error-handling in Typescript's type system. Although, it is still possible to actually use Typescript's type system in order to handle errors, by using a completely different pattern: do not throw errors, return them. This pattern is actually what is used in a lot of different languages (like Rust, Haskell, ...), and apparently comes from the functional programing world. There are a couple ways to implement this in Typescript, either manually or by using a library. Having researched the different available options, I feel like using the Result type from https://github.com/supermacro/neverthrow works pretty well.
There are definitely a few pain points with this solution as well, although I believe they are worth it as they completely address the two objectives I listed at the beginning of this post. By encoding the errors a function can make into its return type, it forces the users to either handle these errors or consciously ignore them. It also allows them (and Warp developers) to know just by looking at the signature of a function exactly what kind of error can originate from it. Another amazing point of this solution is that it greatly simplifies refactoring. If a change to a function make it able to make a new kind of error, coupled with exhaustive switch checks, it will cause Typescript to tell us exactly where we have to handle this new error and also what other functions signatures we have to change (what functions call the one that returns a new error).
The pain points I mentioned for this solution are mainly that it's going to change a lot of function signatures, introducing a large amount of refactoring and breaking changes in the way these functions are consumed (inside Warp and also for users of the lib). In order to demonstrate all of what I have been writing about in this post, I have prepared two PR: one with the first solution and another with the second solution (using the neverthrow library), so that it's going to be easier to understand their reach and what could work better for Warp. I am going to link both of these PR to this issue so they can be found easily.


ESRI Integration Review

Time tracking:
Review options for integrating ESRI Quick Capture with:

[ ] The Campus Mobile App
[ ] ServiceNow
[ ] Maximo

Cannot use the QuickCapture app directly without downloading it

No directly API to call to use for the functionality and interface of QuickCapture
QuickCapture is a open source app tho (https://github.com/Esri/QuickCapture)

ArcGIS has a REST API if we know what attribute we are passing into ArcGIS

https://developers.arcgis.com/rest/
Access to location and offline services
We can do similar function inside the mobile app with API?

https://pub.dev/packages/flutter_map_arcgis
Or https://pub.dev/packages/geolocator

Nothing useful related to ServiceNow/Maximo IBM I can find

Stave Maps on ServiceNow store - used to visualize ServiceNow data. It doesn't seem to relate to our purpose though.

Create Esri Quick Capture with ArcGIS REST API?
https://community.esri.com/t5/arcgis-rest-api-questions/create-esri-quick-capture-with-arcgis-rest-api/m-p/1175774


Bug Report: Tutorial camera doesnt zoom in freeplay

Please check for duplicates, similar issues or closed issues with the same problem, as well performing simple troubleshooting steps (such as deleting the export folder if it's an issue with compiling, reinstalling Kade Engine) before submitting an issue.
If you are playing a downloaded version of the game, what operating system are you using?
Windows (x86), Windows (x86_64), Linux, or macOS? Specify below.
windows 10 64 bit
What version of the game are you using? Look in the bottom left corner of the main menu.
ke 1.5.4
https://github.com/KadeDev/Kade-Engine/releases/tag/1.5.4
Have you identified any steps to reproduce the bug? If so, please describe them below. Use images if possible.
load tutorial on freeplay
Please describe your issue. Provide extensive detail and images if possible.
tutorial's camera zooms when you load the song in story mode but on freeplay it doesnt zoom
camera during story mode

camera during freeplay mode

THIS IS INTENTIONAL
I DON'T KNOW WHY BUT


lomiri.history-service: init at 0.4

Description of changes
Working towards #99090.
history-service provides call and conversation logs for the Lomiri stack. telephony-service and phone-related apps will depend on it.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Any idea what the aarch64-linux failure might be? Is it flaky?

Seems to be flaky yeah. That test, along with afew other ones, uses QSignalSpy, which seem abit finnicky to use 100% reliably. QSignalSpy tests also frequently fail on upstream CI (grep for FAIL!), the solution there is to just wait for the next run...
Unfortunately, I would really prefer to have some tests enabled on this package. Figuring out the issue with the broken schema generation was really hard before I started running the test suite, and running it seems even more important now that we use a custom schema generation script. I'll try to check if we can disable them without losing the tests for the schemas.

Your thorough work is exemplary. It is a joy reviewing these

I have opened an issue about the flakiness upstream, since this also affects their infra: https://gitlab.com/ubports/development/core/history-service/-/issues/13
One possible, easy workaround would be to increase the amount of time all of those tests wait for the signal they're checking for for to be emitted. The current timeout is the default 5s one, Qt's test infra actually waits for 2x that and prints an additional message if the comparison passes after the intended timeout, but before 2x of it.
Unfortunately, building history-service on my current hardware takes at least 17 minutes, so this is kind of a chore to test. And in 4/4 local runs, I didn't hit this issue a single time. And the failure on OfBorg doesn't print this extra message, so it's hard to tell what happened or when the signal would've been emitted.
I'll try vendoring a patch to increase the per-check timeout to something higher - maybe 20 seconds for now, in case the test that timed out on OfBorg would've passed after the arbitrary 2x timeout extension. If that works locally & on OfBorg, then I'll test it afew more times when I'm back home. If it also works there, then I'd be in favour of keeping this vendored for awhile and watching Hydra to see if it ever has any issues like this. If that all works, then I'll send it upstream to see if they think it's good enough. Otherwise, I'll try to disable these tests and see if upstream has any opinions on how to solve this.

Disabled the problematic tests, submitted some fixes upstream and cleaned up some other stuff. I think this should be good for review again.

Result of nixpkgs-review pr 261031 run on x86_64-linux 1

2 packages built:

lomiri.history-service
lomiri.history-service.dev

Sorry I'm slow to respond during the holidays, as I'm mostly AFK. LGTM!

No worries, I'm mostly busy with holidays & other projects myself.


fix: handle deprecated npmjs packages

Fixes #120

:tada: This PR is included in version 2.17.1 :tada:
The release is available on:

Chrome Web Store
v2.17.1
GitHub release

Your semantic-release bot :package::rocket:


refactor: Move createdTime function into pkg/utils

Signed-off-by: zeppp<EMAIL_ADDRESS>
1.Describe what this PR did
Move createdTime function from ps.go to utils.go
2.Does this pull request fix one issue?

3.Describe how you did it
4.Describe how to verify it
5.Special notes for reviews

PTAL @allencloud

Hi @zeppp ， I have issue about this feature, caused by https://github.com/alibaba/pouch/blob/master/apis/server/container_bridge.go#L238
If you run the container, the Created status will be wrong.
➜  pouch git:(master) pouch create --name foo1 registry.hub.docker.com/library/busybox ls
container ID: 7c6816759f1c0a120da91bf1a4f492c487f56630a78ba71ce364de6ed1714ced, name: foo1
➜  pouch git:(master) pouch start foo1
➜  pouch git:(master) pouch ps
Name   ID       Status    Image                                            Runtime   Created
foo1   7c6816   stopped   registry.hub.docker.com/library/busybox:latest   runc      about 17519 days ago

Because the StartedAt is date, not timestamp.
➜  pouch git:(master) cat /var/lib/pouch/containers/7c6816759f1c0a120da91bf1a4f492c487f56630a78ba71ce364de6ed1714ced/meta.json | jq1
{
  "Args": null,
  "Config": {
    "Cmd": [
      "ls"
    ],
    "Entrypoint": null,
    "Env": null,
    "Image": "registry.hub.docker.com/library/busybox:latest",
    "OnBuild": null,
    "Shell": null,
    "Tty": false
  },
  "HostConfig": {
    "Runtime": "runc"
  },
  "Id": "7c6816759f1c0a120da91bf1a4f492c487f56630a78ba71ce364de6ed1714ced",
  "Mounts": null,
  "Name": "foo1",
  "State": {
    "FinishedAt": "2017-12-19 10:51:30.681763441 +0800 CST m=+566.484707937",
    "Pid": -1,
    "StartedAt": "2017-12-19 10:51:30.56459485 +0800 CST m=+566.367539349",
    "Status": "stopped"
  }
}

@0x04C2  Thanks, i will fix it soon.
Should I change all into timestamp instead date? @allencloud

CI fails, please go fmt your code:
daemon/mgr/container.go
pkg/utils/utils_test.go
please format Go code with 'gofmt -s -w'
Makefile:38: recipe for target 'fmt' failed
make: *** [fmt] Error 1


JS Errors

I get this error when following the steps you provided.

Hey, can you please provide more? Maybe something other interacts with content editor

@SebastiaanKloos any updates on this error?


Confusing Identity supportability

Hi, we find this document confusing in that it states Entra ID as not being a supported authentication method yet further down the document states examples of using Entra ID hosts
Is the scenario of Entra ID only joined session hosts with an Entra ID configured storage account supported for MSIX Appattach?

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

ID: c7f896c0-c7a0-d8ff-225e-9b20f5c9dbcc
Version Independent ID: 62e71f0b-88e5-9bca-fa24-383545508801
Content: MSIX app attach and app attach - Azure Virtual Desktop
Content Source: articles/virtual-desktop/app-attach-overview.md
Service: virtual-desktop
GitHub Login: @dknappettmsft
Microsoft Alias: daknappe

@integyjc
I apologize for the confusion in the document. To clarify, Entra ID is not a supported authentication method for Azure Virtual Desktop. However, Entra ID can be used as a storage account for MSIX App Attach in Azure Virtual Desktop.
In other words, you can use Entra ID as a storage account for MSIX App Attach in Azure Virtual Desktop, but you cannot use Entra ID as an authentication method for Azure Virtual Desktop.
I hope this clears up any confusion. Let me know if you have any other questions.

Hi @integyjc - please ignore the previous comment, it's inaccurate. In general, session hosts can be joined to Microsoft Entra ID, but specifically for MSIX app attach, your session hosts musn't be joined to Microsoft Entra ID. For the App attach (new version), your session hosts can be joined to Microsoft Entra ID. The paragraphs that mention Microsoft Entra ID will now only show when you select the new version at the top of the article. Apologies for the confusion.  The changes should be visible later today.
#please-close


New rule on SAGEMAKER_TRAINING_JOB_NETWORK_ISOLATION_ENABLED

New rule to verify that the Amazon SageMaker training jobs have Network Isolation enabled.
Please provide comments on the gherkin if any.

Description:
  Check whether Network Isolation is enabled for all Amazon SageMaker Training Jobs.

Trigger:
  Periodic

Reports on:
  AWS::::Account

Scenarios:
  Scenario: 1
     Given: No Amazon SageMaker training jobs exist
      Then: Return NOT_APPLICABLE
  Scenario: 2
     Given: At least one Amazon SageMaker training job exists
       And: EnableNetworkIsolation is set to False for atleast one Amazon SageMaker training job
      Then: Return NON_COMPLIANT with annotation "Network isolation is not enabled for the Amazon SageMaker Training Job(s): <Training job names>."
  Scenario: 3
     Given: At least one Amazon SageMaker training job exists
       And: EnableNetworkIsolation is set to True for all Amazon SageMaker training jobs
      Then: Return COMPLIANT

Just added a space of "At least". Good to go!


Test build against gcc11

Some ATLAS friends reported problems building in GCC 11. The error is something about us using size_t outside the std:: namespace.
More generally, it might be good to have a few images around with custom compilers installed, to catch issues like this. @matthewfeickert might be able to take a look. If it's easy to add this to CI that would be awesome.

Nice find. We just need boost and Eigen3. They are both header only so install should be easy (I'm pretty sure property-tree doesn't need any of the stuff that boost::jam or whatever requires.


German keymap does not work correctly on Windows 10

In the German keymap some characters (like |) are inserted by pressing the modifier key Alt Gr. This does not work in rustyline.
It seems that Alt Gr (which is Alt + Ctrl) is interpreted as Ctrl on Windows:
https://github.com/kkawakam/rustyline/blob/4a87a1944ee73bcad760b44699e145ee64657a83/src/tty/windows.rs#L140-L152

7.1.0 released.


rocksdb version too old

Graph store depend on rocksdb module at an old version
[dependencies.rocksdb]
git = "https://github.com/pingcap/rust-rocksdb.git"
rev = "23a604459899f4f7a4c8967f16b6fa623474f27b"

We need to upgrade this module in order to support latest version of clang

FYI: #525

Closed due to duplicated


Ft notify often #156577843

What does this PR do?
Notify user when job is run too often
Description of Task to be completed?
User should receive a notification when a job is run too often
The job/check should get an icon indicating the job is running too often
How should this be manually tested?

Install the project and install the requirements.txt
2.Set up email configurations from an email server, host, user, password, port
3:Change the email backend to support the smtp server you are going to use
4: Create a job/check
5: Run the job too often by pinging the check URL multiple times
6: You should receive a an email informing you of the same and the job should get an icon indicating the job has run too often.

What are the relevant pivotal tracker stories?
#156577843
Checklist: I completed these to help reviewers

[x] My IDE is configured to follow the PEP8 Conventions
No? Unsure? -> configure your IDE, format the code and add the changes with git add . && git commit --amend

[] I have added tests to cover my changes. (If you refactored
existing code that was well tested you do not have to add tests)
No? -> write tests and add them to this commit git add . && git commit --amend

[ ] All new and existing tests passed.
No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.

[x] My pull request is based on the latest changes of the develop branch.
No? Unsure? -> execute command git pull --rebase origin develop

observe the PR naming convention #[story-type] [story-id] [story-name]


debug [experimental / please do not review]

Teammates: I know I don't "need" (in some sense) to open a PR to accomplish what this is doing; I could use a branch. Please note that it has always been (and continues to be) my strong preference to use draft PRs because they're easier to discover -- the most recent draft PR is always right there at the top of the PR list; my most recent branch, is a pop-up list and a scroll-down through perhaps dozens of other branches, & I've always preferred to let the machine make it easier for me to find things.
Hence my marking this as "please do not review".
Cheers!

completed; see also for #313 for the keepables.


Don't include the compilation output in the compile classpath

Fix https://github.com/com-lihaoyi/mill/issues/3068
But we need to make sure this is the right thing to do. We include the classes dir in the classpath since very early.

This change break a lot of tests. Also, PR https://github.com/com-lihaoyi/mill/pull/3072 which fixes the left-over tasty files issue, provides a test case that shows that compilation fails properly when tasty-files are not present. So I'm closing this as not correct and needed.