Fix iOS issues. Upgrade to latest version of SystemJS. Replace fat ar…

…row functions with es5 functions

Hi
I think this library was perhaps upgraded to a later babel version, but no presets or plugins were added so the fat arrow functions started breaking in iOS Safari  I guess I could have added the babel plugins, but was easier for me to get it working and tested by just switching to regular functions.  Hope you don't mind. Feel free to disregard/redo.
Martin

Interesting.  If the result of babelify on arrow functions does not work in iOS, there could be some other apps affected.  I'd be interested in getting to the bottom of that.  I think the runtime is probably only included for Promise.  The runtime tries to emulate a full ES6 environment, and it tends to bloat the bundle.  Given that, to get promise functionality, I'd tend to prefer using lie.

My assumption is that it's not that babelify of fat arrow functions doesn't work on iOS. I think it's more that at some point the version of babel in this project was probably upgraded to 6+. In babel 6, by default you get no or minimal e6 support and instead you have to explicitly specify presets or plugins.  I don't think this project is specifying any in it's browserify cmd and doesn't have a babel.rc so by default babel isn't doing much.

I added some css tweaks to the hello-world-fra-iframe, to fix an issue with scrolling in iOS when using VoiceOver.
VoiceOver uses a page based mechanism to allow the user to scroll the page using a 3 finger drag gesture.
I hit an issue with our question editor, where you can scroll the page down then up when the page is first displayed, but then you can no longer scroll.  hello-world-fra-ifram has the same issue.  I narrowed this down to issues caused by ifrau/iframe-resizer setting the iframe height as a style on the fra's iframe.  If the height is set incorrectly (less than the actual height of the fra page) then the scrolling issue presents itself.
The fix was to tweak the css to make it easier for iframe-resizer to correctly calculate the page height.
I believe our iframe-resizer integration is using the default calculation method:
https://github.com/davidjbradshaw/iframe-resizer#heightcalculationmethod
This doesn't correctly calculate the size in a scenario like the following because the h1 margin is collapsed into the margin of the body element.  So the actual margin of the document is 30px but this is not taken into account by iframe-resizer.  So you end up with a body element that is smaller than the html element and the iframe height is set to be too small.

How now brown cow

The workaround I've used for the question editor is to add a body margin-top matching the h1 margin, and I've added that same workaround to this hello world fra.
Maybe it would be better to see if we should be using a different height calculation method, but that seems to be opening up a can of worms, and this is a quick and understandable solution once you are aware of the issue.

Hey Martin, if one doesn't already exist, it would probably be worthwhile logging an issue in ifrau and getting in touch with one of the contributors for ifrau re the sizing issue.  I think a couple of those guys are much more aware of the limitations of iframe-resizer, and the value we get out of it, so they'd be best to comment on solution.

Closing due to age.


MySQL "No operations allowed after connection closed" error

Hello,
As the title says, only luckperms is having this problem from 1 to 3 hours after I start the server. The error message appears around that window of time. No other errors. Just keeps repeating itself again after 1 to 3 hours between each message.
Yes, I already followed the "Storage system errors" in the Wiki.
I double checked the MySQL wait_timeout and it is 28800 (default). I didn't change the default in config.yml either.
Here is the storage section from my config file
And the Console error log
Sumary:

My setup has Spigot 1.13 latest build and LuckPerms 4.3.73
Error happens in production (several plugins) and in test setup (luckperms only)
Error also happens with new MySQL databases
Startup connection works fine
Also tested maximum-lifetime set to half (900000ms, 15min)

I found the autoReconecct property for MySQL, not sure how LuckPerms handle that tho.
Any ideas? Thank you in advance.

Does it happen to be a MariaDB server?
Because if so, you should use the MariaDB storage type. And also it has several configs. I'm never sure which config it actually uses, so I'd check all.

Is MySQL 5.7+, in this case. I was using MariaDB before, it was fine (no errors).

Appreciate you taking the time to read the wiki before making an issue! <3
I'm not sure either. These errors aren't from LuckPerms, and I don't know enough about the way MySQL / the MySQL driver works to be able to give much more advice.
As it's not an LP issue, there's really nothing I can do. I guess in terms of practical advice, you could:

Attempt to set the lifetime even lower
Switch back to MariaDB?? (if it worked before then perhaps that's gonna be the easiest way to resolve the problem)

Bear in mind also that timeout errors can be a result of dodgy network connections - if the link between the servers is bad that could result in connections timing out.

Well, around 17 plugins use that database, and all of them are fine. Only LuckPerms is having the issue.
My database logs show no signs of LuckPerms trying to reconnect.
As you said, you don't know enough about MySQL, this could mean you may have left out some important configuration (or correction) while setting up the JDBC? Several other plugins that I use have the  autoReconect option in their code for MySQL.
The issue is closed, no need for me to keep poking. Just asking kindly to not disregard issues like that because it is not impossible (or unusual) to miss something like that.
Just keep your eyes open for any leads, alright? <3
Thanks for the hard work.

Absolutely, I'm definitely not infallible - far from it. 😉
The reason I closed the issue is because as far as I can tell, there's nothing I can immediately change or identify within LuckPerms itself to resolve the issue.
The JDBC settings are fairly standard, and I'm using a very popular (and I would say generally well regarded) 3rd party library to handle connection pooling. I believe auto reconnect functionality is handled by Hikari in this instance.
If anything else comes up, or if anyone has any ideas, please feel free to comment and I'll reopen the issue. (or you can!)


"silverbullet clean" command to remove directive results materialized in pages

Right now, whenever you use a #query or #use or any other directive, it materializes its results and saves the current state to disk. For local use this is probably ok. The question is if you want this when you e.g. commit your stuff to git as well, or you would want to commit "clean" files without the materialized stuff.
For this we could introduce a silverbullet clean command that goes through all your pages, wipes out anything between <!-- #directive --> and <!-- /directive --> and saves it. You could then use this a pre-commit hook.
First discussed here: https://github.com/mattermost/mattermost-test-management/pull/4#issuecomment-1308964892 cc @m1lt0n
We may also want to introduce an opposite command (not sure what it should be called, maybe render) which populates all directives in a batch mode, without having to "visit" each of the pages to have the directives be rendered.

2/5 that I actually like the current behaviour as the default one because it allows reading the committed files with the directive content in, e.g. GitHub.

Definitely this would be optional. A big reason to "materialize" the queries to disk is to reduce lock in. You can view these files with any tool, even github, and get 100% of the content. This is as opposed to Obsidian where a lot of plug-in functionality depends on having Obsidian + specific plugins installed, like Dataview.


FMP tickrate

When this mod is enabled, Forgive Me Please ticks extremely rapidly (presumably every frame). This can cause crashes when used alongside items that generate entities, such as Monster Tooth or Ghor's tome.

This was most likely due to the mod not being updated for SotS. It has now been updated, please re-open this if you're still having issues.


[vcpkg_configure_make] Misc fixes

Includes #30381.
Fixes SKIP_CONFIGURE option.

[x] Changes comply with the maintainer guide

https://github.com/microsoft/vcpkg/blob/6d69bbacd2fbeae957f034dbbd2b454b5e3941fe/scripts/cmake/vcpkg_configure_make.cmake#L681-L684
Also needs fixing. -L flags only work if cl is used through USE_WRAPPERS

Also needs fixing. -L flags only work if cl is used through USE_WRAPPERS

What kind of fix do you expect?
The wrapper stopped caring about -L since this flag became prefixed with -Xlinker. That's what I see freqently in CI error logs.
I would like to reduce the -Xlinker noise if  the wrappers & libtool are not used.

Which toolchain is expected to match
if (CMAKE_HOST_WIN32 AND VCPKG_DETECTED_CMAKE_C_COMPILER_ID MATCHES [[cl\.exe$]])

What I see in CI for x64-windows is
set(VCPKG_DETECTED_CMAKE_C_COMPILER_ID "MSVC")

Probably VCPKG_DETECTED_CMAKE_C_COMPILER was meant to cover clang-cl/cl but  probably also needs to covers icx somehow in the future. I would like to change that to use MSVC_FRONTEND_VARIANT however that only gets consistently set with a newer cmake version than vcpkg currently has.

@Neumann-A To implement the lib path flags change it would be ideal to simply have CMAKE_LIBRARY_PATH_FLAG and maybe also MSVC, but both are not yet exported from script/get_cmake_vars.

Changing that script will increase the cone of destruction for this PR, making the PR more vulnerable for baseline regressions.
That script has cache variables to control which variables get exported, but there is no simple way to add variables.

For now I decided to not change that script, but just leave comments.
I don't have access to MSVC or clang-cl outside vcpkg CI, so I can't check any logs (or paths with spaces) for these triplets unless CI fails.

I will place this PR in draft until the tests pass.

Baseline regression from new port...

Depends #31383.

Needed for #31497.

The corresponding cmake variables are:
...

Note that not all these variables are currently exported from get_cmake_vars. Touching that script would significantly increase the cone of destruction. I won't do that without a clear request from the maintainers. It increases CI  build times and is prone to hit new baseline regression.

dan-shaw added https://github.com/microsoft/vcpkg/labels/depends%3Adifferent-pr and removed https://github.com/microsoft/vcpkg/labels/requires%3Adiscussion

@dan-shaw This type of change doesn't generate any GH notifications. I noticed it just now.
The merge conflict and minor issues are resolved, CI is running. But which other PR is this waiting for? It is more like other PRs being waiting for this one, for cross-build success.

From the vcpkg team meeting: vcpkg_find_acquire_program(VSCLANG) is blocked by Billy's work on #31748 (however, those changes can be moved out of this PR). The other changes I think we can accept, though the CMake scripts aren't really meant to be changed significantly. Is it possible to move this into a script port so we can get versioning?

VSCLANG is offered for better error reporting. It doesn't download anything, so it doesn't benefit from the new function in #31748, and the suggested guidelines do not say anything about the interface of such script ports. So I simply cannot do that script port now.
But I can simply roll this back to CLANG which worse but already exists.

But I can simply roll this back to CLANG which is worse but already exists.

Done.

No longer https://github.com/microsoft/vcpkg/labels/depends%3Adifferent-pr.

There is a conflict.

There is a conflict.

Trivial, resolved. vcpkg version registry is unfriendly to merges.
Just don't let it wait in the loop too long again.

There is also a gmp conflict.

There is also a gmp conflict.

Trivial, resolved. vcpkg version registry is unfriendly to merges.
The conflicting change to master was after today's first PR update.

We discussed this PR ago and decided that these changes merit the creation of a port version of the make helpers, in order to preserve backwards compatibility with old ports as much as possible. New ports would need to use the modernized port helpers and we add the deprecation warning to the existing helper function.
I understand your reluctance to proceed in this direction since we haven't been clear on a standard interface for helper ports. Personally, I would base it on the interface exposed by the vcpkg-cmake port (similarly, the make helpers were based on the interface of the cmake helpers).
Some things to consider:

We should make migration from helper functions to helper ports as painless as possible.
Functions like vcpkg_configure_make should be renamed to vcpkg_make_configure like we did for the vcpkg-cmake port.
New CMake code should be compliant with the CMake guidelines created by Nicole

We discussed this PR ago and decided that these changes merit the creation of a port version of the make helpers, in order to preserve backwards compatibility with old ports as much as possible. New ports would need to use the modernized port helpers and we add the deprecation warning to the existing helper function.

This PR is more or less a collection of necessary fixes to long-standing bugs in vcpkg_configure_make, wrapped in changes which make maintenance more feasible.
Question: Did the team decide to leave these bugs unfixed, or do you want them to be unwrapped and submitted individually in a more ad-hoc manner?
In particular: C1, C2, C4, C5, C7.

I understand your reluctance to proceed in this direction since we haven't been clear on a standard interface for helper ports. Personally, I would base it on the interface exposed by the vcpkg-cmake port (similarly, the make helpers were based on the interface of the cmake helpers).

I do understand the team's reluctance to accept signifcant changes to vcpkg_configure_make. I'm not reluctant about creating script ports, but I'm much less optimistic about the potential of versioning and the ability to sufficiently deal with trade-offs in a reasonable time.
This is my script port wishlist:

Check and report tool requirements in a consistent manner, instead of leaving it to ports (autoconf-archive, libtool).
Split out the running of in-source maintainer scripts (autoreconf -vfi). A separate script port would allow for expressing tool dependencies (autopoint). This script could deal with stuff which is done in portfiles now, such as disabling autopoint/nls.
Be flexible with regard to configure scripts (none, autotools configure, custom shell script, python (as in openssl).
Support parallel configure - a significant build time improvement for ports like gettext.
Be flexible with regard to the make tool.
Improve make argument handling for build and install
De-duplicate environment variable setup between configure and make.

We should make migration from helper functions to helper ports as painless as possible.

This sounds nice, but I would give priority to significant improvement over painless migration.

Functions like vcpkg_configure_make should be renamed to vcpkg_make_configure like we did for the vcpkg-cmake port.
New CMake code should conform to the CMake guidelines created by Nicole.

Goes without saying.

Having a port helper allows us to leverage versioning, which will allow us to make changes to the API or internals freely.

I don't share the optimism with regard to versioning. ATM only one script version can exist in any installation. This limits the space for changes to the script interface once the port is merged and used.

If further guidance is needed, the team will consider creating helper port guidelines.

Please finish the tool ports guidelines soon.

Be flexible with regard to configure scripts (none, autotools configure, custom shell script, python (as in openssl).

When I wrote vcpkg_configure_make I was working on all the x ports and autotools+automake where standard there however since then I encountered more make based ports with different requierements. make based ports can probably be separate into 4 classes

autotools + automake/libtool

only autotools (no automake or libtool)

configure + make

only make.

as such the script would ne to be split up as follows

a) environment/flag setup (with and without CPPFLAGS + wrapper setup)
b) pkg-config setup
c) calling autoreconf or any other configure preparation step
d) calling configure
e) calling make (build/install)

