text:
data source model uses "type" not "data_type"

🐛 Describe the bug
Impacted versions: >= 1.8.2
Description:
There seems to be a bug in the get_data_sources() method. It eventually tried to get the "data_type" attribute but that throws a no attribute error.
I believe this is the release that introduced the bug: https://github.com/embedchain/embedchain/releases/tag/0.1.82
The model for the data uses "type" but the method that pulls the data is using "data_type"
When bug was introduced:
PR: https://github.com/embedchain/embedchain/pull/1273/files#diff-d494029527663b5dde22e3dc804d17421db5bdc6cdf0d191d3cb294e18aaaff4R16
Code:

"type": https://github.com/embedchain/embedchain/blob/6518c0c06bc32a0163c0c7407c400cf18a883df2/embedchain/core/db/models.py#L16
"date_type": https://github.com/embedchain/embedchain/blob/6518c0c06bc32a0163c0c7407c400cf18a883df2/embedchain/app.py#L298

Recreate bug:

create app and db
add data sources with data_type specified
run the app.get_data_sources() method --> attribute error

I saw same

Fix for me in version 0.1.90
See release note https://github.com/embedchain/embedchain/releases/tag/0.1.90

repo: embedchain/embedchain


text:
Add sh1108 to list of drivers

Thank you for helping out with embedded-graphics development! Please:

[ ] Check that you've added passing tests and documentation
[ ] Add a CHANGELOG.md entry in the Unreleased section under the appropriate heading (Added, Fixed, etc) if your changes affect the public API
[ ] Run rustfmt on the project
[ ] Run just build (Linux/macOS only) and make sure it passes. If you use Windows, check that CI passes once you've opened the PR.

PR description
I just released the sh1108 crate; this PR adds it to the list of supported drivers.
I don't think any of the above checklist items apply here, but let me know if something needs to be changed.

Ha, thank you! Admittedly, I spent way too long creating that image :joy:

source: gharchive/pull-request

repo: embedded-graphics/embedded-graphics

license_type: permissive

license_source: github-api


text:
Autogenerate table of tasks

Seems like the table of tasks can be autogenerated from the existing metadata.
I would suggest removing it from the readme and then linking to a new autogenerated markdown.
What are some thoughts on this?

In the same vein, I'd love if the metadata was a dataclass as well. This makes it easy to:

Type-hint the attributes
Auto-complete in IDEs
Get runtime-errors if keys are missing

Seems like the table of tasks can be autogenerated from the existing metadata.
I would suggest removing it from the readme and then linking to a new autogenerated markdown.
What are some thoughts on this?

Yep let's go! Autogeneration >>> manual generation 🚀

Wonderful glad we agree! Will see if I can find the time to implement it

This PR awaits #260.
@MartinBernstorff Since the table contains the size of the datasets and it would be problematic to fetch all datasets to generate it, it might be ideal to the dataset sizes to the metadata. What do you think?

Makes a lot of sense. There might be some work in formalising what "size" means for each task type, but let's cross that bridge when we get there!

^was just thinking of this

This seems to be fixed by #525 and #541 . Should it be closed?

source: gharchive/issue

authors: HLasse KennethEnevoldsen MartinBernstorff imenelydiaker

repo: embeddings-benchmark/mteb


text:
'Plugin site not available' error when trying to install plugin

Hello
I am getting the error 'Plugin site not available' error when trying to install the plugin.
Can you advise how I can install the plugin?
I have confirmed connectivity from my HOOBS box to the internet.
Thanks
Mark

Hi! The issue doesn't seem related to the plugin itself. For support for the commercial HOOBS product, see here.


text:
Confusion RE: how to include

I added this as:

first: in Brocfile... app.import('bower_components/active-model-adapter/active-model-adapter.js')
second: added it as a direct link to a file in my index.html

In both cases, using the usage provided, I get

Error while processing route: admin.index Could not find module active-model-adapter imported from doki/adapters/application Error: Could not find module active-model-adapter imported from doki/adapters/application

Using
import DS from 'ember-data';
export default DS.ActiveModelAdapter.extend()

instead of
import ActiveModelAdapter from 'active-model-adapter';
export default ActiveModelAdapter.extend()

The code works again and deprecation has gone away. Does this addon add ActiveModelAdapter back to the DS namespace? Is there a more thorough "usage" documentation?

You shouldn't have to use app.import if you run the following: https://github.com/ember-data/active-model-adapter#ember-cli

Ah, silly me, I must've done the bower install. Thanks, @fivetanley, that did the trick!

authors: fivetanley typeoneerror

repo: ember-data/active-model-adapter

license: mit

license_source: bigquery


text:
Python Unikernel stuck on '=== calling "stub" main() ==='

I'm trying to run the python unik example but, after boot, everything is stuck on the message

=== calling "stub" main() ===

Here there's the screenshot.

Any idea?

can you try increasing instance memory on unik run with --instanceMemory flag? (try 512 to 1024)

it is possible you are encountering a bug that was (supposed to be) fixed in 1ee6a52
if you haven't updated since then, try pulling the latest version of master and running make binary to rebuild unik
if it's the same bug, you will notice things run "normally" with instance memory at 1024mb, (or if you wait five minutes for instance to boot). let me know if pulling the most recent master fixes it for you (if you are not already on most recent)

Unfortunately no joy. I have fetched the latest from master and rebuilt it. It works like a charm if memory is 1024 but with the default 256 it's still stuck there for ages (sometime 1m some other waaay more).
I can go on with the 1G of memory but it would be great to have the bug fixed. All in all unikernels are all about minimal footprint and optimal server usage, innit?
Is there any way I can help? (Some hint on where to start from :)

the issue itself is caused by a very strange compatibility problem between Virtualbox and gorump (go running on rumprun). gorump has a function called findnull that searches a byte array for null bytes. it seems that, on providers other than virtualbox, if go reaches the end of the buffer, some kind of interrupt occurs and the function returns. however, Virtuablox behaves strangely and feeds go with an infinite number of 0xFF bytes.
So we put in a (hacky) solution to limit the search to a maximum buffer size, on the order of several hundred GB. This meant that when go is bootstrapping on rump, a buffer of ~200GB is being scanned before the main function gets loaded. When we noticed that this was causing very slow boot times for instances running Go code, we modified that function to halt at 200MB (a reasonable heuristic given the size of the actual buffer that code is scanning is on the order of tens of bytes, as observed on multiple iterations running in a debugger). The line we changed is visible here: https://github.com/emc-advanced-dev/unik/blob/master/containers/compilers/rump/go/fixgo.sh#L18
i think i know what the problem is - we updated our Go containers, but not our Python containers. Python uses a stub written in Go because python doesn't give us access to VM MAC Address, which we need for bootstrapping on virtualbox. Sorry about the inconvenience, I'll make sure to rebuild them and push the fix asap, and thank you for opening this issue!

try with latest version of master; let me know if this doesn't fix the issue

Yes, it did fix the issue. Thanks a lot!

No problem. Thanks for bringing this issue to our attention

authors: ganglio ilackarms

repo: emc-advanced-dev/unik


text:
Makefile uses "uname -p" instead of "uname -m"

ifeq ($(origin GOARCH), undefined)
		UNAME_P := $(shell uname -p)
		ifeq ($(UNAME_P),x86_64)
			export GOARCH = amd64
		endif
		ifneq ($(filter %86,$(UNAME_P)),)
			export GOARCH = 386
		endif
	endif

The correct use is "uname -m" to get x86_64. -p will show unknown or i386 depending on operating system.
$ uname --help
Usage: uname [OPTION]...
Print certain system information.  With no OPTION, same as -s.

  -a, --all                print all information, in the following order,
                             except omit -p and -i if unknown:
  -s, --kernel-name        print the kernel name
  -n, --nodename           print the network node hostname
  -r, --kernel-release     print the kernel release
  -v, --kernel-version     print the kernel version
  -m, --machine            print the machine hardware name
  -p, --processor          print the processor type (non-portable)
  -i, --hardware-platform  print the hardware platform (non-portable)
  -o, --operating-system   print the operating system
      --help     display this help and exit
      --version  output version information and exit

modified Makefile with pull request #444

merged into milestone 0.4.0

repo: emccode/rexray


text:
Feed RSS per categoria e per regione

È utile usare questi template:
https://github.com/snaptortoise/jekyll-rss-feeds

ok. segnalo che qui si stava lavorando sulle fake news non so se può essere roba che serve. #197

authors: iltempe mfortini

license: MIT


text:
minSdkVersion=15

Is there any reason you set the minSdkVersion to 15? I think you can lower it at least to 11.
Arno

Hi the only reason it's 15 is because I personally only target 15/16 or above now,  there is probably no reason why it can't go lower, probably wouldn't want to get in to 2.x however. If you try it and it works on 11 I'll lower it. Thanks.

Just tested it on API 10 (emulator), works just fine!

authors: apuder de-Stan emileb

repo: emileb/DragSortRecycler


text:
Gradle 8 Issue

Summary
Not able to build flutter app, getting error below
PS C:\Users\pranay\Documents\flutter_projects\first_app\android> .\gradlew build --warning-mode all

> Configure project :rtmp_broadcaster
Build file 'C:\Users\pranay\AppData\Local\Pub\Cache\hosted\pub.dev\rtmp_broadcaster-2.2.6\android\build.gradle': line 8
The RepositoryHandler.jcenter() method has been deprecated. This is scheduled to be removed in Gradle 9.0. JFrog announced JCenter's sunset in February 2021. Use mavenCentral() instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.3/userguide/upgrading_version_6.html#jcenter_deprecation
        at build_c79sxsk4oi5vashz9wbmot3hd$_run_closure1$_closure2.doCall(C:\Users\pranay\AppData\Local\Pub\Cache\hosted\pub.dev\rtmp_broadcaster-2.2.6\android\build.gradle:8)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)
        at build_c79sxsk4oi5vashz9wbmot3hd$_run_closure1.doCall(C:\Users\pranay\AppData\Local\Pub\Cache\hosted\pub.dev\rtmp_broadcaster-2.2.6\android\build.gradle:6)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)
Build file 'C:\Users\pranay\AppData\Local\Pub\Cache\hosted\pub.dev\rtmp_broadcaster-2.2.6\android\build.gradle': line 20
The RepositoryHandler.jcenter() method has been deprecated. This is scheduled to be removed in Gradle 9.0. JFrog announced JCenter's sunset in February 2021. Use mavenCentral() instead. Consult the upgrading guide for further information: https://docs.gradle.org/8.3/userguide/upgrading_version_6.html#jcenter_deprecation
        at build_c79sxsk4oi5vashz9wbmot3hd$_run_closure1$_closure4.doCall(C:\Users\pranay\AppData\Local\Pub\Cache\hosted\pub.dev\rtmp_broadcaster-2.2.6\android\build.gradle:20)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)
        at build_c79sxsk4oi5vashz9wbmot3hd$_run_closure1.doCall(C:\Users\pranay\AppData\Local\Pub\Cache\hosted\pub.dev\rtmp_broadcaster-2.2.6\android\build.gradle:18)
        (Run with --stacktrace to get the full stack trace of this deprecation warning.)

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':rtmp_broadcaster'.
> Could not create an instance of type com.android.build.api.variant.impl.LibraryVariantBuilderImpl.
   > Namespace not specified. Specify a namespace in the module's build file. See https://d.android.com/r/tools/upgrade-assistant/set-namespace for information about setting the namespace.

     If you've specified the package attribute in the source AndroidManifest.xml, you can use the AGP Upgrade Assistant to migrate to the namespace value in the build file. Refer to https://d.android.com/r/tools/upgrade-assistant/agp-upgrade-assistant for general information about using the AGP Upgrade Assistant.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

