EURITO's elasticsearch pipeline

Firstly write dev pipelines for:

[x] arXiv
[x] Crunchbase
[x] Patstat

Then:

[ ] Homogenise schemas
[ ] Homogenise entities (countries, maybe others?)
[ ] Process production pipeline

@mindrones thanks for the feedback. Assume that I'm implementing your suggestions where I don't make comments below:

not sure how to interpret terms_fieldOfStudy*_article: eventually can these be merged?

the fields of study are hierarchical, but it's a graph rather than a tree which is difficult to represent in a flat structure, and would be computationally expensive to rebuild in the UI. The 3 options (in order of complexity and experimentalness) for this are:

Completely flatten up to a maximum of n levels (which what I have done up to n=5), thereby losing all structure.
Providing a full JSON representation of the graph like [{'name':Physics'}, {'name':'Statistical Mechanics', 'parent':'Physics'}, {'name':'Statistical Mechanics', 'parent':'Maths'}], down to n levels. This will give a large response, and will require the graph to be built in the UI.
Providing a neo4j interface to link to each article. This will probably require more iteration time than I am able to give.

Do you have a preference or alternative to either of the first two suggestions?

In general, for all arrays term_*, since they can potentially repeat a lot in the response, slowing down the application, it would be ideal to refer to them as id and have endpoints where we can fetch arrays containing them only once.

I'm not 100% convinced (but I'm open to criticism) - since you can exclude large fields from the response, and then re-request specific fields for given documents. The elasticsearch response time per document by id (e.g. POST to _search with body { "query": { "terms": { "_id": [ "math/0612012" ] } } }) is less than 20ms, which is tiny, and would be quicker than doing a lookup every time to a separate API for the lookup (almost by definition) and requires no client-side processing. Alternatively you could read in the entire lookup table, but in the case of fields of study this would yield nearly 1 GB into memory client-side.
On top of this, it would complicate things on my side in terms of providing extra documentation and data_getter interfaces for the data scientists, which could push me beyond my November time limit.

Re: terms_fieldOfStudy*_article
We agreed in Slack to use a single prop terms_fieldsOfStudy_article containing an array of arrays, like
[
['Physics', 'Statistical Mechanics'],
['Maths', 'Statistical Mechanics'],
...
]

each sub-array representing a branch from the root down, the index being the depth.
Re: lookups
We're not going to implement it.


Support building a debuggable image for development

Describe what this PR does and why we need it:
Change to help with the development process from a contributor point of view. Allows building of a remotely debuggable image so a debugger can be attached when needed.
Feel free to close this if it is seen to have no value but I found it useful when working on recent issues so thought I would share.
On a side note the docs to run a local broker did not work for me on OSx on either minishift or oc cluster up but perhaps I'm missing something (broker started but errors out).

AWESOME! Thanks for the contribution.

@PhilipGough can you add some docs around this?

@rthallisey Yep, will do just wanted to see if it was valid first

@jmrodri I've made some changes here which fix the issues discussed. If you are happy with these changes I would like to move the debug work into the the make build-image target and debugging would be enabled in a single image by updating an env var

I feel this is ready to merge, but I'm not going to offer any support if it breaks.

@eriknelson

I feel this is ready to merge, but I'm not going to offer any support if it breaks.

I'd like to get @jmrodri approval on this one because I want to put this stuff into the local image and reduce the overall maintenance. Debugging will be switched on with a simple env var setting at that point. If not we can merge as is.

@rthallisey Sure, I'll land docs with this as soon as its finalised
@djzager > Is there a reason you can't go get it?
The reason I have taken this approach is because it is faster. A go get would need to be called on each image build otherwise, slowing down the development cycle.

@PhilipGough wouldn't the go get really only the first time make debug-image was called and just be there on subsequent calls?

@djzager Hey, not sure I'm totally following. I have baked the delve binary into the image here and am copying from the container to local disk via a docker run command. If the docker run command does a go get instead on a centos image that has go installed, I think that will run each time and don't see anything being cached? Maybe I am missing something or misunderstanding.
The only alternative I see is to maintain an additional Dockerfile on this repo and have a build done from that which would then be cached but I don't like that approach as much. I have done a go get to build this image referenced in the make file.
I see the approach I've taken as a workaround essentially for those that cannot do multi stage Docker builds.

Hey, not sure I'm totally following. I have baked the delve binary into the image here and am copying from the container to local disk via a docker run command. If the docker run command does a go get instead on a centos image that has go installed, I think that will run each time and don't see anything being cached? Maybe I am missing something or misunderstanding.

Here is how I changed the Dockerfile-canary:
--- a/build/Dockerfile-canary
+++ b/build/Dockerfile-canary
@@ -41,6 +41,7 @@ RUN mkdir -p ${BROKER_PATH}
 RUN git clone -b $VERSION https://github.com/openshift/ansible-service-broker ${BROKER_PATH}
 WORKDIR ${BROKER_PATH}

+RUN go get -u github.com/derekparker/delve/cmd/dlv
 RUN go build -i -ldflags="-s -w" ./cmd/broker && mv broker /usr/bin/asbd
 RUN go build -i -ldflags="-s -w" ./cmd/migration && mv migration /usr/bin/migration

On the second run of docker build -t broker:canary -f build/Dockerfile-canary build:
Step 18/26 : RUN go get -u github.com/derekparker/delve/cmd/dlv
 ---> Using cache
 ---> a25234b25eca

@djzager Ah ok, so we were talking about different things :) I intended to merge this work into the local dev image only which does not have golang env available, so the command in the make file makes sense in that respect.
But yeah, if you guys are happy to get this stuff into the canary image also then I'll make the required changes there tomorrow, update the docs and hopefully wrap this up at that point :)

But yeah, if you guys are happy to get this stuff into the canary image also then I'll make the required changes there tomorrow, update the docs and hopefully wrap this up at that point :)

I would like to get this wrapped up too. Sorry to be slowing it down.

Coverage remained the same at 33.435% when pulling 3083e18a6b1e5bc2ce383b4afbd9efb87fc3887b on PhilipGough:debug-image into 9f6d8bef169630c64fbe33a3eedfe2345be956c9 on openshift:master.


winpr: Updates time zones and fixes bias values

Updates time zone information database in libwinpr/timezone/timezone.c to Microsoft's December 2015 update. This was critical as many of my client stations incorrectly jumped forward to US Daylight Savings Time a week early.
Corrects casing in the scripts/TimeZones.cs generator script to fix build errors when compiling libwinpr/timezone/timezone.c .
Changes Bias values from unsigned to signed integer to properly capture negative bias values. Bias should be the number of minutes to add to local time to get to UTC. Bias has the opposite sign value of glibc's tm_gmtoff and .NET's BaseUtcOffset. For example, America/New_York should have a Bias of 300 and Asia/Katmandu should have a bias of -345. The results can be verified by issuing "w32tm /tz" at a command prompt inside the RDP connection.
In cases where the time zone cannot be looked up in the database, the client attempts to compute the proper Bias value from tm_gmtoff so that the client's local time appears inside the RDP connection. Since this is not strict GMT, the client time zone is labeled "Client Local Time" to avoid confusion.

If accepted, this patch addresses issue #3198

@rjcorrig Could you rebase your pull to master to get rid of the many merges?

Yes, sorry. I'm new at this :-)

Better?

@rjcorrig Much better. @bmiklautz What do you think about this?

@freerdp-bot test

@rjcorrig If you spend winpr_detect_windows_time_zone() a void  argument a +1 from me ;)

Done!

and merged!

Thanks! I'll keep an eye out for future time zone updates from Microsoft and submit patches as needed. Glad to help!

@rjcorrig nice one thanks!


[BUG] streaming video using UDP, on the Raspberry Pi (server).

log on the VLC:
$ vlc udp://@:34235 :demux=h264
...
[h264 @ 0x13c9b3800] error while decoding MB 32 6, bytestream -6
[h264 @ 0x13c930e00] error while decoding MB 37 7, bytestream -6
[h264 @ 0x13caa5a00] error while decoding MB 13 7, bytestream -5
[h264 @ 0x13cb42400] error while decoding MB 16 6, bytestream -6
[h264 @ 0x13cabc400] error while decoding MB 17 7, bytestream -6
[h264 @ 0x13caf9800] error while decoding MB 15 7, bytestream -6
[h264 @ 0x13c9b3800] error while decoding MB 0 15, bytestream -6
[h264 @ 0x13c930e00] error while decoding MB 24 6, bytestream -6
[h264 @ 0x13caa5a00] error while decoding MB 20 6, bytestream -6
...

log on raspberry Pi zero 2 W:
$ libcamera-vid -t 0 --inline -o udp://<IP_ADDRESS>:34235 --codec h264
Made DRM preview window
[1:30:40.037162380] [5410]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3866-0c55e522
[1:30:40.107153165] [5411]  INFO RPI raspberrypi.cpp:1374 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media3 and ISP device /dev/media0
[1:30:40.109056654] [5410]  INFO Camera camera.cpp:1035 configuring streams: (0) 640x480-YUV420
[1:30:40.109819049] [5411]  INFO RPI raspberrypi.cpp:761 Sensor: /base/soc/i2c0mux/i2c@1/ov5647@36 - Selected sensor format: 640x480-SGBRG10_1X10 - Selected unicam format: 640x480-pGAA

Thanks!
Run the ffplay or VLC client in another terminal on the server. This eliminates the network and uses the loopback interface.

This is the best quality one. But there is a 1~2 second delay on VLC or ffplay compare to the libcamera-vid original view. Cloud you kindly explain more?

There will always be a small delay due to ffplay buffering the stream.  You can minimise this buffering by using the following command line options with ffplay:
ffplay tcp://<ip-addr-of-server>:<port> -fflags nobuffer -flags low_delay -framedrop

There will always be a small delay due to ffplay buffering the stream. You can minimise this buffering by using the following command line options with ffplay:
ffplay tcp://<ip-addr-of-server>:<port> -fflags nobuffer -flags low_delay -framedrop

yes, it is the minimal latency playback.


Add fields to user card team showcase

Needs https://github.com/keybase/keybase/pull/1967 first

Already getting this done on the serverside, will make a PR shortly. thanks!


fix: improve error message service creation

Purpose

Fixing error message propagation for service instances
Adds a generic handling that can be enhanced when future requirements arise
New test case added to have REST response from service manager
Closes #821

Does this introduce a breaking change?

[ ] Yes
[X] No