The current state is that d) includes a/b/c/d while e) includes a/b/e
These modules would then be combined to different higherlevel functions for the 4 port categories .e.g

a b c d e

a b c d e (maybe with deactivated wrappers or conditional wrappers and no CPP)

a b d e

a (b)? e

De-duplicate environment variable setup between configure and make.

This is currently required due to trying to cater to cases 1/2/3 vs 4
Additionally there should be a port containing compile wrappers for use with make based ports. Having to edit the automake ones is kind of a PITA.

https://github.com/microsoft/vcpkg/issues/32282 also needs a fix in vcpkg_configure_make.

When I wrote vcpkg_configure_make I was working on all the x ports and autotools+automake where standard there however since then I encountered more make based ports with different requierements. make based ports can probably be separate into 4 classes
...
* 4. a (b)? e
...
Additionally there should be a port containing compile wrappers for use with make based ports. Having to edit the automake ones is kind of a PITA.

@Neumann-A, Is there any sort of guide for how to get the vcpkg_configure_make  with the category 4. a (b)? e "only make" style of packages?  I wanted to attempt a port for such a package, but ran into some trouble.
CMake Error at scripts/cmake/vcpkg_configure_make.cmake:178 (message):
  Could not determine method to configure make

Adding SKIP_CONFIGURE seems to be broken, which led me to this PR.

Adding SKIP_CONFIGURE seems to be broken, which led me to this PR.

@gotnone The workaround is to provide a no-op configure script with the port. Maybe not even no-op but generating an custom Makefile.vcpkg which transforms and captures configuration parameters and calls to the actual Makefile.

We discussed this PR ago and decided that these changes merit the creation of a port version of the make helpers, in order to preserve backwards compatibility with old ports as much as possible. New ports would need to use the modernized port helpers and we add the deprecation warning to the existing helper function.

This PR is more or less a collection of necessary fixes to long-standing bugs in vcpkg_configure_make, wrapped in changes which make maintenance more feasible. Question @vicroms: Did the team decide to leave these bugs unfixed, or do you want them to be unwrapped and submitted individually in a more ad-hoc manner? In particular: C1, C2, C4, C5, C7, C9.

Ping @vicroms @BillyONeal

These changes are still needed for correct flags for cross-building python3 for android.

Ping @JavierMatosD
Please take a look at this PR.

Heads up: NDK 26 reached beta 1. #33179.

@dg0yt the team decided to leave those bugs unfixed and that any new fixes would be in a script port

is this can be merge?

@dg0yt the team decided to leave those bugs unfixed and that any new fixes would be in a script port

Just to clarify since this got some downvotes. We do not believe that we can prove that existing versions of ports will never be broken by these changes. Someone can do:
"overrides": [
{"name":"gmp", "version": "6.2.1#20"}
]

which means that the corresponding changes in this PR to gmp will not happen but they'll get the "new" vcpkg_configure_make. We don't know how to prove one way or another that that composition works, meaning that someone updating their vcpkg with an old baseline would suddenly be broken. That would break our 'no changes mean no changes' design goal.
Part of the reason we are in this situation where these helpers have funny behavior is that we don't have a great understanding of how any of these changes interact with all 4ish build systems this is nominally serving.

Please finish the tool ports guidelines soon.