BUILD FAILED in 2s
4 actionable tasks: 4 up-to-date

i have made a pr (#27) collecting all fixes needed for gradle 8 support.
would you mind trying it out and reporting any remaining problems?
pubspec.yaml
  rtmp_broadcaster:
    git: https://github.com/OlJohnny/flutter_rtmp_broadcaster.git

i have made a pr (#27) collecting all fixes needed for gradle 8 support. would you mind trying it out and reporting any remaining problems?
pubspec.yaml
rtmp_broadcaster:
git: https://github.com/OlJohnny/flutter_rtmp_broadcaster.git

Thanks @OlJohnny this fixed my problem, please approve this PR @emiliodallatorre

authors: OlJohnny PranayPant responilla07


text:
Sample solution

WIP

I pulled this in and merged it by hand. Thankyou!

authors: Neppord emilybache

repo: emilybache/VendingMachine-Approval-Kata


text:
Fix add pledges button

Fix add pledges button to display the add pledges fields (cough you had one job, @unkrich )

That's one more job than you :O

ahem https://github.com/emilyengle/hackathon-portal/graphs/contributors

Perks of Kyle using your computer

@unkrich that's so nice of you!

@kylekthompson @emilyengle just saw that... regardless the problem seems to be a result of jQuery and turbolinks conflicts - didn't figure out resolution though

authors: emilyengle kylekthompson unkrich

repo: emilyengle/hackathon-portal


text:
Datadog APM not working

Describe the bug
followed the documentation here to configure datadog but do not see traces coming in from Emissary-Ingress.  traces are going fine via datadog agent
To Reproduce
Steps to reproduce the behavior:

implement datadog tracing as mentioned here
can not see emissary-ingress in datadog APM

Expected behavior
service traces are coming in and see it in Dadadog APM
Versions (please complete the following information):

Ambassador: emissary:3.9.1
Kubernetes environment: EKS
Version: 1.29

Additional context
Configuring Envoy JSON logging in values.yaml via HELM

Tracing service
apiVersion: getambassador.io/v3alpha1
kind: TracingService
metadata:
  name: tracing
  namespace: api-emissary
spec:
  service: "${HOST_IP}:8126"
  driver: datadog
  config:
    service_name: api-ambassador-ingress

Host IP configuration

@danopia - thank you very much for looking into it. you guessed it right AMBASSADOR_ID is the missing link. i added it to tracing service and ambassador appears in DD APM. once again thank you very much.

repo: emissary-ingress/emissary


text:
Update for Elantra on Hyundai-Dev Branch

Latest Elantra values that correlate to progress Community branch.

.

repo: emmertex/openpilot


text:
Write contributing documentation

How does one contribute to EMMO-Python? What are the code style guidelines? What is the design philosophy? How are contributors mentioned and acknowledged?

Parts of this has been started under the "Developers" section of the documentation.

repo: emmo-repo/EMMO-python


text:
Remove or rename "old" version tags

The old version tags (when this repo was EMMO-Python and just called the emmo package once installed) are interfering a bit with the changelog generation.
I think we have accommodated these tags for long enough that I don't see a reason why we should keep them around.
As an alternative, we can prepend them with old- or emmo-python- or something like this?

I think pre-pending with old could work.

I agree with just deleting them. There is not reason to keep old things hanging around which do not have any value for anyone. I will proceed with removing all "1.0...." releases and tags

Deleted old tags and releases that were done when the package was called EMMO-Python. No-one is using these old tags and I see no reason to pollute the internet with them.

authors: CasperWA francescalb

repo: emmo-repo/EMMOntoPy


text:
Open/Close code block syntax proposal

✏ Proposed change
Changing 🍇  to 📖  (open book)
Changing 🍉  to 📕  (closed book)
🤔 Rationale
You open a book to read it. When you're done reading it you close the book. Same rationale behind open/close brackets but with book emojis.
Pro: No more seemingly random grapes and watermelons everywhere.
Con: No more seemingly random grapes and watermelons everywhere.
🕺Example
🏁 📖
👴 I am reading a block. A code block.
📕

See the section: https://github.com/emojicode/emojicode/issues/67#issuecomment-324435285

What about using 👉 and 👈, or 👇 and 👆?
This would match the parenthesis from #79.
And I hope they are not already in use in an standard package 🙈

👉 and 👈 are the left and right shift operators.  👇 and 👆 could be used.
🏁 ➡ 🚂 👇
  🔂 a 🆕⏩⏩❕0 2❗ 👇
    🍮 b a
  👆
👆

Visually, they nicely frame the enclosed statements. As far as the meaning of pointing hands is concerned, I can't see any connotation, though. But basically it looks very are nice.

The block syntax is not going to be changed unless someone has an indisputably great idea.
🍇🍉 are some of the oldest and most iconic parts of Emojicode, with the Emojicode brand colors even inspired by it.

authors: Fasian1 idmean lacinoire thbwd

repo: emojicode/emojicode


text:
Deleting playlist entries from the bottom of the list crashes player

When you select the last entry in a playlist and hit the delete button two times, the player crashes.

Ouch! Will need to look at this one for sure

This seems to happen when you:

Select the last entry and delete it
Press delete again (without selecting a new entry in the list)

Either fix should be that:

The next last entry should be auto selected when the previous was deleted
No deletion will be possible as no entry has been selected.

Callstack
error: libplaylist.so :: Class 'PlaylistView' has a base class 'QObject' which does not have a complete definition.
* thread #1, name = 'hippo_player', stop reason = signal SIGABRT
  * frame #0: 0x00007ffff5932f47 libc.so.6`__GI_raise(sig=2) at raise.c:51
    frame #1: 0x00007ffff59348b1 libc.so.6`__GI_abort at abort.c:79
    frame #2: 0x00007ffff0e0bd77 libhippo_core.so`std::sys::unix::abort_internal::ha13827a9080e2771 at mod.rs:165
    frame #3: 0x00007ffff0dfa3b5 libhippo_core.so`std::sys_common::util::abort::hd5899ff219d6bf54 at util.rs:20
    frame #4: 0x00007ffff0dfc18e libhippo_core.so`rust_panic at panicking.rs:526
    frame #5: 0x00007ffff0dfc05d libhippo_core.so`std::panicking::rust_panic_with_hook::h4280c0e24899f0dd at panicking.rs:494
    frame #6: 0x00007ffff0dfbb20 libhippo_core.so`rust_begin_unwind at panicking.rs:380
    frame #7: 0x00007ffff0e293b1 libhippo_core.so`core::panicking::panic_fmt::hd08789ca336a1e3e at panicking.rs:85
    frame #8: 0x00007ffff0e292fd libhippo_core.so`core::panicking::panic::hc5a93ec0fbeaade1 at panicking.rs:52
    frame #9: 0x00007ffff079fa60 libhippo_core.so`alloc::vec::Vec$LT$T$GT$::remove::he1a459d74c871370(self=0x0000555555828038, index=1232) at <::core::macros::panic macros>:2
    frame #10: 0x00007ffff078f2f5 libhippo_core.so`hippo_core::playlist::Playlist::remove_entry::h0f1c109336507759(self=0x0000555555828038, entry=1232) at playlist.rs:363
    frame #11: 0x00007ffff07323fc libhippo_core.so`hippo_playlist_remove_entry(core=0x0000555555827f00, entry=1232) at lib.rs:370
    frame #12: 0x000055555556c264 hippo_player`PlaylistModel::removeRows(this=0x000055555590c550, row=1232, count=1, (null)=0x00007fffffffd050) at PlaylistModel.cpp:343
    frame #13: 0x00007fffeda76b19 libplaylist.so`PlaylistView::delete_items(this=0x00005555559adec0) at playlist.cpp:188
    frame #14: 0x00007fffeda7a7c2 libplaylist.so`QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (PlaylistView::*)()>::call(f=3a 6a a7 ed ff 7f 00 00 00 00 00 00 00 00 00 00, o=0x00005555559adec0, arg=0x00007fffffffd1b0)(), PlaylistView*, void**) at qobjectdefs_impl.h:152
    frame #15: 0x00007fffeda7a60f libplaylist.so`void QtPrivate::FunctionPointer<void (PlaylistView::*)()>::call<QtPrivate::List<>, void>(f=3a 6a a7 ed ff 7f 00 00 00 00 00 00 00 00 00 00, o=0x00005555559adec0, arg=0x00007fffffffd1b0)(), PlaylistView*, void**) at qobjectdefs_impl.h:185
    frame #16: 0x00007fffeda7a485 libplaylist.so`QtPrivate::QSlotObject<void (PlaylistView::*)(), QtPrivate::List<>, void>::impl(which=1, this_=0x0000555555999650, r=0x00005555559adec0, a=0x00007fffffffd1b0, ret=0x0000000000000000) at qobjectdefs_impl.h:414
    frame #17: 0x00007ffff67542a0 libQt5Core.so.5`void doActivate<false>(QObject*, int, void**) [inlined] QtPrivate::QSlotObjectBase::call(a=<unavailable>, r=<unavailable>, this=<unavailable>) at qobjectdefs_impl.h:394
    frame #18: 0x00007ffff6754283 libQt5Core.so.5`void doActivate<false>(sender=0x00005555559b5700, signal_index=7, argv=0x00007fffffffd1b0) at qobject.cpp:3870
    frame #19: 0x00007ffff77c51e7 libQt5Widgets.so.5`QAbstractButtonPrivate::emitPressed(this=0x00005555559b0550) at qabstractbutton.cpp:429
    frame #20: 0x00007ffff77c5860 libQt5Widgets.so.5`QAbstractButton::mousePressEvent(this=0x00005555559b5700, e=0x00007fffffffd670) at qabstractbutton.cpp:984
    frame #21: 0x00007ffff7718f91 libQt5Widgets.so.5`QWidget::event(this=0x00005555559b5700, event=0x00007fffffffd670) at qwidget.cpp:8653
    frame #22: 0x00007ffff76d99fc libQt5Widgets.so.5`QApplicationPrivate::notify_helper(this=<unavailable>, receiver=0x00005555559b5700, e=0x00007fffffffd670) at qapplication.cpp:3684
    frame #23: 0x00007ffff76e15e8 libQt5Widgets.so.5`QApplication::notify(this=<unavailable>, receiver=0x00005555559b5700, e=0x00007fffffffd670) at qapplication.cpp:3128
    frame #24: 0x00007ffff671d8f8 libQt5Core.so.5`QCoreApplication::notifyInternal2(receiver=0x00005555559b5700, event=0x00007fffffffd670) at qcoreapplication.cpp:1092
    frame #25: 0x00007ffff76dfeca libQt5Widgets.so.5`QApplicationPrivate::sendMouseEvent(receiver=0x00005555559b5700, event=0x00007fffffffd670, alienWidget=0x00005555559b5700, nativeWidget=0x00007fffffffde60, buttonDown=<unavailable>, lastMouseReceiver=0x00007ffff7dd4a40, spontaneous=true, onlyDispatchEnterLeave=false) at qapplication.cpp:2614
    frame #26: 0x00007ffff7731cb1 libQt5Widgets.so.5`QWidgetWindow::handleMouseEvent(this=0x0000555555986b90, event=0x00007fffffffda50) at qwidgetwindow.cpp:674
    frame #27: 0x00007ffff77348fb libQt5Widgets.so.5`QWidgetWindow::event(this=0x0000555555986b90, event=0x00007fffffffda50) at qwidgetwindow.cpp:295
    frame #28: 0x00007ffff76d99fc libQt5Widgets.so.5`QApplicationPrivate::notify_helper(this=<unavailable>, receiver=0x0000555555986b90, e=0x00007fffffffda50) at qapplication.cpp:3684
    frame #29: 0x00007ffff76e0980 libQt5Widgets.so.5`QApplication::notify(this=0x00007fffffffde40, receiver=<unavailable>, e=0x00007fffffffda50) at qapplication.cpp:3430
    frame #30: 0x00007ffff671d8f8 libQt5Core.so.5`QCoreApplication::notifyInternal2(receiver=0x0000555555986b90, event=0x00007fffffffda50) at qcoreapplication.cpp:1092
    frame #31: 0x00007ffff6dcefc8 libQt5Gui.so.5`QGuiApplicationPrivate::processMouseEvent(e=0x0000555556491950) at qguiapplication.cpp:2209
    frame #32: 0x00007ffff6dd04a5 libQt5Gui.so.5`QGuiApplicationPrivate::processWindowSystemEvent(e=<unavailable>) at qguiapplication.cpp:1941
    frame #33: 0x00007ffff6dace3b libQt5Gui.so.5`QWindowSystemInterface::sendWindowSystemEvents(flags=<unavailable>) at qwindowsysteminterface.cpp:1163
    frame #34: 0x00007fffd907d08a libQt5XcbQpa.so.5`::xcbSourceDispatch(source=<unavailable>, (null)=<unavailable>, (null)=<unavailable>) at qxcbeventdispatcher.cpp:105
    frame #35: 0x00007ffff278d417 libglib-2.0.so.0`g_main_context_dispatch + 743
    frame #36: 0x00007ffff278d650 libglib-2.0.so.0`___lldb_unnamed_symbol192$$libglib-2.0.so.0 + 512
    frame #37: 0x00007ffff278d6dc libglib-2.0.so.0`g_main_context_iteration + 44
    frame #38: 0x00007ffff67763ec libQt5Core.so.5`QEventDispatcherGlib::processEvents(this=0x00005555558de4a0, flags=<unavailable>) at qeventdispatcher_glib.cpp:423
    frame #39: 0x00007ffff671c312 libQt5Core.so.5`QEventLoop::exec(this=0x00007fffffffddd0, flags=<unavailable>) at qeventloop.cpp:225
    frame #40: 0x00007ffff6725240 libQt5Core.so.5`QCoreApplication::exec() at qcoreapplication.cpp:1400
    frame #41: 0x000055555556ed65 hippo_player`main(argc=1, argv=0x00007fffffffdfd8) at hippo_main.cpp:53
    frame #42: 0x00007ffff5915b97 libc.so.6`__libc_start_main(main=(hippo_player`main at hippo_main.cpp:16), argc=1, argv=0x00007fffffffdfd8, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffdfc8) at libc-start.c:310
    frame #43: 0x000055555556199a hippo_player`_start + 42

authors: emoon knochenhans

repo: emoon/HippoPlayer


text:
Resolution Scale Above 100%

About a month ago, PureDark made DLSS mod for GTA V. It allows resolution scale to be increased up to 200%, essentially achieving DLDSR results without the extra steps.
I haven't managed to get DLSSTweaks to work well/at all with resolutions above native. Could this be investigated and made a potential feature?
As a side note, I haven't tried that mod so I cannot confirm myself whether or not the scale is controlled purely by DLSS or of it is some other shenanigans.

GTA V. It allows resolution scale to be increased up to 200%,

GTA supports this natively with Frame Scalling mode in game advanced settings.

GTA V. It allows resolution scale to be increased up to 200%,

GTA supports this natively with Frame Scalling mode in game advanced settings since it released.

Yes, but I would like to see something similar with DLSSTweaks for any DLSS enabled game.

repo: emoose/DLSSTweaks


text:
TODO: Add cluster feature when scale the docker image under stack or service

[x] EMQ configured by docker ENV settings
[x] Plugins load by docker ENV settings
[x] Plugins configured by docker ENV settings
[ ] Service discovery under stack or service(e.g. docker-compose case)
[ ] Cluster feature when change scale container number up, automatically join cluster
[ ]  Automatically leave cluster when scale down container number

I have a somewhat working setup for items 3-5.
3.- preprocessing of the configuration files through python / regex to generate go-lang text template files which then I process at startup using gucci. Variable names get mapped by ENV files by translating them, dots get replated by __ and the whole thing get's uppercased and default values are set to whatever was originally on the config file.
4-5.- there's a "special" env var which should be set to the service name, then basically nslookup to get all the IPs (does require that the service's endpoint mode is set to dnsrr when on swarm), and a while trying to cluster join.
I'm tidying up the thing anyways, so I could fork the repo on github if you're interested.

Hi, thanks your  for your efforts to make clustering.
I noticed that you use nslookup to get all the IPs, but I found a problem that nslookup depends on busybox under alpine, it only support UDP method to get IP list. So it only can get 14 IPs at most. When swarm mode scale node number above 14, the IP will change every time and incomplete. This is because alpine's busybox use resolv unit to do dns query, but resolv under uclibc only support UDP method that the buffer only NS_PACKETSZ=512bytes. every where NS_PACKETSZ is 512
I used to use UDP to discovery service(at my old docker image https://github.com/devicexx/docker-images/blob/master/library/emqttd/latest/default/start.sh) but it not stable when run opt/emqttd/bin/emqttd_ctl cluster join 'emqttd@'${REMOTE_IP}  many times, without success when node above 3. Then I tried method such like you use, using DNS to do service discovery.
I think your script can be optimized, do not use busybox's nslook up under apline due to 14 IPs limit, you can try install bind-tools by apk add --no-cache bind-tools and use nslookup which bind-tools provides, that is no problem. The easiest way is using ubuntu and ubuntu have no IP limits in nslookup(It's depends on glibc).
I'm also learning and studing how to make emq-cluster stable, when I success I'll open source it.
Thank you again and very glad to talking with you, I looking forwards to discussion cluster problem again.

@vowstar
Please have a look at the EMQ 2.3 beta. It adds cluster autodiscovery. You might also find my comment to a similar issue useful: https://github.com/emqtt/emq-docker/issues/13#issuecomment-318831416

@vivobg OK, thanks

authors: je-al vivobg vowstar

repo: emqtt/emq-docker


text:
How to empty the queue?

Hi, i have a question of the behavior of my EMQ cluster (version 2.3.7).
Iam running 3 docker containers on 3 hosts as a cluster.
I have set the MAX_INFLIGHT=10000 and have a persistent session.
Then sending off a large amount of data to a topic and it looks like the max in flight window is getting full. So that means the queue starts filling up. But when i stop the data stream i would suspect the queue to be emptied right? Is there a configuration fault or something i am missing in my setup?
Also would someone explain to me what MqueueDropped means and how to avoid this?
And what MqueueLen means exactly?

What i noticed is that when i have the subscriber offline and send some data to the topic and then get the subscriber online again. He will get the enqueued messages directly. But the queue is not getting reset to 0.
So it looks like the queue is still full. Maybe its just a stats page problem?

BTW i updated to 2.3.9

repo: emqtt/emqttd


text:
bcrypt missing number of passes

Hi, I noticed that there is no way to configure number of passes when you use bcrypt hashing, from checking the code I noticed that default is 12, but it would be good to be able to adjust this from security perspective.

Duplicate to https://github.com/emqx/emqx-passwd/issues/1

Hi Josip,
The "number of passes" is contained on the salt. For example, salt "$2a$06$eHX8EKlD8G.A/4/hqnN8Du", the second $06 means the "number of passes" is 6.
Emqx does not generate the salt for you. It is created by the user so that the user can configure the preferred "number of passes". To provide the salt when using emqx-auth-redis, please set the salt for your mqtt users in Redis. Emqx will just read the salt info from redis.
HMSET mqtt_user:<username> password "hashedPassword" salt "salt"

Thank you for your participation, we will close this issue.

authors: kotky ngjaying turtleDeng

repo: emqx/emqx-auth-redis


text:
FORTECH-38: Update styles for CheckboxItem

Feature Added
Updated styles for Agate CheckboxItem component.
Comments
Updated Agate Checkbox component styling according to zeplin design. Added unit tests.
Enact-DCO-1.0-Signed-off-by: Stanca Pop stanca.pop@lgepartner.com

Checklist

[x] Pass - npm run test-ui
[x] Pass  - npm run parse( Known parse errors: ThumbnailItem, useChainRefs )
[x] Pass - npm run test-ss ( for more information about how to run, please check my comment - https://github.com/enactjs/agate/pull/274#issuecomment-646705673 )

authors: stanca-pop-lgp ybsung

repo: enactjs/agate


text:
Set new state only when it's needed.

Checklist

[x] I have read and understand the contribution guide

[ ] A CHANGELOG entry is included

[ ] At least one test case is included for this feature or bug fix

[ ] Documentation was added or is not needed

[ ] This is an API breaking change

Issue Resolved / Feature Added
Issue: Scrollbar buttons update for every animation frame/ scroll and this takes about 30-50 milliseconds.
Resolution
This update will remove unnecessary Scrollbar buttons updates.

To clarify, the proposed fix attempts to avoid the call to setState when we expect the result wouldn't be a change of state. Is that accurate, @haileyR? Is this a case where we think that calling setState at all -- even when the updater callback returns null/undefined is causing a performance impact?

authors: haileyR ryanjduffy

repo: enactjs/enact


text:
Publish 1.0.7 to npm

Any chance we could get 1.0.7 onto npm?

1.0.8 is now on npm. Thanks!

repo: encharm/xcase


text:
BLE disconnects after a short period of time

I've noticed that BLE connections are terminated after a less than a minute. It's not due to the connecting device because it happens both with nRF Connect and BlueZ + gatt-cts-server.py.
The debug log displays this warning: bt_att: Ignoring unexpected request.

After searching for the warning message, I found something interesting in this Zephyr issue:
https://github.com/zephyrproject-rtos/zephyr/issues/15714
This setting appears to do the trick:
CONFIG_BT_ATT_ENFORCE_FLOW=n
https://docs.zephyrproject.org/2.3.0/reference/kconfig/CONFIG_BT_ATT_ENFORCE_FLOW.html

repo: endian-albin/pinetime-hypnos


text:
Release v0.2

Release v0.2

The app's information shows release 0.2:

repo: endlessm/endless-key-flatpak


text:
Azure Kubernetes Services 1.28 & 1.29 EOL dates are not correct

Product Page: https://endoflife.date/azure-kubernetes-service
endoflife.date for AKS 1.28: 2024-Nov-30
Product documentation for AKS 1.28: 15 Jan 2025
endoflife.date for AKS 1.29: 2025-Jan-31
Product documentation for AKS 1.29: 31 Mar 2025
Source website: https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions?tabs=azure-cli#aks-kubernetes-release-calendar
Additional context
This is a great resource, thank you for maintaining it.

Filed a PR for this. Can you review https://deploy-preview-6230--endoflife-date.netlify.app/azure-kubernetes-service and confirm it looks good? I've made slight changes to the content as well, explaining Platform Support.
Small PRs for changes like these are very much appreciated.


text:
Add MySQL 8.3

See https://dev.mysql.com/doc/relnotes/mysql/8.3/en/news-8-3-0.html.

@big-dream, thanks a lot for this contribution. 8.0.36 was automatically updated after https://github.com/mysql/mysql-server/releases/tag/mysql-8.0.36 was caught by our automation, so reverted this change.

authors: big-dream marcwrobel


text:
Add HTTPie and Pillow package to awesome packages list

Pillow and HTTPie

Thanks for this contribution!

authors: endormi xqsz

repo: endormi/django


text:
⚠ Tukarcoid has degraded performance

In 2112d47, Tukarcoid (https://tukar.co.id) experienced degraded performance:

HTTP code: 200
Response time: 2580 ms

Resolved: Tukarcoid performance has improved in d424a25 after 7 minutes.

repo: endosulistio/tukarcoid-status


text:
Hexagonal grid support?

I can't find any mention of hexagonal grid support. Does this support hexagon grids?

No, only orthographic square tile grids are currently supported.
I'm open to PRs though :)

authors: englercj eranimo

repo: englercj/gl-tiled


text:
Wrong handling of 'undocumented' attributes with jsdoc 3.6.x

As noticed by jsdoc#1672, jsdoc 3.6.x output differs from 3.5.x, especially on undocumented attributes strangely set to true while the comment attribute is correctly set with some user comment.
The effect for tsd-jsdoc is that such doclets are not managed anymore.
Steps to reproduce :

checkout tsd-jsdoc, run npm install but then force the installation of jsdoc with version 3.6.3.
npm run build
npm run test => failure

Yeah there are a bunch of backwards incompatible changes to jsdoc 3.6. I really wish they had done a major release.
I think in this lib we need to update to work with 3.6, and change how we determine exports (a la #100), then do a major release on our side.

I've just committed a sample of code to fix this problem.
See changes on publish.ts in PR#98.

authors: Alexis-ROYER englercj

repo: englercj/tsd-jsdoc


text:
Run_algorithm ends at 23:59 no matter the specified value

Dear Catalyst Maintainers,
Before I tell you about my issue, let me describe my environment:
Environment

Operating System: mac os 10.13.3
Python Version: 2.7.13
Python Bitness: 64
How did you install Catalyst: conda
Python packages:

alembic==0.9.6
appnope==0.1.0
backports-abc==0.5
backports.functools-lru-cache==1.4
backports.shutil-get-terminal-size==1.0.0
bcolz==0.12.1
bleach==2.1.2
boto3==1.5.27
botocore==1.8.41
Bottleneck==1.2.1
ccxt==1.10.1049
certifi==2016.2.28
chardet==3.0.4
click==6.7
configparser==3.5.0
contextlib2==0.5.5
cycler==0.10.0
cyordereddict==1.0.0
Cython==0.27.1
cytoolz==0.9.0
decorator==4.1.2
docutils==0.14
empyrical==0.2.1
enigma-catalyst==0.5.3
entrypoints==0.2.3
enum34==1.1.6
eth-abi==0.5.0
eth-keyfile==0.5.1
eth-keys==0.1.0b4
eth-utils==0.7.4
functools32==3.2.3.post2
futures==3.2.0
html5lib==1.0.1
idna==2.6
intervaltree==2.1.0
ipykernel==4.8.2
ipython==5.5.0
ipython-genutils==0.2.0
ipywidgets==7.1.2
Jinja2==2.10
jmespath==0.9.3
jsonschema==2.6.0
jupyter==1.0.0
jupyter-client==5.2.2
jupyter-console==5.2.0
jupyter-core==4.4.0
Logbook==1.1.0
lru-dict==1.1.6
Mako==1.0.7
MarkupSafe==1.0
matplotlib==2.1.0
mistune==0.8.3
multipledispatch==0.4.9
nbconvert==5.3.1
nbformat==4.4.0
networkx==2.0
notebook==5.4.0
numexpr==2.6.4
numpy==1.13.1
pandas==0.19.2
pandas-datareader==0.5.0
pandocfilters==1.4.2
pathlib2==2.3.0
patsy==0.4.1
pexpect==4.4.0
pickleshare==0.7.4
prompt-toolkit==1.0.15
ptyprocess==0.5.2
pycryptodome==3.4.11
Pygments==2.2.0
pyparsing==2.2.0
pysha3==1.0.2
python-dateutil==2.6.1
python-editor==1.0.3
pytz==2017.2
pyzmq==17.0.0
qtconsole==4.3.1
redo==1.6
requests==2.18.4
requests-file==1.4.2
requests-ftp==0.3.1
requests-toolbelt==0.8.0
rlp==0.6.0
s3transfer==0.1.12
scandir==1.7
scikit-learn==0.18.1
scipy==0.19.1
Send2Trash==1.5.0
simplegeneric==0.8.1
singledispatch==3.4.0.3
six==1.11.0
sortedcontainers==1.5.7
SQLAlchemy==1.1.14
statsmodels==0.8.0
subprocess32==3.2.7
swagger-client==1.0.0
TA-Lib==0.4.16
tables==3.4.2
terminado==0.8.1
testpath==0.3.1
toolz==0.8.2
tornado==4.5.3
traitlets==4.3.2
typing==3.6.4
urllib3==1.22
wcwidth==0.1.7
web3==4.0.0b7
webencodings==0.5.1
widgetsnbextension==3.1.4

Now that you know a little about me, let me tell you about the issue I am
having:
Description of Issue
Hi, running the algorithm with the following parameters
run_algorithm(
               capital_base=1000,
               data_frequency='minute',
               initialize=initialize,
               handle_data=handle_data,
               analyze=analyze,
               exchange_name='poloniex',
               algo_namespace=NAMESPACE,
               base_currency='btc',
               start=pd.to_datetime('2018-1-1', utc=True),
              end=pd.to_datetime('2018-1-4  08:00:00', utc=True),
           )

results in the last close date beeing  “2018-1-4 23:59:00” and not  “2018-1-4 07:59:00” as expected
What steps have you taken to resolve this already?
none
Anything else?
nope
Sincerely,

Hi @greghor is this fix something that is urgent for you? after looking into this, we decided to postpone the fix to a future release as it is a larger task than we thought it is and it seems to be less of an issue as long as the desired dates are within the window which is received at the end.
I added a warning that will be posted to whoever is trying to get a window within specific times such as this example.

Hi @AvishaiW, this fix is not that urgent for me since it doesn't crash strategies, it it more a matter of saving times when running many simulations.

how to solution the problem?

authors: AvishaiW greghor tanjhysj0

repo: enigmampc/catalyst


text:
feat(client): Async iterator for subscriptions

The iterate method on the client allows async iteration over the subscription events.
import { createClient } from 'graphql-sse';

const client = createClient({
  // singleConnection: true, preferred for HTTP/1 enabled servers and subscription heavy apps
  url: 'http://localhost:4000/graphql/stream',
});

// query
(async () => {
  const query = client.iterate({
    query: '{ hello }',
  });

  const { value } = await query.next();
  expect(value).toEqual({ hello: 'world' });
})();

// subscription
(async () => {
  const subscription = client.iterate({
    query: 'subscription { greetings }',
  });

  for await (const event of subscription) {
    expect(event).toEqual({ greetings: 'Hi' });

    // complete a running subscription by breaking the iterator loop
    break;
  }
})();

TODO

[ ] ~Overload subscribe method~ https://github.com/microsoft/TypeScript/issues/54354

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: enisdenjo/graphql-sse


text:
Unable to randomize choices with randomize=true

Describe the bug
Choices cannot be randomized with the parameter randomize=true.
To Reproduce
survey

type
name
label
parameters

select_one numbers
num
Number
randomize=true

choices

list_name
name
label

numbers
1
One

numbers
2
Two

numbers
3
Three

numbers
4
Four

numbers
5
Five

Result:

Expected behavior
Same behaviour as Collect: choices are randomized.

Additional context
Report in KoBo community forum: https://community.kobotoolbox.org/t/seed-and-randomize-whats-that-preventing-to-deploy-my-form/4739/12

You’re running the latest version with https://github.com/enketo/enketo-core/pull/822?

Aha, we're not — still on 2.8.1 👌

authors: joshuaberetta lognaturel

repo: enketo/enketo-core


text:
🛑 Tactsolutionslk is down

In 422f34d, Tactsolutionslk (https://tactsolutionslk.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Tactsolutionslk is back up in 1c09087 after 1 hour, 31 minutes.

repo: enlivenonedrive/upptime


text:
Dev databinding newsapi

change binding implementation of details fragment, style read more button, add a seperate method in viewmodel for visibility of list..

Thanks! :) I caught an error myself in the singleton instantiation. I didn't use double checked locking correctly. In fact the sample used in Udacity Android Architecture Components had this error so I learned it incorrectly. Anyway, I'll correct that tomorrow as well.
Thanks for reviewing!

Great work @OyaCanli  Keep it up :100:

authors: OyaCanli rajtheinnovator

repo: enpassio/Databinding


text:
Don't fork to download the jar, use the Download library from npm

Uses the download library already pulled in by the main ensime-atom package.
The download was failing in Windows which doesn't have chmod or curl installed by default (some may have it installed via cygwin or msysgit but natively it's not there).
This also feels more idiomatic of node.

Awesome! This was on my todo. Thanks alot!
Related:
https://github.com/ensime/ensime-atom/issues/210
You know if this issue is fixed by this PR?

It doesn't fix that issue. I took at look at how atom handles proxy and it looks like it relies on the request module instead of download. I'll try to adapt to their approach and submit a new PR in a bit.

Whoops, this actually blows upon load for me now. download uses got which uses create-error-class which uses eval that blows up:

Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".
Hide Stack Trace
EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'".
at createErrorClass (/Users/viktor/dev/projects/ensime-node/node_modules/create-error-class/index.js:18:49)
at Object. (/Users/viktor/dev/projects/ensime-node/node_modules/got/index.js:363:20)
at Module.contents.overrideModuleCompile.Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
at Object.keys.forEach.Object.defineProperty.value [as .js] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/Users/viktor/dev/projects/ensime-node/node_modules/download/index.js:9:11)
at Module.contents.overrideModuleCompile.Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
at Object.keys.forEach.Object.defineProperty.value [as .js] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/Users/viktor/dev/projects/ensime-node/lib/ensime-server-update-coursier.js:14:14)
at Object. (/Users/viktor/dev/projects/ensime-node/lib/ensime-server-update-coursier.js:85:4)
at Module.contents.overrideModuleCompile.Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
at Object.keys.forEach.Object.defineProperty.value [as .js] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/Users/viktor/dev/projects/ensime-node/lib/index.js:6:26)
at Module.contents.overrideModuleCompile.Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
at Object.keys.forEach.Object.defineProperty.value [as .js] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:50:27)
at Object. (/Users/viktor/dev/projects/atom-ensime/lib/ensime.coffee:7:16)
at Object. (/Users/viktor/dev/projects/atom-ensime/lib/ensime.coffee:1:1)
at Module.contents.overrideModuleCompile.Module._compile (/Applications/Atom.app/Contents/Resources/app.asar/src/native-compile-cache.js:103:30)
at Object.keys.forEach.Object.defineProperty.value [as .coffee] (/Applications/Atom.app/Contents/Resources/app.asar/src/compile-cache.js:208:21)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12

