Implement #152

Hi all,
This is a first pass on #152, a strict enforcement of the PySide2 API.
It's a suggestion, so do not merge unless we've talked it through and are all happy with it.
Things to note:

Qt.py is now twice as large (from 446 to 889 lines) as before, due to explicitly specifying each member.
This will break existing code that uses members other than those found in PySide2.
A number of inconsistencies were immediately found (and fixed) in tests, CAVEATS and examples. This is a good thing! Have a look.
QtWebKit was excluded as it is not guaranteed to exist in PyQt4 and 5 (it's an optional add-on).

On (1), this isn't necessarily a disadvantage; it does make the code trivially simple and require close-to-zero understanding of the overall code to make contributions. Such as adding missing members, or members that become available (as PySide2 is still under active development).
Discussion
I personally think this is the right way forwards, but it does mean less code will run on it. At the moment, Qt.py is rather forgiving but then of course punishes you secretly further on as you attempt to run it on other bindings.
I could imagine we either make this leap, force users to conform to a strict subset of PySide2, or install a switch such as QT_STRICT=True.
$ python
>>> from Qt import QtGui
>>> widget = QtGui.QWidget()
>>> exit()
$ export QT_STRICT=True
$ python
>>> from Qt import QtGui
>>> widget = QtGui.QWidget()
AttributeError: 'module' object has no attribute 'QWidget'

If so, (1) is the added code worth the trouble? and (2) which value should be the default?
Let me know what you think.

I've written a quite large application using Qt.py which uses PySide2 when in Maya, PySide when in Nuke and PyQt5 for all other scenarios (such as standalone use). This just works quite magically and well.
I need to give this a whirl before commenting further, but when using e.g. PyQt5 as the binding, and when hitting issues, what would be the solution at hand?
Do I have to query Qt.QtCompat.binding and depending on what I'm doing I might have to import PyQt5 separately? (I hope not)

This just works quite magically and well.

Did you mean this PR, or Qt.py in general?

when using e.g. PyQt5 as the binding, and when hitting issues, what would be the solution at hand?

What kind of issues?

Did you mean this PR, or Qt.py in general?

Initially, I meant Qt.py in general. But after having now replaced Qt.py with the one from this PR I can just say I now also refer to this PR 👍

when using e.g. PyQt5 as the binding, and when hitting issues, what would be the solution at hand?

What kind of issues?

Sorry, I was being vague. When enforcing PySide2, I was merely wondering which approach to take when code break as a result of the enforcement. For example, I noticed a very large chunk of my code base works but I got this error early on in Python 2.7 with PySide 1.2.4:
Traceback (most recent call last):
  ...
    ...
    quit_app.triggered.connect(QtWidgets.qApp.quit)
AttributeError: 'NoneType' object has no attribute 'quit'

I'm glancing through Qt.py top to bottom and when I reach the bottom half where all objects are mapped, I have a hard time understanding where the "_"-prefixed objects were created. For example:
Where in the code was _QtGui defined so that this mapping could be performed:
QtGui.QAbstractTextDocumentLayout = _QtGui.QAbstractTextDocumentLayout

Also, let me see if I am getting this right;

First the binding is imported and possibly remapped (e.g. QtWidgets = QtGui for PySide/PyQt4), and stored in a temporary "_"-namespaced module (e.g. _QtWidgets)
We then build a QtWidgets fresh by manually specifying all its members and mapping them against the "_"-namespaced module _QtWidgets.

This all means that if a member is not part of the long list of mappings which now takes up approx. half of the Qt.py file, this won't end up in our custom-created QtWidgets. Am I correct?
Like you say, this makes the file bigger but it also becomes much easier to see exactly what is supported by Qt.py. I'd say if we make sure to explain every major section of Qt.py using inline comments and docstrings this would all contribute to improved readability of the file and make it easier for people to contribute.
Other questions

What about all the other modules which today aren't defined in Qt.py (e.g. QtQML, QtQuick); do we want to support them too?
How did you generate the long list of members, should perhaps a tool or guide (README or inline comment?) be included in the repository which can do this and aid in future development of Qt.py where new members needs to be added? Perhaps a test should be implemented which checks whether there are members of PySide2 which is not defined in Qt.py?

All in all, I like this PR and all my code works great with it (although it was initially written for Qt.py 0.6.x). 👍
On a side note, just curious; I see you define empty lists using some_list = list(). I usually just do some_list = [] from old habit. May I just ask if this is just a personal preference of yours or if there are any special advantages?

Ok, now I understand.
This kind of enforcement should only cause one problem - a member is missing - for two causes.

It does exist across all bindings, but hasn't yet been added
It is missing from at least one binding, in which case it shouldn't exist

For (1), this layout would make it trivial to PR a new member, by simply adding a line to the long list of lines.
For (2), this is where enforcement kicks in. If something is missing and should be missing, that's a signal that it wouldn't work across all bindings.
With this PR, only members of PySide2 that also exists in all other bindings are included. It's a subset of PySide2, which does mean that Qt.py has the least amount of members out of all bindings.

qApp

As it happens, this is an interesting example. qApp is a special case that (I'm assuming) is added dynamically upon instantiation of QApplication. Before instantiation, the member does not exist.
Now the problem is that, qApp is only added to PySide2.QtWidgets, and not Qt.QtWidgets.
This is clearly a limitation of this approach.
What we could do is make Qt.QtWidgets into a class, rather than a module, and have it dynamically fetch items from the original QtWidgets.
class QtWidgets_(object):
  def __getitem__(self, attr):
    return getattr(_QtWidgets, attr)

But if we do that, we lose out on other module-like functionality, like this.
from Qt.QtWidgets import QPushButton

All in all, if we are to approach this issue of PySide2 enforcement with this particular technique - of explicitly specifying members - I'm not sure I see any other way than to bite the bullet on this one special case and accept that qApp is no longer viable, and that we should instead use QApplication directly (which, for those that do not know, is what qApp is an alias/shortcut to).
Worth considering!

Okay, great - thanks for the clarification. So, overall, this clearly is an improvement as users are not tricked into writing cross-binding compatible code when they're not. Which is a important feature for my and my company's use of Qt.py; I write code which needs to work on multiple bindings.
So, whenever something doesn't work using Qt.py because of a member being exclusive to a specific binding, I guess we'll recommend you resort to doing something like:
if ('PyQt4') in QtCompat.__binding__:
    import PyQt4
    ...
elif 'PySide' in QtCompat.__binding__:
    import PySide
    ...
else:
    import Qt
    ...

...or would you advise differently?
It would actually be good to come up with a working concrete example where one might need to do this to explain this new (and backwards-breaking) functionality.

What we could do is make Qt.QtWidgets into a class, rather than a module, and have it dynamically fetch items from the original QtWidgets.

It would be interesting to get others thoughts on this. Personally, I think it would help maintain Qt.py (keeping it up to date automatically). Not being able to import like from Qt.QtWidgets import QPushButton is totally fine by me, however I appreciate this may or may not be the case with the majority of users (although I'm leaning towards the latter).

Where in the code was _QtGui defined so that this mapping could be performed:

The three submodules QtGui, QtCore and QtWidgets are loaded within each function, like before. E.g. _pyside(). But this time, the function returns the loaded modules, and are later passed to here where they are given an underscore to separate them from the replacement submodules that we create.
For Qt 4, the _QtGui module is remapped to _QtWidgets for convenience in the module, neither are accessible one the module has finished loading, as you can see at the bottom of the module where they are explicitly deleted.
It means you can't do this.
import Qt
Qt._QtGui  # This would be the original binding.

This all means that if a member is not part of the long list of mappings which now takes up approx. half of the Qt.py file, this won't end up in our custom-created QtWidgets. Am I correct?

Precisely.

What about all the other modules which today aren't defined in Qt.py (e.g. QtQML, QtQuick); do we want to support them too?

Simple, they aren't supported by all bindings, therefore would not be included.
If you are looking for QtQML, odds are you aren't looking for compatibility with Qt 4, hence Qt.py is not what you are looking for.
There is however a case for PyQt5 and PySide2 compatibility, and it's possible we would still like to facilitate that. Otherwise, we could make that a separate project. Such as Qt5.py.

How did you generate the long list of members,

An excellent and important question.
The list was generated by the included build_membership.py module.
$ python build_membership.py

The resulting reference_members.json contains all members of PySide2, excluding those that do not exist in other bindings. Each of which are marked in-line.

See here

Members are built given the currently installed version of PySide2, on Travis this means whatever version is available on apt-get. It's likely we'll need to keep up to date with that, but it's debatable whether we want to adhere to a newer version of PySide2 than what folks generally have access to, such as whichever version Maya happens to ship with. In that sense, it makes sense to go with the oldest version of PySide2, but that has other problems given it is still in Alpha.
Tough call!
In this PR, some members are doubly being excluded from within Qt.py as well, such as this one. Those should all ideally lie in a single spot for ease of maintenance.

some_list = list()

Just personal preference, I don't think there is any technical advantage.

I guess we'll recommend you resort to doing something like:

I'm torn.
On one hand, if you find yourself needing to use non-cross-compatible Qt code, you might want to question why you use Qt.py.
On the other hand, there are always special cases. In some cases, one binding might be the recommended one due to some feature or bug in other bindings. In might be the case that a program runs best under PyQt5, and works less than ideal - perhaps with less features and glitter - under other bindings too.
Kind of like how Xbox One games sometimes works on Xbox 360, with lesser quality.

Regarding working around supporting a member not supported by Qt.py; I have no idea when and why I would need to do this but I wanted to raise the question to see how we feel about it.

There is however a case for PyQt5 and PySide2 compatibility, and it's possible we would still like to facilitate that. Otherwise, we could make that a separate project. Such as Qt5.py.

Yes, this what actually exactly which was on my mind. I think, at least for me, it's too early to start such a project. I'm head over heels in developing for practically all the bindings with Qt.py now and QML is just out of the question. But I can clearly see the benefits of one such project (Qt5.py).

The list was generated by the included build_membership.py module.

Ah, nice. So basically you run this and copy-paste the members mapping from the JSON into Qt.py?
Sorry for all these questions... this PR is bigger than I have time reading today. I'll try reading this through more closely during the holidays. I'm glad and thankful that you're taking your time making clarifications :) Helps me be able to quickly grasp how this may affect developing Qt.py and developing with Qt.py.

The resulting reference_members.json contains all members of PySide2, excluding those that do not exist in other bindings. Each of which are marked in-line.

If these exclusions wasn't generated, how did you manage to list them (here)?
Did you just look these up manually and added them to the exclusion lists?

Members are built given the currently installed version of PySide2, on Travis this means whatever version is available on apt-get. It's likely we'll need to keep up to date with that, but it's debatable whether we want to adhere to a newer version of PySide2 than what folks generally have access to, such as whichever version Maya happens to ship with. In that sense, it makes sense to go with the oldest version of PySide2, but that has other problems given it is still in Alpha.

A simple solution could be to just follow the vfxplatform spec and be observant of whether vendors do follow it or not and then adjust to what the industry standard actually ends up being.

Did you just look these up manually and added them to the exclusion lists?

In the membership tests, after comparing members of PySide2 with each other binding, such as PyQt4, a listing of missing members is printed.

See here

I then go in and manually add those to build_membership.py.
I figure it'll be a lot of work initially, but very little in the long run. I'd imagine we'll discover one or two members missing as time goes by and PySide2 is updated and that we'll simply add those to the list.
There might be more automatic ways of going at it, but I couldn't think of one that didn't make things too magical. Like the "hidden" reference_members.json currently produced by build_membership.py. Ideally I'd like those things to be out in the open so we can inspect and reference those in talks.

A simple solution could be to just follow the vfxplatform spec and be observant of whether vendors do follow it or not and then adjust to what the industry standard actually ends up being.

That is a great idea. Let's do exactly that.

I'm glad and thankful that you're taking your time making clarifications :)

My pleasure! A lot of these things I take for granted while typing it out. It sometimes doesn't occur to me that people can't read my mind until someone points it out, so do carry on!

In the membership tests, after comparing members of PySide2 with each other binding, such as PyQt4, a listing of missing members is printed.

❤
I was afraid you were doing that manually.

I figure it'll be a lot of work initially, but very little in the long run. I'd imagine we'll discover one or two members missing every now and then as time goes by and PySide2 is updated and that we'll simply add those to the list.

I must say, even if you think a lot is missing, my Python application (146.6 files/s, 17973.3 lines/s according to CLOC) just works with this 0.7.0 version of Qt.py.
Overall, a big thumbs up from me initially on this PR! :1st_place_medal:

Ok, I'm happy with this.
I've reduced the character-count significantly, and implemented QT_STRICT (which is off by default).
At the end of the day, this introduces a major shift in how Qt.py is implemented but should have minimal affect on users.
The most significant change is that Qt.py is no longer replaced by the original binding. This means members other than QtWidgets, QtCore, QtGui and QtCompat are no longer available.
Without QT_STRICT, this will still break code that previously worked on one binding but no others. For example, if someone was using QtTest or QtScript.
With QT_STRICT, my hope is that code should fail only when it would have failed on one or more bindings. The goal is to enable the user of Qt.py spot instantly when using something not entirely cross-compatible, and I think this is a good step in that direction.

This is all very excellent in my opinion 👍
The fact that you managed to get a QT_STRICT switch implemented is awesomesauce. Everybody wins.
To me, this also means we won't have to think much more about something like a "Qt5.py" project (discussed earlier) as I can easily use Qt.py (with QT_STRICT off) whenever I wish to use e.g. QML in a PyQt5/PySide2 combo situation.
I'm going to enable QT_STRICT for everything I do right now though. I really like this. I think QT_STRICT should become the default setting at some point. I'd go as far as to even raise the question whether maybe it should be enabled by default starting with 0.7.0. However, I do respect the fact that Qt.py is still young (although it has seen good adoption) and it might be hurtful to already create a legacy issue by enabling QT_STRICT by default.

With QT_STRICT, my hope is that code should fail only when it would have failed on one or more bindings. The goal is to enable the user of Qt.py spot instantly when using something not entirely cross-compatible, and I think this is a good step in that direction.

Haven't looked at your README changes just yet, but this should be prominent in the README and drive users towards wanting to enable QT_STRICT. I believe it should simply be a friendly recommendation which should have been enabled by default if we didn't already have code running out there on Qt.py <= 0.6.x.
Great job!

My compliments on getting the module inclusion lists (of _strict_members) much more readable as well.

I'm going to enable QT_STRICT for everything I do right now though.

I'd encourage everyone to do the same. I'm expecting someone to try it and experience some issue that might prevent it to become the new default, but unless that happens I'd imagine it become the default once we hit 1.0.

this also means we won't have to think much more about something like a "Qt5.py" project (discussed earlier) as I can easily use Qt.py (with QT_STRICT off) whenever I wish to use e.g. QML in a PyQt5/PySide2 combo situation.

Actually that still wouldn't work, because only QtCore, QtGui and QtWidgets are available via Qt.py.
And also, what does "strict" mean if one is looking to use if for Qt 5 bindings only? I'd imagine Qt5.py to also have a strict mode, to exclude members exclusive to PySide2 or PyQt5.
I dunno, it doesn't feel right.

this should be prominent in the README

Agreed. I haven't found the right spot for it in the README. Too advanced to introduce it with, yet too important to leave for later. I was thinking of making it the central message of the Release.

Actually that still wouldn't work, because only QtCore, QtGui and QtWidgets are available via Qt.py.

Now I'm a bit confused. With QT_STRICT I thought we get this new functionality of the PR. With QT_STRICT disabled I thought we'd get the current 0.6.x behavior. No?

Now I'm a bit confused. With QT_STRICT I thought we get this new functionality of the PR. With QT_STRICT disabled I thought we'd get the current 0.6.x behavior. No?

Not quite, no.
See before, we simply made import Qt into whatever binding was chosen, for example import PySide2. Which would have exposed QtGui and QtWidgets like it does currently, but also all other members that are unique to PySide2 and PyQt5, such as QtQml.
The way this is implemented now, it Qt.py wouldn't replace itself with a module, it would be the actual module you use.
It's the only way we could have control over what's inside of it, and is probably how it should have been done to begin with. But it does mean things are different.

Sorry for the long idle time. Holidays, children and other private matters have been taking up my time.
I'm feel a bit thick, as I don't quite understand the exact definition of what will be the difference when having QT_STRICT enabled vs disabled. Are the below definitions correct?
QT_STRICT=False (default): Limit usage to whatever is shared between PySide2/PyQt5/PySide/PyQt4.
QT_STRICT=True: Limit usage to PySide2.

QT_STRICT=False means you can still use QtCore.pyqtSignal, whereas QT_STRICT=True means you cannot. It means you can only use members that exist in PySide2, even if you are on another binding, such as PyQt4 or PyQt5. It means Qt.py would be a lowest common denominator of all bindings.
Having thought more about it over these past few weeks, I'm also open to the idea of not having a QT_STRICT=False mode at all. It would break backwards compatibility, but only in cases where code written with Qt.py would have broken on one or more bindings anyway. For example if one were to actually use pyqtSignal.
To ease the transition, we could increment the major release, making it 1.0.0, and let those that prefer the current more lax alternative stick to 0.x.x.
Writing new GUIs today, it makes the most sense to me. It would mean I know with confidence that if it works with Qt.py, it would work on all bindings.
What do you think?

I totally agree with you; not having QT_STRICT=False.
I think it's a little bit confusing to have both modes. I can't really see when or why you'd want that.
I feel having the 0.6.x behaviour (a.k.a. "wild west mode" :wink:), is probably what people want if they don't want QT_STRICT=True.

I don't know if it's worth doing, but we could maintain a branch which we call something like "legacy"... or something more clever. Which is in fact the 0.x behavior, retained.

I totally agree with you; not having QT_STRICT=False.

Cool!

I can't really see when or why you'd want that.

It would be for backwards compatibility. For example, to those who have already built GUIs that work well with, e.g. PyQt5 and PyQt4. This update could break that.

EDIT: No, wait. Then travis testing etc won't work, I guess. Never mind.

We could instruct Travis to pick a particular branch, but whether we should maintain the previous version via a branch at all I'm unsure of.
What I'd like to do, is finish this up and make an alpha release. We make an announcement and ask for people's opinions. And move on from there.
One of the things we lose out on with this release is the immediate benefit to those who transition to PyQt5. Those users won't necessarily care for the current limitations of a pre-alpha PySide2, but they would be limited by it nonetheless. I think @melevine is such a user, correct me if I'm wrong!
On the upside, PySide2 will inevitably catch up, at which point this would no longer be a downside. Unless we care for compatibility with this first version of Maya 2017, which comes bundled with the pre-alpha version.
Choices!

What I'd like to do, is finish this up and make an alpha release. We make an announcement and ask for people's opinions. And move on from there.

Sounds good to me! 👍

Polished and QT_STRICT removed. Tested with GUIs within my possession, and it looks ALL OK to me.
Merging this tomorrow, but won't make an official release on PyPI until I've made an announcement and have had a few of you test this out for yourselves to find edgecases we'll need to take into account.
To install the pre-release, I'll be suggesting this.
$ pip install git+git://github.com/mottosso/Qt.py

Which is a method of installing Qt.py directly from GitHub, before releasing it into the wild.
And just to clarify, this will be a breaking release. Breaking things that would have broken on any of the four bindings, such as when using Qt.QtCore.pyqtSignal, but nothing else. On my GUIs, as I have been careful from the get-go, only one thing broke; using the QtWidgets.qApp macro, which is not part of this release.

I'll be putting this to the test after lunch. Will be back with any impressions later today.

Considering Qt.py no longer needs to replace itself with an original binding, we can add members to is without worrying about hiding those from the original.
Also considering this is already a breaking change, it'd be ideal to break as much as possible now, as opposed to spreading out breakage over several versions.
So I moved __version__, __binding__, __qt_version__ and __binding_version__ to the main Qt namespace.
For example.
# Before
>>> from Qt import QtCompat
>>> print(QtCompat.__version__)
u'0.6.9'

# Now
>>> import Qt
>>> print(Qt.__version__)
u'1.0.0.b1'

See this section of the README.

Considering Qt.py no longer needs to replace itself with an original binding, we can add members to it without worrying about hiding those from the original.

Excellent. Would it be useful to keep some backwards compatibility to Qt.QtCompat?
As we're hitting 1.0.0 I'd say that's not necessary.

I just ran tests on internal stuff using Qt.py from this PR and it works fine without any hiccups.

Would you like to still have the compatibility functions under QtCompat or do you wish to also move these onto Qt?

Would you like to still have the compatibility functions under QtCompat or do you wish to also move these onto Qt?

As we still include compatibility wrapppers, like load_ui, I thought QtCompat was still relevant to those, and future wrappers that might appear. It's just these members, that didn't quite fit as "compatibility" related (at least to my mind).
But it's a detail, and I'd be happy to leave all additions to QtCompat if you'd prefer. What do you think?

Here's what I've got in mind for an announcement on the VFX Platform.

Qt.py and safety
Hi community,
Today we've made a significant leap forwards for Qt.py and implemented a guarantee where if your program runs with Qt.py and any binding, such as PySide2, it will run in an identical fashion on any binding.
This means that it will throw an error if you use any feature of any particular binding that isn't available on another binding.
For example, this is currently possible with Qt.py
1: from Qt import QtGui, QtCore
2:
3: class Widget(QtGui.QWidget):
4:   my_signal = QtCore.pyqtSignal(str)

On the third line, we run into an immediate problem; QWidget is only available via QtGui in PyQt4 and PySide(1).
On the 4th line, we refer to a signal as pyqtSignal which would work well on both PyQt4 and PyQt5, but fail in PySide and PySide2.
Worst yet, these problems would not make themselves known until you run it on each of the 4 bindings and make sure, first hand that it works as you'd expect.
With this new change, Qt.py limits the available members of each submodule into a subset of members that exist across all bindings. The result is finding out about these problems faster and being able to guarantee that if it runs on one binding, it works on all.
1: from Qt import QtGui
2:
3: class Widget(QtGui.QWidget):
4:   pass
5:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'QWidget'

As a consequence of this breaking change, some of your already written software with Qt.py may need some tweaking. They would behave badly if they would have already behaved badly in any of the 4 bindings.
We are confident in this change and direction, but are still in discussion about whether now is the right time. One of the bindings, namely PySide2, is so far behind the other bindings that it is currently the "weakest link" by far.
These are the modules supported by Qt.py (and in effect, PySide2 (2.0.0)) with this change.
__all__ = [
    "QtGui",
    "QtCore",
    "QtWidgets",
    "QtNetwork",
    "QtXml",
    "QtHelp",
    "QtCompat"
]

The second concern regards which version of this weakest link to match. As PySide2 matures, more feature will be added and Qt.py could start to grow. But Maya 2017 and others are currently fixed at version 2.0.0. Growing Qt.py beyond what Maya 2017 is capable of would limit its usefulness.
For this I figure it wouldn't be too cumbersome to implement compatibility profiles; where the end-user specifies which version of, say, the VFX Platform to provide support for.
$ # For example
$ export QT_BASELINE=CY2018
$ python -c "from Qt import QtOpenGL"

For now, we'd like your feedback on this major change and for you to test it out for yourself. The release is still considered "alpha" and is available directly via GitHub for download or install.
$ pip install git+git://github.com/mottosso/Qt.py

Source
Pull request
Issue

Thanks to Matthew Levine for the initial feature request and Fredrik Averpil for the unwavering support. :)
Best,
Marcus

But it's a detail, and I'd be happy to leave all additions to QtCompat if you'd prefer. What do you think?

Nah. I think this is good. :)