Yeah that is still on my plate, sorry :(. But I don't think that affects what happens with helpers for make.

Please finish the tool ports guidelines soon.

Yeah that is still on my plate, sorry :(. But I don't think that affects what happens with helpers for make.

It is relevant for getting UX right:

VS's clang as used by gmp et al. (This change is removed from this PR, but the problem persists.)
autoconf, autoconf-archive, automake, libtool. (See the recent python update for the trouble with handling this properly on a per-port base.)
This is too much to ask for in the central script, but it should be done right in the script port.

Heads up: NDK r26 is now the latest official LTS release.
Export more reports like #33881.

I do understand the concerns about breaking old versions.
I do not understand the general decision "to leave the bugs unfixed" which effectively forbids cherry-picking less problematic changes.

Requesting a new review @BillyONeal @JavierMatosD @dan-shaw @vicroms.

No port changes required, so there should be more confidence that it doesn't break customer ports and triplets.
(Exception: uwp support in port icu is fairly new, and the change seems to be a real fix, dealing with the uwp appcontainer bits. I compared build logs with #35848.)
Tested with Android NDK r26 in #35851.
(More changes required to ports, mostly because new headers became available but the availability of functions still depends on API level. And clang seems to use C++17 by default, removing e.g. std::unary_function.)

Ok, I like the changes here. I'm going to bring it up to the team during our next review meeting :) Thanks @dg0yt for your work and patience!

The team has reviewed the changes and agrees with the approach, as long as we can confirm that the command line to the compiler remains the same before and after, with the specific handling of the --target flag being the only exception.


Make it Easy to Access All of the Hydra Files that a User has Uploaded

I know that we have the search feature for this but putting a quick access button to this page will make a lot of users conscious of their profile ans image to our larger budding community.  It will also remind them which files they are responsible for to that they maintain them better.

This already exists.   Nevermind.


can this plugin as same as 'vite-plugin-vue2-jsx' plugin ?

They are not the same.
This plugin is for Vue 2.7 JSX support.
If you are using Vue 2.6 + JSX, please use https://github.com/underfin/vite-plugin-vue2#jsx and set its jsx to true.
I didn't know there was a vite-plugin-vue2-jsx before this issue. It's not developed by the Vue team.


Multi channel EPG

While current EPG is good for a single channel. It is not how people would decide what to watch when having multiple channels available. That's why I would suggest not to invent something new but do it as all satellite boxes have done it before, like kodi simple iptv epg is doing and many others - multi channel EPG. You see your multiple channels, timeline, and what each channel has to offer. Here's a quick example i've found on the net: https://www.sat-universe.com/imagehosting/2821884dc95a2ded497.png

This is a function I've also been waiting for myself, like the Kodi PVR IPTV Simple Client plugin

First version of the feature is in included in v0.11.0, see: https://github.com/4gray/iptvnator/releases/tag/v0.11.0


Add travis file that runs hlint

Currently this merely runs hlint (source code suggestions) as per Neil Mitchell's blog post. I've configured it to always pass, we'll see how that works.


Hello Symox I change your web code as your need

hello, Symox I change your web as your need. please review my pull request
if you like that please marge to the main branch and we  will work together

Hi Harsh Singh, Thanks for the requests, this project is actually some pre-work I'm doing in preparation for a course I am starting to learn all the basics. I appreciate the changes but I'd like to build it up and learn it all for myself. Maybe we can work in the future!


Add docs for html elements reusability

This is about:

[ ] A typo
[ ] Innaccurate/misleading documentation (e.g. technically incorrect advice)
[x] Undocumented code
[ ] Outdated documentation
[ ] Other

Problem

Read up here: https://github.com/yewstack/yew/pull/2178#discussion_r754165481

Details about the solution you'd like (Optional)
Additional context (Optional)

Questionaire (Optional)

[ ] I'd like to write this documentation
[ ] I'd like to write this documentation but I'm not sure what's needed
[x] I don't have time to add this right now, but maybe later

@voidpumpkin, @mc1098, can you describe what exactly needs to be documented? What are "weird cases" we should expand upon?

@voidpumpkin, @mc1098, can you describe what exactly needs to be documented? What are "weird cases" we should expand upon?

@hamza1311 Coming back to this, its probably going to be a bug what i had in mind. Until i test it, i will keep this issue on me as a reminder and alter either add the docs or remove the statement about "weird cases".

I did not reproduce my issues, this task can be used to just remove that "weird" sentence https://github.com/yewstack/yew/pull/2178#discussion_r754165481


Remove quarantine label

Signed-off-by: Vatsal Parekh<EMAIL_ADDRESS>
What this PR does / why we need it:
Remove the quarantine label added in #5998
I was not able to reproduce this locally and after some changes in the test file, I see this has not failed in last 15 days, so removing the quarantine label for stability check
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

We also have #6096 which should further reduce timeout-based flakes in this test, as well as address the failures in its VMI-counterpart.
/lgtm
/cc @enp0s3

/retest

/hold until #6096 makes stability better

/hold until #6096 makes stability better

#6096 has just been merged.

/retest

#6096 has just been merged.

Great, we are now checking the stability in the periodics. If we don't have any more failures until 2021-08-12 we can unhold this one.

@fgimenez
/hold cancel

/retest


pending payments display in order summary

display received payments & refunds in one list, with a subtotal, then below that add pending payments, with a total.
rather than just all payments in one list, with a column for whether they've been received.

@nmorduch This seems like you'll probably need differently structured data. Does that seem accurate?

i.e. it can't be fixed by just changing the templates.

Yeah. And I think that's it's important for OJDF, because I also want to display in the list of all orders how much each order has in outstanding payments.

I think that in all cases, promising to send a check should not mean that you are marked as paid. You should be marked as pending payment (though with your order complete).
It's super confusing for the organizers otherwise; when everyone pays by check, the event summary says that none of the payments are outstanding, rather than giving a useful overview of how much money has actually been received.

+1

As part of this, we should also distinguish between cash in hand and pending payments in the event summary data.

Partially resolved with merge of #303


sonoff sc

hi,,
will be great if we can add support to sonoff sc.
I will upload the debug file as soon as i'm able to run it.
thanks for your support on getting this done.

i got the below error running the debug.
pi@hassbian:/home/homeassistant/.homeassistant/custom_components/sonoff-debug $ sudo python sonoff-debug.py  --username<EMAIL_ADDRESS>--password  'anadeem232' > /home/pi/devices.json
Traceback (most recent call last):
File "sonoff-debug.py", line 2, in
import argparse, sys, json, time, random, pprint, base64, requests, hmac, hashlib, re
ImportError: No module named requests
would you plz help

Hi,
i got the below error while running the debug
pi@hassbian:/home/homeassistant/.homeassistant/custom_components/sonoff-debug $ sudo python sonoff-debug.py  --username 'xxxxxxxxx' --password  'xxxxxxx' > /home/pi/devices.json
Traceback (most recent call last):
File "sonoff-debug.py", line 2, in
import argparse, sys, json, time, random, pprint, base64, requests, hmac, hashlib, re
ImportError: No module named requests

@ashrafmn take a look at this comment (and the others around it) https://github.com/peterbuga/HASS-sonoff-ewelink/issues/35#issuecomment-452749386 it's the same problem

followed all the suggested steps, i also tried it from another mac pc, getting exactly the same error :(

On 6 Apr 2019, at 1:33 AM, Peter Buga<EMAIL_ADDRESS>wrote:
@ashrafmn https://github.com/ashrafmn take a look at this comment (and the others around it) #35 (comment) https://github.com/peterbuga/HASS-sonoff-ewelink/issues/35#issuecomment-452749386 it's the same problem
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/peterbuga/HASS-sonoff-ewelink/issues/74#issuecomment-480442895, or mute the thread https://github.com/notifications/unsubscribe-auth/AumPlSaTtjSO6RF5tmAQZepYAL7Mtq5Oks5vd89PgaJpZM4cFD8Z.

@ashrafmn i hope not to offence too much but i sort of got tired to explain this basic problem over and over so i took the time and added (i hope) a super basic way to provide me the information requested above.
i've redone a bit chunk of the component and now it's enough just to install the component and literally flip a switch, is this easy enough?
please update the component with the last files from master branch and read 10 times the new installation option + the debug section
i really don't know how i can make it more easier than this, if you still can't figure it out... just wait and maybe someone else with a similar device will be able to provide the output i need.

Regards,

yes and no-ish,
this is an important piece of information but because i've never got the the dump of a sonoff-sc i can only guess the overall structure and what information it's available.
by any chance could you please give it another try to run the sonoff-debug.py script?

hi @peterbuga
here u go another capture,, hope this will help
. --------------COPY-FROM-HERE--------------
2019-08-29 20:37:48.472 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:38:10.441 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 60, "light": 10, "noise": 5, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:38:15.505 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 60, "light": 10, "noise": 4, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:38:45.535 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 60, "light": 10, "noise": 5, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:38:55.748 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 60, "light": 10, "noise": 4, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:39:43.524 [W] {"action": "sysmsg", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "1000413b32", "params": {"online": true}, "ts": 0}
2019-08-29 20:39:43.863 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "1000413b32", "from": "device", "params": {"channel0": "211", "channel1": "211", "channel2": "0", "channel3": "0", "channel4": "0", "fwVersion": "2.6.0", "rssi": -75, "staMac": "xx:xx:xx:xx:xx:xx", "state": "off"}, "ts": 0, "userAgent": "device"}
2019-08-29 20:40:36.908 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "100067ae87", "from": "device", "params": {"rssi": -70}, "ts": 0, "userAgent": "device"}
2019-08-29 20:41:36.974 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "100067ae87", "from": "device", "params": {"rssi": -67}, "ts": 0, "userAgent": "device"}
2019-08-29 20:43:26.555 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 5, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:43:32.184 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:44:01.513 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 27}, "ts": 0, "userAgent": "device"}
2019-08-29 20:44:05.539 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:44:23.513 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 27}, "ts": 0, "userAgent": "device"}
2019-08-29 20:44:55.268 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 26}, "ts": 0, "userAgent": "device"}
2019-08-29 20:45:03.515 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 27}, "ts": 0, "userAgent": "device"}
2019-08-29 20:51:05.615 [W] {"action": "sysmsg", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "1000516faf", "params": {"online": false}, "ts": 0}
2019-08-29 20:51:12.813 [W] {"action": "sysmsg", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "1000516faf", "params": {"online": true}, "ts": 0}
2019-08-29 20:51:13.194 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "1000516faf", "from": "device", "params": {"channel0": "192", "channel1": "192", "channel2": "0", "channel3": "0", "channel4": "0", "fwVersion": "2.6.0", "rssi": -70, "staMac": "xx:xx:xx:xx:xx:xx", "state": "off"}, "ts": 0, "userAgent": "device"}
2019-08-29 20:51:35.900 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 28}, "ts": 0, "userAgent": "device"}
2019-08-29 20:51:45.507 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 27}, "ts": 0, "userAgent": "device"}
2019-08-29 20:52:05.985 [W] {"action": "update", "apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "deviceid": "10003b72dc", "from": "device", "params": {"dusty": 2, "humidity": 59, "light": 10, "noise": 4, "temperature": 28}, "ts": 0, "userAgent": "device"}
---------------END-OF-COPY----------------

sorry if i mislead you above :( actually i mean this script dump https://github.com/peterbuga/HASS-sonoff-ewelink/issues/74#issuecomment-480389665 or this https://github.com/peterbuga/HASS-sonoff-ewelink/tree/master/sonoff-debug
if you still can't get it to work, i'll probably include/dump it automatically as a starter for the dumps you've done above. just to be clear, the above info is really good and i'll try to work with it even if i don't have the complete picture

@peterbuga here u go,,
hope it will help,, I'm really excited to get this available in home assistant to use the temp as a trigger and to use the iOS notification if temp reaches a specific number
{
"__v": 0,
"_id": "[hidden]",
"apikey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"brandLogoUrl": "https://as-ota.coolkit.cc/logo/KRZ54OifuGmjoEMxT1YYM3Ybu2fj5K2C.png",
"brandName": "Sonoff",
"createdAt": "xxxx-xx-xxxxx:xx:xx.xxx",
"devConfig": {},
"devGroups": [],
"deviceStatus": "0",
"deviceUrl": "https://as-api.coolkit.cc:8080/api/detail/5a2e1b3a0cf772f92c342f02_en.html",
"deviceid": "[hidden]",
"devicekey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"extra": {
"_id": "[hidden]",
"extra": {
"apmac": "xx:xx:xx:xx:xx:xx",
"brandId": "58e5f344baeb368720e25469",
"description": "WWJG001294",
"mac": "xx:xx:xx:xx:xx:xx",
"manufacturer": "\u6df1\u5733\u677e\u8bfa\u6280\u672f\u6709\u9650\u516c\u53f8",
"model": "PSA-BTA-GL",
"modelInfo": "5a2e1b3a0cf772f92c342f02",
"staMac": "xx:xx:xx:xx:xx:xx",
"ui": "\u4f20\u611f\u5668\u4e2d\u5fc3",
"uiid": 18
}
},
"group": "",
"groups": [],
"ip": "[hidden]",
"location": "",
"name": "[hidden]",,
"offlineTime": "xxxx-xx-xxxxx:xx:xx.xxx",
"online": true,
"onlineTime": "xxxx-xx-xxxxx:xx:xx.xxx",
"params": {
"bindInfos": {
"gaction": [
"f4846e50-0071-4fe3-9437-41c26c8b147f_ewelink-google-home-v1"
]
},
"dusty": 2,
"fwVersion": "2.7.0",
"humidity": 57,
"light": 10,
"noise": 4,
"rssi": -24,
"sledOnline": "on",
"staMac": "xx:xx:xx:xx:xx:xx",
"temperature": 26
},
"productModel": "SC",
"settings": {
"alarmNotify": 1,
"opsHistory": 1,
"opsNotify": 0
},
"sharedBy": {
"nickname": "nickname",
"permit": 15,
"phoneNumber": "[hidden]",,
"shareTime":<PHONE_NUMBER>424
},
"showBrand": true,
"type": "10",
"uiid": 18
},

@ashrafmn thanks for the output 🙌!
and good news: now that i have all the information i need it turns out it's actually terrible easy to add it (just a few lines), i'll push it in a few days 👍

@peterbuga great news ,, and thanks a lot for your support and help on this.
will be looking forward once this is release.
please do let me know once its released.
Regards,
Ashraf

hi @peterbuga
any chance??

@ashrafmn give it a try https://github.com/peterbuga/HASS-sonoff-ewelink/commit/d5623863421ba383ab7abf8c4badcfd15698a717
ps: the values will update to a minimum value of 60sec (aka the value of scan_interval ). i sort of believe you might not need something faster than that (in next version version i might made them update instantly like the switches... that if it's not plagued by fw 3.3.0+ bug that's killing sensors on POW R2 devices, IMO better to not update it if it works ok now!)

@peterbuga the sonoff SC sensors are not yet discovered by the custom_componant
i still don't see the 5 sensors (light, temp, humid, noise and air quality)

@ashrafmn could you please give it another go 😊? @difelice pointed and pushed a fix for a small typo i've made that for sure was messing stuff up, most likely throwing some error too

@ashrafmn you should see something like this (i used your dump from above to inject the information like I would have the device in my eWeLink account, it should definitely work now)

Thanks @peterbuga
How do I get the updated code to try?
Is it in the master  or websocket branch?

@ashrafmn master
that if, hopefully you don't get hit by the bug it's going around these days with the latest version of HA (so you might wanna hold on a bit longer on upgrading it)

@peterbuga you are the king  :)
my sonoff sc sensors are available running HA 9.33 on hassbian pi
you may close issue #74