Pull Request Type
What kind of change does this Pull Request introduce?

[X] Bugfix
[ ] Feature
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Test the code via automated test

go test ./...

What to Check
Verify that the following are valid:

Automated tests are executed successfully

Other Information
n/a
Checklist for reviewer

The following organizational tasks must be completed before merging this PR:

[X] The PR is assigned to the Terraform project and a status is set (typically "in review").
[X] The PR has the matching labels assigned to it.
[X] The PR has a milestone assigned to it.
[X] If the PR closes an issue, the issue is referenced.
[X] Possible follow-up items are created and linked.

Successful execution of regression test on local build of provider

Fixture drift is okay as new test case was recorded and existing have been re-recorded to ensure recorded request structure

Looks Good


adjusting social media margin and adding some animation in bio phrase

Looks good however there seems to be some merge conflicts becuase I merge some stuff before this. if you have time to fix it I'll happily merge :)

Awesome 👍


Online playground

When using trpc-nuxt I've always wanted a way to quickly start a project with it and using my t3 clone but with nuxt we can finally do that!

I do use the playground for my local testing 🤔

So is an online playground not something you'd be interested in? I do believe you can clone a codesandbox project and if all else fails you can use my cli but I kinda don't like those solutions, any proposals?


MACHINE_FEATURES_append = " rtc" won't sync the sys clock to hwclock

I'm not sure if this functionality should be included or not in meta-raspberry.
To my understanding, setting MACHINE_FEATURES_append = " rtc" should add the full capability to the board, including setting the system time from the RTC device. At the moment, this is not possible without adding a dedicated init script / systemd unit to initialize the system time from the time stored in the RTC device before trying the NTP synchronization.
Would it be wise to add such initialization logic in order to set the system time from the RTC device?

@nucatus  see here  https://github.com/agherzan/meta-raspberrypi/issues/913.  maybe  help you:
after reading /etc/init.d/hwclock.sh , I add IMAGE_INSTALL_append = "tzdata" in local.conf and ln -s /usr/share/zoneinfo/America/Toronto /etc/localtime
I make it works well.

@nucatus if you check the bitbake environment, does rtc end up in MACHINE_FEATURES?

@agherzan,
$ bitbake -e my-image | grep MACHINE_FEATURES
# $ANY_OF_MACHINE_FEATURES
#     [doc] "When a recipe inherits the features_check class, at least one item in this variable must be included in MACHINE_FEATURES."
#     [doc] "A set of features common between MACHINE_FEATURES and DISTRO_FEATURES."
#     "${@oe.utils.set_intersect('DISTRO_FEATURES', 'MACHINE_FEATURES', d)}"
#     [vardeps] "DISTRO_FEATURES MACHINE_FEATURES"
#   "${@oe.utils.set_intersect('DISTRO_FEATURES', 'MACHINE_FEATURES', d)}"
# $CONFLICT_MACHINE_FEATURES
#     [doc] "When a recipe inherits the features_check class, no item in this variable can be included in MACHINE_FEATURES."
# $MACHINE_FEATURES [5 operations]
MACHINE_FEATURES=" apm usbhost keyboard vfat ext2 screen touchscreen alsa bluetooth wifi sdio vc4graphics rtc qemu-usermode"
# $MACHINE_FEATURES_BACKFILL [2 operations]
#     [doc] "Features to be added to MACHINE_FEATURES if not also present in MACHINE_FEATURES_BACKFILL_CONSIDERED. This variable is set in the meta/conf/bitbake.conf file and is not intended to be user-configurable."
MACHINE_FEATURES_BACKFILL="rtc qemu-usermode"
# $MACHINE_FEATURES_BACKFILL_CONSIDERED [2 operations]
#     [doc] "Features from MACHINE_FEATURES_BACKFILL that should not be backfilled (i.e. added to MACHINE_FEATURES) during the build."
MACHINE_FEATURES_BACKFILL_CONSIDERED="rtc"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
#   "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
#   "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
#   "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "userland", d)}"
#     "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
#   "${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa", "mesa-gl", d)}"
# $REQUIRED_MACHINE_FEATURES
#     [doc] "When a recipe inherits the features_check class, all items in this variable must be included in MACHINE_FEATURES."
#     "     xserver-xorg     ${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "xserver-xorg-extension-glx", "", d)}     ${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "xf86-video-modesetting", "xf86-video-fbdev", d)}     "
#     [depends] "     parted-native:do_populate_sysroot     mtools-native:do_populate_sysroot     dosfstools-native:do_populate_sysroot     virtual/kernel:do_deploy     ${IMAGE_BOOTLOADER}:do_deploy     rpi-config:do_deploy     ${@bb.utils.contains('MACHINE_FEATURES', 'armstub', 'armstubs:do_deploy', '' ,d)}     ${@bb.utils.contains('RPI_USE_U_BOOT', '1', 'u-boot:do_deploy', '',d)}     ${@bb.utils.contains('RPI_USE_U_BOOT', '1', 'u-boot-default-script:do_deploy', '',d)}     ${RPI_SDIMG_EXTRA_DEPENDS} "
    oe.utils.features_backfill("MACHINE_FEATURES", d)

Going through the logs, I see that the rtc feature is present in the MACHINE_FEATURES_BACKFILL variable, as well as into the MACHINE_FEATURES_BACKFILL_CONSIDERED variable. According to the documentation, when the feature is present in both of these, the feature is actually removed from the MACHINE_FEATURES. Please correct me if I'm wrong.

Here is the outcome of my research on the subject.
The rtc feature was added at a later time in the standard distribution and for back compatibility reasons the feature was not added to the MACHINE_FEATURES variable, but to the MACHINE_FEATURES_BACKFILL variable. The explanation behind it is in the documentation.
Now, for developers, to deactivate a feature that is added in the MACHINE_FEATURES_BACKFILL you have to add this feature to the MACHINE_FEATURES_BACKFILL_CONSIDERED variable. (If you're the person who chose the name of this variable, plase stay away!).
The raspberrypi machine removes the feature by adding "rtc" to the the MACHINE_FEATURES_BACKFILL_CONSIDERED variable.
However, if your board features a RTC device, you can still add the rtc feature by undoing the setting in the raspberrypi machine.conf. In your local.conf or other global conf file, add MACHINE_FEATURES_BACKFILL_CONSIDERED_remove = "rtc".
For this to properly work, you also need to compile the kernel with the RTC driver included and other protocol drivers that are required by the device. In my case, where I used the pcf8563 device, I compiled the kernel with these settings:
CONFIG_I2C_CHARDEV=y
CONFIG_RTC_DRV_PCF8563=y

# Automatically set the system clock from hwclock
CONFIG_RTC_HCTOSYS=y

Of course, you need to enable the overlay device tree accordingly.

That is correct @nucatus. Can you remind me what takes into consideration this machine configuration? Wasn't there also an equivalent distro feature? I'm wondering if we should just drop this assumption in meta-raspberrypi. Sure, the boards don't have an RTC but there are a good set of RPI-based boards with onboard RTC modules and as you said, you can always attach one.
PS I'm not the one naming that variable :) and it's not ideal. But as you know, figuring out names is the hardest part of any implementation.

@agherzan, strictly speacking, I guess the decision to deactivate the rtc module in case of meta-raspberrypi is wise, taking into account the standard board. However, I don't have the knowledge of how reinstating the feature will affect the standard build on a board where the device is absent.
In case of a board featuring an rtc device, as I mentioned in the previous post, there's not much you have to do in order to get the feature working, besides reinstating the feature by removing it from MACHINE_FEATURE_BACKFILL_CONSIDERED.
Regarding the naming, my intention was not to point at you, rather to an imaginary person who happens to be both, the person to name it, and somebody reading this post. It's a safty valve to disipate unneeded frustration :)

@nucatus So basically, everything that this MACHINE_FEATURES actually does is to pull in VIRTUAL-RUNTIME_base-utils-hwclock - which by default is from busybox. Obviously, this configuration can't know the kernel configuration, module, etc associated with it so it assumes that it is done separately. The annoyance is that if I start to enable this, everyone will start deploying a runtime service for hwclock. So I reckon the way forward now is to just add it in your own image. I don't see another easy way out of this. @kraj, what do you think?

you can do something like
KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 'features/rtc/rtc.scc', '', d)}"

in a kernel bbappend. You might have to create rtc.scc if it does not exist.

@kraj The issue here fundamentally is that we disable a feature by default for all machines (rtc) even though there could be rtc device attached to basically any of these boards.

@kraj The issue here fundamentally is that we disable a feature by default for all machines (rtc) even though there could be rtc device attached to basically any of these boards.

That deserves to be a new machine IMO unless we want to make it runtime dynamic, which could be quite complex.

@kraj That is hard to justify as a new configuration only for a peripheral attached. It would easily blow in configurations. I would say that for now a custom image/layer with the right kernel configuration + the right hwclock provider should be the way.

@kraj That is hard to justify as a new configuration only for a peripheral attached. It would easily blow in configurations. I would say that for now a custom image/layer with the right kernel configuration + the right hwclock provider should be the way.

rtc is a MACHINE_FEATURE, so if you tend to ignore that then you will end up with sub-optimal solution.

@kraj there are issues with that. You saw in the past how creating machines based on existing ones is showing side effects. Practically you are proposing for downstream to create a duplicated machine only for a machine feature?

if we have a smarter way to make the service ineffective during runtime perhaps thats fine but it will be a complex solution.

Ok, @nucatus. I think I will take back my initial idea of removing the RTC machine feature "considered". This is because it would either have an impact on the majority of the layer's users or need way more work to make this runtime-based implementation (with minimum runtime impact). And currently, there are at least a couple of avenues that can be pursued. Having a custom machine would be the cleanest - we have some machines that are based on existing ones so you could take inspiration from that. Another option would be to go down the image/configuration route (I mentioned this before).
Given that there are workarounds/solutions I'd say we can for now close this issue. What do you think?

@agherzan, yes, this totally makes sense. The only recommendation I would add is to somehow improve the documentaiton to make this obvious for people going into the matter.
Yes, the issue can be closed. Thanks.

@nucatus Makes sense. Check this one out for a short review: https://github.com/agherzan/meta-raspberrypi/pull/1035


Added test for changing position of a record and insert a new one in front of it in one step

The added should work, but it currently fails. This is why I have marked it as "incomplete".
The unit test shows that there is a bug. I couldn't find a solution, yet, but I think adding the test should be done anyway.
The problem is that during processing of the updates, the maximum position is 1, so that the position of $item3 is set to 1. Later, when the relocations are applied, the position of $item3 is not changed to 2 again, because it is already marked as changed.