Here's what I've got in mind for an announcement on the VFX Platform.

The only addition I'd perhaps do is a simple example of how to detect which binding is being used and then do something binding-specific, such as on this line in the README:
if "PySide" in __binding__:
  do_pyside_stuff()

Very nice stuff! 👍

Agreed and added.

For the time being, and where you need functionality exclusive to any particular binding, such as sip in PyQt, there is still the __binding__ member that allows conditional inclusion.
if "PySide" in __binding__:
  do_pyside_stuff()

This would allow you to explicitly mark the parts of your codebase that depend on any particular binding, and to enable a bridge to your code today and your code sometime in the future when the required functionality is officially part of Qt.py.

Let's do it!


Fix Values.ingress.annotations check

Resolves #206

well, the linter is being a jerk, but I'm going to merge this 'cause it's fine except for the version complaint :)


My sql alchemy

Updates

Hello, this branch has conflicts with the master.  In order to avoid merge conflict in the main branch, please specify the actual changes you are implementing in the request message.


untangle reverse-mode from forward-mode autodiff; include finite diffs

As of Stan 2.4, the code in agrad/fwd has dependencies into agrad/rev and the finite diff code is spread all over.
What I propose is creating four directories under agrad:

finite-diff:  for finite difference code
fwd: forward mode only, no dependency on reverse mode
rev: reverse mode only, no dependency on forward mode
fwd-rev: mixed code that depends on both fwd and rev