I think I have a super simple fix though… If I move the require to later it's run by a node thread… I'll open a ticket and report there…

authors: hedefalk jeckhart

repo: ensime/ensime-node


text:
File browse defaults to folder browse

https://github.com/enso-org/enso/assets/1720119/d621e7a3-4f43-4a55-a164-c3e4b8931ebb
Should be a file browse.
Also should the file browse be modal?

The same problem is on Linux:

I can click only folders here.

The issue is probably caused by weird Electron behavior. See the relevant code here: https://github.com/enso-org/enso/blob/c983d081d98c803d38bc5a32b0c17bc29fd27b9a/app/ide-desktop/lib/client/src/index.ts#L381
The documentation: https://www.electronjs.org/docs/latest/api/dialog#dialogshowopendialogbrowserwindow-options
Apparently we shouldn’t pass openDirectory property on Linux and Windows. I didn’t find any open issue in the Electron repo about it.

authors: AdRiley farmaazon vitvakatu

repo: enso-org/enso


text:
[do no merge or review] Testing

Pull Request Description
#10750
Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[ ] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[ ] All code follows the
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
[ ] Unit tests have been written where possible.

Of course, when I want to test the problem it suddenly disappears.


text:
Add COOP+COEP+CORP headers

Pull Request Description
Adds COOP+COEP+CORP headers. This is mainly required for high resolution timing (on Chrome, it increases performance.now resolution from 100us to 5us)
Important Notes
None
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