thanks, hope someday we will solve this


Critical: White Screen Error

With latest code version when I start I get the login screen - I enter the password and then the url says http://localhost:3000/home while I just see a white screen.
The error console says Too many re-renders - see:

Network communication shows:

It seems this error is related to the wallet being "locked" after login.


Interference between m-dash and single quote

Test case:
And I ask you: "What's the idea behind this - how do you call it - 'one size fits all' approach?"
Expected:
And I ask you: “What’s the idea behind this—how do you call it—‘one size fits all’ approach?”
Actual:
And I ask you: “What’s the idea behind this—how do you call it—’one size fits all’ approach?”
Note the ‘ just before "one size".

Thanks @filiph for catching and reporting that one! I'll look into fixing it with the next update.

Fixed in version 2.3.2


Cannot find module 'glob' in Node 4

Failing job in Node 4: https://travis-ci.org/automutate/automutate/jobs/202870830
Passing jobs in 5-7: https://travis-ci.org/automutate/automutate/builds/202870826
Is there a minimum Node version supported by node-glob?

Is there a minimum Node version supported by node-glob?

Yes, but it's 0.10 :)
If I had to guess, what's happening is that some module is requiring glob, but isn't listing it as a dependency or peer dependency.  But, since some other module in your tree requires glob, it "works by accident" in npm version 3 and above, because of tree-flattening.
Run npm i glob -S in your project and see if that fixes it.

Cool, thanks for the fast response! It's a dev-dependency and I must have forgotten to -D. 😄


Intermittent 404 on v2.2.8

Hi guys...
Do you want to request a feature or report a bug?
Bug
What did you do?
i'm trying to passthrough a https tls connection through the keycloak container via TCP.
I'm doing because i want to use client authentication via x509 certificates and i didn't get it up and running via the https router.
What did you expect to see?
i stable working connection
What did you see instead?
I see a "part time" working connection. The first requests works fine but after some request i get a 404 in the browser.
Curl is working fine.
It's the same issue like https://github.com/containous/traefik/issues/7020
The only difference is that i'm using the tcp router.
Output of traefik version: (What version of Traefik are you using?)
/ # traefik version
Version:      2.2.8
Codename:     chevrotin
Go version:   go1.14.6
Built:        2020-07-28T15:46:03Z
OS/Arch:      linux/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
traefik.yml
log:
  level: DEBUG

serversTransport:
  insecureSkipVerify: true

#accessLog: {}

api:
  dashboard: true

providers:
  docker:
    swarmMode: true
    exposedByDefault: false
    swarmModeRefreshSeconds: 30
    network: web
  file:
    directory: /dynamic/
    watch: true

entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

docker-compose.yml
version: '3.8'

services:
  keycloak:
    image: jboss/keycloak
    ports:
      - target: 8443
        published: 8443
        protocol: tcp
        mode: ingress
    volumes:
      - ./https:/etc/x509/https
      - ./tls:/etc/x509/tls
    environment:
      - KEYCLOAK_LOGLEVEL=DEBUG
    deploy:
      replicas: 1
      placement:
        constraints:
          - "node.hostname==host"
      labels:
        - "traefik.enable=true"
        - "traefik.tcp.routers.tcp_keycloak.entrypoints=websecure"
        - "traefik.tcp.routers.tcp_keycloak.tls.passthrough=true"
        - "traefik.tcp.routers.tcp_keycloak.rule=HostSNI(`auth.mydomain.de`)"
        - "traefik.tcp.services.tcp_keycloak.loadbalancer.server.port=8443"
    networks:
      - web
    command: ["-b", "<IP_ADDRESS>", "-Dkeycloak.profile.feature.docker=enabled", "-Dkeycloak.profile.feature.upload_scripts=enabled"]

If applicable, please paste the log output in DEBUG level (--log.level=DEBUG switch)
sometime i find some rare error debug messages
rocket_traefik.1.oxpixxbainkn@srvedv128    | time="2020-08-03T07:10:12Z" level=debug msg="Error while setting deadline: set tcp <IP_ADDRESS>:43522: use of closed network connection"
rocket_traefik.1.oxpixxbainkn@srvedv128    | time="2020-08-03T07:10:37Z" level=debug msg="Error while setting deadline: set tcp <IP_ADDRESS>:43784: use of closed network connection"
rocket_traefik.1.oxpixxbainkn@srvedv128    | time="2020-08-03T07:11:40Z" level=debug msg="Error while setting deadline: set tcp <IP_ADDRESS>:44280: use of closed network connection"

Hey @beranPro
Can you check if the issue disappears when;

You use curl
You use Firefox
Use Browser with http/1

We're experiencing the same issue when using Traefik 2.9.9.
When using curl and a browser with http/2 disabled it becomes a reliable connection and traefik routes as expected. When re-enabling http/2 on the browser, the intermittent 404s return.

I also encountered the same problem. I used terminating TLS in Varnish with traefik. Referring to https://github.com/traefik/traefik/issues/9983, I have stopped using wildcard certificates, but this problem still occasionally occurs when making HTTP/2 requests, and I tested traefik 3.0 and the problem still exists.

Hey @everyx ,
Thanks for reaching out.
Could you provide a minimal reproducible case (for instance, full Kubernetes manifest to reproduce the issue)?
In the meantime, if any community member can help us find verified steps to reproduce and fix the issue if possible, we would love the help.


feature/made-layout-sticky

Thanks! Published here: https://new-branding.apidocs-killbill-io.pages.dev/


Dark mode with View Transition API

Clear and concise description of the problem
https://juejin.cn/post/7207810396420325413
Toggle Dark Mode for click
Suggested solution
ViewTransition API
Alternative
No response
Additional context
No response
Validations