Implement MNAIO post hook for saving VM images

In order to be able to re-use MNAIO VM images for other
projects to reduce test times when using the MNAIO build
we implement a change to the MNAIO tooling to use a file
backing store for the VM's, the post hook to prepare them
for uploading, and the component_metadata.yml file to
upload them to Cloud Files using the standard RE hook for
uploading file artifacts.
Issue: RE-1561

Testing this PR with the MNAIO tooling in https://rpc.jenkins.cit.rackspace.net/job/PM_rpc-openstack-master-xenial_mnaio_no_artifacts-swift-deploy-odyssey4me/1/

Looks like it passed.  Can you explain the image lifecycle?  it sounds like the gate creates the image, is it just replaced the next time gate passes and a new image is created?

Well, it actually failed - but given it's in the 'post' stage it will not cause a fail for the test. The fix is on the way to merging now: https://review.openstack.org/593652
Once that's in I'll re-test.
The image will get uploaded, then on the next success for the same combination of ${RPC_RELEASE}-${RE_JOB_IMAGE}-${RE_JOB_SCENARIO} it will overwrite. So once a release is done, the initial macro will change and the images will be available indefinitely.
This is not yet confirmed to all be in a working state yet, but I'd like to get the images start to get built and uploaded so that I can use them to test with for the (follow on card)[https://rpc-openstack.atlassian.net/browse/RE-1615] which is to make them useful to other tests.

Initial test failed due to issue in MNAIO tooling. Retesting with https://rpc.jenkins.cit.rackspace.net/job/PM_rpc-openstack-master-xenial_mnaio_no_artifacts-swift-deploy-odyssey4me/5/

So are the storage reqs just going to grow indefinitely?

@prometheanfire Yes. They're in Cloud Files, we can auto-expire them if we like - but feedback from QE has been that having a catalog of MNAIO images dating back as far as possible would be very useful for all kinds of tests or bug validation.

recheck_issue_link

Testing now with updates to rpc-gating and the MNAIO tooling: https://rpc.jenkins.cit.rackspace.net/job/PM_rpc-openstack-master-xenial_mnaio_no_artifacts-swift-deploy/292/


User Actions Feature

Give the possibility for:

The library users to define some actions the users can do
The UI users to click on buttons that show on top of elements (nodes, links, ...) in order to trigger those actions

Examples of must-have actions:

Delete the selected element
Start dragging a new portless link
Show the boundary of the selected element

Example in draw.io:

May I recommend that you adopt the command pattern (GoF).  Command pattern - Wikipedia
Take for example the current DeleteSelectionBehavior
The behavior listens to the key down event for the associated key press, and the code to the action the delete is in the behavior’s keydown event
Now let’s say I want to add a menu option in my client UI to delete selected nodes.  There is no way I can reuse the behavior’s Diagram_KeyDown event.  It is private and takes a KeyboardEventArgs.
So, by separating the invokers (in this case the behavior) and creating another class for the command (the action of deletion), you would have something more flexible.
The DeleteSelectionBehavior accepts a command class in the constructor and if matches the delete key, calls the command’s execute method.
So, in my UI, I can now also call the delete command's execute method.  In some future date, if you change the command to delete something else that derives from SelectableModel – I don’t need to make any changes in my code.
Now you could go a step further.  The changed DeleteSelectionBehavior now just connects the keystroke and the command.  It can renamed as keystrokeBehavior that accepts a keystroke and ideally an interface for a command, or perhaps, it refences a dictionary of keys/command interfaces for all the keystrokes.  Keystrokes no longer need to be set in various options – it is part of the creating and registering the behaviors.
Now as a user, I can write my own commands and bind it to a keystroke using the supplied keystrokeBehavior class.
(As an aside, I would also let users supply the code to register behaviors – rather than have a set registered and the user unregister the ones they don’t like and register new ones. Less messy.)
Now, for example, a user could create their own DeleteCommand, derived from yours, and display a “do you want to delete” dialog, and still reference your underlying delete command.
A command interface, let’s call it ICommand, can also have other properties such as enable and an enabled changed action.
The Maui ICommand is defined thus:
public interface ICommand
{
public void Execute (Object parameter);
public bool CanExecute (Object parameter);
public event EventHandler CanExecuteChanged;
}
See https://docs.microsoft.com/en-us/dotnet/maui/fundamentals/data-binding/commanding#icommands
(Just to clear, I am not suggesting you reference  System.Windows.Input – just have a similar interface.)
This will be useful for the selection behaviour– when models are selected/deselected, a list of ICommands have their CanExecuteChanged events raised and the UI reacts accordingly.  Thus if no models are selected, all the UI elements that require selected models are disabled.

Hello!
I appreciate your opinion, thank you for taking the time to write that.
The command pattern does feel a little bit weird in the frontend, especially for UI actions that can be as complex as API calls and anything the library users want to do really. I don't want to use that pattern for this specific feature because it's not really needed, all actions are button clicks so a delegate or something will work just fine.
What I do like however, is your generic shortcut behavior with the commands pattern. Something like this would be great to handle all shortcut use cases.

The more I think about it, the more it does make sense to have commands as actions...


Table view freezes with certain GIFS with needsPrescaling set to false

Check List
Thanks for considering to open an issue. Before you submit your issue, please confirm these boxes are checked.

[x] I have read the wiki page and cheat sheet, but there is no information I need.
[x] I have searched in existing issues, but did not find a same one.
[x] I want to reoprt a problem instead of asking a question. It'd better to use kingfisher tag in Stack Overflow to ask a question.

Issue Description
AnimatedImageView with certain gifs takes a leap on main thread. Tableview scroll freezes.
What
[Tell us about the issue]
Reproduce
https://s-media-cache-ak0.pinimg.com/originals/4e/50/06/4e500657d2273140e77b0bb807bc342c.gif
Set this gif in AnimatedImageView - 40x40 circular frame.
needsPrescaling = false
If I set needsPrescaling = true . Tableview works fine. But Gif appears scaled.
[The steps to reproduce this issue. What is the url you were trying to load, where did you put your code, etc.]
Other Comment
[Add anything else here]

Hey, @Ankish
Thanks for open it. It seems you are trying to decode a big gif. Decoding and rendering a gif (which contains multiple frames) itself is a performance consuming operation, especially the large gifs. In AnimatedImageView, the frames are decoded frame by frame when needed. Your huge gif (2287 × 2287) takes too much time to decode and render. needsPrescaling will scale your image to the size to the image view, as long as keeping its scaleFactor for screen.
I suggest you to keep the needsPrescaling to be true to keep acceptable performance. Or you could resize and provide the gif file in a reasonable size.


design: JSON access logs

Updates https://github.com/heptio/contour/issues/624
Signed-off-by: Abi X Renhart<EMAIL_ADDRESS>

Thank you. It’s the weekend in Australia. I’ll respond on Monday.

On 11 May 2019, at 08:10, Abi X Renhart<EMAIL_ADDRESS>wrote:
Updates #624
Signed-off-by: Abi X Renhart<EMAIL_ADDRESS>You can view, comment on, or merge this pull request online at:
https://github.com/heptio/contour/pull/1080
Commit Summary
Updates https://github.com/heptio/contour/issues/624
File Changes
A design/json-access-logs-design.md (74)
Patch Links:
https://github.com/heptio/contour/pull/1080.patch
https://github.com/heptio/contour/pull/1080.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Thank you for taking the time to write this up. We’re still debating it internally, I’ll commit to replying in full by the end of the week.

I'm sorry I was not able to make the friday deadline. I'm sorry but I will not be able to give you and ETA til later in the week.

While not an active Contour user (we went back to Nginx ingress for weak/unimportant reasons),
I feel I can wade in after too many years sorting out logging at medium sized companies.

I don't think it should be the default - stick with what you have now.

I'm afraid there is no standard JSON format, and you would indeed "MUST" make it fully flexible.  I would suggest making minimal-ideally-zero difference between the Envoy "Format Dictionary" config and how you surface it in Contour.  Lean on the Envoy designers to handle backwards compatibility or new changes, don't burden your CRE team/future-maintainers with translation.  Just include perhaps this design’s suggestion as a documented config example and link to the Envoy docs.

I guestimate 90% of users (certainly all my historical use-cases) would be happy with cluster/ingress-controller level config.  If you know of heavy multi-tenant Contour users then it may have to go down to ingress level – but I’m sure that could be left to a v2 of this feature.  Note that if done in a v2, different JSON formats cope with the “munged into /dev/stdout” issue just fine by design.

I would also add that my personal vote would be for flexible JSON, not diverting time to adding CLF.

@youngnick has put together this proposal, #1485 which is our prefered design.


Carousel cards right icon to scroll right not appearing