mini self QA:
:heavy_check_mark: self.crossOriginIsolated === true + 5ms resolution performance.now on npm run watch-dashboard
:heavy_check_mark: self.crossOriginIsolated === true + 5ms resolution performance.now on ./run gui watch
:heavy_check_mark: self.crossOriginIsolated === true + 5ms resolution performance.now on ./run ide watch
:heavy_check_mark: self.crossOriginIsolated === true + 5ms resolution performance.now on ./run ide build
:heavy_check_mark: google login still works on npm run watch-dashboard
:question: oauth still works on desktop IDE - i cannot test as i'm not on macos
issues, unrelated to this PR:
:x: github login works on npm run watch-dashboard - it fails with OAuth - Error handling auth response. Error: User+is+not+confirmed.+ at @aws-amplify/auth/src/OAuth/OAuth.ts:222 (handleAuthResponse)
:x: oauth works on gui watch - this is a known issue. the main issue is that localhost:8080 isn't a valid redirect url for cognito

I tested it and it does seem to not break anything. I did not test loging with the new dashboard as its not enabled and I don't know how to run it, but if it did not break login using Google, then it should not influence anything else.


text:
Improve compiler's diagnostic messages

Pull Request Description
Improve compiler's diagnostic messages. Inspired by gcc.
Important Notes
Example of messages:

Some of our diagnostics are multiline, and gcc does not have any multiline reports. For multiline diagnostics, there is no underline:

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[ ] The documentation has been updated, if necessary.
[ ] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[ ] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[ ] Unit tests have been written where possible.
[ ] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@JaroslavTulach Suggested that the reported file names should be navigable from our IDEs (NetBeans, VSCode, IJ, ...) with some kind of Ctrl + click shortcut.

Indeed, I think that maybe we should provide an absolute path? Or at least a bit more than just filename?
I know that technically we have the module path above the set of errors, but I always found it tedious to have to find the top one (if there are many errors it may be quite a few lines above) just to identify if that Table.enso comes from Database or Table. So having a full(er) path could be helpful IMO (although I'm slightly worried if we don't make the output too noisy).

After the latest update, the format of diagnostics is 100% aligned with the output from GCC. Some examples:

authors: Akirathan radeusgd


text:
Keep order of Fields and Edges columns on indexes

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡
index.Edges("myEdge").Fields("myField")

should generate a different index than
index.Fields("myField").Edges("myEdge")

Motivation 🔦
The order of columns on index is relevant.
Currently Edges columns are always added after Fields columns and this prevents more specific optimizations.

Hey @petersondmg and thanks for suggesting this.
You can achieve this today by using edge fields. I added an example to our integration tests. Would you like to add it to our documentation?

repo: ent/ent


text:
updated quaconfig

I added functions and some docstrings to quaconfig at the request of Yonatan.
We probably need to merge it with Satya's work, but for now let's just update

Satya's work? meaning the qua config wrapper?

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@cac24e9). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #17   +/-   ##
=======================================
  Coverage        ?   74.91%
=======================================
  Files           ?        8
  Lines           ?      845
  Branches        ?        0
=======================================
  Hits            ?      633
  Misses          ?      212
  Partials        ?        0

Flag
Coverage Δ

unittests
74.91% <0.00%> (?)

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

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cac24e9...9d31bab. Read the comment docs.

@qguyk added some tests - still many more needed
@galwiner please see changes

authors: codecov-commenter galwiner liorella-qm

repo: entropy-lab/entropy-qpu


text:
filters: add resetIdleTimeout filter callback

Signed-off-by: Mike Schore mike.schore@gmail.com

Updated with rename and added issue here for tests: https://github.com/envoyproxy/envoy-mobile/issues/1584

repo: envoyproxy/envoy-mobile


text:
dns: disable dns refresh on network change

Description: disable while we fix https://github.com/envoyproxy/envoy-mobile/issues/1842

closing in favor of removing the assert: https://github.com/envoyproxy/envoy/pull/18301


text:
RFC: reorganize repo

I'm going to fill this in with an actual plan, but the rough goal is to do the following:
Move all statically registered components (filters, access loggers, stats, etc.) into an "extensions" directory. Under this directory we would have "experimental" and "stable." This would also more easily allow us to compile extensions in and out more easily.
The goal here is to be able to more clearly separate out extensions from core, and have discrete OWNERS for extensions.
cc @envoyproxy/maintainers

OK finally coming back to this. Here is what I concretely propose:
/source/extensions/<maturity_level>/access_loggers
/source/extensions/<maturity_level>/http_filters
/source/extensions/<maturity_level>/http_tracers
/source/extensions/<maturity_level>/listener_filters
/source/extensions/<maturity_level>/network_filters
/source/extensions/<maturity_level>/resolvers
/source/extensions/<maturity_level>/stat_sinks

where maturity level is either experimental or production.
where there is a parallel tree under /test.
where all config registration is colocated with the extensions.

The benefits of this approach are:

Allows us to start having OWNER files for extensions different from core maintainers.
Much easier to discover status of extensions.
Experimental extensions are marked as such.
Extension writers now have  single directory to look through to find the extensions to look for examples.

I considered having a different tree outside of /source and /test but I'm not sure it's really worth the extra effort of fixing all the resultant build issues that assume this is where code is.
@envoyproxy/maintainers any thoughts?

I like the overall plan. How do you propose dealing with filters that have libraries with mockable components? We've tended to use include/envoy and test/mock here, how do you envisage this mapping into the new filter space?

My thinking was to break this for extensions and just put abstract interfaces and mocks (if any) directly with the test code of the extension so that it is self contained. The one thing to think about is what if extensions end up having common code. We might need some type of common directory, allow extensions to refer to each other, or potentially require common code to go on "core" Envoy. Thoughts?

Is there anything special we want to do to make it globally easy to condition in/out individual filters from the build in the general OSS distribution based on this organization? What about avoiding taking certain external dependencies that are irrelevant (LuaJIT, I'm looking at you!)?

My thinking here is to work towards a place where every extension in the repo is governed by a bazel define that can turn it off. Thus, if no Lua filter is used, there doesn't need to be any Lua code. However, Lua already exposed the issue with common code. Does all Lua code go in extensions? Or just the filter parts?

I have a personal preference, which might not be universally shared, for shorter, more concise names where possible. Would a filters/listener, filters/network, etc. hierarchy make sense?

What do you mean exactly?
/source/extensions/<maturity_level>/access_loggers
/source/extensions/<maturity_level>/http_tracers
/source/extensions/<maturity_level>/filters/http
/source/extensions/<maturity_level>/filters/listener
/source/extensions/<maturity_level>/filters/network
/source/extensions/<maturity_level>/resolvers
/source/extensions/<maturity_level>/stat_sinks

? If so that sounds fine to me.

Things I don't love but have no good solution for - I feel like it's going to be harder/more-annoying to find code, and I dislike files moving around when we promote filters.  I don't see a good way around either so shrug
Mainly I have a bunch of questions :-)
Do we have definitions of what gets you over the bar to a production extension?   Significant time in production by a heavy user?  Active maintainer support?  Do things move back out of production if they end up abandonware?  I assume we're not lowering the bar for code / test for extensions directory but maybe we are if we allow a wider variety of OWNERS.   Do we ever remove extensions from experimental if they don't get promoted?  Maintenance cost is low if we don't extend APIs but if we have a policy anyone willing to own things can stick it in extensions, cost in subtle things like CI build time could end up being non-trivial.

My thinking here is to work towards a place where every extension in the repo is governed by a  bazel define that can turn it off. Thus, if no Lua filter is used, there doesn't need to be any Lua code. However, Lua already exposed the issue with common code. Does all Lua code go in extensions? Or just the filter parts?

One thing to keep in mind is the growth of the binary itself. Do we want to keep Envoy suitable for very tight, resource constrained environments? E.g. in tiny containers or embedded applications? If so, it might be a good idea to have a plan to avoid unchecked growth in binary size. The model I'm thinking of is something closer to how the Linux kernel deals with drivers, with its config files. There are sensible minimal defaults which you can then opt-in on various features from.
I realize that if folks really want to strip it down they can today and in the future (just by creating distinct BUILD files), but making this convenient would be nice and could be accomplished somewhat structurally (e.g. by avoiding Lua code leaking into common) while we work on this specific issue.

Things I don't love but have no good solution for - I feel like it's going to be harder/more-annoying to find code, and I dislike files moving around when we promote filters. I don't see a good way around either so shrug