and moving pieces into the appropriate place to remove the spaghetti dependencies.

[ ] src/stan/agrad/fwd/matrix/typedefs.hpp includes rev

this was fixed with #1222.


[Feature][zeta][monitoring] Support exposing monitoring metrics by prometheus exporter protocol (#5070)

PR for  #5070
The final effect ： https://github.com/kim-up/incubator-seatunnel/blob/telemetry/docs/en/seatunnel-engine/telemetry.md
Overall Design

Node Hazelcast Metrics
Getting metrics from ManagedExecutorServiceMBean

systemExecutorMBean
asyncExecutorMBean
scheduledExecutorMBean
clientExecutorMBean
clientQueryExecutorMBean
clientBlockingExecutorMBean
queryExecutorMBean
ioExecutorMBean
offloadableExecutorMBean
partitionServiceMBean

Including,  executor_executedCount、executor_isShutdown、executor_maxPoolSize 、executor_poolSize、executor_queueRemainingCapacity、executor_isShutdown、executor_queueSize
Zeta Thread Pool Metrics
Getting metrics from CoordinatorService#(ThreadPoolExecutor) executorService
Including, pool_activeCount、pool_corePoolSize 、pool_maximumPoolSize、pool_poolSize、pool_completedTask_total、pool_task_total
Zeta Job Metrics
Getting metrics from CoordinatorService#(IMap<Object, Object>)runningJobInfoIMap
Including, job count  in various states
Node Jvm Metrics
Getting metrics from io.prometheus.client.hotspot.prometheus.DefaultExports
Including, Memory、BufferPools、Garbage、Thread、ClassLoading、VersionInf
Cluster metrics
Getting metrics from ClusterService
Including, cluster_info、cluster_time

Purpose of this pull request

Check list

[x] Code changed are covered with tests, or it does not need tests for reason:
[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update change log that in connector document. For more details you can refer to connector-v2
Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist

[x] Update the release-note.

Good job.

document has some dead links, please check.

@ic4y @hailin0 @Hisoka-X @EricJoy2048
This feature is not small, may need to discuss further development.

@ic4y @hailin0 @Hisoka-X @EricJoy2048
This feature is not small, may need to discuss further development.

@TyrantLucifer

@liugddx @TyrantLucifer @Hisoka-X @hailin0 @EricJoy2048 PTAL

Can we add the slowoperation metric? It's quite valuable for troubleshooting. You can refer to the Hazelcast Management Center for guidance.

Can we add the slowoperation metric? It's quite valuable for troubleshooting. You can refer to the Hazelcast Management Center for guidance.

Good idea! I will research it later. After the current PR is merged, create a new PR to improve it, because the current PR is relatively large.

We need this feature when does it merged?

@TyrantLucifer @kim-up
we need this feature does it planned to be merged?
Thanks

Please merge the dev branch and wait for ci to run successfully

@TyrantLucifer @kim-up @hailin0
we need this feature too, does it planned to be merged?
Thanks

@kim-up we’re excited to see this merged. Thank you for your contribution.

We should continue push this pr. @kim-up Could you fix conflict？ cc @EricJoy2048 @hailin0

@kim-up I intend to continue this feature of yours, as it has been too long since the last update. I will be creating a new branch and porting your code to implement the necessary changes. Please be aware of this and looking forward to cooperating with you,TKS! :>


Connecting to Python from GH does not work on IronPython 2.7.0 (Rhino version)

(From email, food4rhino)
This happens only when using the IronPython version included in Rhino (2.7.0), adding the IronPython 2.7.5 libraries to Rhino fixes the issue. When trying to connect, fails with:
10. Runtime error (MissingMemberException): 'module' object has no attribute 'async'

11. Traceback:

  line 117, in _get_connection, "C:\Users\Alex\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\ghpythonremote\connectors.py"

  line 36, in __init__, "C:\Users\Alex\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\ghpythonremote\connectors.py"

  line 49, in script

When the async import is fixed, fails with:
11. Runtime error (TypeErrorException): sequence item 1: expected bytes or byte array, str found
12. Traceback:
  line 508, in sync_request, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\core\protocol.py"
  line 549, in root, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\core\protocol.py"
  line 100, in _connect, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\core\service.py"
  line 70, in connect, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\utils\classic.py"
  line 117, in _get_connection, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\ghpythonremote\connectors.py"
  line 49, in script
  line 319, in dump, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\core\brine.py"
  line 235, in _send, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\core\protocol.py"
  line 266, in _send_request, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\core\protocol.py"
  line 195, in on_connect, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\core\service.py"
  line 43, in connect_channel, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\utils\factory.py"
  line 54, in connect_stream, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\utils\factory.py"
  line 93, in connect, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rpyc\utils\factory.py"
  line 36, in __init__, "C:\Users\pcuvil\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\ghpythonremote\connectors.py"

async was renamed to async_, fixed in d288316.
IronPython 2.7.0 does not cast to bytes before joining a list into a bytes, which was fixed in 2.7.5, explaining the different behavior. The issue comes from the brine _dump methods not always returning bytes (strings instead), and so merging into the stream fails. Fixed in pilcru/rpyc@1fddd65cb819772444de315199349e68bbf875ed.


Apply visual filter to the image

When some objects collide or are damaged, they may want to repaint their images somehow. For example, we can create the apply_color method to the VisualEntity. It will accept Color and should repaint the image of the entity.

Already have done) https://github.com/PlatformerTeam/mad/pull/86


chat gpt alert

L bozo skid i hope lightning dies

Bro why do you care so much. What did I even do to you??

Bro why do you care so much. What did I even do to you??

this ChatGPT code is for real???

Bro why do you care so much. What did I even do to you??

this ChatGPT code is for real???

No. My friend @endlessalpacaYT literally watched me code this all, marv is accusing me of having a second monitor, I will happily show my setup

Bro why do you care so much. What did I even do to you??

this ChatGPT code is for real???

No. My friend @endlessalpacaYT literally watched me code this all, marv is accusing me of having a second monitor, I will happily show my setup

Do you have a second monitor?

No.

'skid' hahaha very funny. At least i tried to do something original.
---- On Sun, 13 Oct 2024 21:55:43 +0100 Marvelco @.***> wrote ---
L bozo skid i hope lightning dies
—
Reply to this email directly, https://github.com/optixyt0/Axis-Backend/issues/1, or https://github.com/notifications/unsubscribe-auth/BDX4XSFONO5IGGPLMPVGM7LZ3LM4ZAVCNFSM6AAAAABP3Y4KZSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU4DIMRWGUZTGMI.
You are receiving this because you are subscribed to this thread.


Fixed #59395 - Emmet Syntax Profiles tag_nl produces no extra space

This PR fixes https://github.com/Microsoft/vscode/issues/59395.
With:
"emmet.syntaxProfiles": {
        "html": {
            "tag_nl": false
        }
    },

It no longer allows extra space.
Before:

After:

Thanks for considering this request.

I updated my code to use expandOptions.profile. I'm wondering if you can give me an example of how to change the config in tests. I am having some problems trying to change tag_nl to false.

https://github.com/Microsoft/vscode/blob/release/1.28/extensions/emmet/src/test/abbreviationAction.test.ts#L441 is an example where I changed the config for the emmet.excludeLanguages setting. You can use that as an example.

Thanks for the help. I had to use expandOptions['profile'].format instead of expandOptions['format'] because it didn't seem to produce any properties when tag_nl was set to true.
I also added tests for this feature.

It seems like my commits fail when running the hygiene tests. Is there any way for me to run these tests on my local machine? Running ./scripts/test-integration.sh passes all of the tests.

The hygiene failure was due to formatting errors. I have pushed a change to fix that.

Wrap still produces incorrect results if tag_nl_leaf is false, I believe. (tag_nl_leaf doesn't seem to be respected at all, really, nor does the 'decide' value for tag_nl)

@contentfree I have logged an upstream issue for that. See https://github.com/emmetio/output-profile/issues/1


"Add an OpenID Connect-based single sign-on application" documentation shouldn't rely on app-specific integrations.

This page doesn't document how to set up a generic OIDC app, it documents how to add SmartSheet.  That's not the same.
I don't have access to Entra, as I'm not a SSO admin.  My support team is telling me Entra doesn't support OIDC for Enterprise apps, only SAML and SWA.  Based on this this they're not wrong, Entra apparently does not generally support OIDC on Enterprise Apps because this documentation shows only preconfigured, integrated apps.  If that's not true then hopefully the point of this report is clear.
Please bear in mind when writing these docs the person reading them likely will not have access to the console due to corporate access policies, and even if they do what is available might be masked by incorrect ACLs.  So please do not assume anything is discoverable.

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

ID: 92406442-8660-21d8-c0ce-a29e91351739
Version Independent ID: 70ce205a-9019-2a4a-087e-6b0239e77a21
Content: Add an OpenID Connect-based single sign-on application - Microsoft Entra ID
Content Source: docs/identity/enterprise-apps/add-application-portal-setup-oidc-sso.md
Service: entra-id
Sub-service: enterprise-apps
GitHub Login: @omondiatieno
Microsoft Alias: jomondi

@ag-TJNII
Thanks for your feedback! We will investigate and update as appropriate.

@ag-TJNII
I'm going to assign this to the document author so they can take a look at it accordingly.
@omondiatieno
Can you please check and add your comments on this doc update request as applicable.

@ag-TJNII, thanks for your feedback concerning the OIDC article. We're currently reviewing your feedback internally and if we find that we need to update the article to improve clarity based on your feedback, we'll raise a PR to do so. I'll proceed to close this issue for now. Feel free to reach out in case of anything.
#please-close


Reserved resource name errors - need a workaround

If a repo contains a reserved name, we currently throw this error:

The issue here is "microsoft". Sample app: https://github.com/OfficeDev/microsoft-teams-apps-champion-management

@rajeshkamal5050  @ellismg any thoughts here?

@rajeshkamal5050 @ellismg any thoughts here?

Do you think we can capture ReservedResourceName error as part of the troubleshooting docs to refer here - https://learn.microsoft.com/en-us/azure/azure-resource-manager/troubleshooting/error-reserved-resource-name#cause so users know which part of the string is causing it?

IMO, we shouldn't have to ask people to rename their repos. That's sort of a tall ask.

IMO, we shouldn't have to ask people to rename their repos. That's sort of a tall ask.

Don't think they need to rename repo. It seems to be cause due to a specific IaC resource which they are trying to provision contains name with microsoft in it. Seems the error is coming from ARM and not in Azd
Why do you think its caused due to the repo naming?

I ran into this using the new simplified init flow so perhaps we need to consider this in the IaC we are generating.

cc: @weikanglim

Simplified init uses directory names as the defaults to things like: service name, project name.
We could update the default naming scheme to handle these reserved names as an added line of defense.
Personally, the autogenerated names may not always be what users want either way. And renaming the names should be something worth considering by most users.
This is currently accomplished by the following:

Update the name in azure.yaml
Ctrl + F in VSCode for azd-service-name and update accordingly

That should be all that is needed.


Chore/commitlint

Just an idea - what about moving this to package.json? https://github.com/conventional-changelog/commitlint#config
Less config files (especially when this is just a reference to parent config) may be even better.

Good Idea! But All or Nothing! Eg. we can store all configs in package.json or none of them. If we store there only part of configs it could lead into inconsistency and misleading developers where to store or find the which config is used.
In a near future all configs should be short enough to place them into package.json.

But All or Nothing!

You would say "Better something than nothing" :-D . The root scope is filled with so many config files, making it already a bit confusing so any cleanup would be welcomed to me, but whatever, it was just an idea :) . LGTM!


feat: upgrade to .net 6

Description

Upgrade Framework and Sample Projects to .NET 6
Update C# language version from 9 to 10

Fixes #298  #322
How Has This Been Tested?
Ran both WebApi and Dashboard samples.
Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have added tests to cover my changes (N/A?)
[x] I have made corresponding changes to the documentation (did not find any doc related to the .net versioning will be added in the release notes?)

@joelfoliveira @jose-sousa-8 I think we to target this to a 3.0 branch related to the milestone https://github.com/Farfetch/kafkaflow/milestone/1

please, change the commit and PR message prefix from "feat" to "chore" ;)