Bot Info

Bot handle: ctlibot
App ID: fbd62590-7a79-466d-8c3b-9a6e14784190
SDK Platform: .NET
SDK Version: 3.9
Active Channels: Web Chat
Deployment Environment: Azure Bot Service

Issue Description
I started using Carousel Cards feature in my code to display multiple Hero cards. In local when i run the code in emulator everything seems to be working fine. Specifically, I am able to see both left and right arrow icons to help scroll through the cards properly. But when i deployed the code to Azure Bot Service and tested in web chat channel, I am unable to see the right arrow icon at all. However left arrow icon appears once i scroll to right using middle mouse button.
I think emulator might be using older UI code since i downloaded it a while ago whereas webchannel is using latest code so maybe some code changes introduced this bug.
Code Example
Using any Carousel code should produce the same issue since the issue is in UI and not in logic.
Reproduction Steps

Testing Carousel cards locally in emulator gives required result.
Deploying same code in Azure.
Testing in web channel is now not giving right arrow icon in Carousel Cards.

Expected Behavior
Both left and right arrow icons should appear in Carousel Cards. (ScreenShot from emulator. Same expected in Web Channel)

Actual Results
Only left arrow icon is appearing to help scroll left side horizontally. Right arrow icon is missing to help scroll right side horizontally. (ScreenShot from web channel. Working as expected in local emulator as in previous screenshot)

Closing this issue as it's a duplicate of WebChat issue 567: [WebChat Carousel] doesn't display right scroll button. Please follow the issue there.


Implement cairo context matrix

Added matrix.go for cairo_matrix_t binding. Implemented missing context translation methods in translations.go
Some of this was taken from github.com/ungerik/go-cairo, but fleshed out a lot more than what is there and cleaned up. Most of it is also implemented in my own fork of go-cairo at github.com/bit101/go-cairo since ungerik's is not in active development in 2 years.

One issue I found:
native() lowercase must return the real C type of the object.
Native() uppercase must return a pointer as uintptr.
Native that returns a C object is useless in another package, we're forced to recast it to the same C type to use it. (otherwise build error is like _struct_mypackage_CtypeX is not _struct_gotk3_gtk_CtypeX)
note: I made a similar mistake in one of my last commits, WrapRGBA needs to receive a uintptr instead of unsafe.Pointer.
Native and WrapXX are working together.

OK, good to know. I'll address that.

Updated so it has native and Native. Hopefully I did that right.


[BUG] Nightly upgrade test sometimes failed: Node not ready after upgrade

Describe the bug
test_upgrde  Node is not ready, couldn't attach volume
To Reproduce

Install Longhorn v0.7.0
Run upgrade test test_upgrade

Expected behavior
Upgrade test should pass and for nightly test it should continue to run integration tests after upgrade.


[Feature] Implement NER and POS tasks

We want to implement support for two new tasks: Named Entity Recognition (NER) and Part of Speech tagging (POS). While best performant models are encoder-only, these are standardized tasks with reference, original corpora in many languages that can be used as baseline comparison for decoder-only models as well. This feature is meant to be used to evaluate models within the "Ibero-LLM: Optimal Data Distribution, Training and Instruction" RES project, which considers at least 6L (EN/ES/CA/GL/EU/PT) and the subsequent "Towards Linguistic Diversity: Optimizing Data Distribution for Multilingual NLP Inclusivity" EuroHPC project, which goes up to 36L.
Feature Details

Named Entity Recognition (NER) task:
Dataset: WikiAnn/PAN-X (282L), BIO format
Evaluation metrics: F1 score, precision, recall for each entity type (e.g., PERSON, LOCATION, ORGANIZATION).

Part of Speech Tagging (POS) task:
Dataset: Universal Dependencies treebanks (UD)
Evaluation metrics: Accuracy, optionally F1 per tag for more granular insights.

Proposed Implementation Plan

[ ] Convert datasets to required format.
[ ] Integrate task loaders for NER and POS datasets.
[ ] Add task-specific configuration files under the tasks module.
[ ] Use unit tests to validate task's scoring metrics.

[ ]  Unit testing for both tasks.
[ ]  Documentation updated.

Hi @jsaizant, what is the status on this? I am unsure why would we want to evaluate on these types of tasks, as they are widely considered to be solved tasks.

I'm closing this ticket for now due to lack of activity. @jsaizant Feel free to reopen it if you decide in the future to implement these tasks.


Feature Request: resize stacked windows with padding for title bar

Something like this would be really useful to know when you're working with a stack:

Sounds reasonable. Could add a config option "cascade_window_stack".
Should the focused window be moved to the front of the stack when this option is enabled? That way the titlebar of all other windows in the stack will always stay visible. If not, only windows "further up the stack" will be visible as the active window changes.

Yea that makes sense to me. Thanks!

Stackline—which I used to identify Yabai stacks—seems to be no longer in development and it gives lots of errors on Hammerspoon, so I hope something like this is implemented within Yabai itself 🤞

The way this appears to work on sway and i3 is the titlebar is drawn seperately.
Since all applications on linux with i3 or sway are forced to use server-side-decorations for things like the titlebar, it is drawn with an efficient and simple bar, to identify if it is stacked or tiled.
I really like the idea here, and I wonder if it's possible in macOS.
But, if you think about how yabai stacks windows, it literally stacks them. In sway/i3, windows will never really be stacked. Just the "titlebar" while the windows which are not shown, contents will not even be drawn.
In yabai, the best way to probably do so is figure out how to spawn a titlebar arbitrarily, and allow the titlebar to have a min hight contents of 0, so there will be no window with the bar - Then renaming this titlebar with the name of the application.
i3/sway do not show application icon. So this should be easier.
with yabai, this means we could spawn alias titlebars maybe as a subprocess under the yabai application process, which would allow us to stack them like shown in stacked mode with i3/sway, or even tile them width wise for a potential new "tabbed" mode in yabai. This would be a lot easier if the titlebar was not the original application titlebar. Meaning, it would work for all applications, not just ones with a configurable titlebar such as alacritty.
tiled vs stacked vs tabbed i3/sway example

On macOS the application itself is responsible for drawing window decorations, not the window servers. This is a tehnical difference between Linux and macOS.

I know that there is large difference there in macOS.
and I am aware of the many limitations in macOS.
I don’t even know if spawning alias titlebara would work. But I think it would be easier visually if using a mouse.
i really like the implementation idea @diocletiann came up with.
i guess what my concern is, using the window titles of the application in apps other than alacritty, which do not use this classic titlebar height, or even no titlebar.

I thought about emulating the i3 tab bar in SketchyBar but lost steam. An cascaded view like this doesn't waste much space and would be big improvement imo. @koekeishiya I'm not sure you'd even need to swap the window locations, it actually may be more disorienting if the window you're about to focus suddenly shifts.

The main motivation here is to have some sort of visual indicator of how many windows are in a given stack, and which entry is currently focused right?

Would something like this be too intrusive? (color and opacity can be customized at user level).

<img width="901" alt="stack2" src="https://github.com/koekeishiya/yabai/a

ssets/6175959/8b2e5e00-626a-441f-bc0

8-7bde2a5bf854">

I think there are too many applications that utilize this space to render helpful information. What do you think about rendering the indicator in the gap above the window, if a gap is configured, or at least allowing a vertical offset to be configured to achieve this effect?

Adding a top gap for a stack and using that space for indicators sounds promising.

I thought about having a top margin for this behavior. So the node has frame 10, 10, 500, 500. With a top margin of say 40, the actual frame applied to the window would be 10, 50, 500, 460. The indicator would then be rendered inside that margin.
At first it seems like it would cause a lot of dead space, but maybe that isn't all that important and it will be fine.
I'm also not sure if it is better at the top, or at the side (left? right? towards the edge of the screen, but how does that work when it is enclosed by another window from all sides?) etc.

Honestly, I think the way that Stackline was doing it was perfect. It even had this "minimal" mode that was not obtrusive at all.

So the "issue" I have when briefly looking at stackline screenshots is that it doesn't showcase a wide variety of situations. How does it look and operate under more complex layouts; what if the user does not have any padding or gaps enabled, and the layout is as follows:
Node A and E are single windows.
Node B, C, and D have multiple windows (stacks).
+-----------------+
|     |  B  |     |
|     | (s) |     |
|     |-----|     |
|  A  |  C  |  E  |
|     | (s) |     |
|     |-----|     |
|     |  D  |     |
|     | (s) |     |
+-----------------+

It looks good in the provided screenshots, but I need to extrapolate that to always look good enough, and not just look good in specific scenarios.

If people are interested in some brainstorming, please do some simple "programmer art" images/ascii art showing how you imagine it would work in a way that you are satisfied with / wastes the least amount of space. It is more helpful if you try to include a wide variety of scenario in your design, such as optionally configured padding or gap.
What I'm interested in at this point is a design that could work well. The implementation specifics for how to achieve that solution doesn't really matter yet.

Well, for example, I would love to have ability to customize with 1:1 look-alike with swaywm/i3wm defaults.
Maybe it could be an option between:
bars
dots
dots-inline
dots-left
native
in which the native option would render an alias title-bar which could just add a window titlebar above, renamed to the same important info in regular windows, and the bars option would clone the sway/i3 titlebars, and the dots inline would be in the titlebar, the dots left would be left, dots would be above etc

Something like this would be really useful to know when you're working with a stack:

I’m still feeling this approach.. feels closest to macOS. Might even be possible to implement ourselves, using the yabai layer feature to reorder a window’s layer.
but, I think this is still the best way.

Has something like this been implemented? Couldn't find it in the wiki.

So the "issue" I have when briefly looking at stackline screenshots is that it doesn't showcase a wide variety of situations. How does it look and operate under more complex layouts; what if the user does not have any padding or gaps enabled, and the layout is as follows:
Node A and E are single windows. Node B, C, and D have multiple windows (stacks).
+-----------------+
|     |  B  |     |
|     | (s) |     |
|     |-----|     |
|  A  |  C  |  E  |
|     | (s) |     |
|     |-----|     |
|     |  D  |     |
|     | (s) |     |
+-----------------+

It looks good in the provided screenshots, but I need to extrapolate that to always look good enough, and not just look good in specific scenarios.

@koekeishiya I was just playing with stackline and was going to ask for a setting to add a separate border setting for stacks because currently for me stackline isn't really working.. here is a screengrab based on your ascii art:

After setting a windowgap of 50 it's better but I don't want that much gap all the time:

And the stackline no-icon setting with window_gap set to 15, which I can live with:

here is how stackline is managing dual stacks, which I don't like, I believe the indicators should always be in the same position on the stack.

There's an approach that Aerospace takes, which is to add a top/bottom or left/right padding to the active window in the stack, so that other windows in the stack a visible. It would be cool if we could have a similar option in Yabai, maybe even with darkening of background windows, if possible.
Aerospace has some screenshots in the docs, if was not sure if I could post them here :) So here's the link:
https://nikitabobko.github.io/AeroSpace/guide#layouts
For now, I'm also sticking with Stackline, but I'm a little worried that it's not supported anymore

There's an approach that Aerospace takes, which is to add a top/bottom or left/right padding to the active window in the stack, so that other windows in the stack a visible. It would be cool if we could have a similar option in Yabai, maybe even with darkening of background windows, if possible.
Aerospace has some screenshots in the docs, if was not sure if I could post them here :) So here's the link: https://nikitabobko.github.io/AeroSpace/guide#layouts
For now, I'm also sticking with Stackline, but I'm a little worried that it's not supported anymore

I have to say I prefer the Stackline pills method over what Aerospace is doing there, only thing I'd change about stackline is having the pills always be on the left of the stack

I too prefer Stackline, but it’s weird with multiple stacks
Dmytro Suvorov
On Fri, Nov 29, 2024 at 02:17 Brian Gilbert @.***>
wrote:

There's an approach that Aerospace takes, which is to add a top/bottom or
left/right padding to the active window in the stack, so that other windows
in the stack a visible. It would be cool if we could have a similar option
in Yabai, maybe even with darkening of background windows, if possible.
Aerospace has some screenshots in the docs, if was not sure if I could
post them here :) So here's the link:
https://nikitabobko.github.io/AeroSpace/guide#layouts
For now, I'm also sticking with Stackline, but I'm a little worried that
it's not supported anymore
I have to say I prefer the Stackline pills method over what Aerospace is
doing there, only thing I'd change about stackline is having the pills
always be on the left of the stack
—
Reply to this email directly, view it on GitHub
https://github.com/koekeishiya/yabai/issues/2045#issuecomment-2506874733,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHSJU3GX4HYNYD3YFSPOJD2C6XAPAVCNFSM6AAAAABBQT5INCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBWHA3TINZTGM
.
You are receiving this because you commented.Message ID:
@.***>

I also really like the implementation by Stackline. Unfortunately I had to stop using it because it relies on Hammerspoon which in my system was having constant crashes/taking lots of memory. Something similar implemented within Yabai itself would me amazing.

There's an approach that Aerospace takes, which is to add a top/bottom or left/right padding to the active window in the stack, so that other windows in the stack a visible. It would be cool if we could have a similar option in Yabai, maybe even with darkening of background windows, if possible.
Aerospace has some screenshots in the docs, if was not sure if I could post them here :) So here's the link: https://nikitabobko.github.io/AeroSpace/guide#layouts
For now, I'm also sticking with Stackline, but I'm a little worried that it's not supported anymore

I created this issue after trying Aerospace, I think it would work well in Yabai. Could never get used to stackline and it was buggy in my experience.


Toslchan/add giotto data

The one failing test is a separate issue, and it's been fixed on master: /home/travis/.cache/Cypress/3.2.0/Cypress/Cypress: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory


x/tools/gopls: add documentation for eglot

What version of Go are you using (go version)?
1.14.2
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
Linux amd64
What did you do?
Look up Emacs integration documentation
What did you expect to see?
At least a mention of the "eglot" package.
What did you see instead?
Only the "lsp-mode" package.
Eglot works nicely with gopls.
To the best of my knowledge, lsp-mode will never be integrated more tightly with Emacs, while eglot is on track for that.
Please consider mentioning eglot in https://github.com/golang/tools/blob/master/gopls/doc/emacs.md.
With go-mode, eglot, and gopls properly installed, all it takes is
(add-hook 'go-mode-hook #'eglot-ensure)

I can supply a config snippet to auto-format code (as in the lsp-mode config example) if it helps.

That doc is community maintained, so please open a PR adding an eglot section. Thanks!

The docs now contain info about eglot so I think this can be closed.

That's great, I (obviously) did not get to it...  Thanks a lot!


Backup existence indicator for snapshots not shown until manual refresh.

Rancher Server - Build from master
Steps to reproduce the problem:
Create a VM with ROOT and DATA on longhorn driver.
Create few snapshots (3) for the volume.
Take backup for one of the snaphshots (2nd snaphot).
Backup existence indicator for snapshots not shown until manual refresh.

Tested with UI version - v1.1.5
Backup existence indicator for snapshots is shown as soon as it gets created (without having to do manual refresh)


Improvement: better pretty printing for nested structures

The library makes a good attempt at pretty printing which works well for structures having only 2 levels of nesting. But for more deeply nested structure the current pretty printing algorithm is lacking.
Consider the following deeply nested structure:
[grid]
  colors = {fg = {r = 0.01568627543747425, g = 0.0117647061124444, b = 0.007843137718737125, a = 1.0}, bg = {r = 0.03921568766236305, g = 0.0470588244497776, b = 0.1607843190431595, a = 0.0}}
  grid = 3
  x = 42.42
  flag = true

This isn't easy to read or manually modify. I think the default pretty printing behaviour should be as shown below:
[grid]
  colors = {
    fg = {
      r = 0.01568627543747425,
      g = 0.0117647061124444,
      b = 0.007843137718737125,
      a = 1.0
    },
    bg = {
      r = 0.03921568766236305,
      g = 0.0470588244497776,
      b = 0.1607843190431595,
      a = 0.0
    }
  }
  grid = 3
  x = 42.42
  flag = true

We could get then a bit fancy and say specify a max line length as an encoding parameter, and then leaf-level objects would still be condensed into a single line if that would not exceed the max line length.
I think this is an important issue because one of the major selling points of TOML is readability/easy modifyability by humans.

Happy to give the implementation of this a go if you guys think it's a good idea.

We also happy to to have such improvements, and it would be nice to have a new test specific to this new feature if possible.

new line break in inline table is not officially supported by the spec. The reader/decoder also put it behind TomlInlineTableNewline flag when parsing.
The writer should do the same thing. Adding new line should be activated only when the user ask it through the flag and he has compatible parser to read new line in inline table.


fix: liq-1056-digits-visualization-in-multiple-views

:books:   LIQ-1056  :books:

PR closed in favour of new one against the current release candidate


A download server for linux packages for AdoptOpenJDK

We've been using an Artifactory instance sponsored by JFrog for roughly half a year to host Linux packages of AdoptOpenJDK. There's work underway to host our flavour of JMC there, too. I'd like to reconsider whether we're on the right track here:

What are our needs?
Do we favour a managed solution like Artifactory?

Is Artifactory the right solution, after all?

Do we favour to host it oursevles?

There are various reason I'd like to reconsider our choice of Artifactory:

We're dependant on the external provider, in this case JFrog.
We don't have full control over the URL (it's https://adoptopenjdk.jfrog.io/). As a consequence, migrating to a different service (if we ever have to do it) is going to be a pain and take a long time.
The automatic generation of Debian package indices is broken (upstream issue) rendering our automation inoperative. The ETA for a fix is in the next two quarters (according to JFrog).
The support for Eclipse update sites (JMC) isn't great.
We might want to host things that don't fit into Artifactory at all, like packages for Alpine Linux.

My objective is to collect a list of requirements first so that we can check the various options out before coming up with an actionable proposal.

From the perspective of the Linux packages:

We've amassed approx. 20 GB of Debian/Ubuntu packages and 180 GB of RPMs since May 2019 (6 months). I expect that we need around 500 GB of storage per year for releases alone. In the first months, we didn't build all OpenJ9 variants. We have 5 TBs of nightly builds.
I'm leaning towards using upstream tooling to host the package feeds, i.e reprepro and createrepo. This means I'd need a server that has a complete local copy of all the packages so that the package indexes and metadata can be generated and signed with our GPG key (increased security required).

Sounds excellent. Having the JMC update sites on a download server would be great. Something along the lines of:
https:///jmc/updatesites/latest/ide/
https:///jmc/updatesites/latest/rcp/
https:///jmc/updatesites/7.0.0/ide/
https:///jmc/updatesites/7.0.0/rcp/
https:///jmc/updatesites/7.1.0/ide/
https:///jmc/updatesites/7.1.0/rcp/

Note that once we have published the update sites, we should re-spin and re-publish the application builds, including 7.0.0 and 7.1.0, with correct overrides for the URLs. Then it will finally be possible to install the optional plug-ins. :)

Rough idea using AWS terminology:

The Jenkins nodes push build artifacts to an upload server using restricted SFTP. The upload server keeps a local copy of all files. It is responsible for generating package indices and signing files. This cannot be done on Jenkins nodes because reprepro needs all packages on a local disk to generate the package indices. The upload server syncs its local copy of all files with a S3 bucket. From there, our users download the files via Cloudfront.
The AdoptOpenJDK GPG key needs to be stored on the upload server. Therefore, it has to be locked down.
Questions:

Does that look okay to you?
Although I used AWS terminology, what would be our preferred provider?
Does SFTP work for everyone?

As soon as we have a proposal everybody is happy with, I'll do a test setup so that we can verify that it actually works as expected.

Sound fine reasonable to me, but I'm not directly involved in these part. Patrick (@reinhapa), what do you think?

I have no specific opinion about this, but I will need some help getting the update sites to be working later down the process though...

@aahlenst - when do you think the test setup will be available?

Requirements we have:

Support for deb, rpm, apk (Alpine), Eclipse P2
500 GB of releases per year
2 TB of nightly builds per year
20 TB of bandwidth per month via CDN
Custom domain via SSL (e.g., packages.adoptopenjdk.net)

The storage and bandwidth requirements are estimates. It's very hard to get that info out of Artifactory.
I did some further research on options:

Self-hosting with OSS (createrepo and friends) is rather expensive because of storage and bandwidth requirements. We need a full local view of the entire package trees to generate and sign indexes. So we need some TBs of block storage. Just to fulfill the requirements for one year, we'd need to spend around 3200$ for the machine at AWS (t3a.medium with 3 TB of EBS, no backup). Bandwidth via Cloud Front is another 20000$ per year (seems a bit high?). We might be able to reduce the spending on bandwidth with Cloudflare, Fastly, ... Backup and people to operate that would come on top. I looked at Hetzner, too, where we host Jenkins. They would be significantly cheaper, but they do not really have good backup facilities for that amount of data. Another drawback of self-hosting: No API.
Self-hosting with Sonatype Nexus Pro: Would be cheaper because Nexus Pro can use S3 (and only S3, no Azure Blob Storage or something like that) and S3 is significantly cheaper than EBS. Nexus OSS does not support S3. Drawbacks: We'd still have to operate everything ourselves and Sonatype did not seem that interested to work with us.
Using GitHub, Azure Artifacts, AWS CodeArtifact, GCP ArtifactRegistry: Do not support the formats we need.
PackageCloud.io: They do not support P2, APK, but still interesting.
CloudSmith: They do not support P2, but are willing to add it.

Hey folks / @aahlenst; Lee from @cloudsmith-io here. We're happy to help if we can. We're firm believers in data portability and reducing vendor lock-in, which is why we offer things like the custom domains support. If P2 is critical, we can see about prioritising it for you.

I'm going to close this since we're currently remaining with JFrog with Fastly fronting it, although that is giving intermittent HTTP/403 responses for some users as per https://github.com/adoptium/adoptium-support/issues/923


Group by Schema action icon changes size when toggled

Doesn't look very polished like this, the icon itself should stay the same size with only the x being added/removed.

@aasimkhan30 @erinstellato-ms FYI

verified in latest rc1 build.


Ticket/master/6352 facter should not be hard coded

As mentioned in ticket #6352, Facter is hard-coded as a dependency in Puppet in a ton of places, including both the code but also especially the tests.
This series of patches largely fixes that, although not entirely.  The only place I couldn't push the Facter usage was in defaults.rb - that still has to be hard-coded (given the current implementation) for load order reasons.
Everything else goes through a new, simple interface added to Puppet::Node::Facts.  This interface also knows how to load facts when asked, which is good on its own.
The only questionable part of this series in my opinion is the last patch - it caches the fact values in the Facts class, because repeated access caused full Fact loads.  I think this is the best approach, but alternatives exist.

There seem to be a couple of unresolved issues (extending the ABI in a non-standard way, caching) that need to be resolved before this can be merged. Have you guys worked out what needs to be done?

I have been trying to get direction from the dev team on how best to do those two things.  I agree that those are the two remaining issues to resolve, and the current code is my recommendation.  I'm happy to implement other choices, but I need some direction on what would be acceptable.

Further discussion of this is going to start up in the ticket, in just a few minutes.  Sadly, I must have missed the previous request to discuss this further.  Sorry about the long delays here.

I have updated the ticket, finally, with discussion about this.  Lets figure out the value of this, and get it in.


gulp failed to load external module babel