We can just drop <maturity_level> from the directory structure if we don't think it would provide enough value and handle in docs? That would be fine with me.

Do we have definitions of what gets you over the bar to a production extension? Significant time in production by a heavy user? Active maintainer support? Do things move back out of production if they end up abandonware? I assume we're not lowering the bar for code / test for extensions directory but maybe we are if we allow a wider variety of OWNERS. Do we ever remove extensions from experimental if they don't get promoted? Maintenance cost is low if we don't extend APIs but if we have a policy anyone willing to own things can stick it in extensions, cost in subtle things like CI build time could end up being non-trivial.

I agree these are all good questions which I don't really have answers for. My suggestion would be to just iterate what we have today into a new directory structure, and then go from there. We can initially do nothing different other than directory structure. If we decide to drop maturity level from the directory structure entirely, some of this becomes moot.

One thing to keep in mind is the growth of the binary itself. Do we want to keep Envoy suitable for very tight, resource constrained environments? E.g. in tiny containers or embedded applications? If so, it might be a good idea to have a plan to avoid unchecked growth in binary size. The model I'm thinking of is something closer to how the Linux kernel deals with drivers, with its config files. There are sensible minimal defaults which you can then opt-in on various features from.

I agree. Basically, as I said above IMO every extension in the future should have a bazel define. Some can even default to disabled if we want. I think the best course of action is to get the extensions into the new directory layout, and then start to figure out a general way to handle these types of defines. I'm guessing we can have some common Skylark that can help us here.

Hi, I will try to play around with the proposal i.e. using the following pattern
/source/extensions/filters/http
/source/extensions/filters/network
...

and reflect that to the envoyproxy/envoy-filter-example, and will share the experience 😁

@dio thanks. FYI I'm planning on updating this issue this coming week with a final proposed plan.

@mattklein123 thanks for the heads up. I saw that as one of the agenda for the next community call. Cool!

Would this notion of "pluggable extensions" be extended to TransportSockets? (thinking about fd.io VPP integration, and could be applicable to SslTransportSocket?)

+1 on pluggable transport sockets

Yes definitely re: pluggable transport sockets. I will update the proposal to account for that also.

OK sorry for the radio silence here. The new proposal after chatting with various people is:

We will drop <maturity_level>. We can cover that via docs as needed. For now we will assume that anything in the core Envoy repo is sufficiently mature that it should be tested, adhere to standards, etc. In the future we might possible have some type of sandbox repo with additional extensions that are held to a lower standard.

There may still be a common directory inside extensions for code that is shared between extensions but is not used by core.

All config static registration will be colocated for easier inspection of how everything works.

Final directory layout:

/source/extensions/access_loggers
/source/extensions/http_tracers
/source/extensions/filters/http
/source/extensions/filters/listener
/source/extensions/filters/network
/source/extensions/resolvers
/source/extensions/stat_sinks
/source/extensions/transport_sockets

The general idea will be to allow every extension to have a bazel flag that can be used to disable compilation. This would allow for example easily not pulling in lightstep, OT, LuaJit, etc.

Any objections to this proposal? My plan is to get started on this once we release 1.6.0 early next week. I discussed offline with @jmarantz and he might also be interested in helping. I will coordinate with him.

@mattklein123 can you elaborate on (3)? Are you saying the factories for modules will still lives outside /source/extensions or are you only referring to the core factory code?

IMHO dropping maturity level from the dir structure is a good idea. Less churn. Could be handled by build time defines I guess. i.e. "give me all the mature extensions" with still having per extension granularity. I'm happy to help if there is a particular task you want to farm out.

@htuch re: (3) my intention is to remove https://github.com/envoyproxy/envoy/tree/master/source/server/config and colocate the static registration with each extension. I think this will be a very nice improvement for readability.
@alagalah I had the same idea about build tagging. I think we should explore this in the future.

+1 on colocating registration with the extension.

+1 on proposal so far, but we need to also figure out what happens with test code. @dio has done some example implementation of this layout in https://github.com/envoyproxy/envoy-filter-example/pull/43/files. There are two features there of interest:

Source and test code are not colocated (same as Envoy structure today).
We now have two subtrees that reflect the extensions hierarchy, test/extensions and test/integration/extensions. The structuring of the integration tests is the first time we've imposed structure there. This is a nice cleanup IMHO.

I think this could work, and reflects existing Envoy source/test split. We could have OWNERS in the parallel trees. Call this the "core Envoy structure for extensions".
An alternative would be to have root level extensions/filters/http/foo/source, extensions/filters/http/foo/test, extensions/filters/http/foo/test/integration,  etc. Call this "single root structure for extensions".
I think the single root structure has a nice property, where all code is colocated and under a single OWNERS. But, it's a weird inversion of the existing order.
I'm leaning towards existing structure as per https://github.com/envoyproxy/envoy-filter-example/pull/43, but I wanted to throw it out there that we should clarify the test structure and consider the alternatives before locking the structure in.

In general, I have a preference for a "single root," but my concern was that it was going to break too many things which assume the code is in //source and //test. So I was planning on doing the former. Yes the integration cleanup sounds good to me. If people feel very strongly about "single root" we can look into what it would take to make that happen.

FWIW I'm not averse to experimental / production, I really just didn't have a feel for what went there.
Most of the documented reasons for doing this were around the experimental / production split, with the last being around owners/reviewers.  For that last issue,  Would we have subdirectory-per-various filters and have  /source/extensions//http_filters/lua owned by lua-savvy people or do more of per-file syntax?
I'd love if as a part of this move or a close follow-up we could have build rules / tools to make opting in and out of individual pluggable components easier, to head dependency bloat before we get there :-)

I'm not hearing any strong argument for single root. @mattklein123 @alyssawilk @ggreenway can you folks all take a look at https://github.com/envoyproxy/envoy-filter-example/pull/43 and see if this matches what you envisage in the new layout? If so, we can merge that and we can move to applying this to the main repo.

Yes envoyproxy/envoy-filter-example#43 is essentially what I was planning on doing. I was planning on moving the echo filter first, since it's so simple. Probably on Friday. So perhaps I can do that and then we can look at that PR and envoyproxy/envoy-filter-example#43 together and then make a final call?

I have a mild preference for single root, with test code located near the thing it is testing, instead of a parallel directory structure for tests. But I don't feel at all strongly about it, so if everyone else is happy with this, I say go for it.

I think the encoder/decoder split makes sense for the example code, but are we planning the same split for non-example code?
I'm with Greg that I mildly prefer code and tests to be colocated (test code is easy to flag in build rules with testonly) but will go with what folks prefer.
Otherwise 'tis fine by me

I think the encoder/decoder split makes sense for the example code, but are we planning the same split for non-example code?

I wasn't planning on it.

I'm with Greg that I mildly prefer code and tests to be colocated (test code is easy to flag in build rules with testonly) but will go with what folks prefer.

I don't have a strong preference on this one way or the other. The main issue I see with colocating test code with source code is that we don't do it anywhere else, so it's a bit strange. One middle ground would be to do:
/source/extensions/...
/test/extensions/...

But just put the integration tests colocated with the unit tests. That seems fine to me and would reduce one aspect of the split? Thoughts?

Agree, if we wouldn't move the rest of the tests to be colocated it'd be sort of weird.   I figured if we were moving around 80% of the code it was worth discussing the other 20% but no need to make this larger than it is :-P
I prefer keeping unit tests and integration tests separate, since integration tests often cover more than one thing, so of the two choices I'd lean towards keeping things as they're done in this PR.

Yeah I think this more like 20% code movement, vs. the other way around. OK SGTM. I will do the echo PR on Friday.

@alyssawilk @jmillikin-stripe and I just had our regular sync with the Bazel team and we covered this topic. The best suggestion so far is to continue our approach of using --define, but to create custom bazel.rc files that get fed into the Bazel CLI invocation to allow this to scale. The idea is that they would in turn be generated by a user facing configuration system or language (e.g. kernel config system, some YAML thing, whatever else is trendy) that generates the bazel.rc.
Making this work when Envoy is composed into something like envoy-filter-example and unifying the bazel.rc approach with explicit cc_binary deps for configuration is something that we should explore further.

authors: alagalah alyssawilk dio ggreenway htuch mattklein123

repo: envoyproxy/envoy


text:
Host and Authority Headers RFC Compliance: Decode Percent-encoded UTF8 Characters