verified the lib with random matrices. the lib works well.

This looks like an extra unit test, the cmake file would need to be updated and the makefile removed, then it could be merged.


x/tools/packages: analysis fails completely if a module version cannot be determined

$ go version
ql/src/semmle/go/frameworks/Testing.qll

Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/sauyon/.cache/go-build"
GOENV="/home/sauyon/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/sauyon/devel/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/sauyon/devel/codeql-go/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build836052876=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Try to run tools/packages.Load on any source package that has broken modules.
What did you expect to see?
Some, albeit incomplete, information, especially AST for files that are in the package (and can be resolved).
What did you see instead?
An error.

Can you please provide a simple reproduction that has more detail? It’s unclear what you mean by “broken modules” and saying “An error” is also quite cryptic.
Thanks.
/cc @matloob

Any time modules cannot be resolved, such as with private modules or the following:
module test

go 1.14

require github.com/nonexistent/package v1.1

Running Load will fail with something like
[2020-07-14 09:15:17] [build-err] 2020/07/14 09:15:17 go [-e -json -compiled=true -test=false -export=false -deps=true -find=false -- ./...]: exit status 1: go: errors parsing go.mod:
[2020-07-14 09:15:17] [build-err] /home/sauyon/devel/test/go.mod:5: require github.com/nonexistent/package: git ls-remote -q origin in /home/sauyon/devel/go/pkg/mod/cache/vcs/139553494be65d19324b2f01a845543af52f84ae4003b210e1d50bdd18e263c9: exit status 128:
[2020-07-14 09:15:17] [build-err] 	fatal: could not read Username for 'https://github.com': terminal prompts disabled
[2020-07-14 09:15:17] [build-err] Confirm the import path was entered correctly.