[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

https://github.com/YunYouJun/valaxy/commit/b76f20e8594631f2e8ca5f8a1d229cb16aa8f5f0


[Epic] Reach 80% test coverage for the OC challenge search page

What product(s) is this story for?
No response
As a user, I want
No response
Description
Reach 80% test coverage for the OC challenge search page and its components using unit and e2e tests.
This Epic could be an opportunity to collaborate with @mdsage1 and @hallieswan as they may provide guidance on how to write meaningful tests.
Acceptance criteria
No response
Tasks

[x] #2143
[x] #2387
[x] #2435
[x] #2380

Anything else?
No response
Have you linked this story to a GitHub Project?

[X] I have linked this story to a GitHub Project and set its metadata.

Next

Review the scope of this Epic with @rrchai
Organize a meeting with @rrchai, @mdsage1 and @hallieswan to review the tools and best practices on writing unit and e2e tests for Angular.

Returning this item to backlog until we actively start working with the Agora team: it would be a waste of time to add tests to selected OC components and that end up being replaced by better versions from the Agora web app.


thrimbletrimmer: When no end time set, show and auto-refresh chat

We request current time + 1 minute, and re-request every 10 seconds.
If I'm reading the code correctly, everything already correctly handles the chat being replaced
by a new fetch (as though we loaded a new video range).

Chat can sometimes take a really long time to render (this is why we put it off to a background worker). How long of ranges/much chat was this tested on? Should we do this less frequently than 10 seconds?

This was not tested.

My hope was that it would be frequent enough for someone watching live. If that's not feasible without a smart "what changed" algorithm, we can do without.

I just remembered this also:
Doesn't the server-side chat functionality only update with new chat once per minute?


chore: add proper shebang to build.sh

Should probably be added to all other shell scripts as well, but this is the most prominent one since it's mentioned in the README and it uses Bash features, so it will break when not called from Bash.

Would it instead be advisable to just use single braces so as to support all POSIX shells?

Sure, why not. Changed.


[Bug] Insert from empty source will begin an infinite transaction

Search before asking

[X] I had searched in the issues and found no similar issues.

Version
master
What's Wrong?
As title.
InsertIntoTableCommand#runInternal
private void runInternal(ConnectContext ctx, StmtExecutor executor) throws Exception {
        AbstractInsertExecutor insertExecutor = initPlan(ctx, executor);
        // if the insert stmt data source is empty, directly return, no need to be executed.
        if (insertExecutor.isEmptyInsert()) {
            return;
        }
        insertExecutor.executeSingleInsert(executor, jobId);
}

Here insert command will not be actually started when empty relation, so callback of txn commit and publish will never be called, resulting in an infinite transaction which will only finish when timeout reached.
InsertIntoTableCommand#initPlan  (transaction begins here)
public AbstractInsertExecutor initPlan(ConnectContext ctx, StmtExecutor executor) throws Exception {
        // ...
        try {
           // ...
            insertExecutor.beginTransaction();
            insertExecutor.finalizeSink(planner.getFragments().get(0), sink, physicalSink);
            targetTableIf.readUnlock();
        } catch (Throwable e) {
            targetTableIf.readUnlock();
            // the abortTxn in onFail need to acquire table write lock
            if (insertExecutor != null) {
                insertExecutor.onFail(e);
            }
            throw e;
        }

        executor.setProfileType(ProfileType.LOAD);
        // We exposed @StmtExecutor#cancel as a unified entry point for statement interruption,
        // so we need to set this here
        executor.setCoord(insertExecutor.getCoordinator());
        return insertExecutor;
    }

What You Expected?
Empty source optimization should commit and publish transaction.
How to Reproduce?
Just create an empty table, insert data from itself.
Anything Else?
introduced by #34418
Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Maybe just do not begin a transaction for empty insert is better.


llvm, top-level: Baby steps towards cross support

Motivation for this change
Tried to do what I could while preserving hashes (always a good test!).

Less wrapper "helper" function madness
Clang wrapper and stdenvs at least try to refer to adjacent stages.
Removed some old dead clean stuff

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Success on x86_64-darwin (full log)
Attempted: llvm
Partial log (click to expand)
/nix/store/c0halv3c1zxax8dj7zwsyg0jlwicp64z-llvm-5.0.1

Success on aarch64-linux (full log)
Attempted: llvm
Partial log (click to expand)
/nix/store/pskvivaqfn92jiiw30kwg32d33d1ak48-llvm-5.0.1-python/share/opt-viewer/opt-stats.py: interpreter directive changed from "/usr/bin/env python2.7" to "/nix/store/vhz9s1dzzbndz032dysnixj8mxyfl30s-python-2.7.14/bin/python2.7"
/nix/store/pskvivaqfn92jiiw30kwg32d33d1ak48-llvm-5.0.1-python/share/opt-viewer/opt-diff.py: interpreter directive changed from "/usr/bin/env python2.7" to "/nix/store/vhz9s1dzzbndz032dysnixj8mxyfl30s-python-2.7.14/bin/python2.7"
checking for references to /build in /nix/store/pskvivaqfn92jiiw30kwg32d33d1ak48-llvm-5.0.1-python...
shrinking RPATHs of ELF executables and libraries in /nix/store/35q99mahim3gihys7d7g6xciwfika7fi-llvm-5.0.1-lib
shrinking /nix/store/35q99mahim3gihys7d7g6xciwfika7fi-llvm-5.0.1-lib/lib/libLLVM-5.0.so
strip is /nix/store/jk6j4lh9v5mvjdbdc35sj0zffhhf6s56-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/35q99mahim3gihys7d7g6xciwfika7fi-llvm-5.0.1-lib/lib
patching script interpreter paths in /nix/store/35q99mahim3gihys7d7g6xciwfika7fi-llvm-5.0.1-lib
checking for references to /build in /nix/store/35q99mahim3gihys7d7g6xciwfika7fi-llvm-5.0.1-lib...
/nix/store/04vd1yznqdzqpphj946hnkc88xaxf59x-llvm-5.0.1

Failure on x86_64-linux (full log)
Attempted: llvm
Partial log (click to expand)
Dependee "/build/llvm/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/build/llvm/build/CMakeFiles/check-all.dir/depend.internal".
Scanning dependencies of target check-all
make[3]: Leaving directory '/build/llvm/build'
make -f CMakeFiles/check-all.dir/build.make CMakeFiles/check-all.dir/build
make[3]: Entering directory '/build/llvm/build'
[100%] Running all regression tests
/nix/store/l9j2jsc9flrbmpf799nw9wdq59gpwms8-python-2.7.14/bin/python2.7 /build/llvm/utils/lit/lit.py -sv --param llvm_site_config=/build/llvm/build/test/lit.site.cfg --param llvm_unit_site_config=/build/llvm/build/test/Unit/lit.site.cfg /build/llvm/build/test
-- Testing: 21436 tests, 4 threads --
building of '/nix/store/ymm68lzgkawgpif7q4bnxh9x9pfzxkq4-llvm-5.0.1.drv' timed out after 1800 seconds
error: build of '/nix/store/ymm68lzgkawgpif7q4bnxh9x9pfzxkq4-llvm-5.0.1.drv' failed

Success on x86_64-darwin (full log)
Attempted: llvm
Partial log (click to expand)
/nix/store/c0halv3c1zxax8dj7zwsyg0jlwicp64z-llvm-5.0.1

Success on aarch64-linux (full log)
Attempted: llvm
Partial log (click to expand)
/nix/store/04vd1yznqdzqpphj946hnkc88xaxf59x-llvm-5.0.1

Success on x86_64-linux (full log)
Attempted: llvm
Partial log (click to expand)
these paths will be fetched (37.22 MiB download, 234.41 MiB unpacked):
  /nix/store/87k8q7x4j1mzgq4r69lkvsyhvk47xrcr-llvm-5.0.1-lib
  /nix/store/khmzmxzyxik5v4vkg8n0l8p6kfcx3x95-llvm-5.0.1
copying path '/nix/store/87k8q7x4j1mzgq4r69lkvsyhvk47xrcr-llvm-5.0.1-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/khmzmxzyxik5v4vkg8n0l8p6kfcx3x95-llvm-5.0.1' from 'https://cache.nixos.org'...
/nix/store/khmzmxzyxik5v4vkg8n0l8p6kfcx3x95-llvm-5.0.1

Success on x86_64-darwin (full log)
Attempted: llvm
Partial log (click to expand)
/nix/store/c0halv3c1zxax8dj7zwsyg0jlwicp64z-llvm-5.0.1

Success on aarch64-linux (full log)
Attempted: llvm
Partial log (click to expand)
/nix/store/04vd1yznqdzqpphj946hnkc88xaxf59x-llvm-5.0.1

Success on x86_64-linux (full log)
Attempted: llvm
Partial log (click to expand)
these paths will be fetched (37.22 MiB download, 234.41 MiB unpacked):
  /nix/store/87k8q7x4j1mzgq4r69lkvsyhvk47xrcr-llvm-5.0.1-lib
  /nix/store/khmzmxzyxik5v4vkg8n0l8p6kfcx3x95-llvm-5.0.1
copying path '/nix/store/87k8q7x4j1mzgq4r69lkvsyhvk47xrcr-llvm-5.0.1-lib' from 'https://cache.nixos.org'...
copying path '/nix/store/khmzmxzyxik5v4vkg8n0l8p6kfcx3x95-llvm-5.0.1' from 'https://cache.nixos.org'...
/nix/store/khmzmxzyxik5v4vkg8n0l8p6kfcx3x95-llvm-5.0.1

OK the top commit that fixes the overriding also causes a mass rebuild, so removed it. [But then ofborg didn't update labels because the testing was cached.]


Python 3.6 build for linux-64

Hi, thanks for putting this feedstock together.
I'd like to use this package from Python 3.6 on Linux, but from https://anaconda.org/conda-forge/cairosvg/files it looks like the Python 3.6 version is only built for OS X.
What would it take to build this for Linux 64 as well?
Thanks!

@jonmmease can this be closed?

Yes, looks like the Linux builds are there now. Thanks!


[AB3: Adding Command] Test writing instructions

Situation
In the writing test section, there is a line:

Of course you can simply add the test cases manually, like you've been doing all along this tutorial.

However, throughout the tutorial, there was no mention of adding test cases or test files. Since the tests are added with the actual Java implementation code in the git commit links, there should be mentions of these tests in the steps.
Proposed
In the introduction of the tutorial, include:
We will also write tests to ensure that the changes are working as expected. You will find the implementation details of these tests in information boxes like this one.
In Hook RemarkCommand into the application section

Since we created a new file RemarkCommand, we should also create a RemarkCommandTest file. JUnit tests are annotated with @Test. For now, we expect the execute in RemarkCommand to fail. Thus, the test will reflect this expectation.
Don’t forget to include a test case in AddressBookParserTest to ensure that a RemarkCommand is created when the command is parsed successfully.

In Enhancing RemarkCommand section

Since RemarkCommand’s constructor now accepts arguments, the tests will reflect that. Note: you can use CommandTestUtil.java to include constant test values for greater reusability.
Additionally, the equals method should be tested with various inputs, like objects of the different values or types.
RemarkCommandParserTest should also be included to ensure that RemarkCommandParser works as we expect. Write test cases that cover a wide range of user inputs, such as presence of remark and fields.

In Update other usages of Person section

PersonBuilder.java is used to create a default Person object for testing purposes. Don’t forget to include a remark field in this default Person too!

In Updating Storage section

TypicalPersons.java is used to create various Person objects for testing. Add the remark field for these Person objects!

@ruishanteo you can send a PR for this, if interested.


confuse with "go vet error is not a type"

What version of Go are you using (go version)?

$ go version
go version go1.12.7 linux/amd64

What did you do?
the sample code:
package main

import (
	"log"
	"os"
)

func main() {
	file, error := os.Open("hs.json")
	if error != nil {
		log.Println("open file ", error)
		return
	}
	defer file.Close()
	h := func(string) error {
		return nil
	}
	h("hello")

}

What did you see instead?
i am beginner with golang, the go vet output is 'error is not a type'. so, it can be confusing to fix problem

Go has a flat namespace: variable names and and type-names can (and do) shadow each other.
Here, you have declared a local variable error (on line 9), and it shadows the declaration of the built-in type error.

Duplicate of #33567


Main file can not be named main.swift

As per the Swift runtime for AWS Lambda, the main file can not be named main.swift

Note that the file can not be named main.swift or you will encounter the following error: 'main' attribute cannot be used in a module that contains top-level code.

https://github.com/swift-server/swift-aws-lambda-runtime
While a basic build works with Swift 5.8 and swift 5.9, it breaks some other library, such as the OpenAPIGenerator
Fix : rename the main file from the template to LambdaHandler or any other name

submitted https://github.com/aws-samples/aws-sam-swift/pull/5 to fix this


Like feature for posts added

Like button with counter added to each post

post_likes_count column with default value 0 added into db

Give some time to review the code. Thanks for keeping patience.

Hello @kristonela sorry for the delay in reviewing the code.
The like button is not working correctly. It is not updating the likes also it acts as an input field. I am sharing the snipe.
You kindly review your code again and do the necessary changes.
Thank you

I'm sure it worked when i pulled the request .. but I will check it again.
Odoslané z iPhonu

Dňa 20. 11. 2021 o 5:39 užívateľ Chaitak Gorai @.***> napísal:

Hello @kristonela sorry for the delay in reviewing the code.
The like button is not working correctly. It is not updating the likes also it acts as an input field. I am sharing the snipe.
You kindly review your code again and do the necessary changes.
Thank you
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Hello, I fixed the input field, I checked the like button for a million times, it works just fine ... I 'm sure it is all as it is supposed to be and functional. Thank you for checking it :)

hello @kristonela sorry but the like button is not working. it is not adding likes to the post.

As you can see, it DOES Work ... i believe there must be issue in commit or something

Dňa 22. 11. 2021 o 17:32 užívateľ Chaitak Gorai @.***> napísal:

hello @kristonela sorry but the like button is not working. it is not adding likes to the post.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

@kristonela it is not functioning in the post.

Can you send me some details of what is happening ? I sent you a video that it is working for me so I would like to find where is the problem. Odoslané z aplikácie Pošta pre Windows Od: Chaitak GoraiOdoslané: pondelok 22. novembra 2021 18:46Komu: chaitak-gorai/blogbookKópia: Kristonela; MentionPredmet: Re: [chaitak-gorai/blogbook] Like feature for posts added (PR<EMAIL_ADDRESS>it is not functioning in the post.—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
			Táto správa bola skontrolovaná na prítomnosť vírusov programom Avast Antivirus.
			www.avast.com


Improve Postgres debugging and test options

Issues on Postgres tend to take to long to fix and sometimes to find. This is due to the fact that the sync takes longer and errors manifest themselves at new block heights at the end of the chain.
Although the test chain or custom chains can be used for certain things it´s kinda complex to setup and run. I think what is needed is a debug option at block level. Where you can specify a block height, fetch that block and test data and check if Postgres code can parse it without crashing.
Also a way to test new  or specified transaction(s) before putting it into live would be good. Like testing a new transaction type to see if that can be parsed.
I know it will be hard to approach 100% test coverage. But I think these 2 things can speed if finding bugs, but also new development, because it´s easier to confirm if new code works. Now I´m just hesitant to add or change stuff, because of testing complexibitly
I guess adding some options to postgres_test.go would be best? And calling the existing functions from there? Not sure what is the best way to have/mock testdata. Maybe fetch the data from node.deso.org? Are there packages which are recommended for this?
Let me know your thoughts.

@tijno @lazynina @diamondhands0 FYI


Spark Job on AWS Glue fails to Emit Metadata

Describe the bug
Using DataHub's recommended Spark Session configuration for Apache Spark (https://datahubproject.io/docs/metadata-integration/java/spark-lineage/), lineage metadata is pushed to the DataHub REST endpoint as expected when running a Spark job on Amazon EMR latest version 6.5.0. However, when running the same Spark job on AWS Glue (Spark v3.1.1), the ELT part of the job succeeds but the metadata fails to be sent to DataHub and throws vague errors.
To Reproduce
Steps to reproduce the behavior:

Configure a Spark Job with AWS Glue's Spark script editor, using DataHub's recommended Spark Session configuration for Apache Spark (exact same job that runs successfully on Amazon EMR)
Run the job
The ELT part of the job will succeed (the overall job is successful)
View the log output in Amazon CloudWatch
There are errors indicating that the DataHub portion of the job failed. The job failed to emit metadata to DataHub (see screengrab below)

Expected behavior
The same Spark job, configured to send metadata to DataHub that runs on Amazon EMR, should also run successfully as an AWS Glue job.
Screenshots

Desktop (please complete the following information):

OS: macOS 11.6 (20G165)
Browser: Google Chrome
Version 99.0.4844.51 (Official Build) (x86_64)

Additional context
Example Spark Session which succeeds on Amazon EMR but fails on AWS Glue to emit metadata:
spark = SparkSession \
    .builder \
    .appName(table_name) \
    .config("hive.metastore.client.factory.class",
            "com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory") \
    .config("spark.jars.packages", "io.acryl:datahub-spark-lineage:0.8.27") \
    .config("spark.extraListeners", "datahub.spark.DatahubSparkListener") \
    .config("spark.datahub.rest.server", "http://111.222.333.444:55555") \
    .enableHiveSupport() \
    .getOrCreate()

Errors (shown above):
22/03/15 13:04:16 ERROR DatahubSparkListener: Execution end event received, but start event missing for appId/sql exec Id spark-application-1647349401206:2

22/03/15 13:04:16 ERROR DatahubSparkListener: Skipping processing for sql exec Id2 as Query execution context could not be read from current spark state

Hi @MugdhaHardikar-GSLab! Would you mind taking a look at this issue?

This seems to be duplicate issue of https://github.com/datahub-project/datahub/issues/4399
Can you confirm?

Totally unrelated. Two different issues with two different services.

Below are the CloudWatch logs from one of several Spark jobs that failed to emit metadata.
**CloudWatch Logs Insights**
region: us-east-1
log-group-names: /aws-glue/jobs/logs-v2
start-time: -604800s
end-time: 0s
query-string:
fields @timestamp, @message
| sort @timestamp desc

@timestamp
@message

2022-03-16 16:58:12.137
22/03/16 16:58:12 ERROR McpEmitter: Failed to emit metadata to DataHub

2022-03-16 16:58:02.122
22/03/16 16:58:02 ERROR DatahubSparkListener: Skipping processing for sql exec Id2 as Query execution context could not be read from current spark state

2022-03-16 16:58:02.122
22/03/16 16:58:02 ERROR DatahubSparkListener: Execution end event received, but start event missing for appId/sql exec Id spark-application-1647449810140:2

2022-03-16 16:58:02.073
22/03/16 16:58:02 ERROR McpEmitter: Failed to emit metadata to DataHub

2022-03-16 16:57:54.842
22/03/16 16:57:54 ERROR CoarseGrainedExecutorBackend: Executor self-exiting due to : Cannot register with driver: spark://CoarseGrainedScheduler@<IP_ADDRESS>:43513

2022-03-16 16:57:54.628
22/03/16 16:57:54 ERROR TransportRequestHandler: Error while invoking RpcHandler#receive() for one-way message.

2022-03-16 16:57:54.458
22/03/16 16:57:54 INFO ShutdownHookManager: Shutdown hook called

2022-03-16 16:57:53.917
22/03/16 16:57:53 INFO Executor: Starting executor ID 1 on host <IP_ADDRESS>

2022-03-16 16:57:52.482
22/03/16 16:57:52 INFO Executor: Starting executor ID 6 on host <IP_ADDRESS>

2022-03-16 16:57:51.246
22/03/16 16:57:51 WARN SessionState: METASTORE_FILTER_HOOK will be ignored, since hive.security.authorization.manager is set to instance of HiveAuthorizerFactory.

2022-03-16 16:57:50.278
22/03/16 16:57:50 INFO DAGScheduler: Job 2 finished: saveAsTable at NativeMethodAccessorImpl.java:0, took 5.054870 s

2022-03-16 16:57:50.252
22/03/16 16:57:50 INFO DAGScheduler: Job 2 is finished. Cancelling potential speculative or zombie tasks for this job

2022-03-16 16:57:49.889
22/03/16 16:57:49 INFO MultipartUploadOutputStream: close closed:false s3://databrew-demo-111222333444-us-east-1/sinusitis_glue_spark_40/part-00000-96d94482-79aa-4920-b67a-aa1dfdda68d7_00000.c000.snappy.parquet

2022-03-16 16:57:45.228
22/03/16 16:57:45 INFO DAGScheduler: Got job 2 (saveAsTable at NativeMethodAccessorImpl.java:0) with 1 output partitions

2022-03-16 16:57:44.960
22/03/16 16:57:44 INFO MultipartUploadOutputStream: close closed:false s3://aws-glue-assets-111222333444-us-east-1/sparkHistoryLogs/spark-application-1647449810140.inprogress

2022-03-16 16:57:41.876
22/03/16 16:57:41 INFO HadoopRDD: Input split: s3://databrew-demo-111222333444-us-east-1/big_data/conditions/conditions.csv:0+30584684

2022-03-16 16:57:41.876
22/03/16 16:57:41 INFO HadoopRDD: Input split: s3://databrew-demo-111222333444-us-east-1/big_data/patients/patients.csv:0+12438413

2022-03-16 16:57:41.876
22/03/16 16:57:41 INFO HadoopRDD: Input split: s3://databrew-demo-111222333444-us-east-1/big_data/patients/patients.csv:12438413+12438414

2022-03-16 16:57:41.876
22/03/16 16:57:41 INFO HadoopRDD: Input split: s3://databrew-demo-111222333444-us-east-1/big_data/conditions/conditions.csv:30584684+30584685

2022-03-16 16:57:40.366
22/03/16 16:57:40 INFO Executor: Starting executor ID 4 on host <IP_ADDRESS>

2022-03-16 16:57:38.947
22/03/16 16:57:38 INFO Executor: Starting executor ID 15 on host <IP_ADDRESS>

2022-03-16 16:57:34.796
22/03/16 16:57:34 WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources

2022-03-16 16:57:19.796
22/03/16 16:57:19 WARN TaskSchedulerImpl: Initial job has not accepted any resources; check your cluster UI to ensure that workers are registered and have sufficient resources

2022-03-16 16:57:13.587
22/03/16 16:57:13 ERROR McpEmitter: Failed to emit metadata to DataHub

2022-03-16 16:57:13.533
22/03/16 16:57:13 ERROR McpEmitter: Failed to emit metadata to DataHub

2022-03-16 16:57:03.437
22/03/16 16:57:03 ERROR DatahubSparkListener: Execution end event received, but start event missing for appId/sql exec Id spark-application-1647449810140:0

2022-03-16 16:57:03.403
22/03/16 16:57:03 ERROR DatahubSparkListener: Skipping processing for sql exec Id0 as Query execution context could not be read from current spark state

2022-03-16 16:57:03.302
22/03/16 16:57:03 ERROR McpEmitter: Failed to emit metadata to DataHub

2022-03-16 16:56:49.808
22/03/16 16:56:49 INFO Utils: Successfully started service 'sparkDriver' on port 43513.

[encoded data, 4117 characters]```

There seems to be 2 issues here. Bellow error indicates that there is connectivity issue between glue and datahub server.
ERROR McpEmitter: Failed to emit metadata to DataHub
This is direct reason of missing data on datahub
Can you try to fix this error and report back what exactly is missing?

Hi @garystafford
Is this still an issue? If not, will close it in a few days due to inactivity.

Hello @garystafford, does the spark agent work with glue? Thanks.


CC73020: Normalization of punctuation mark

Hello, @kraigb,
This proposed file change comes from https://github.com/MicrosoftDocs/visualstudio-docs.pt-br/pull/6 .
Could you review this contribution and help to merge if agreed?
Many thanks in advance.

@v-makoud : Thanks for your contribution! The author, @kraigb, has been notified to review your proposed change.


Support Pronto 0.10.x too

Pronto changelog: https://github.com/prontolabs/pronto/blob/master/CHANGELOG.md#0100

Released as v0.0.11


'module' object is not callable

ciphey -t "5piv55qE5piv55qECiA="

Traceback (most recent call last):
File "c:\users\24385\appdata\local\programs\python\python37\lib\runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "c:\users\24385\appdata\local\programs\python\python37\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\Users\24385\AppData\Local\Programs\Python\Python37\Scripts\ciphey.exe_main.py", line 7, in
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 829, in call
return self.main(*args, **kwargs)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\ciphey\ciphey.py", line 261, in main
with yaspin(Spinners.earth, "Thinking") as sp:
TypeError: 'module' object is not callable

Include your plaintext here, replacing this

Version
⚠IMPORTANT⚠ We need this information because different environments will induce different bugs in Ciphey

OS/Distro: Windows10
Python version: Python 3.7.8
Ciphey versions: ciphey 5.11.0
Did you use Docker? No.

Verbose Output
Pastebin
To Reproduce
Steps to reproduce the behavior:

What input did you use?
ciphey -t "5piv55qE5piv55qECiA="
What flags / arguments did you use?
base64

I dont get the error for me it is stuck at the thinking process because ciphey only can detect english text/words

I dont get the error for me it is stuck at the thinking process because ciphey only can detect english text/words

Need to learn more languages

Need to learn more languages

I dont get the error for me it is stuck at the thinking process because ciphey only can detect english text/words

ciphey -t "amRm"
Traceback (most recent call last):
File "c:\users\24385\appdata\local\programs\python\python37\lib\runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "c:\users\24385\appdata\local\programs\python\python37\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\Users\24385\AppData\Local\Programs\Python\Python37\Scripts\ciphey.exe_main.py", line 7, in
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 829, in call
return self.main(*args, **kwargs)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\ciphey\ciphey.py", line 261, in main
with yaspin(Spinners.earth, "Thinking") as sp:
TypeError: 'module' object is not callable
it is base64 English text

I dont get the error for me it is stuck at the thinking process because ciphey only can detect english text/words

ciphey -t "amRm"
Traceback (most recent call last):
File "c:\users\24385\appdata\local\programs\python\python37\lib\runpy.py", line 193, in _run_module_as_main
"main", mod_spec)
File "c:\users\24385\appdata\local\programs\python\python37\lib\runpy.py", line 85, in run_code
exec(code, run_globals)
File "C:\Users\24385\AppData\Local\Programs\Python\Python37\Scripts\ciphey.exe_main.py", line 7, in
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 829, in call
return self.main(*args, **kwargs)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "c:\users\24385\appdata\local\programs\python\python37\lib\site-packages\ciphey\ciphey.py", line 261, in main
with yaspin(Spinners.earth, "Thinking") as sp:
TypeError: 'module' object is not callable
it is base64 English text

look for this file :site-packages/ciphey/ciphey.py
change the line"import yaspin" to "from yaspin import yaspin"
then try again.

look for this file :site-packages/ciphey/ciphey.py
change the line"import yaspin" to "from yaspin import yaspin"
then try again.

a update led to this problem

a update led to this problem

I'm going to close this. This error is because Ciphey version 5.11.0 is broken and it was pulled from PyPI a while ago. Run the command pip install ciphey==5.10.0 to downgrade to version 5.10.0 to fix it. Once we release the next version, this will be fixed so it will no longer install 5.11.0.

I'm going to close this. This error is because Ciphey version 5.11.0 is broken and it was pulled from PyPI a while ago. Run the command pip install ciphey==5.10.0 to downgrade to version 5.10.0 to fix it. Once we release the next version, this will be fixed so it will no longer install 5.11.0.


[Feature] Adds Image Generation Capability

Why are these changes needed?
Proof of concept to use agent capabilities as a way of multimodal communication.

Related issue number

Checks

[ ] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
[ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
[ ] I've made sure all auto checks have passed.

Codecov Report
Attention: Patch coverage is 0% with 81 lines in your changes are missing coverage. Please review.

Project coverage is 46.17%. Comparing base (b604c44) to head (aca17d5).
Report is 5 commits behind head on main.

Files
Patch %
Lines

.../agentchat/contrib/capabilities/generate_images.py
0.00%
81 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1874       +/-   ##
===========================================
+ Coverage   35.99%   46.17%   +10.17%
===========================================
  Files          63       64        +1
  Lines        6614     6700       +86
  Branches     1459     1592      +133
===========================================
+ Hits         2381     3094      +713
+ Misses       4039     3355      -684
- Partials      194      251       +57

Flag
Coverage Δ

unittests
46.10% <0.00%> (+10.10%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@BeibinLi @rickyloynd-microsoft

@WaelKarkoub  Thanks for the contribution! Can you add a few lines of high-level explanation at the top of this PR? Something that describes the use cases of this implementation, and it's current limitations.

Hi @rickyloynd-microsoft, I've updated the PR with more details, let me know what you think!

Awesome!
Responding to a couple of your questions:

I'm using TextAnalyzerAgent, so more llm calls, more token usage.

Nice to see TextAnalyzerAgent being used more.

If an image was generated, we treat it as a final reply. Should it be the final reply? Or should we pass it along the reply chain?

I think all of the existing reply functions do the same, and I think it's very appropriate to treat a generated image as the final reply.

Looking forward to @BeibinLi's feedback.

@WaelKarkoub Fantastic PR! Thanks so much for your work.
@rickyloynd-microsoft One thing I want to ask you is: should Dalle be a "skill" or "capability"? From the implementation perspective, I really like the current "capability" style. However, it may occur additional cost (aka, for text_analyzer) to process every message. The "skill", on the other hand, even though cheaper, would be less accurate (especially for small language models).

@WaelKarkoub Fantastic PR! Thanks so much for your work.
@rickyloynd-microsoft One thing I want to ask you is: should Dalle be a "skill" or "capability"? From the implementation perspective, I really like the current "capability" style. However, it may occur additional cost (aka, for text_analyzer) to process every message. The "skill", on the other hand, even though cheaper, would be less accurate (especially for small language models).

How are you defining 'skill' here? As a function call?


update(data structures): update queue and stack

Hi, I just updated the stack and queue, and create each dedicated markdown files. Also changed the links of the data structure's list to its dedicated files.

Data structure/readme.md should have short description. Check long description should be on the desiccated file. See the data structure folder now. Maybe you had the old version of repo forked.

Is it enough or too short to be descriptive?


Py doc utils client fix

Fix changes asked on this PR #117.
Makes changes on :

Fix comment format not recognised by PyDoc
Removal of examples in order to add them all at once later
More details on some classes

@theolebever Can you please fix the formatting issue?

Done @JoFrost


Test Issue created at Tue, 15 Jun 2021 12:20:56 GMT

Test issue body  Tue, 15 Jun 2021 12:20:56 GMT

Comment on issue at Tue, 15 Jun 2021 12:20:57 GMT


release notes: please mention changed defaults like disabling git hooks explicitly

Gitea version: 1.13.0

Description
In this release git hooks have been disabled by default for security reasons as detailed in #13058. This is not immediately visible from the changelog/release notes but could be considered a breaking or at least rather important change.
It would be really helpful if changes like this could be explicitly mentioned.

See https://blog.gitea.io/2020/12/gitea-1.13.0-is-released/#1130httpsgithubcomgo-giteagiteareleasestagv1130---2020-12-01, It's on security section. We missed a security label on the PR. I have added it.

Sorry, I should have been a bit more verbose.
I noticed it in the security section, but would not have expected a changed default from reading the title. The one following in the list "Disable DSA ssh keys by default" is rather clear on the other hand.
Just as a suggestion, it might be helpful to include some kind of breaking changes list (like changed default values, changed API behaviour etc.) or clearer titles for such issues.

Sorry, I should have been a bit more verbose.
I noticed it in the security section, but would not have expected a changed default from reading the title. The one following in the list "Disable DSA ssh keys by default" is rather clear on the other hand.
Just as a suggestion, it might be helpful to include some kind of breaking changes list (like changed default values, changed API behaviour etc.) or clearer titles for such issues.


Transition Checksum

Hi,
Serial transition might have errors at some point it might cause unexpected behavior so adding a checksum for each packet might be useful.
Kind Regards

Something like this could help, but we haven't really seen a need for use of a checksum. If we find the packet to be invalid while parsing it, we can simply drop it and wait for the next one to come in.
From my testing, I've never really run into any issues with this approach, and also haven't really errors while transmitting through serial.
I'm going to close this issue for now, but if you'd like to open a pr with this included, you are more than welcome to open this issue back up and I would be more than happy to accept it.


Fixes accessibility behavior of Watching, Staring and Fork buttons

Add tabindex to buttons of repository views.
Contributed by @forgejo

Codecov Report

Merging #22634 (7e12d38) into main (cc1f8cb) will decrease coverage by 0.22%.
The diff coverage is 46.10%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main   #22634      +/-   ##
==========================================
- Coverage   48.22%   48.00%   -0.22%
==========================================
  Files        1050     1059       +9
  Lines      142937   144360    +1423
==========================================
+ Hits        68925    69305     +380
- Misses      65772    66780    +1008
- Partials     8240     8275      +35

Impacted Files
Coverage Δ

models/auth/token.go
45.18% <ø> (ø)

models/git/lfs.go
17.37% <0.00%> (-3.96%)
:arrow_down:

models/issues/issue_project.go
31.29% <0.00%> (+0.23%)
:arrow_up:

models/issues/pull.go
50.63% <ø> (+0.01%)
:arrow_up:

models/organization/team.go
58.00% <ø> (-7.45%)
:arrow_down:

models/organization/team_user.go
66.66% <ø> (-7.91%)
:arrow_down:

models/packages/package_blob.go
50.00% <0.00%> (-6.82%)
:arrow_down:

models/repo/repo_list.go
74.29% <0.00%> (-0.17%)
:arrow_down:

models/system/setting.go
53.80% <0.00%> (-2.13%)
:arrow_down:

models/user.go
38.33% <0.00%> (+3.21%)
:arrow_up:

... and 109 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:mage: :)


[release-1.9] Upgrade to latest dependencies

bumping pkg -dprotaso
/cc knative/serving-writers knative/eventing-writers
/assign knative/serving-writers knative/eventing-writers
Produced by: knative-sandbox/knobots/actions/update-deps

/lgtm
/approve


Support _FILE environment variable?

We are trying to run Kibana in DDC (sigh) and the secrets are mounted as files, and thus the "secret" has to be read from /run/secrets/secret-name. The "workaround" for this issue in DDC is to  create a wrapper script that reads the secret and puts the value into the correct env variable.
I propose that the "helper" script could look for SOME_VAR_FILE, and if it finds that (and its a file thats readable), put the contents of the file into SOME_VAR.
The places I see this being most useful is "ELASTICSEARCH_PASSWORD" and maybe "SERVER_SSL_KEYPASSPHRASE" as the other places I would use a "secret" are already looking for a file.
Suggestions?
~tommy

Hey - we're migrating issues over to the kibana repo so I reopened this at https://github.com/elastic/kibana/issues/39605.


[Reservations] Self review comments

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.Reservations


added docker-compose with continuumio/anaconda3

Hi Mark
thank you very much for your work.
I added a docker-compose.yaml so you are able to run the analytics without installing anaconda to your local system.
Maybe you like to add this to your repo.
Best regards
Carsten

This looks good to me. Maybe only add would be to put a line the Readme about usage.

Hi Mark, did it. BR Carsten


UI - execution status and error messages

If an execution fails, I have to go back to the workflow page in order to see the error.  I'd like to be able to see the error on the actual execution page as well.  I feel like I have to go back currently, make sure i'm looking at the right execution (cuz there are sometimes a lot of executions), and then hop back and forth.

Closing as a duplicate of #319


Title: Elon Musk Tribute Page

Describe your issue.
I will make a tribute web page, which will be fully responsible. Tribute to the great Elon Musk
Screenshots (if applicable).
No response
Additional context (if any)
No response

Sure, Go ahead,
Make sure to read CONTRIBUTING.md before starting contributions.
Best of luck!

sure @RajVarsani

Yes, @legit-develop. it is still Open
You may contribute if you want to.

@anshulsoni4 are you working on the issue, or do you want me to assign it to @legit-develop?

@RajVarsani you can assign this to someone

Okay, I'm assigning this to @legit-develop

Any update @legit-develop?


Add WebAssembly (wast) to meta.js

closes #6450
Summary
The WebAssembly wast mode already exists, but it is not currently available via meta.js. This will apply to the .wat and .wast extension for now, but it looks like .wat and .wast have separate meanings going forward.

Thanks!


Feature Request: Layer 2 to honor externalTrafficPolicy

Is this a bug report or a feature request?: Feature request
What happened:
Having no clue about BGP, I opted for the Layer 2 setup.
All works fine except one little detail. Layer 2 does not honor the externalTrafficPolicy (as documented). Unfortunately this is a show stopper in case of web services since you have to know the source IP for any production web service for many reasons (from simple stats to identifying abuse/hack attempts etc).  Could this be changed to use NodePort instead of ClusterIP?
What you expected to happen:
Well it works as expected :)
It would be great to get the source IP on REMOTE_ADDR on the ingress controller (ingress-nginx in my case). This is possible if metallb would honor externalTrafficPolicy and the ingress-controller is deployed as a DaemonSet on all nodes running a metallb speaker.
How to reproduce it (as minimally and precisely as possible):
Metallb is configured as a loadbalancer
Ingress-nginx is configured to handle ingress
nginx pod is configured to display a phpinfo(); page.
The phpinfo page gives cluster specific IPs as $_SERVER['REMOTE_ADDR'] and $_SERVER['HTTP_X_FORWARDED_FOR']
$_SERVER['HTTP_X_FORWARDED_FOR']	<IP_ADDRESS>
$_SERVER['REMOTE_ADDR']	<IP_ADDRESS>
(Note: <IP_ADDRESS> is the IP of nginx-ingress-controller)
Anything else we need to know?:
Environment:

MetalLB version: 0.62
Kubernetes version: 1.9.7
BGP router type/version: n/a - layer 2 mode used
OS (e.g. from /etc/os-release): Ubuntu 16.04.4 LTS
Kernel (e.g. uname -a):4.4.0-122-generic

PS: Thank you for the great work!! :)

Thanks for the suggestion! I'm already planning to do this, it's tracked in #195 because removing leader election is a prerequisite to make this work.
You can read the proposed design in the other bug, but the bottom line is: yes, we can make this work, but the tradeoff is that only 1 machine will receive traffic. It will behave completely like a VRRP active/passive failover. Unfortunately, due to the limitations of layer 2 protocols, that's the best we can do :(
I'll keep this bug open in addition to #195, so that it's obvious to other people that we're planning this, the other bug doesn't make it obvious.


Add rulerz to vsCode?

I don't use or know much about vsCode, but I'd be happy to help!
Do you know if this will require refactoring, or is it simply a matter of registering the plugin with another service?

Thanks for using rulerz, and caring enough to submit a bug report! We're no longer actively using Atom day-to-day, and so haven't devoted a great deal of time to the package. If you're interested in picking up maintainership, please let me know.

@sergeysova Hope you found a solution for vscode. Will close this issue now as it's pretty old and this project is not (very) actively maintained.


IoC extend not working (custom driver)

Hi
I try to extend Ally with my own driver. I followed the comment in #32, but without success.
Currently the start/hooks.js file contains the following code:
const { ioc } = require('@adonisjs/fold');
const { hooks } = require('@adonisjs/ignitor');

hooks.after.providersBooted(() => {
    ioc.extend('Adonis/Addons/Ally', 'corpid', function() {
      return require('../app/Extensions/AllyCorpid');
    });
});

But when I try to redirect to the authorize page using the following code...
async redirect ({ ally }) {
    await ally.driver('corpid').redirect()
}

... i get an «E_INVALID_PARAMETER: corpid is not a valid ally driver» error in my browser window (but no errors in the node console).
The driver itself (AllyCorpid.js) is inspired by the 1st party facebook driver and looks almost identical.
Btw. I also tried to return an instantiated object in hooks.js - didn't work either.

Should be inside hooks.before.providersBooted

Thanks for your reply.
I changed the hook, but still get the same error 😕

Ahh, my bad. Just checked the code https://github.com/poppinss/adonis-fold/blob/develop/src/Registrar/index.js#L179, it should be before.providersRegistered :)


fix: correct the spread order for http_emitter options

fixes: #223
I would like to add a test for this,  but I think some type definitions need to be added so typescript doesn't complain about me trying to pass in more options in the send method.  Keeping as Draft for now
Signed-off-by: Lucas Holmquist<EMAIL_ADDRESS>

While this should be a fairly straightforward change,  i'm running into issues related to Typescript when adding in the tests.
I know basic's, but I'm not sure how to proceed when trying to declare the type for a variable object that uses the spread operator.
@grant perhaps you have some insight, since from my reading of other issues,  you were the most vocal for adding typescript support.   Thanks in advance
Also cc @lance

That's a bad bug. Thanks for the PR!
I too have seen many TypeScript issues due to the fact this repo is half js, half ts, which causes issues with types due to inferred types.
I've added an issue here: https://github.com/cloudevents/sdk-javascript/issues/203
I'll talk about that issue there.

I don't know. It could be a while before the rewrite lands and it might be that @c-pius may want to ref master for the time being? Care to chime in @c-pius?

From my side there is no urgency. Anyway, thanks for your great work with CE and this SDK!

closing this since it will be fixed in #226


chore: rename FaissPostgresIndexer

Has this some implication for hubble?
Unfortunately, yes. They will be considered as new executors and therefore need new UUID and secrets


A small inaccuracy in the metrics of the unquantized llama-2-7b model

Hello!
In the AQLM (v4) paper, in Table 1 and Table 12, the values of PiQA, HellaSwag, ArcE, ArcC metrics are different for the unquantized llama-2-7b model. Is this the way it should be? It seems to me that it is a small error, because all other tables are correct.

Hey @ArtemBiliksin, thanks for noticing this! Both numbers are correct. We remeasured the unquantized model for the camera-ready version of the paper, a few months after the initial measurements. Although we tried to keep the setup mostly the same as in the initial experiments, I think the small difference is due to some libraries being updated to newer versions.

Hi, @Vahe1994 ! Thanks for the reply!


fix-120429 only add color to debug codicons in specific places

This PR fixes #120429
To test, verify that all the places where debug codicons previously displayed in color still do so.

/assign @isidorn

To see the benefit of this change amend this line of statusbar-sample:
https://github.com/microsoft/vscode-extension-samples/blob/63d86e3a0e459b2adf26487204891f7af62898ce/statusbar-sample/src/extension.ts#L37
to append  $(debug-start) $(debug-pause) $(debug-stop) $(debug-disconnect) $(debug-restart) $(debug-step-over) $(debug-step-into) $(debug-step-out) $(debug-continue) $(debug-step-back to text.
Build and run the extension. Open a file or create a new one with at least 2 lines. Select at least 2 lines. View the statusbar item.
Before this PR:

After this PR:

@gjsjohnmurray thanks for creating this PR, however the problem is the following, we use those icons in 3 places:

Debug toolbar floating
Debug toolabar in the debug viewlet title area (set "debug.toolbarLocation": "docked")
Inline callstack actions. Have mutliple sessions debugging and hover over the debug session item in the CALL STACK view

Your PR correctly handles 1, but breaks 2 and 3 if I am not mistaken.

1 and 3 both work correctly:

You are correct that I wasn't handling 2 (docked toolbar)

Which class do you suggest I allow the colors for? Maybe monaco-toolbar ?

An alternative, if this is specifically an issue with status bar items, is to set color: inherit !important on the status bar items:
https://github.com/microsoft/vscode/blob/c7faaf0ea08b12317d54b50d8d27a2d0c8641034/src/vs/workbench/browser/parts/statusbar/media/statusbarpart.css#L112-L116

An alternative, if this is specifically an issue with status bar items, is to set color: inherit !important on the status bar items:

@misolori the original issue was that the colors that get added to these debug codicons mean they don't look good when used on the status bar. My initial suggestion had used a :not to prevent this, but you asked for colors to be permitted only where the debug part of VS Code uses them.
I'm not clear what effect your proposed color: inherit !important would have. Maybe I should just try it and see.

Yeah I also suggest that we try to have a simpler approach.
I am not a fan of using important though.
I am also not 100% convinced we need to fix this asap. So if we get a nice solution I will happily merge if not no problem.

I am also not 100% convinced we need to fix this asap.

Maybe not asap, but the longer it remains unchanged the more places these colored codicons will start appearing in the UI (e.g. inline menu contributions to view/item/context, so if we want the rule to be that they only get colored when used in core debug UI I think we should apply the constraint sooner rather than later.
If we are content to let them get colored wherever they appear I still think we should prevent it happening on the status bar. My initial proposal did that by using :not
Or can we add -uncolored aliases to the codicons here and here so extension devs can choose to use them via names that won't trigger the CSS coloring?

This is a debt color issue which I would leave up to @misolori to tackle when he thinks is best.
For now unassigning myself and moving out of current milestone.

Closing as this was fixed, see https://github.com/microsoft/vscode/issues/120429#issuecomment-899602053


Update roslyn-version-support.md

Add point release version info

@jmarolf : Thanks for your contribution! The author(s) have been notified to review your proposed change.

As far as I know, this is the only place on the internet where this information is documented, and it's in a PR which was closed for no apparent reason.
Can we please open this up and get it merged?


Defect: get_team() does not compile properly

Avg response time

Defect/Bug Report

OpenCoarrays Version: 2.1.0-22-gbca8f16
Fortran Compiler: GNU Fortran (GCC) 8.1.1 20180528
C compiler used for building lib: gcc 8.1.1 20180528
Installation method: cmake gui -> makefile -> make install
Output of uname -a: Linux dune 4.16.12-1-ARCH #1 SMP PREEMPT Fri May 25 23:30:31 UTC 2018 x86_64 GNU/Linux (running under VirtualBox on an iMac)
MPI library being used: mpich 3.2.1
Machine architecture and number of physical cores: X86-64 / 4 cores
Version of CMake: 3.11.2

Observed Behavior
I get a compile error when trying to use the get_team() intrinsic:
program test_get_team
   use, intrinsic :: iso_fortran_env, only: team_type
   type(team_type) :: initial
   initial = get_team()
 end program test_get_team

Compiling the above, I get:
../get-team.f90:4:13:

    initial = get_team()
             1
Error: Can't convert INTEGER(4) to TYPE(team_type) at (1)

So, it appears that get_team() returns an integer.
FURTHER...
I then changed the return type to an integer:
program test_get_team
   use, intrinsic :: iso_fortran_env, only: team_type
   integer :: tn
   tn = get_team()
 end program test_get_team

I then get a internal compiler error:
[ 37%] Building Fortran object CMakeFiles/get-team.dir/get-team.f90.o
f951: internal compiler error: Intrinsic function '_gfortran_caf_get_team' (118) not recognized
0x61a32f gfc_internal_error(char const*, ...)
    ../.././gcc/fortran/error.c:1358
0x70ba60 gfc_conv_intrinsic_lib_function
    ../.././gcc/fortran/trans-intrinsic.c:855
0x70fa07 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
    ../.././gcc/fortran/trans-intrinsic.c:9556
0x6ee8dc gfc_conv_function_expr
    ../.././gcc/fortran/trans-expr.c:6788
0x6eee2a gfc_conv_expr(gfc_se*, gfc_expr*)
    ../.././gcc/fortran/trans-expr.c:7922
0x6f6463 gfc_trans_assignment_1
    ../.././gcc/fortran/trans-expr.c:10098
0x6bc227 trans_code
    ../.././gcc/fortran/trans.c:1828
0x6e246b gfc_generate_function_code(gfc_namespace*)
    ../.././gcc/fortran/trans-decl.c:6507
0x673146 translate_all_program_units
    ../.././gcc/fortran/parse.c:6121
0x673146 gfc_parse_file()
    ../.././gcc/fortran/parse.c:6324
0x6b948f gfc_be_parse_file
    ../.././gcc/fortran/f95-lang.c:204
Please submit a full bug report,

Expected Behavior
get_team() should compile and link. get_team should return a TEAM_TYPE variable.
NOTE: This could be a bug in both gfortran and opencoarrays.
Steps to Reproduce
In Observed Behavior.

@dobrecht Sorry, am I understanding you correctly that you are compiling with GCC/GFortran trunk? Or at least the latest commit on the 8.x branch? Or are you using the 8.1.0 official release?

CC: @scrasmussen

From my own testing: the get_team intrinsic function does not seem to be implemented yet and using it gives error messages at multiple levels (I did use gfortran 9.0.0 20180506 (experimental); on my system, the error messages are in german):
sync team (get_team())

generates the same compile time error as yours above.
sync team (get_team(1))

generates compile time error:
Error: Argument »level« of the intrinsic »get_team« at (1) is not supported yet
sync team (get_team(initial_team))

generates compile time error:
Error: Symbol »initial_team« at (1) has no IMPLICIT-Typ
(this error is also with the constants parent_team and current_team)
The full test case:
program Main
! please compile and run with 15 coarray images
  !
  use,intrinsic :: ISO_FORTRAN_ENV, only: team_type
  implicit none
  !
  integer :: intTeamNumber
  type (team_type) :: MainTeam
  type (team_type) :: SubTeam
  !
!
!************************************************
! MainTeam **************************************
!************************************************
!
! split the 15 images of the initial team into 3 child teams consisting of 5 images each:
  if (this_image() <= 5) then
    intTeamNumber = 1
  else if (this_image() >= 6 .and. this_image() <= 10) then
    intTeamNumber = 2
  else if (this_image() >= 11) then
    intTeamNumber = 3
  end if
  !
form team (intTeamNumber, MainTeam) ! this creates the 3 child teams in MainTeam
!
change team (MainTeam)
!
! important: the following gets executed on the images of all the 3 newly created child teams:
!
!************************************************
! SubTeam ***************************************
!************************************************
!
! split the 5 images of the MainTeam's child teams into two distinct teams resp.:
  if (this_image() < 3) then
    intTeamNumber = 1
  else
    intTeamNumber = 2
  end if
!
form team (intTeamNumber, SubTeam) ! this generates 6 teams (2 new sub teams in the 3 main teams resp.)
                                   ! within the change team (MainTeam) construct
change team (SubTeam)
!
sync team (get_team()) ! generates compile time error
!sync team (get_team(1)) ! generates compile time error
!sync team (get_team(initial_team)) ! generates compile time error
!
SubTeam_select: select case (team_number())
!
case (1) SubTeam_select
  ! codes for child team 1 of SubTeam:
  write(*,*) 'image number: ', this_image(), ' of team number: ', team_number(), &
             ' in SubTeam, of MainTeam''s child team number:', team_number(MainTeam)
              !Fortran runtime error on image 1: team_number does not yet support the optional team argument
  !
!*******************
case (2) SubTeam_select
  ! codes for child team 2 of SubTeam:
  write(*,*) 'image number: ', this_image(), ' of team number: ', team_number(), &
             ' in SubTeam, of MainTeam''s child team number:', team_number(MainTeam)
              !Fortran runtime error on image 1: team_number does not yet support the optional team argument
!
end select SubTeam_select
!
end team !(SubTeam)
!
!*************
!*************
!*************
!
end team !(MainTeam)
!
end program Main

Best Regards

@zbeekman I am using the updated branch of 8.1.X (gcc 8.1.1 20180528) ; the 2018-05-28 build

@scrasmussen is Fortran 8.2 and OpenCoarrays 2.2.0 supposed to support get_team() and sync team?
$ cat testteam.f90
sync team(get_team()) ; end

$ caf testteam.f90
f951: internal compiler error: Intrinsic function '_gfortran_caf_get_team' (118) not recognized
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/Homebrew/homebrew-core/issues> for instructions.
Error: comand:
   `/usr/local/bin/gfortran-8 -I/usr/local/include/OpenCoarrays-2.2.0-4-gc536225_GNU-8.2.0 -fcoarray=lib -Wl,-flat_namespace -Wl,-commons,use_dylibs -L/usr/local/Cellar/libevent/2.1.8/lib testteam.f90 /usr/local/lib/libcaf_mpi.a /usr/local/Cellar/open-mpi/3.1.2/lib/libmpi_usempif08.dylib /usr/local/Cellar/open-mpi/3.1.2/lib/libmpi_usempi_ignore_tkr.dylib /usr/local/Cellar/open-mpi/3.1.2/lib/libmpi_mpifh.dylib /usr/local/Cellar/open-mpi/3.1.2/lib/libmpi.dylib`
failed to compile.

In case it helps:
My first successful test of using the SYNC TEAM statement as standalone was with gfortran 8.0.1 and OpenCoarrays 2.0.0, like this: sync team (new_team) . The effect of SYNC TEAM was only on the images with the same team number (within the SELECT CASE for code execution with that team number). Using SYNC ALL, on the other hand, did effect all images within the CHANGE TEAM construct. That is exactly the desired runtime behavior, everything was perfect with my testing.
(My above test case was only to show, that GET_TEAM() does not seem to be implemented yet. Instead, you can use the test case to test the SYNC TEAM statement by simply putting a SYNC TEAM(SubTeam) within the CASE(1) block, for example.)
cheers

@zbeekman Fortran 8.2 is supposed to support get_team(), I've started looking into this issue and will work on solving it. Thanks for pinging me and that short reproducer

Any updates @scrasmussen ?

After doing some code spelunking, it seems clear that get_team() just is not implemented, whatsoever on the library (OpenCoarrays) side.

Just FYI, the missing intrinsic function get_team() can easily be circumvented by the programmer for the team variable of the parent and the current team (just by maintaining the values of these team variables locally). Only the team value of the initial team is not accessible to the programmer without the get_team() function.

I did just newly check using OpenCoarrays 2.6.1 and the most recent gfortran 9.0.1 (experimental). My above test case does still generate the same compile time errors. Therefore, I would recommend to leave this issue open yet.
These error messages remain:

f951: internal compiler error: Intrinsic function '_gfortran_caf_get_team' not recognized
Error: Argument »level« of the intrinsic »get_team« at (1) is not supported yet
Error: Symbol »initial_team« at (1) has no IMPLICIT-Typ
(that last error is also with the constants parent_team and current_team, they are missing in iso_fortran_env)

Yes, I agree... I needed to fix something in the configuration of the stalebot. This issue should stay open until it is resolved.

This has also been reported in the gfortran front end: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88154

This bug happens with -fcoarray=single so it appears changes are needed on the compiler side too.

I read through this thread and understand that implementation of get_team() is a TODO.
Posting here for the next person who lands here: get_team is not implemented as of gcc-9.2.0 and OpenCoarrays-2.8.0.
It be extremely helpful to maintain a doc that lists the status of features (not implemented/in progress/implemented) so that people know what they can expect. Is there any such doc?

I'm not part of the OpenCoarrays team but, regarding coarray teams, did maintain such a list myself. The good news: this open issue here was the last unresolved issue on my (old) list.
Among the already solved (more important) issues on my list are:
https://github.com/sourceryinstitute/OpenCoarrays/issues/533
https://github.com/sourceryinstitute/OpenCoarrays/issues/610
https://github.com/sourceryinstitute/OpenCoarrays/issues/524
But I did not too many new coding with coarray teams in the last few month, since my recent main focus is on object-oriented parallel programming through coarray components using OpenCoarrays/gfortran.
cheers

I think this would be more straightforward to implement if OpenCoarrays (at least when compiled with MPI support) used the underlying MPI communicator to directly represent the team object. I had a branch of an older version of OpenCoarrays that implemented this (as well as the optional TEAM argument to TEAM_NUMBER()): https://github.com/nathanweeks/OpenCoarrays/commit/31e39f29ac2197981fda8ccf21fb7c9e9f4bb701
If there's interest, I could update this branch for OpenCoarrays 2.8.0 and submit a PR for more formal review.


add volumes_from config item

Added support for a volumesFrom configuration item, which is simply passed through to docker-py and the docker API.

Seems like this is good, then.  I did a bunch of testing, eventually using my fork for a production deploy last night, and everything works as expected.  Thanks for being so responsive!

LGTM
Thanks for the contributions!