Title: Host and Authority Headers RFC Compliance: Decode Percent-encoded UTF8 Characters
Description:
While working on the unified header validation component (#20261), we found that the Host and Authority headers do not decode percent-encoded UTF8 characters, per the RFC spec.
Although the fix could be targeted for UHV, I wanted to register this issue with the community to get consensus on how percent-encoded characters should be handled within the H1 Host and H2 :authority headers. For now, we are only looking at the Host and :authority headers and not talking about URI or path normalization.
Some initial options after reading the RFCs, which could be implemented as new configuration settings:

Keep the current behavior and verify that Envoy users can register services that match on percent-encoded host/authority.
Decode all percent-encoded characters from Host and :authority, verify they are valid UTF8 codepoints, and re-encode them in the upstream request (where appropriate).

The URI RFC says that clients producing URIs should only encode non-ASCII characters in this way. Envoy could enforce this by also verifying that the decoded UTF8 codepoint is outside the ASCII range.
This could also be done on a per-service configuration basis (e.g.- decode_authority = [true|false]

Relevant Links:

RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax

Section 3.2.2 Host

The reg-name syntax allows percent-encoded octets in order to represent non-ASCII registered names in a uniform way that is independent of the underlying name resolution technology.  Non-ASCII characters must first be encoded according to UTF-8 (STD 63), and then each octet of the corresponding UTF-8 sequence must be percent-encoded to be represented as URI characters.
URI producing applications must not use percent-encoding in host unless it is used to represent a UTF-8 character sequence.

The authority component within the URI is used by both H1 Host header and H2 :authority header:

RFC 7230 - HTTP/1.1, section 5.4. Host:

A client MUST send a Host header field in all HTTP/1.1 request messages.  If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its @ delimiter.

RFC 7540 - HTTP/2:

The :authority pseudo-header field includes the authority portion of the target URI (RFC 3986, Section 3.2).  The authority MUST NOT include the deprecated userinfo subcomponent for http or https schemed URIs.

CC @yanavlasov

@snowp I would like to work on this issue

authors: MdSahil-oss ameily


text:
tools: refactor protoxform to distinct transform/pretty-print stages.

This patch moves protoxform to a protoc plugin that is solely in the
business of transforming FileDescriptorProtos to FileDescriptorProtos,
taking into account package status and performing vN -> v(N+1)
migrations.
A distinct tool, protoprint.py, which has the guts of the former
protoxform.py (basically no changes), is then invoked by proto_sync.py
during source tree copy-back.
The rationale for this split is that proto_sync.py needs to be able
to combine both the v2 next major version candidate and the hand edited
v3 protos when generating the v3 shadow, once v3 becomes canonical. This
is easiest to do when we operate on FileDescriptorProtos.
Risk level: Low
Testing: proto_format.sh (no changes).
Signed-off-by: Harvey Tuch htuch@google.com

@mattklein123 reasonably confident in the multiprocessing safety here, the reasoning is that each independent process is sourcing from an immutable location (the Bazel cache) and writing to an independent file in the temp directory. I moved the creation of the temp directory structure outside the multiprocessing to avoid potential conflict between mkdir (which I was observing). It's now pretty easy to reason about.

The rationale for this split is that proto_sync.py needs to be able
to combine both the v2 next major version candidate and the hand edited
v3 protos when generating the v3 shadow, once v3 becomes canonical. This
is easiest to do when we operate on FileDescriptorProtos.

@htuch Can you elaborate this a bit more? I can bazelify what protoprint does in this PR but not sure that works for the end goal.

@lizan see what merge_active_shadow.py (https://github.com/envoyproxy/envoy/pull/10601/files#diff-80ced58a80869102317246e98e6c425a) does in https://github.com/envoyproxy/envoy/pull/10601/ (as invoked by proto_sync.py).
IMHO, we should ship this for freeze and work on Bazelifying after this. It's a lot easier to Bazelify if we have a PoC that shows how things should work.

authors: htuch lizan


text:
quiche: implement QUIC_HISTOGRAM api

Signed-off-by: Dan Zhang danzh@google.com
Create a QUICHE stats instantiation and reference approach in Envoy which is applied to platform implementation of QUIC_HISTOGRAM_XXX(...), and will be applied to implement QUIC counters which will be added in QUICHE later.
An upstream change is need to change the stats name in QUIC_HISTOGRAM_XXX(name, ... ) from string to a token.
Risk Level:
Testing:
Docs Changes:
Release Notes:
[Optional Fixes #Issue]
[Optional Deprecated:]

@antoniovicente

/wait

/assign @antoniovicente

authors: antoniovicente danzh2010 jmarantz


text:
tcp: fixing a bug in the new connection pool due to too many shared pointers

The prior regression was due to variable shadowing.
ActiveTcpClient::ActiveTcpClient sets real_host_description_ in the constructor.  Here it set its own real_host_description_ where it was supposed to set the base class real_host_description_
When onPoollFailure was called, it was called with the base class real_host_description_ (nullptr)  So in the TCP filter
read_callbacks_->upstreamHost(host); set a null pointer.
and in void Filter::onUpstreamEvent read_callbacks_->upstreamHost()->outlierDetector().putResult( would segfault.
Risk Level: n/a (flag disabled code)
Testing: new regression test of upstream failure, unit test assert
Docs Changes: n/a
Release Notes: n/a

argh, local tests just informed me that I need a better integration test hackaround.  will reopen when fixed.

1 is privileged so I think it'll be Ok.  If not it should fast fail and we'll do another workaround.


text:
Add test to verify the extremely large min_rtt in adaptive concurrency

Signed-off-by: Junchao Lyu jlyu@lyft.com
test the scenario for https://github.com/envoyproxy/envoy/issues/14997

For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

It is tracked by https://github.com/envoyproxy/envoy/pull/15004


text:
hcm: support raw header value

Commit Message: Implement base64 encoding for dynamic raw header values.
Risk Level: low
Testing: done
Docs Changes: yes
Release Notes: yes
Issue: https://github.com/envoyproxy/envoy/issues/29590

Assigning @yanjunxiang-google for a first pass.
/assign @yanjunxiang-google

LGTM in general
@yanavlasov Could you please take a look?

Base64 is commonplace (e.g. JWT), and lossy encoding is not always desired if the payload needs to be decoded. I was considering a formatter function, but I think we don't actually have any yet, and I'm worried about the hand-written parser code in the formatter. CEL might be another option, we can expose a Base64 encoding function and require CEL formatter extension.  In any case, what do we actually raw_value to mean in HCM context?

I think base64 encoding the value will lock this feature into a very specific use case.
I think the use case is the following: I want to add a header with the 0xC9 character in it. I need to use the raw_value to avoid UTF-8 check in proto string.
If Envoy also base64 encodes it it makes the feature too limited. Which is I would prefer to add an operator for base64 encoding. I think it will be more challenging to implement base64 operator since we do not have support for recursive commands, but I would rather go that way, to avoid locking raw_value usage into specific behavior.
/wait-any

Let me explore CEL option, as it is more robust to adding new custom functions.

authors: adisuissa kyessenov yanavlasov yanjunxiang-google


text:
Undeprecate global_downstream_max_connections key (#30620)

Backport for https://github.com/envoyproxy/envoy/pull/30620
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

cc @KBaichoo @phlax is this the right branch to backport fixes for release 1.28?


text:
[WIP] ci/coverage: Fix flake on common/stats tests

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

probably unnecessary - as https://github.com/envoyproxy/envoy/pull/33411 should resolve i think

closing as unneeded


text:
aws: update credential provider proto and support credential file reload

Commit Message: aws: update credential provider proto and support credential file reload
Additional Description: Allows for customisation of the credential provider settings, using the credential provider proto added in #36217
Risk Level: Low
Testing: Unit
Docs Changes: Updated
Release Notes: Updated
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue] Addresses #36769 and partially addresses #37432
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@mathetake

/retest


text:
config: centralize gRPC and REST method strings in SubscriptionFactory

Previously, constant strings like "envoy.api.v2.EndpointDiscoveryService.FetchEndpoints" were all over eds.cc, rds_impl.cc, etc, being fed into SubscriptionFactory. Now, they are all centralized in SubscriptionFactory, the only place that actually uses them. #4991
Risk Level: low

/assign htuch

I think this a nice cleanup even just by itself, but the real motivation is delta xDS. The places that create subscriptions (eds.cc, cds_api_impl.cc, etc) need some simplification to avoid getting really messy with delta. This is one such simplification. (The other being unification of DeltaSubscriptionImpl and GrpcSubscriptionImpl).

Ready to merge?

Yeah, sure, but needs to resolve conflicts again, sorry.

Ha, it's my own conflict, so nothing to complain about!

authors: fredlas htuch


text:
mark all extension API fields as experimental

Description:
Mark all top level fields in all our extension APIs as experimental . This allows us to decouple graduating APIs from graduating API fields

Where would you like to see these markings? On doc site, crd annotations?

On the docs API page

you can just update the comment, or what is the UX you expected?

ideal UX would be a experimental string, that is hyperlinked into our API graduation/deprecation policy doc

maybe we should step back a little, had a good discussion in the community meeting with @guydc and @kflynn, let me outline some options
Option 1 - All fields within a v1 API are stable and cannot be removed, only deprecated
Pros

High velocity of feature additions
No extra cognitive load for user - No extra user docs or install steps

Cons

High Maintenance burden + complexity in case the fields are not well accepted by users, creating many deprecated fields  with multiple variants existing in the code base for the same feature

Option 2 - Stable and Experimental Release Channel (different CRDs) for v1
Pros

High velocity of feature additions, adding fields with experimental support into the experimental channel
Fields can be removed from experimental, if they haven't graduated to stable keeping the API and code lean and simple

Cons

Increased Cognitive load for user + more install knobs in helm to decide which CRDs to install

ptal @envoyproxy/gateway-maintainers

either is fine to me.

@arkodg Option 2 is more reasonable for me. If a stable API frequently is marked as deprecated, the UX is bad for end-users. Instead, separating core and extended like what gwapi does, it provides infos to end-users that what is more stable to use and what is not. And if they accept to use the experimental ones, they should also accept the possibilities of API breaking changes.

@arkodg Option 2 is more reasonable for me. If a stable API frequently is marked as deprecated, the UX is bad for end-users. Instead, separating core and extended like what gwapi does, it reminds end-users that what is more stable to use and what is not. And if they accept to use the experimental ones, they should also accept the possibilities of API breaking changes.

stable does not mean that it cannot be deprecated, need a workflow to make sure it won't be panic too much.

Yes, I mean stable APIs should not be making breaking changes frequently.

but actually in kubernetes, we shouldn't promise anything in alpha.

As discussed in the meeting today, ultimately, the most sane route forward is most likely to introduce stable and experimental release channels:

Be cautious about taking CRDs to v1, since once you do that you’ll need to support it forever, with no reasonable way to remove a field or change its semantics
Leave pre-v1 CRDs in the experimental channel
Mark fields as “likely to change” or “considered very unlikely to change” even in experimental so that users know what to expect as CRDs move to stable
Allow Envoy Gateway as a whole to go to v1 without taking the CRDs to v1

With Envoy Gateway v1, have the installation default to using the experimental CRDs; have an install option to use stable instead

We don’t want to start with stable as default because the BackendTrafficPolicy, ClientTrafficPolicy, and SecurityPolicy are very young and shouldn’t start out in stable

At some later point when we have more feedback and more confidence with the CRDs, switch the installation to default to stable instead

This is also being discussed in Gateway API itself, since we realized that we hadn't really written anything down about it. Some combination of Rob and I will be writing on it for upstream.

thanks for writing this down @kflynn ! agree with all of these points except prefer the --experimental-crds helm knob to be disabled by default, so the helm defaults to stable CRDs. However if all our Quickstart and other installation guides, I'd prefer to incorporate --experimental-crds into the hem installation command and explain why to use it and why not to

Yeah, I could get behind that, too. Just a question of whether we want to go with docs or conventions; I'm fine with either. 🙂

QQ: how can I move forward https://github.com/envoyproxy/gateway/pull/2549?

hey @zirain I have some WIP stashed locally to create standard and experimental CRDs in Helm Charts, will try and push that son

@arkodg still need this?

lets close, not needed atm

authors: Xunzhuo arkodg kflynn zirain

repo: envoyproxy/gateway


text:
Fix ignore_empty test cases.

Prior to this change, ignore_empty test cases where testing an negated
range (<=128, >=256), and since the value 0 falls in that range, the
tests would pass regardless of ignore_empty.  To make the tests pass
for the right reason (ignore_empty is given), the range is changed to
[128,256] so 0 falls outside the range.
The tests for Float already had the correct range. This commit updates
all the other messages to be consistent with Float.

It looks like all the test cases we have with ignore_empty set are valid. Can we also add negative tests that make sure that non-zero values that are invalid according to the range conditions are rejected as expected?

authors: akonradi thesamet

repo: envoyproxy/protoc-gen-validate


text:
enyo.json.parse() missing reviver support

The following...
parse: function(inJson) {
  return inJson ? JSON.parse(inJson) : null;
}

Does not allow for the optional reviver function argument to JSON.parse( object [, reviver ]).

Closing as duplicate of #13 since that includes code

Just a heads up - when you include "Fixes #12" as I did in the Pull Request, github will auto-close the ticket that is referred to, in this case, #12 being this ticket.

ah, didn't know that... just didn't want duplicate items in our issue list.

Ugh, no kidding... Drives me crazy that Pull Requests automatically generate a new issue instead of having a mechanism to consolidate with an existing issue.

authors: rwldrn unwiredben

repo: enyojs/enyo


text:
Add support for xlsx and pdf downloads

See downloads

[x] xlsx
[ ] pdf

you can do xlsx like this:
`    ui.tags.script(type="text/javascript", src="https://oss.sheetjs.com/sheetjs/xlsx.full.min.js")
 async with TabulatorContext("tabulator") as table:
      table.trigger_download("xlsx", "data.xlsx", {"sheetName":"sheetName"})

`

@j0bekt01 Yes, this is already implemented with use_sheetjs as shown in this example.
Issue is still open because of the pdf support. Maybe I will split the issues.

repo: eodaGmbH/py-tabulator


text:
Evaluator Review: EVMNS_Milestone_4&5

Review, approve, or deny https://github.com/eosnetworkfoundation/grant-milestones/pull/121

Closed per @wanderingbort approval for https://github.com/eosnetworkfoundation/grant-milestones/pull/121.

repo: eosnetworkfoundation/grant-milestones


text:
fix(chat): fix selecting convs & prompts in search mode (Issue #1874)

Description:

fix delete selected prompts in search mode
apply same changes to conversations epic as well

Issues:

Issue #1874

Checklist:

[x] the pull request name complies with Conventional Commits
[x] the pull request name starts with fix(<scope>):, feat(<scope>):, feature(<scope>):, chore(<scope>):, hotfix(<scope>): or e2e(<scope>):. If contains breaking changes then the pull request name must start with fix(<scope>)!:, feat(<scope>)!:, feature(<scope>)!:, chore(<scope>)!:, hotfix(<scope>)!: or e2e(<scope>)!: where <scope> is name of affected project: chat, chat-e2e, overlay, shared, sandbox-overlay, etc.
[x] the pull request name ends with (Issue #<TICKET_ID>) (comma-separated list of issues)
[x] I confirm that do not share any confidential information like API keys or any other secrets and private URLs

/deploy-review

repo: epam/ai-dial-chat


text:
Скріншоти російською

На скріншотах інтерфейс Jenkins російською. Не впевнений, що це корректно в наявній ситуації.
https://github.com/epam/edp-ddm-architecture/blob/5127201c9fee2db3cbec7e30936b9b8bf06d1957/docs/ua/modules/admin/pages/backup-restore/control-plane-backup-restore.adoc?plain=1#L27-L28

Fixed: https://github.com/epam/edp-ddm-architecture/commit/c3231a1a768d2cdce7441cbed701adf93e377c4f

repo: epam/edp-ddm-architecture


text:
Create add-ons approach to install EDP and all cluster components using Argo CD

Use ArgoCD to quickly bootstrap kubernetes cluster from scratch.
Acceptance criteria:

EDP user can use pre-defined structure in edp-install as a baseline for cluster deployment;
For each engagement user can use this structure as baseline for new cluster provisioning;
ArgoCD is used to deploy all tools on the cluster;
Deploy new cluster and apply addons approach to ensure cluster has all the required capabilities and EDP as well

The repository now has the initial structure with addons, including the EDP platform installer and essential dependencies like logging, monitoring, and system component deployment. Moving forward, we aim to further enhance and maintain this deployment approach as it significantly streamlines our processes.
To adopt this approach, you can fork the provided repository, make necessary modifications to tailor it to your specific requirements, and seamlessly integrate it with your Argo CD server for deploying all the showcased components effectively.
Closing the issue as the initial setup has been successfully implemented.

repo: epam/edp-install


text:
Macro: Selected RNA preset not discards when mouse moved on canvas and 'ESC' button is pressed

Steps to Reproduce

Open Ketcher and switch to Macro mode
Switch to RNA tab
Select any RNA Presets
Move mouse cursor to canvas and press 'ESC' button

Actual behavior
Selected RNA preset not discards when mouse moved on canvas and 'ESC' button is pressed
Expected behavior
Selected RNA preset discards when mouse moved on canvas and 'ESC' button is pressed
Screenshots
https://github.com/epam/ketcher/assets/62464241/f767c288-53a8-4464-8aa9-007628974d15
Desktop (please complete the following information):

OS: Windows 11
Browser Chrome
Version 112.0.5615.138 (Official Build) (64-bit)

Ketcher version
Version 2.18.0-rc.2

Test automated.

Tested on 2.21.0-rc.1 Fixed.
https://github.com/epam/ketcher/assets/62464241/b93e6d4b-b7db-41c9-8830-8887667bbcf1

repo: epam/ketcher


text:
Question: llama3

Hi,
On the meta-site https://ai.meta.com/blog/llama-2-3-meditron-yale-medicine-epfl-open-source-llm/
I saw that you also published a model based on llama3? However, I could not find it and the link provided on the meta-site does not work: https://meditron-ddx.github.io/llama3-meditron.github.io/
I was just curious, if you are going to publish it?
Kind regards!

Yes, I am very interested, please let us know with more info about this, thanks!

Same question here, looking for the version with LLama3 :P
I found that website https://www.meditron.io/  but not info about a model based on llama3 ;(

authors: YuniorGlez lordpba ruizcrp

repo: epfLLM/meditron


text:
Display hidden errors (only saved in tracer file)

From issue: -
High level changes:

Lors de l'export-many, des sites étaient uniquement parsés mais après le script sortait sans aucun message d'erreur affiché...  Après recherche, il y avait bel et bien une exception qui était levée mais celle-ci était juste notée dans le "tracer" mais pas dans la console. Donc un peu vicieux pour investiguer... bref, ajout de l'affichage de l'erreur dans la console.

Targetted version: x.x.x

Bien vu, je m'étais uniquement attardé sur l'erreur qui me concernait, ceci sans regarder plus loin ailleurs.
J'ai fait la correction demandée.


text:
Add synchronize call between MOFF and Save

I'll just copy-paste Jayce's explanation because I don't fully understand it.

The underlying problem was that all of the CUDA operations are done asynchronously.  Normally Bifrost forces a sync when the data cross a memory space boundary.  However, when using a CUDA-based ring you end up with data being written that isn't actually there until the memcpy completes.  The reserve on the ring doesn't know about this so when that reserve is released the next block starts to read.  That read can start before the copy finishes.

Yep.

If anyone wants a bit more info:  bifrost#138

authors: adampbeardsley jaycedowell


text:
fix sentry cors issues

sentry changed its url from *.ingest.sentry.io to *.ingest.[LOCATION].sentry.io
which results in cors errors
[Report Only] Refused to connect to '.......' because it violates the following Content Security Policy directive: "connect-src *.ingest.sentry.io 'self'".

I think you are correct on the fact sentry didn't change server url. However for new customers or for customers that are non US, we get assigned a different address with the location in it. The documentation regarding this change seems very light. all info I could find were this doc page that says the ability to change location is only available by creating a new accounts. see https://docs.sentry.io/product/accounts/choose-your-data-center/
I invite you to create a new account and follow the instructions in the readme of epic stack or just wait for people here to confirm the issue/fix. No hurry at all

repo: epicweb-dev/epic-stack


text:
Place platform-specific fields inside a nested structure

At the moment, we place all logged fields at the top level of the JSON structure:
{
  "level": "INFO",
  "timestamp": "2021-01-26 14:33:15",
  "rails_environment": "development",
  "method": "GET",
  "path": "/feed_approvals",
  "format": "html",
  "controller": "FeedApprovalsController",
  "action": "index",
  "status": 200,
  "duration": 324.0,
  "view": 240.1,
  "exception": null,
  "exception_object": null
}

Following a suggestion from @andrew-pickin-epi, we will nest output keys that Rails-specific under a sub-key:
{
  "level": "INFO",
  "timestamp": "2021-01-26 14:33:15",
  "method": "GET",
  "path": "/feed_approvals",
  "status": 200,
  "duration": 324.0,
  "rails: {
    "action": "index",
    "controller": "FeedApprovalsController",
    "environment": "development",
    "view": 240.1,
    "exception "xxxx",
    "exception_object": "yyyy"
  }
}

Common keys will remain at the top level. Keys with null values will be removed altogether.

Also have this kind of event.
https://kibana-fsa.epimorphics.net/app/kibana#/discover/doc/logstash-*/logstash-default-2021.01.27-000001?id=PmGFRHcBBtbYVXFE3eJn
{"level":"INFO","timestamp":"2021-01-27 15:45:54","rails_environment":"production","message":"server: \"nginx/1.19.1\"\ndate: \"Wed, 27 Jan 2021 15:45:54 GMT\"\ncontent-type: \"application/json\"\ntransfer-encoding: \"chunked\"\nconnection: \"keep-alive\"\nvary: \"Accept-Encoding, Accept, Origin\"\nsleuth-trace-id: \"5988fc18ed2f5bd1\"\nsleuth-span-id: \"5988fc18ed2f5bd1\"\ncache-control: \"max-age=1200\"\nx-cache-status: \"HIT\""}
Which results in
log+message= server: "nginx/1.19.1"
date: "Wed, 27 Jan 2021 15:45:54 GMT"
content-type: "application/json"
transfer-encoding: "chunked"
connection: "keep-alive"
vary: "Accept-Encoding, Accept, Origin"
sleuth-trace-id: "5988fc18ed2f5bd1"
sleuth-span-id: "5988fc18ed2f5bd1"
cache-control: "max-age=1200"
x-cache-status: "HIT"

Also have this kind of event.
https://kibana-fsa.epimorphics.net/app/kibana#/discover/doc/logstash-*/logstash-default-2021.01.27-000001?id=PmGFRHcBBtbYVXFE3eJn
{"level":"INFO","timestamp":"2021-01-27 15:45:54","rails_environment":"production","message":"server: \"nginx/1.19.1\"\ndate: \"Wed, 27 Jan 2021 15:45:54 GMT\"\ncontent-type: \"application/json\"\ntransfer-encoding: \"chunked\"\nconnection: \"keep-alive\"\nvary: \"Accept-Encoding, Accept, Origin\"\nsleuth-trace-id: \"5988fc18ed2f5bd1\"\nsleuth-span-id: \"5988fc18ed2f5bd1\"\ncache-control: \"max-age=1200\"\nx-cache-status: \"HIT\""}
Which results in
log+message= server: "nginx/1.19.1"
date: "Wed, 27 Jan 2021 15:45:54 GMT"
content-type: "application/json"
transfer-encoding: "chunked"
connection: "keep-alive"
vary: "Accept-Encoding, Accept, Origin"
sleuth-trace-id: "5988fc18ed2f5bd1"
sleuth-span-id: "5988fc18ed2f5bd1"
cache-control: "max-age=1200"
x-cache-status: "HIT"

The kibana log output is about the richest example were have of prior art. It might server as a pattern.
https://kibana-hmlr.epimorphics.net/app/kibana#/discover/doc/c84f80d0-0243-11eb-8589-eb35cb72fe94/fluentd-20210128?id=6j7JSHcBSC-fGwD-TKd8&_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-1h,to:now))

The kibana log output is about the richest example were have of prior art. It might server as a pattern.
https://kibana-hmlr.epimorphics.net/app/kibana#/discover/doc/c84f80d0-0243-11eb-8589-eb35cb72fe94/fluentd-20210128?id=6j7JSHcBSC-fGwD-TKd8&_g=(filters:!(),refreshInterval:(pause:!t,value:0),time:(from:now-1h,to:now))

Done and should be in release 0.2.0 👌

repo: epimorphics/json-rails-logger