This is probably because this is the behavior of go list -e; perhaps this issue should have been filed for the go list command instead?

@bcmills @jayconrod
Maybe I'm missing all the details, but this seems to be working as intended? In general, loading packages depends on getting the dependencies for the packages being analyzed. If we can't fetch the modules in the dependency tree, we can't get the build list and determine what gets built, which in turn means that we can't do the build.
There might be a way around this if you just want to determine the set of files in a package with the appropriate flags to load (no export data, type information, etc.), but even that is difficult and error-prone.

Building on what @matloob said, a working go.mod file is necessary for loading almost any information about packages. It's necessary just for translating package paths to directories. I'm sure there are cases where we could fail a little more gracefully, but it would take a lot of effort (significant changes in the go command).
I'm not sure I understand the motivation here. Why is it important that this work when go.mod refers to modules that don't exist? Why not fix go.mod first?

I only reported this as a bug because it's a regression from pre-module behavior, which would still give you partial information about the dependencies that were resolved. In this case deleting the go.mod file gives more info, which feels like it shouldn't be the case.

I'm not sure I understand the motivation here. Why is it important that this work when go.mod refers to modules that don't exist? Why not fix go.mod first?

We use packages in our (CodeQL Go)[https://github.com/github/codeql-go] analysis, and our goal is to extract as much information as we can without user input. This sometimes means that dependencies aren't resolved properly (particularly with proprietary codebases). I'd understand if this isn't a priority, but I think it would still be helpful in general from a static analysis tool standpoint.

Okay, thanks for the context. This use case is unfortunately in the category of being difficult enough to support that the effort required to support it wouldn't be worth the gains: we'd have to make major changes to cmd/go to try to continue working even if module loading fails and those changes wouldn't be justified by this use case.
One option you could take if you want incomplete data would be to use the -modfile flag: you could make a version of the go.mod file that either adds replaces or completely removes the broken modules, and use -modfile with that alternative go.mod file. Then module loading will succeed, and your build will fail later on. You might be able to get more information that way.
I'm going to close this as "unfortunate".

That's understandable. I think the workaround should work well enough for our use-case (and frankly if somebody wants full analysis they should figure out their builds anyway...). Thanks!

Glad to hear that the workaround should work. Thanks for the feedback!


Expand Element WaitFors

There are still 3 interfaces that can be implemented for WaitFor, determine which ones should be added

Completed via #221


libspotify is deprecated

As you certainly know, libsotify is deprecated since 2 years and spotify plan to shut it down this year.
Do you have an alternative library for playback on a desktop application? As there is currently only mobile Sdk...

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Nope there is no alternative library that is supported by Spotify.  We're just waiting for them to release the web API they've been promising for years now - don't hold your breath!  When it lands I plan on developing v2 of soundbounce if work & family commitments allow!

the web api is out, as far as i know?

https://github.com/pdaddyo/soundbounce-v2 :)


add contributor/community guidelines on parsl/parsl/readme and elsewhere

I think we should add some contributing guidelines to the readme, perhaps summarizing and pointing to a new section in https://parsl.readthedocs.io/en/latest/index.html
Basically, that we welcome contributions, maybe pointing to the roadmap for some ideas of things we know we want, how contributions should be made (PRs), code style, etc.  Also explaining how to get support, which might be copied from http://parsl-project.org/support
And http://parsl-project.org/support should have the contributor part updated to more than just "follow the project on GitHub"

@kylechard addressed the README part in https://github.com/Parsl/parsl/commit/b51121450a0de0294251a383e3e23c6d00c3f471
We still need address the checklist items two comments above.


luci-app-adblock: Fix visualizzation

Fix wrong visualizzation of runtime information

cc @dibdot

@Ansuel What's wrong with a dummy section header without making a new section? Which type of visualization error will be fixed?
Thanks!

@dibdot This

@Ansuel OK, usually I only use bootstrap ... change looks good, just one change: please rename "dv" variable to "ds" cause it's a section variable - than it's OK from my point of view.
Thank you!


cannot ssh cf apps

Hi, i try to ssh to cf apps with ssh  -p 2222 diego:$(cf app machine-service<EMAIL_ADDRESS>i got<EMAIL_ADDRESS>password:  Permission denied, please try again.
And from ssh-proxy job of the diego_brain vm the following errors.
{"timestamp":"1496342707.673976898","source":"ssh-proxy","message":"ssh-proxy.authentication-failed","log_level":2,"data":{"error":"no auth passed yet","user":"diego:67996643-2578-4279-bcff-c4802ce7f982/1"}}
{"timestamp":"1496342710.995449066","source":"ssh-proxy","message":"ssh-proxy.diego-authenticate.authenticate-starting","log_level":1,"data":{"session":"41"}}
{"timestamp":"1496342710.997464180","source":"ssh-proxy","message":"ssh-proxy.diego-authenticate.do-request.failed-doing-request","log_level":2,"data":{"error":"Post https://bbs.service.cf.internal:8889/v1/actual_lrp_groups/get_by_process_guid_and_index: http: server gave HTTP response to HTTPS client","session":"41.1"}}
{"timestamp":"1496342711.499431849","source":"ssh-proxy","message":"ssh-proxy.diego-authenticate.do-request.failed-doing-request","log_level":2,"data":{"error":"Post https://bbs.service.cf.internal:8889/v1/actual_lrp_groups/get_by_process_guid_and_index: http: server gave HTTP response to HTTPS client","session":"41.1"}}
{"timestamp":"1496342712.001325607","source":"ssh-proxy","message":"ssh-proxy.diego-authenticate.do-request.failed-doing-request","log_level":2,"data":{"error":"Post https://bbs.service.cf.internal:8889/v1/actual_lrp_groups/get_by_process_guid_and_index: http: server gave HTTP response to HTTPS client","session":"41.1"}}
{"timestamp":"1496342712.501556635","source":"ssh-proxy","message":"ssh-proxy.diego-authenticate.building-ssh-permissions-failed","log_level":2,"data":{"error":"Post https://bbs.service.cf.internal:8889/v1/actual_lrp_groups/get_by_process_guid_and_index: http: server gave HTTP response to HTTPS client","session":"41"}}
{"timestamp":"1496342712.501711845","source":"ssh-proxy","message":"ssh-proxy.diego-authenticate.authenticate-finished","log_level":1,"data":{"session":"41"}}
{"timestamp":"1496342712.501757622","source":"ssh-proxy","message":"ssh-proxy.authentication-failed","log_level":2,"data":{"error":"Post https://bbs.service.cf.internal:8889/v1/actual_lrp_groups/get_by_process_guid_and_index: http: server gave HTTP response to HTTPS client","user":"diego:67996643-2578-4279-bcff-c4802ce7f982/1"}}

Could you please help me out to determine what is going on?.
Thank you in advance.

Hi @fghorbel,
Looking at the error messages it seems there is a mismatch between the ssh-proxy configuration and the bbs configuration. If your bbs does not use ssl, then make sure that ssh_proxy.bbs.require_ssl is set to false. If you do want to use ssl, make sure to set the bbs.require_ssl as well as the corresponding certs & properties with the ssh_proxy.bbs prefix.
@jvshahid && @swetharepakula


Fix config for local environment

It is currently not possible to access the Django admin without updating the CSRF_TRUSTED_ORIGINS in the local configuration.
It is also necessary to update some names in the local docker urls.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 91.858%

Totals

Change from base Build<PHONE_NUMBER>8:
0.0%

Covered Lines:
2121

Relevant Lines:
2309

💛  - Coveralls


Need to escape the square brackets '[' & ']'?

in some cases it can be necessary to declare a variable accessor in a input name such as:
<input type="text" name="array[0].something" value="value"/>

If we then want to replace the index (0) with a variable we would get:
<input type="text" name="array[[~input.var default="0"]].something" value="value"/>

The variable is in this case however not output/shown as 0. The tag is printed as is and is not handled by the renderer. This is probably related to escaping the square brackets. How is this done?

This is a use-case that is currently not yet taken in to account I think but it can be easily added without the need to escape anything

Would be great!

example case:
[include:'shared/editor-templates/textarea' id="parts[[~include.part.index default="0"]].content"]

This now works properly.


[BUG] generate_series for months, generates a series for minutes

appears to be a problem with the documentation rather than the code.


codecov.io returning a 503 should not break builds

currently, if https://codecov.io/bash returns a 503, it results in our build pipeline failing.

this hasn't bitten us again in a few months, I think for now things are fine the way they are.


Add localization support to parseValue

The parsing methods is currently US centric. Which is not not great for nearly all other cultures.
This has the following properties:

Parse 1.000,12 as well as 1,000.12.
Parse date entity names using the locale data available.
Prefer dd/mm/yyyy to mm/dd/yyyy in locales given something like 05/05/2022

is there any other way to parse data of different locale?. maybe by setting default locale.
because it is possible to format data into different locales. so it should be possible to parse them as well


trouble installing PySide in pyenv virtualenv using pip

Hi, thanks for a great tool!
As my title suggests, I am having trouble installing PySide in a pyenv virtualenv using pip. Part of the errors I get are
Linking CXX shared library libshiboken-python2.7.so
/usr/bin/ld: /home/demba/.pyenv/versions/2.7.8/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC
/home/demba/.pyenv/versions/2.7.8/lib/libpython2.7.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [libshiboken/libshiboken-python2.7.so.1.2.4] Error 1
make[1]: *** [libshiboken/CMakeFiles/libshiboken.dir/all] Error 2
make: *** [all] Error 2
error: Error compiling shiboken
I am on Ubuntu 14.04.3, 64 bit.
I am able to install PySide fine outside of a virtualenv using pip. Any help would be appreciated. I tried compiling shiboken from source but that did not help.
Thanks,
Demba.

/usr/bin/ld: /home/demba/.pyenv/versions/2.7.8/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC
/home/demba/.pyenv/versions/2.7.8/lib/libpython2.7.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

read the error message.

Thanks for the prompt response. Can you be more precise?

It is saying that your binary isn't built with required compiler options. Read some document and rebuild CPython with those options like this; 'env PYTHON_CFLAGS=-fPIC pyenv install -v 2.7.8'


Addresses pagination not working with render, but only with old include

First of all thanks for great starter theme. Love it.
Describe the bug
Pagination snippet is not rendering with new render tag, but works if you call it with include
To Reproduce
Steps to reproduce the behavior:

Go to account addresses inside user account area
Add some addresses, enough to trigger the pagination render
Pagination is not rendering and .pagination element renders empty

Expected behavior
Pagination showing
Desktop (please complete the following information):

OS: OSX
Browser : All
Version: Latest

Additional context
{% include 'pagination' %} fixes it, but since this is deprecated, i dont know if its good to use include anyomore

@marioloncarek Thanks for the feedback! It is genuinely appreciated 👍
We'll be replacing all of the include tags with render tags very soon. I'll make sure to prioritise this. We should have a new version up in the next few days.

Perfect man!  been looking for vanilla Slate replacement. If you need any help with repos im happy to contribute!

Contributions are always welcome :)
Sorry for the slow action here. We're pretty run off our feet right now. But I assure you an update is on its way.

dont even mention it, take your time :)