hi everyone i'm always get this
`RoliesDonalds-MacBook-Pro:berita roliesdonald$ gulp
[15:32:41] Failed to load external module babel-core/register
[15:32:41] Failed to load external module babel/register
/Users/roliesdonald/Documents/job/newsweb/berita/gulpfile.babel.js:25
import fs from 'fs';
^^^^^^
SyntaxError: Unexpected reserved word
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:413:25)
at Object.Module._extensions..js (module.js:448:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Liftoff.handleArguments (/Users/roliesdonald/.nvm/versions/io.js/v3.3.1/lib/node_modules/gulp/bin/gulp.js:116:3)
at Liftoff. (/Users/roliesdonald/.nvm/versions/io.js/v3.3.1/lib/node_modules/gulp/node_modules/liftoff/index.js:198:16)
at module.exports (/Users/roliesdonald/.nvm/versions/io.js/v3.3.1/lib/node_modules/gulp/node_modules/liftoff/node_modules/flagged-respawn/index.js:17:3)`
my gulp version is
[RoliesDonalds-MacBook-Pro:berita roliesdonald$ gulp -v [15:40:05] Failed to load external module babel-core/register [15:40:05] Failed to load external module babel/register [15:40:05] CLI version 3.9.0 [15:40:05] Local version 3.9.0
anybody can help me please....

@donrolies I assume you're building from the current state of mdl-1.x? There's several possible causes for your issue, so I'd recommend:

git pull, to make sure you have the latest changes, including all the recent fixes.
Double-checking you have the latest package.json, which includes the correct Babel configuration for the latest Babel releases.
Running npm i to make sure you have the latest version of every package installed.

Looking at your output, it also looks like you're running io.js. That's a pretty old runtime, so I'd recommend upgrading to a stable (v7.x) or LTS (v6.9.x) version of node.js.
I've run a clean build from scratch to confirm everything is right in mdl-1.x, and it looks that way, so I'm closing this issue.

hi @sgomes this is my
https://github.com/RoliesDonald/mdl-sass
stil had problem
RoliesDonalds-MacBook-Pro:mdl-sass roliesdonald$ gulp [13:19:39] Requiring external module babel-register [13:19:40] Using gulpfile ~/Documents/localgithub/mdl-sass/gulpfile.babel.js [13:19:40] Starting 'clean'... [13:19:40] Finished 'clean' after 14 ms [13:19:40] Starting 'default'... [13:19:40] Starting 'styles'... [13:19:40] Starting 'styles-grid'... [13:19:41] styles-grid all files 18.82 kB [13:19:41] Finished 'styles-grid' after 995 ms [13:19:43] styles all files 812.97 kB [13:19:43] Finished 'styles' after 3.07 s [13:19:43] Starting 'lint'... [13:19:44] 'lint' errored after 740 ms [13:19:44] TypeError: Cannot convert undefined or null to object     at Function.keys (<anonymous>)     at copyConfiguration (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/config/configuration.js:920:12)     at NodeConfiguration.Configuration._processConfig (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/config/configuration.js:459:5)     at NodeConfiguration.Configuration.load (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/config/configuration.js:211:10)     at Checker.configure (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/string-checker.js:62:29)     at Checker.configure (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/checker.js:27:39)     at Object.module.exports (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/gulp-jscs/index.js:35:10)     at Gulp.<anonymous> (/Users/roliesdonald/Documents/localgithub/mdl-sass/gulpfile.babel.js:107:13)     at module.exports (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/orchestrator/lib/runTask.js:34:7)     at Gulp.Orchestrator._runTask (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/orchestrator/index.js:273:3) [13:19:44] 'default' errored after 3.83 s [13:19:44] TypeError in plugin 'run-sequence(lint)' Message:     Cannot convert undefined or null to object Stack: TypeError: Cannot convert undefined or null to object     at Function.keys (<anonymous>)     at copyConfiguration (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/config/configuration.js:920:12)     at NodeConfiguration.Configuration._processConfig (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/config/configuration.js:459:5)     at NodeConfiguration.Configuration.load (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/config/configuration.js:211:10)     at Checker.configure (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/string-checker.js:62:29)     at Checker.configure (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/jscs/lib/checker.js:27:39)     at Object.module.exports (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/gulp-jscs/index.js:35:10)     at Gulp.<anonymous> (/Users/roliesdonald/Documents/localgithub/mdl-sass/gulpfile.babel.js:107:13)     at module.exports (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/orchestrator/lib/runTask.js:34:7)     at Gulp.Orchestrator._runTask (/Users/roliesdonald/Documents/localgithub/mdl-sass/node_modules/orchestrator/index.js:273:3)


Parens hugging for Functor?

include
  Impl(
    {
      type nonrec t = taaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
    }
  );

Ideally:
include Impl({
  type nonrec t = taaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
});

I believe related: https://github.com/alexfedoseev/re-formality/blob/master/examples/SignupForm.re#L25-L30


Error handling for Objects that fail because they're too big

Started seeing this error yesterday on https://maurice-renck.de/de/blog/2023/podcaster-plugin-3 (parsed mf2), which includes a big inlined data: img. Datastore raised  google.api_core.exceptions.InvalidArgument: 400 entity is too big, which we don't yet handle, so we 500ed.
Datastore max property value size and entity size are both 1MB. OK. Total parsed mf2 size is only 200KB though, and the converted as1 computed property is similarly ~200KB. So why does the datastore think we're over 1MB?
...arguably it doesn't matter, we should just handle this exception and return HTTP 400.

#1501 is probably the most common cause of this, doing that should help.


Running workflow on Graphite branches

Current dependencies on/for this PR:

master

PR #81   👈

This comment was auto-generated by Graphite.

Graphite Merge Job
Current status: 🔄 Waiting for checks to pass
This pull request is currently waiting for CI and mergeability checks to pass before being merged.
This comment was auto-generated by Graphite.

Job Reference: RGnphUs1ewEbeV56UCBG


Improve map.recalculate_bounds! speed

By @javisantana :
# select _postgis_stats('my_table', 'the_geom')::json->'extent';
                      ?column?
-----------------------------------------------------
 {"min":[-5.52764,41.0878],"max":[-3.97387,42.3147]}

but this only works if the stats are updated (after a vacuum) but I think we use that function only after we create a map

If flow hasn't changed, we always do a VACUUM after importing, so would be valid.

confirmed, after either a copy from existing table or registering a new one, a table.optimize is performed, which does internally a run("VACUUM FULL #{qualified_table_name}"), so can be used

Ok, it seems not always works, at least with small datasets.
At a test, with a just created table with 5 rows:
VACUUM FULL public.untitled_table_1;
SELECT _postgis_stats ('public.untitled_table_1', 'the_geom')
ERROR:  stats for "untitled_table_1.the_geom" do not exist

So I'll implement a fallback for when there are no stats because data is small or "yet" stats aren't calculated.

After some tests, it is indeed much faster, but also less accurate. Table with 62k rows, complex geoms, etcetera:
SELECT _postgis_stats ('public.aaa', 'the_geom')::json->'extent';
-- -141.442
-- 43.8096
-- -52.4573
-- 76.6626

SELECT
        ST_XMin(ST_Extent(the_geom)) AS minx,
        ST_YMin(ST_Extent(the_geom)) AS miny,
        ST_XMax(ST_Extent(the_geom)) AS maxx,
        ST_YMax(ST_Extent(the_geom)) AS maxy
      FROM public.aaa;
-- minx -141.002672003315
-- miny  -13.455676000376
-- maxx   30.8416667003606
-- maxy   79.8750000004749

@javisantana If you're ok, we can go for it. It always fallbacks to real row calculation in case of errors so shouldn't be dangerous.

go with it


Flattening not succedeed after implementing eigen equivalent of cholmod routines

Hi, there's some issue with my wrappers and I'd like to know if I've implemented corretly the Eigen equivalent of some of the cholmod routines, the documentation doesn't say much.
For example you've implemented:
inline cholmod_sparse* add(cholmod_sparse *A, cholmod_sparse *B, double alpha[2], double beta[2])
{
    // C = alpha*A + beta*B
    return cholmod_l_add(A, B, alpha, beta, 1, 1, common);
}

My eigen equivalent, which actually I'm not sure anymore, is:

inline SpMat* add(SpMat *A, SpMat *B, double alpha[2], double beta[2])
{
    // C = alpha*A + beta*B
    SpMat & refA = *A;
    SpMat & refB = *B;

    return new SpMat(alpha[0]*refA + beta[0]*refB);
}

Where SpMat is defined as:
using SpMat = Eigen::SparseMatrix<double>;

Is my conversion correct? There're similar function throught in SparseMatrix.inl I guess the interpretation of the inputs must be the same.
But I've not clear why you have alpha,beta as vectors with two entries.
What I'm currently getting is something like:

While originally is supposed to generate:

By the way, the client app I'm using is:
#include <Bff.h>
#include <MeshIO.h>
#include <iostream>

int main(int argc, char** argv) {

	if(argc != 3) {
		std::cout << "Usage : UnitTestDewrinkling <input-filename>.obj <output-filename>.obj" << std::endl;
		return 1;
	}

	std::string input_filename = argv[1];
	std::string output_filename = argv[2];

	Mesh test_mesh;

	std::cout << "Loading mesh from " << input_filename << "..." << std::endl;

	if(!test_mesh.read(input_filename))
		std::cout << "Reading problems!" << std::endl;

	std::cout << "Initializing flattening module..." << std::endl;

	BFF flattening_module(test_mesh);
	EigenDenseMatrix boundaryData(flattening_module.data->bN);

	std::cout << "Flattening (generating uv)" << std::endl;

	flattening_module.flatten(boundaryData,true);

	std::cout << "Flattening done, now storing into " << output_filename << "..." << std::endl;

	test_mesh.write(output_filename,false,false);

	std::cout << "Output stored!" << std::endl;

	return 0;

}

Maybe there's some other setting I'm before starting the flattening. For example I noticed you have something like:
        // flatten
        if (type == BoundaryType::automatic) {
            removeVertexHandles();
            DenseMatrix u(bff->data->bN);
            bff->flatten(u, true);
            performPCA();
            update();

        }

In your Viewer.cpp, are the removeVertexHandles and PerformPCA used somehow?

And one more question... I'm not 100% sure, but why is the image of the checkboard like shifted (from your original tool)?

You can probably just get rid of the alpha and beta (this is cholmod specific) and return "refA + refB". It seems like your client app is alright, there is no need to call/implement "removeVertexHandles" and "performPCA" - these are called for visualization purposes.

There was an issue with my initialization function in my Dense/Sparse classes now I'm getting the following outputs (normalized and not normalized)

The second picture is closer to what your tool originally provides,

I've accidentally closed the issue... sorry...

You'll have to translate, rotate and/or scale either the texture image or the uvs to get them to align the way you want them to. The "Show UV Tex Param" option in Meshlab lets you see the current alignment.

So despite not being aligned, you would say the parameterization is still correct.

Its difficult for me to say, I'd print out the uvs from the BFF tool and your implementation and see the error between them to check if your implementation is correct.

I was more referring, in general. The UV look different to me, so there might still be something to sorted out.

You can probably just get rid of the alpha and beta (this is cholmod specific) and return "refA + refB". It seems like your client app is alright, there is no need to call/implement "removeVertexHandles" and "performPCA" - these are called for visualization purposes.

I don't think I can get rid of the two constants, since you use them in your overload of the operator -

Right, but you can just get rid of the "add" function and directly return "A + B" and "A - B" in the appropriate operators.

Fair point.

In my experience, Cholmod is a more stable solver than Eigen. Eigen has wrappers around multiple external solvers such as Cholmod (see here: http://eigen.tuxfamily.org/dox/group__TopicSparseSystems.html), it might be worth giving them a try to see if the results improve (and to make sure the problem is solver related).


Fix ConstantManager.set to accept array of serializable

LGTM But you need to check why unit tests are failing

LGTM But you need to check why unit tests are failing

They are failing because the fix on Args (as) is needed.


Use the Ghc monad to emit warnings

Previously Haddock warnings were emitted directly to stdout via
putStrLn.  This commit changes the output to go via the Ghc monad
as a new type of Haddock warning.  To take advantage of using Ghc in
this way, source locations are now tracked and emitted as part of most
warning messages.
This is an attempt to address #927.
The corresponding GHC commits are here and here.

Sorry for the delay.  I think I've addressed all the requested changes.  In testing the changes, I realised that the out-of-scope and ambiguous identifier warnings changed from
Warning: 'mapAccumR' is out of scope.
    If you qualify the identifier, haddock can try to link it anyway.

to
<no location info>: warning:
    'mapAccumR' is out of scope.
    If you qualify the identifier, haddock can try to link it anyway.

If I were a user, I'd be annoyed to receive the latter ("thanks for pointing out that neither of us knows where this problem is, Haddock"), so I added the last commit in the series, which plumbs through module location info.  Now the messages look like:
libraries/containers/Data/IntMap/Internal.hs:1:1: warning:
    'mapAccumR' is out of scope.
    If you qualify the identifier, haddock can try to link it anyway.
  |
1 | {-# LANGUAGE CPP #-}
  | ^

Unfortunately, as you can see, this always grabs the source span at the beginning of the file in question, which usually has nothing to do with the link destinations.  What do you think?

I've made my patch against the ghc-head branch, but it looks like the tests are failing due to lack of a field introduced to GHC a few weeks ago.  Is it possible the test suite is testing against 8.6 or an outdated HEAD branch of the compiler?

I've made my patch against the ghc-head branch, but it looks like the tests are failing due to lack of a field introduced to GHC a few weeks ago. Is it possible the test suite is testing against 8.6 or an outdated HEAD branch of the compiler?

Don't worry about CI on ghc-head; it hardly ever works. I'll test locally when I review (which should be in the next couple of days - I did notice that you addressed my comments, I've just not found time to give the final thorough review it deserves).

This looks great!
I'm not going to merge just yet because I'd like to wait for the next GHC release cycle in order to dogfood on HEAD for a while (the new 8.8 release just got cut). I'm a bit concerned that we might end up breaking the workflows of people who are using -Werror. That is especially a problem if we don't have a specific flag with which to disable just Haddock warnings or if there are some warnings in Haddock which cannot be avoided (I think there might be some nasty edge cases... for instance missing links to methods which are mentioned in MINIMAL pragmas but are otherwise not exported).

Thanks for the review and thanks again for your guidance while working on this feature.  Is there anything else you need from me now or in the future to ensure that this goes in smoothly?
I assume once Opt_WarnMalformedHaddock makes it into DynFlags.hs, it's possible to disable only Haddock warnings or prevent only Haddock warnings from being errors?

I don’t think so. It might be necessary to rebase at some point (depending on how long it takes me to finish the motivating patch for Opt_WarnMalformedHaddock). I’ll ping you if so.
Yes, once Opt_WarnMalformedHaddock makes it into DynFlags, it’ll be possible to disable Haddock warnings, or prevent just Haddock warnings from being errors. I think it should even be possible to do this on a module-by-module basis with OPTIONS_GHC.
Thanks again for all your hard work!

On Nov 20, 2018, at 2:41 AM, Matt Peddie<EMAIL_ADDRESS>wrote:
Thanks for the review and thanks again for your guidance while working on this feature. Is there anything else you need from me now or in the future to ensure that this goes in smoothly?
I assume once Opt_WarnMalformedHaddock makes it into DynFlags.hs, it's possible to disable only Haddock warnings or prevent only Haddock warnings from being errors?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/haskell/haddock/pull/969#issuecomment-440226966, or mute the thread https://github.com/notifications/unsubscribe-auth/AKRHAf3a21bXHodqACQePruZkp-zCIKtks5uw9xVgaJpZM4YbCs3.

Hello.
Any news about this?
I'm regularly rebasing these changes on top of my current GHC and that's a painful process. What can I do to help getting this merged?

Ping ? Any movement on haddock's logging would be great. Perhaps this would also fix the -w/--no-warnings flag, which I think haddock currently ignores ?

We are actually very close to this! There is a GHC patch that will introduce a Haddock related warning flag to GHC's flags, and it is close to being merged: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377.
@guibou I apologize for the delay here - the blocker was that without a flag under which to register these warnings, it won't be possible to turn them on or off directly. This would be very annoying in the presence of -Werror. Also, don't worry about rebasing changes - I can help with that part. Thanks again for putting this together.

@harpocrates what is the status of this pull request.
At work, I'm rebasing this on each GHC release. I'm starting to think about another approach (using a post processing of the haddock cli output) to detect error and I'm wondering where my motivation will be best used.
So what is missing for that PR to be merged? Are you interested by a rebase on top of haddock master? If not, are we closing this PR as "won't fix"?

@peddie Does this PR affect non-GHC consumers? If no, could you please re-open it targeting the ghc-9.0 branch so that all may benefit from it?

@Kleidukos I think this PR could affect anything that's used to the current format of Haddock errors -- is that what you're asking?
I made this patch over 2 years ago, and unfortunately I do not currently have the time to continue working on it.  It's difficult for me to prioritize tasks that have already been "accepted" and then left untouched by the maintainers for 2 years and several GHC releases.  I hope someone with more time and/or the ability to directly merge the patch when it's ready can find the time to update it and land it so that all may benefit, as you say.

@Kleidukos I think this PR could affect anything that's used to the current format of Haddock errors -- is that what you're asking?

Yes. The ghc-head branch is reserved for the GHC-specific patches, like glue code. Patches to the documentation generator should go toward the current GHC release branch, which is currently ghc-9.0.

I made this patch over 2 years ago, and unfortunately I do not currently have the time to continue working on it.  It's difficult for me to prioritize tasks that have already been "accepted" and then left untouched by the maintainers for 2 years and several GHC releases.  I hope someone with more time and/or the ability to directly merge the patch when it's ready can find the time to update it and land it so that all may benefit, as you say.

That's understandable. Thanks for your contribution, I am certain it will live under one shape or another in the codebase one day.
Have a nice day!