Migrate circleci-1.0 to circleci-2.0

This PR migrates the circle-ci from 1.0 to 2.0.
Signed-off-by: Pradeep<EMAIL_ADDRESS>

Codecov Report

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

@@            Coverage Diff             @@
##             staging      #13   +/-   ##
==========================================
  Coverage           ?   44.87%
==========================================
  Files              ?        4
  Lines              ?      332
  Branches           ?        0
==========================================
  Hits               ?      149
  Misses             ?      171
  Partials           ?       12

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 86f1469...03d96cc. Read the comment docs.


Advertise HTTP2 support via ALPN

@nicolasnoble - this may want to be patched into 0.9.

@ejona86 - as discussed.

@jayantkolhe - this will be needed if Android wants to talk to a 0.9 server - WDYT about backporting it?

Seems safe.. Lets backport.. It might help other proxies too...

LGTM.
On Wed, May 27, 2015 at 10:01 AM, Jayant Kolhe<EMAIL_ADDRESS>wrote:

Seems safe.. Lets backport.. It might help other proxies too...
—
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/pull/1764#issuecomment-105995470.


[carry 26348] Update cURL connection example in remote API reference

cURL 7.50 changed the validation for URL's
when using socket connections. cURL 7.4x
did not expect a hostname, whereas cURL
7.5x and above requires a hostname.
See https://github.com/curl/curl/issues/936
This updates the example to take both
versions into account, because cURL 7.4x
is still widely used by distros.
carries #26348
closes #26348

author LGTM


Vagrant ansible environment setup

No need to install the correct version of PHP etc, this small and simple vagrant & ansible script will build a new VM environment.

It looks interesting!

Thanks. I wanted to make it easy for people to setup the project with a few commands without polluting their host machine. This way, it installs everything required in a sandbox (VM) with the correct versions of PHP etc. The code is kept outside the VM on the host machine and mounted (shared) in.

PHP version
vagrant@design-patterns:/vagrant$ php -v
PHP 5.6.11-1+deb.sury.org~trusty+1 (cli)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
    with Xdebug v2.3.2, Copyright (c) 2002-2015, by Derick Rethans

Great idea, but it looks like phansible adds a lot of clutter that we don't need. E.g. why do we need pecl or pear or php-fpm?

I will remove those, then rebuild to test it all again.

:+1:

Thank's.

All suggested changes should be applied now

@domnikl any more changes required on this?

@eddiejaoude it just needed to test it on my machine. Works like a charm. Thanks for the great idea and work!

it just needed to test it on my machine

Sure of course.

Works like a charm.

Great! :smile:

Thanks for the great idea and work!

No problem :+1:


Must it be running in jupyter notebook?

Or any way to export the graph to image files?

You can do
output = model(input)
dot = make_dot(output, params=dict(model.named_parameters()))
dot.format = 'svg'
dot.render()

to export it as a svg file in your working directory.
And if you want to know more I recommend you checking this out.

And if you want to know more I recommend you checking this out.

To understand why graph is rendered and displayed directly one can have a look at Jupyter Notebook section of graphviz's manual.


refactor: #139 removed 'any'

Codecov Report

Merging #141 into master will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #141   +/-   ##
=======================================
  Coverage   99.67%   99.67%
=======================================
  Files          32       32
  Lines        1828     1828
  Branches      103      103
=======================================
  Hits         1822     1822
  Misses          4        4
  Partials        2        2

Impacted Files
Coverage Δ

src/sections/fulfillment-inbound-shipment/codec.ts
100.00% <100.00%> (ø)

src/sections/fulfillment-inbound-shipment/type.ts
96.87% <100.00%> (ø)

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 a593e51...3c30085. Read the comment docs.


Fix checksum for nested sh(wpkh())

Only include it for the outer descriptor and not for the inner one.
This was already considered for sh(wsh(..)), but not for sh(wpkh(..)), which resulted in sh(wpkh(<key>)#<checksum1>)#<checksum2>.

I added a to_string_no_checksum() method to nestable descriptors, to avoid repeating it in the Sh implementation as currently done for sh(wsh()). Let me know if you prefer the previous way this was handled.

I added a to_string_no_checksum() method to nestable descriptors, to avoid repeating it in the Sh implementation as currently done for sh(wsh()). Let me know if you prefer the previous way this was handled.


UI fixes

Solved UI P2 and P3 issues:

#724
#754
#738
#526
#735

@Peersyst conflict to resolve

@Peersyst conflict to resolve

just resolved it


Bug: When opening the post overlay, only part of the image is often displayed (as well as on the post submitting page)

Fixed by 8055843 commit


Bug in useMemo (?)

I noticed a problem with useEffect() - the second argument (changed props) which gets passed on through to useMemo(), is not respected: the effect is triggered every time anything updates; even if the component itself doesn't update and another component on the page does.
As you can see in this example, the component should only update if count has changed - but the effect runs for all three components:

I narrowed it down to to useMemo(), where the last time triggers the change every time:

As you can see, it correctly detects that isChange is false - but still triggers the update, because isMounted is always undefined.
I will try to add a failing test for this problem.

This seems to be a bug. The code here is not very clear. Maybe I need to refactor it.

Same problem as before, but it's not useMemo causing it anymore. 🤔

It could have something to do with the combination of useState and useEffect maybe?
I've been trying to write a test - it should be simple really:
test('useEffect with change detection', async () => {
  let updates = 0

  let effect = () => updates += 1

  const Component = ({ value }) => {
    useEffect(effect, [value])

    return
foo

  }

  await testUpdates([
    { content: <Component value={1}/>, test: () => expect(updates).toBe(1) }, // mounted: should trigger effect
    { content: <Component value={2}/>, test: () => expect(updates).toBe(2) }, // updated: should trigger effect
    { content: <Component value={2}/>, test: () => expect(updates).toBe(2) }, // no change: should NOT trigger effect
  ])
})

For some reason, the test just runs forever, and jest doesn't time out like it should... I have no idea how to fix this. 😐

I seem to know what you mean. Maybe my understanding of useEffect is biased.
Can you send me the url of sandbox? I need to debug the use case. Thank you very much.

https://codesandbox.io/s/fre-demo-uxuic

Looks good now, thanks!


(python3) python3 requires nonexistent python311

Chocolatey Version
1.3.1
Chocolatey License
None
Package Version
3.11.0 -> 3.11.2
Current Behaviour
I was trying to upgrade python3 (dependency of python) to 3.11.2 but it requires a dependency of "python311" which doesn't currently exist, and it fails.
Expected Behaviour
No response
Steps To Reproduce

Try to upgrade python
Unable to resolve dependency

Environment
- Operating System:
- PowerShell Version:
- Shell:

Chocolatey Log
You have python v3.11.0 installed. Version 3.11.2 is available based on your source(s).
Progress: Downloading python3 3.11.2... 100%
python not upgraded. An error occurred during installation:
 Unable to resolve dependency 'python311 (= 3.11.2)'.
python package files upgrade failed with exit code 1. Performing other installation steps.
The upgrade of python was NOT successful.
python not upgraded. An error occurred during installation:
 Unable to resolve dependency 'python311 (= 3.11.2)'.
 Unsuccessful operation for python.
  Rollback to previous version (package files only)?([Y]es/[N]o):

Anything else?
No response

@AdmiringWorm would force pushing 3.11.2 fix this and the other python issue we have (on mobile so can't link to that issue)?

@pauby no, most likely not. It looks like there is a likelihood that there is something wrong with the updater.
I'm investigating what is going on right now.

hmm, it looks like it did try to push 3.11.2 in the past, but my guess is that the push itself failed, but since it successfully pushed 3.12.x it thought it succeeded.
As this issue and #2141 is basically the same, I'll close this one out as a duplicate (fixing one will fix the other).

Duplicate of #2141


catkin_make with devel space fails due to relocation of include paths

Hi everyone,
recently I encountered an issue that seems to be caused by the patch 0001-relocate-dependency-s-headers-to-current-sysroot.patch for catkin.
When building a project with multiple catkin packages with one recipe it happens that the generated cmakeConfig in the catkin devel space use non-existing include paths. This can break the build if headers are installed by an earlier package during the build process.
For example, we have package A and package B, that should be build with one single catkin run. In addition, B uses headers from A. During the build process, catkin creates a devel space, in which a cmakeConfig for A is placed. When package B performs a find_package(catkin COMPONENT A) it finds the aforementioned cmakeConfig. However, the include path in this cmakeConfig is not correct, as it is the joined "${root_path}${includepath}", although ${includepath} is already pointing to the correct directory. As a result, cmake throws a warning and the build fails lateron, due to missing headers.
To fix this issue, I am currently not using the relocation patch. However, since the patch fixes other issues, I believe it would be good to include another fix for builds that rely on the catkin devel space. I am using the latest meta-ros with all patches until yesterday.
Best regards,
Fabian
cmake Warning:
CMake Warning at build/DEVEL/share/MyDatatypes/cmake/packageAConfig.cmake:111 (message):
Project 'MyDatatypes' specifies
'/data/foboril/yocto/project/build/tmp/sysroots/qemux86-64/data/foboril/yocto/project/build/tmp/work/core2-64-poky-linux/new-project/0.1.20-r0/build/DEVEL/include'
as an include dir, which is not found.  It does neither exist as an
absolute directory nor in
'/data/foboril/yocto/project/build/tmp/work/core2-64-poky-linux/new-project/0.1.20-r0/generated/packageA//data/foboril/yocto/project/build/tmp/sysroots/qemux86-64/data/foboril/yocto/project/build/tmp/work/core2-64-poky-linux/new-project/0.1.20-r0/build/DEVEL/include'.
Ask the maintainer 'todo<EMAIL_ADDRESS>to fix it.
Call Stack (most recent call first):
/data/foboril/yocto/project/build/tmp/sysroots/x86_64-linux/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:76 (find_package)
generated/packageB/CMakeLists.txt:16 (find_package)

Can you please link to the mentioned patch. Also please provide exact steps to reproduce your case. Otherwise it is almost impossible to give any specific feedback.

Sorry. I send this issue by mistake to the wrong place.


Add Python syntax highlighting

This is very minor, but the blue 'n' on this page was eating away at my soul :)

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Cannot find module 'node-telegram-bot-api'

npm --max_old_space_size=128 start

<EMAIL_ADDRESS>start /root/aria-telegram-mirror-bot
node index.js

module.js:478
throw err;
^
Error: Cannot find module 'node-telegram-bot-api'
at Function.Module._resolveFilename (module.js:476:15)
at Function.Module._load (module.js:424:25)
at Module.require (module.js:504:17)
at require (internal/module.js:20:19)
at Object. (/root/aria-telegram-mirror-bot/index.js:1:83)
at Module._compile (module.js:577:32)
at Object.Module._extensions..js (module.js:586:10)
at Module.load (module.js:494:32)
at tryModuleLoad (module.js:453:12)
at Function.Module._load (module.js:445:3)
npm ERR! Linux 3.10.0-957.10.1.el7.x86_64
npm ERR! argv "/usr/bin/node" "/bin/npm" "--max_old_space_size=128" "start"
npm ERR! node v6.16.0
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'node index.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the mirror-bot package,
npm ERR! not with npm itself.
npm ERR!     node index.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs mirror-bot
npm ERR! Or if that isn't available, you can get their info via:

You forgot to run npm install first.

I have run it already, but this issue is still there

npm install
Killed.............] | fetchMetadata: sill mapToRegistry uri https://registry.npmjs.org/tough-cookie

You seem to be using a VPS. How much RAM does it have? The bot itself can't upload large file with less than 1GB, and I'd expect npm to have problems, too. If it's a VPS, try increasing RAM, else use a larger swap.

f1-micro (1 vCPU, 0.6 GB memory)
Ok, I upgrade it immediately.

node-telegram-bot-api deprecated Automatic enabling of cancellation of promises is deprecated.
In the future, you will have to enable it yourself.
See https://github.com/yagop/node-telegram-bot-api/issues/319. module.js:577:32
/root/aria-telegram-mirror-bot/drive/upload-file.js:114
request(options, async function (error, response, body) {
^^^^^
SyntaxError: missing ) after argument list
at createScript (vm.js:56:10)
at Object.runInThisContext (vm.js:97:10)
at Module._compile (module.js:549:28)
at Object.Module._extensions..js (module.js:586:10)
at Module.load (module.js:494:32)
at tryModuleLoad (module.js:453:12)
at Function.Module._load (module.js:445:3)
at Module.require (module.js:504:17)
at require (internal/module.js:20:19)
at Object. (/root/aria-telegram-mirror-bot/drive/drive-upload.js:3:19)
at Module._compile (module.js:577:32)
at Object.Module._extensions..js (module.js:586:10)
at Module.load (module.js:494:32)
at tryModuleLoad (module.js:453:12)
at Function.Module._load (module.js:445:3)
at Module.require (module.js:504:17)
at require (internal/module.js:20:19)
at Object. (/root/aria-telegram-mirror-bot/fs-walk.js:3:16)
at Module._compile (module.js:577:32)
at Object.Module._extensions..js (module.js:586:10)
at Module.load (module.js:494:32)
at tryModuleLoad (module.js:453:12)
npm ERR! Linux 3.10.0-957.12.2.el7.x86_64
npm ERR! argv "/usr/bin/node" "/bin/npm" "--max_old_space_size=128" "start"
npm ERR! node v6.16.0
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: node index.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'node index.js'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the mirror-bot package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node index.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs mirror-bot
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls mirror-bot
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /root/aria-telegram-mirror-bot/npm-debug.log

aria-telegram-mirror-bot]# npm install
Killed.............] | fetchMetadata: sill mapToRegistry uri https://registry.npmjs.org/tough-cookie

Tried running npm install with sudo ?

Are you sure that you didn't make any changes to the source? There aren't any SyntaxErrors here.


[Feature Request]: Agent Step Iterator

Feature Description
Hey folks,
What do you think about having the new native Agent classes able to yield/stream all their steps (function calls, thoughts, observations, etc) rather than just the final output? I've been digging through the source code after this was mentioned in passing in the docs, but I don't see this implemented yet.
A colleague and I implemented a similar thing in a PR for Langchain, so this is definitely something we could either help the established devs with if it is already in the pipeline here, or take the lead on if not.
Reason
I don't think there's anything stopping this structurally, it just requires modifying some internals.
The places that would need adapted would be the stream_chat method for example here:
https://github.com/jerryjliu/llama_index/blob/be0ded30701f45bd097b30a00fa93d2cdf06a592/llama_index/agent/openai_agent.py#L141
And (potentially?) the StreamingAgentChatResponse here.
https://github.com/jerryjliu/llama_index/blob/be0ded30701f45bd097b30a00fa93d2cdf06a592/llama_index/chat_engine/types.py#L27
Value of Feature
This is super valuable to us because it's generally useful to be able to hook into the whole  "reasoning" process, both for debugging and for transparency in a chat interface. If only the final answer is revealed and it happens to be wrong, it is harder to understand where the problem lies. When talking to an agent in an interactive setting, we can also see and potentially interrupt and guide its trajectory earlier and with finer detail if we can resolve each step. Imagine a chat where one can elect to see/sort/modify function calls / tool outputs / intermediate "thoughts".

Definitely would be a good feature.
Originally we had the stream_chat function return a generator of generators for each step, but tbh it made the interface pretty complicated, especially compared to the existing streaming options in the library
Since the OpenAI agent doesn't have any internal reasoning really (since all the reasoning happens in the function calling api), you can actually see the decisions in the chat history (i.e. which tools it called), as well as a list of all tool sources (i.e. tool inputs/outputs) in the response.sources. This has a list of ToolOutput objects which contain the raw tool inputs and outputs
However for the react agent, this is a different story, looks like it wasn't updated to track tool sources yet

Hey @logan-markewich, thanks for the insight. Yeah I can understand the nested generator UX being a bit janky, I tried something similar this evening and I can totally understand why it should not be the default.
I had a closer look at the code following your comments and I see now (if i'm understanding correctly) that the chat_history is updated in a separate thread running write_response_to_history, which itself uses streaming. With the current interface one can retrieve the function/tool call details as you point out, but it seems only after the threads have finished.
Assuming stream_chat is to be untouched then, off the top of my head some possible options which come to mind are:

(Re-)implement the nested generator version as another advanced method for this use case without touching stream_chat (slight disadvantage for maintainability, although some refactoring could make this and the current stream_chat rely on largely the same building blocks)

One way could be to introduce a method which wraps stream_chat, but intercepts the chat_history while the individual function call messages are being streamed into it from inside threads, and yield from these.

Implement a callback inside the StreamingAgentChatResponse something like this:

  @dataclass
class StreamingAgentChatResponse:
    """Streaming chat response to user and writing to chat history."""
    # ...
    callback: Optional[Callable[[Any], None]] = None

  def write_response_to_history(self, memory: BaseMemory) -> None:
      # ...
      for chat in self.chat_stream:
          # ...
          if self.callback is not None:
              self.callback(chat.delta)

  # ... in application logic
  def send_to_chatbox(output):
    # ...

chat_stream_response = StreamingAgentChatResponse(
    chat_stream=self._llm.stream_chat(all_messages, functions=functions),
    callback=send_to_chatbox,
)

(After writing it out this second idea feels convoluted, as the streaming of the final response and the intermediate steps are handled completely differently, and one would also have to make such a callback aware of the instance of the StreamingAgentChatResponse it was called from to distinguish different "parent" messages/function calls).
Would be very happy to hear your thoughts on what an elegant solution might look like for you all.

Yea both approaches make some sense, but yea the second one could be complicated ha!
I actually don't mind the first idea though. Although I'm also hesitant to add more functions to the interface, because right now the main four (chat/achat/stream_chat/astream_chat) are all mostly duplicates of each-other.
Tbh, if you are interested in contributing here and working on this, there's a few issues/tech debt that I'd love to solve and just haven't had time to look at:

major code duplication across 4 functions (and possibly 5-6 with these suggestions!)
callbacks un-aware of parents (and also not quite working for async, ha!)

I think if either of those are solved, then adding intermediate responses should be a little more straightforward/less scary 💪🏻

Just checking in to say @Lacico and I have been working on a PR to address the tech debt / refactoring point - useful exercise to learn the nitty gritty of the internals anyway - will share it with you soon once we've tested it a bit more.

Amazing @SlapDrone thanks a ton for tackling some of this!! ❤🦙


Yabai interferes with SoundSource menus and does not show them in query

Hi, and thank you for a maji yabai window manager!
Version: fe86f24
macOS 12.1, M1 Pro processor
I am using SoundSource for sound device management.
Unfortunately, with yabai on, this happens:
https://user-images.githubusercontent.com/1571309/150977847-e8fd3528-9d02-477e-9c71-96a68a5d1c26.mov
Instead of this:
https://user-images.githubusercontent.com/1571309/150977870-6df20a98-49be-4b4a-bb05-432157a0e3ab.mov
I cannot exclude this window (or I don't know how, at least) with yabai -m rule since the window appears in neither yabai -m query --windows | jq 'map(.pid)' nor yabai -m query --windows | jq 'map(.window).
Please let me know what debug info I could provide.
Thanks!

have you tried running the query command using watch -n1 then triggering the popup? it should show in the list while it is visible.

have you tried running the query command using watch -n1 then triggering the popup? it should show in the list while it is visible.

Thanks - yes I did. In fact, the other menus from the top bar (like Wi-Fi, Battery, etc.) do not trigger any change as well.

System menus won't, but in general third party menus seem to. I don't have SoundSource handy to test with unfortunately (it may be using a new API or something), but can confirm things like iStat Menus create a window.

Ah, you're right, iStat Menus creates it on my computer as well. I even created a rule for that :)

I run SoundSource, too, and don't have that issue.  All you're doing is disabling Yabai to make the SoundSource child picker work normally?

Hi all, it struck me to disable window_topmost in my config, and that helped with this issue. While it's a shame, since I like that setting, yabai is back to being usable for me :)

Would love for there to be a solution to this, it's quite a significant issue!

I have this issue with Firefox when window_topmost is on.

Fixed in v6.0.0 #1887


Package dependancies are not installed when "*" is ignored in bower.json.

Consider the following bower.json file residing in project_root/packageA:
}
    "ignore": ["*"],
    "dependencies": {
        "some-dependancy": "0.0.0",
    }
}

And this bower.json in project_root:
}
    "dependencies": {
        "packageA": "./packageA",
    }
}

Running bower install in project_root should install packageA with only a .bower.json file and all of packageA's dependancies.   So we would expect project_root/bower_components to look like this:
packageA
  - .bower.json
some-dependancy
  ...

However, packageA's dependancies are not installed, only a directory for packageA with a .bower.json file.   Has someting changed?  Is there any reason for this behavior?  Can we get this to behave as expected?

AFAIK this is expected behavior unless @sheerun says otherwise. This might help you: https://stackoverflow.com/questions/21225803/recursive-bower-install


This is great. But is possible for rpm package?

This is great.I like it on Ubuntu.
But I still work on fedora, is possible for rpm package?

Hello. The rpm packages do not support yet. But you can build program from sources whith qt/qmake and g++.


Fix sanitycheck failures for v2m_musca_b1_nonsecure

We've currently disabled sanitycheck from running on v2m_musca_b1_nonsecure (see boards/arm/v2m_musca_b1/v2m_musca_b1_nonsecure.yaml).
If you remove the sanitycheck: false line in v2m_musca_b1_nonsecure.yaml:
./scripts/sanitycheck -p v2m_musca_b1_nonsecure:
JOBS: 64
Cleaning output directory /home/galak/git/zephyr/sanity-out
Building testcase defconfigs...

Fixed by #15595


Support OIDC Client Authentication

Globally support OIDC Client Authentication, this is for output sinks proxied by something like OAuth2-Proxy

attempt to support .well-known/oidc-configuration

What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area config
/area outputs
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #712
Special notes for your reviewer:

Welcome @dmolik! It looks like this is your first PR to falcosecurity/falcosidekick 🎉

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: dmolik
Once this PR has been reviewed and has the lgtm label, please assign leogr for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Interesting proposal, thnaks. I edited the title to specify it's a WIP, ping when you want a deeper review. Thanks. I enabled the CI btw.

Adding label do-not-merge/contains-merge-commits because PR contains merge commits, which are not allowed in this repository.
Use git rebase to reapply your commits on top of the target branch. Detailed instructions for doing so can be found here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

LGTM label has been added.  Git tree hash: e3c4fa41292b36ea2a39a75d580d3986d6e4e9e6

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: dmolik, Issif
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Issif]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/remove-approve

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: dmolik
Once this PR has been reviewed and has the lgtm label, please ask for approval from issif. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

What's the status on your side for this PR? Is it ready for a review?

I'm going to merge main again, and test locally via minikube, I'll let you know in a day or two.

Hi,
are you still working on that PR?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle stale

/remove-lifecycle stale

@dmolik are you still working on this PR? you need to rebase on the master, a lot of changes have been made since your last commits. I would like to release the 2.30 in the next weeks, I prefer to post-pone your proposal to the 2.31 anyway


[DO-NOT-MERGE] Record strace of "ip netns add"

This PR replaces the "ip netns add ..." command in the TestByPing script with "strace ip netns add ...". For each attachment, the output of strace is added to an additional field of Status.PostCreateExec.

e1d68ee adds the "-x" flag so that strace prints NETLINK messages in base 16. This is needed because we'll use pyroute2 to convert NETLINK messages to a human-readable format, and pyroute2 expects messages to be in base 16.

1st commit erroneously removed it, force-push correctly re-added it.

Closing this as the targeted problem was solved, and it was never meant to be merged.


Error when trying to open .splat file

Hi. Could you please tell me what's wrong with this splat file?
https://www.dropbox.com/scl/fi/be18cj4ord79hy37uyqh2/whitehouse.splat?rlkey=9bf19cuj2mq898aq0fbo2s3ij&st=ete286ie&dl=0
When I try to open it in the demo I get the following error:

And when I do this using npm package I get the following error:

I see the same issue when I try to load your .splat file locally. I'm guessing there is something wrong with the format; I can load the .splat files from the antimatter15 demo just fine.

@AlexRynas, your .splat misses header info


Doc added instructions for Git LFS support

Under Docs Usage menu, added an article on how to enable Git LFS support. It's actually easy, but it took me a long time to figure out when I first installed gitea.

Codecov Report

Merging #8391 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #8391   +/-   ##
=======================================
  Coverage   41.79%   41.79%
=======================================
  Files         497      497
  Lines       65603    65603
=======================================
  Hits        27420    27420
  Misses      34667    34667
  Partials     3516     3516

Impacted Files
Coverage Δ

models/repo_indexer.go
66.27% <0%> (-1.94%)
:arrow_down:

modules/log/event.go
64.61% <0%> (-1.03%)
:arrow_down:

models/repo_list.go
74.14% <0%> (+0.97%)
:arrow_up:

modules/process/manager.go
81.15% <0%> (+4.34%)
:arrow_up:

models/unit.go
67.56% <0%> (+5.4%)
:arrow_up:

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 8a82850...083ffcb. Read the comment docs.


New container image for ArangoDB framework (bugfix).

This fixes a bug with persistent volumes and ownership of files.

thanks for the PR @neunhoef but you don't need to open a separate PR for version-3.x branch. I'll be rebasing this branch when we are ready for it to take over as the default branch.  Version-2.x branch is the only branch supported in production at this time.


Installing doctor on windows causes high cpu utilization

Windows 10
Since installing docker and doctor i've had this service pegging my CPU constantly, this occurs even when not running docker/doctor.

Killing this process solves the problem until it restarts itself some amount of minutes later.
See this issue. It's my only other info. Anyone have any insight?

Will investigate.

I uninstalled docker but it had no effect.
Once i uninstalled HyperV that resolved the issue. As it's not a Doctor issue it's probably closeable.

yep. I read the documentation about this. Closing this issue hence.


[vsgimgui] New port

[x] Changes comply with the maintainer guide
[x] The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
[x] Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
[x] The versioning scheme in vcpkg.json matches what upstream says.
[x] The license declaration in vcpkg.json matches what upstream says.
[x] The installed as the "copyright" file matches what upstream says.
[x] The source code of the component installed comes from an authoritative source.
[x] The generated "usage text" is accurate. See adding-usage for context.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is in the new port's versions file.
[x] Only one version is added to each modified port's versions file.

CI reports a regression on vcpkg-ci-opencv and vcpkg-ci-openimageio, but I'm not sure what the reason for that is. Those aren't related to this port at all.

/azp run

Is there anything that might cause those test ports to spuriously fail? It's strange that two other PRs I made at the same time didn't fail on that CI test.

Is there something that I might need to do for this? I'm not sure why the CI pipeline is trying to build nearly 1000 packages, or why those two CI test ports are failing, and I can't reproduce those failures.

To reduce the patch size and to make it more flexible, please use file(REMOVE "${SOURCE_PATH}/<...>/imgui.h") in the portfile.

That does sound like a better way to do it. I'll try that out.

I can't repro the CI error locally, I can install vcpkg-ci-openimageio:x64-windows succeed locally. cc @BillyONeal for response, could you help take a look the CI pipeline on this PR?


Make StorageClass parameters available to Delete()

Custom provisioners may require the StorageParams parameters when deleting a volume (e.g. to access a storage system's management API for deleting).

Instead, could you store the parameters in the PV annotations when you Provision? That way you can Delete the PV's storage asset even if the StorageClass is somehow modified or deleted

@wongma7: I've implemented your suggestion in my custom provisioner, and it works well. This is no longer required.


interactivePanGestureDissmisalDireciton misspelled

Just a silly thing, interactivePanGestureDissmisalDireciton is misspelled, it should be interactivePanGestureDissmisalDirection

Michał, I just opened a pull request for this, less work for you ;)