Considerations on interoperability and evolution

What are the plans, if any, to ensure the SSSOM TSV format remains interoperable

across versions (a file produced with an implementation conforming to version X can be used by an implementation conforming to version X+1),
across implementations (a file produced by implementation X — e.g. sssom-py — can be used another implementation Y — e.g. sssom-java)?

Currently, this interoperability goal is explicitly not sought after, as indicated both by the lower-than-one major version number (which, if we assume the project is using semantic versioning, means that anything can change at any time) and by the explicit warning on the top-level README: Note that SSSOM is currently under development and subject to change.
With the SSSOM format being seemingly more and more used in the wild, I believe it is time to consider committing to some form of long-term stability of the format, and/or design ways to make the format evolve while preserving some basic interoperability across versions and implementations.
The following is a random set of ideas that could be explored. Feel free to discuss them, refute them, and add more.
Defining a “core” set of metadata that will never change
We could select a handful of the most important mapping metadata and promote them to a “core set” that would be guaranteed never to change in any future evolution. This is similar to the “minimal spec” idea, though it could probably include slightly more metadata slots than the four mentioned in that ticket.
The principle here is that potential users could be confident that, no matter how the format evolves over time, as long as they only use the “core set” their files would always remain exploitable by any version of any conforming implementation. For users who need metadata from the “non-core set”, the situation would be the same as it is now for the entire standard: they would need to watch carefully the evolution of the standard to avoid being surprised by a breaking change.
For implementations, this would mean that they should only be strict when parsing the “core” metadata (at least by default — of course they can choose to allow users to specify a different behaviour). If they encounter a metadata slot they don’t recognise (because it’s an addition from a newer version of the spec), or a slot whose format has changed (e.g. because of a change such as the one envisioned here, they may log a warning but should not fail altogether to parse the file.
Allow each set to declare its own “must-understand” slots
This can be seen as a variation of the “core set” idea. Here, instead of having a fixed list of “core” metadata slots, the creators of a mapping set could define their own list of the slots they consider as critical.
For example, considering the following set (and assuming that the similarity_threshold slot, proposed here, and the mapping_chain_intermediate slot, proposed here, have been added to a later version of the spec):
# must-understand:
#   - mapping_chain_intermediate
subject_id	predicate_id	predicate_modifier	object_id	mapping_justification	similarity_threshold	mapping_chain_intermediate
EXA:1234	skos:exactMatch	Not	EXB:5678	semapv:ManualMappingCuration	0.8	EXC:4321

An implementation trying to read that file would first check the list of the “must-understand” slots for any slot that it does not recognise, and should flatly reject the file if it does contain such a slot.
So, an implementation up-to-date with the latest version of the spec (and thus, which supports both mapping_chain_intermediate and similarity_threshold) would parse the file without any issue. An implementation that for whatever reason does not recognise mapping_chain_intermediate (maybe because it has not been updated to catch up with the latest version of the spec yet) should immediately fail with an error.
Adding a slot for the spec version
We could add a simple sssom-version metadata slot at the mapping set level, to indicate the version of the spec this set is conforming to. Ideally that slot would be required to be the very first slot listed in the metadata block, so that a parser could figure out immediately whether the file it is trying to read is using a version it supports.
It would be up to the implementations to decide whether they want to support several versions at the same time or not.
Versioning the format in addition to the spec
Regardless of whether we add a versioning slot, it could be useful to introduce a version number for the file format, distinct from the version number of the specification. Not all changes to the specification have an impact on the file format, so tracking the evolution of the spec separately from the evolution of the format would make sense.

This is of great concern to me as well, and related to https://github.com/mapping-commons/sssom/issues/189.
I do not know the best answer to any of your questions, and I am happy to yield to advice by more experienced people in standards management. Here is my rough sense:

Allow each set to declare its own “must-understand” slots

Seem to be too complicated to implement in practice.

Adding a slot for the spec version

I think this is a very good idea. Even if you cant open a specific version of an (older) file, this could give a hand which tool sssom-py, sssom-java version could deal with this. I would support such a slot potentially even as "mandatory".

Core slots

This is my cautious weak position:

I think the idea is good. We have a notion of core properties in sssom-py which are all required properties, plus predicate_modifier. We could stableise these right now. But how do we communicate this?
We should probably agree that file format breaking changes should always require a new major version upgrade, while format changes that do not affect parsing (metadata etc) could be dealt with by minor version updates. This means that all file formats are intrinsically tied to a major release of SSSOM, say 1.0, 2.0 etc.

I think we are on the same page regarding where we are going with this. We need a little to substantiate this understanding:

Currently, the two are completely intertwined, because the file format is basically a direct serialisation of the data model.

As far as I understand, this is only really true for the YAML serialisation, which we have not promoted much at all; I think the "mapping" from the data model to their serialisations is done via transformation procedures. So there is actually a double risk: not only can the changes to the datamodel directly affect json and rdf serialisations, but also changes to the transformation procedures. So I now think we should probably do as you say:

Define serialisation versions
Tie them to specific versions of linkml transform (this has the ugly ugly ugly consequence that we need to pin any specific version of sssom-py to a specific version of linkml-runtime) and sssom-schema
Add unit tests for each release when updating linkml (deliberately) to ensure the serialisation does not change.

Ugh.. You are shining some torchlight into the underdark @gouttegd..

As far as I understand, this is only really true for the YAML serialisation

It is also partially the case for the SSSOM-TSV format, with sssom-py.
When writing a SSSOM-TSV file, sssom-py writes the metadata block by basically dumping the metadata dictionary as it is (yaml.safe_dump(meta)) and writes the TSV part by basically dumping the Pandas data frame (msdf.df.to_csv()). So what’s written is a direct serialisation of the SSSOM data model, so there’s no room for the serialisation format and the data model to diverge.
The good news is that when reading though, sssom-py first loads the metadata block and the TSV rows as they are, and then compares them with what it expects from the SSSOM schema – meaning that here it would be possible from the serialisation format to diverge from the data model, because the parser could perform any necessary “translation” (for example, replace owl class by owl:Class, if we take again the example of #323).

I think the "mapping" from the data model to their serialisations is done via transformation procedures.

Unless I missed something, I don’t think so, at least not for SSSOM-TSV and not in the current version of sssom-py.

Tie them to specific versions of linkml transform

Please don’t. The serialisation format should be specified on its own, without any reference to any LinkML stuff.
Reference to LinkML is precisely the problem with the JSON serialisation format (#321). The “specification” just says, “the JSON format is whatever LinkML’s serialisation procedures do.” In effect this makes this format impossible to implement in any language that does not have decent LinkML support (so, any language other than Python¹).

¹Yeah, I know, “LinkML is definitely not only for Python developers”… Believe that if you want. As someone who has been implementing two LinkML-defined projects in Java,  I can tell you the support for other languages in LinkML is symbolic at most. Make the SSSOM serialisation format entirely dependent on the LinkML runtime and the only result will be that nobody will ever try to support SSSOM in any other language than Python — which would mean for example no more SSSOM plugin for ROBOT.

Unless I missed something, I don’t think so, at least not for SSSOM-TSV and not in the current version of sssom-py.

sssom TSV is indeed different, for all other serialisations though, it is true.
As always, all you say is sane and we should go this way. What is the best way to document the file format independently of the schema though? I thought this is precisely what the LinkML JSON Schema export was for.
Before we start with anything, we should probably build a library of examples and, similar to ROBOT, build a test suite that ensures that with every release, we do not break serialisation expectations..

As always, all you say is sane and we should go this way.

Err, which way? My mind is not set on any way in particular (sorry if I gave the impression it was), I was merely throwing ideas. ^^'

What is the best way to document the file format independently of the schema though?

The documentation/specification does not need to be completely “independent of the schema”. What it must be (and that’s the only aspect on which I do have a firm opinion) is to be independent of the LinkML runtime – that is, it must not do what the description of the JSON format is doing. The SSSOM-TSV format is currently described independently of the runtime, and it should remain so.
In fact, the way the SSSOM-TSV format is currently specified is pretty good, I think. It’s a textual description that refers to the LinkML schema when needed (e.g., to avoid manually listing all the metadata fields or the meaning of some enumeration values).
What needs to be decided is if we want to allow the SSSOM-TSV format to deviate from the schema for backwards-compatibility reasons, so that the format (or rather, its parsers) can act as a compatibility layer that shields users from breaking changes in the schema.
If we want do to that, it can be done simply by adding a section in the spec that would say something like

Compatibility with previous versions
In addition to the columns described in the metadata table mentioned above, a compliant parser MUST be ready to accept the following columns from previous versions of the specification:
match_type
This column was used to indicate how a mapping had been asserted in versions prior to 0.9.1. If it is present, the parser MUST silently convert it to a mapping_justification slot using the following table:

Lexical -> semapv:LexicalMatching
HumanCurated -> semapv:ManualMappingCuration
[etc.]

match_term_type
This column was used to describe the type of entities being matched. It was replaced in SSSOM 0.9.1 by two distinct columns subject_type and object_type. If it present, the parser MUST convert it to those two columns using the following table:

ClassMatch -> owl class
ConceptMatch -> skos concept

Of course, this is only an example. These changes occurred before version 1.0, so it would be fine not to guarantee backwards compatibility in this case. But this illustrates how we could do it if we need to introduce breaking changes after version 1.0.

What needs to be decided is if we want to allow the SSSOM-TSV format to deviate from the schema for backwards-compatibility reasons

If we do not want to do that (that is, we want the SSSOM-TSV format to always follow closely the schema, as it currently does), then I think that adding a version number to the metadata becomes necessary.

Trying to summarise the options:

Backwards compatibility is out of scope for the specification.

We decide that the spec simply does not care about backwards compatibility. The spec is only ever about the latest (current) version. We update the schema as we see fit. At most, we promise, once version 1.0 is out, to break things as rarely as possible. But backwards compatibility is entirely left at the discretion of the implementations: some may only support the latest version of the spec, other may try to do their best to support previous versions as well.

Backwards compatibility is out of scope, but with a version number.

Basically same as option 1), but we do add a sssom_version field to the dataset metadata so that implementations can at least immediately know whether the file they are trying to read is using a version of the model that they support (instead of figuring that out the hard way, for example upon encountering a metadata slot that they do not recognise). It is again left at the discretion of the implementations whether they want to support older versions and how they do so.
Both options 1 and 2 do not require the SSSOM-TSV format to deviate from the data model.

Backwards compatibility is a spec feature

The spec explicitly a) allows, b) encourages, or c) mandates (pick one option) implementations to support older versions. The SSSOM-TSV format is allowed to deviate from the latest data model. Every new version of the spec includes some backwards compatibility notes describing what has changed, what old metadata slots are no longer present in the data model but may still be found in SSSOM-TSV files, and how to deal with such slots (e.g. how to convert them to the current data model).
A sssom_version metadata slot, as in option 2, would also be nice here, though not indispensable.
I am inclined towards option 3b, personally.

Err, which way? My mind is not set on any way in particular (sorry if I gave the impression it was), I was merely throwing ideas. ^^'

Sorry I should have referred to your quote on not tying to a specific linkml runtime version. :D

What needs to be decided is if we want to allow the SSSOM-TSV format to deviate from the schema for backwards-compatibility reasons, so that the format (or rather, its parsers) can act as a compatibility layer that shields users from breaking changes in the schema.
If we want do to that, it can be done simply by adding a section in the spec that would say something like

I think we could do something like that. Of course, this approach will also have certain limits (for example, if the free field (not enum) changes from string to entityref datatype, and you don't know all the possible values like in the match_type case))
I think we can go this way.

If we do not want to do that (that is, we want the SSSOM-TSV format to always follow closely the schema, as it currently does), then I think that adding a version number to the metadata becomes necessary

I think we should do that anyways. Making this an optional property that defaults to the latest version.

Trying to summarise the options:

Great summary!
Can you play the following through: what exactly would happen if an uncontrolled field (no fixed values) is changed from type string to type EntityRef? This happened twice in the past, with subject_source and mapping_justification (aka match_type). Are you saying that when writing file where a value is still a string, the reference writers

Will try to repair the value silently if not ambiguous
Will be forced to write the value as it was (maybe printing a warning)

I am not against encouraging implementors to support older versions, but I fear that this will create a big communication overhead (with resources that have their own parsers). Every more small variants of the file formats will make the parser requirements ever more complex. Validation methods will become stranger too, as the parsers required for validation are very much tied to the schema at the moment (linkml validate). I am personally more inclined towards (2), so far.

this approach will also have certain limits (for example, if the free field (not enum) changes from string to entityref datatype, and you don't know all the possible values like in the match_type case))

Yes. Depending on the breaking changes we introduce, there will not always be a straightforward way to ensure backwards compatibility.

what exactly would happen if an uncontrolled field (no fixed values) is changed from type string to type EntityRef?

 :)
There is no pre-defined answer. Every time we introduce a breaking change, we’ll have to consider what could/should be done.
That may depend on many things, such as:

Is the field that we are breaking an “important” field? For example, when match_type  was replaced by mapping_justification, this was touching a very important field. For such a field, we should probably go to greater length to ensure compatibility than for a more “minor” field.
Do we have any idea of how widely the field has been used in the wild?
For an uncontrolled field, is there a way we could get a glimpse of how it has been used (what type of values people put in it)?
When the field had been used, what has it been used for?

What should probably be done to get some answers to at least some of these questions is to advertise beforehand our intention to change the field (e.g. on a GitHub ticket, with call to comments on Slack and any other channel you can think of).
And then, we decide: if we go ahead with the changes, and if yes, how do we suggest / recommend / mandate that implementations deal with the change. Options may include:

Don’t even try to deal with it. It’s only a minor field, just ignore it. Print a warning if you want, but then forget it and process the rest of the mapping set normally.
Don’t even try to deal with it. It’s a field that is too important for you to try to guess how to convert it to the new model. Just abort immediately if you come across the old field. Leave it to the user to amend her mapping set with the new field. Point her to this very helpful page we have prepared in which we explain the issue.
Use the table below that lists some commonly used values for this field along with the EntityRef that should now be used instead. If the mapping set your parsing contains values that are not in this list, use the special value semapv:IHaveNoIdeaWhatThisIsAbout, print a warning, but keep parsing the mapping set.

Validation methods will become stranger too, as the parsers required for validation are very much tied to the schema at the moment (linkml validate)

That is not a problem as long as validation happens after any compatibility preprocessing.
For example, if a mapping set is still using match_type, the compatibility layer in the parser will convert that to mapping_justification, and then the validator will only ever see mapping_justification. The validator needs not be changed in any way; it can remain aware only of the latest version of the schema.

I am personally more inclined towards (2)

The main difference between (2) and (3a) is that, while in both cases backwards compatibility is entirely optional, in (3a) at least the spec provides informations about how to do it.
Basically, option (2) is: “This document only describes the latest version of the spec. You MUST support that version as described here. It’s entirely up to you whether you want to support older versions, but if you do, it’s up to you to dig up older versions of this document, figure out what has changed, and coming up with a way to deal with those changes. Have fun!”
Option (3a) is: “This document describes the latest version of the spec. You MUST support that version as described here. You MAY support older versions if you want, it’s up to you. If you want to do that, please refer to the COMPATIBILITY WITH OLDER VERSIONS section below for details of what has changed in the last version and hints on how to deal with older versions.”
One issue with option (2) is that if you leave each implementations come up with their own solutions, well… they will each come up with their own solutions, which may very well be completely different from one implementation to the next. One implementation will silently ignore that old field, another one will reject it outright, yet another one will silently convert it in one way, and yet another will convert it in another slightly incompatible way.

Support for older versions does not need to be a “all-or-nothing” choice. The spec can offer the choice between MAY / SHOULD / MUST for every single compatibility issue.

This also means that “supporting older versions” does not need to mean “support for all older versions”. We can fine-tune the expected level of support for each version.
For example, if we make a SSSOM version 1.1, it would be perfectly reasonable, in my opinion, to ask that implementations compliant with that version SHOULD (possibly even MUST) also support version 1.0, because presumably there wouldn’t be much differences between 1.0 and 1.1.
Later, when we get to SSSOM 2.0, it would also be perfectly reasonable to say that implementations compliant with that version MAY support any 1.x version (meaning that they can do it if they want, but they are not expected to).

Option (3a) is: “This document describes the latest version of the spec. You MUST support that version as described here. You MAY support older versions if you want, it’s up to you. If you want to do that, please refer to the COMPATIBILITY WITH OLDER VERSIONS section below for details of what has changed in the last version and hints on how to deal with older versions.”

I am sold! Would you be interested to try and draft the basic guidelines to enacting your proposal? I think we should do a SSSOM 1.0 before the end of the year, which also explicitly introduces your (3a) suggestion. I do not think we should try (and I don't think you are suggesting this) to figure out the dozens of breaking changes that happened in the past. But it would be good if the guidelines are in place, and documented explicitly as part of the "spec", before we publish 1.0.

what exactly would happen if an uncontrolled field (no fixed values) is changed from type string to type EntityRef?

Another option that I did not include yesterday, but that I think could the best option if the field is really important: phased deprecation.
That is, let’s say that in SSSOM version X we have a foo uncontrolled field that we wish to change to EntityRef with a controlled vocabulary; that field is too important to ignore but alas it is also impossible to define an automated way of mapping the thousands of free text values in use in the wild to the controlled vocabulary.
What we can do then:

In SSSOM version X+1, we leave foo unchanged and we introduce a new field called foo_id that uses the controlled vocabulary. Both fields are present simultaneously in the schema, so all implementations MUST support both. If both fields are present in a mapping set, implementations MUST ignore foo and only use foo_id. If only foo is present, implementations MUST accept it as before but MUST print a warning that foo is going to be deprecated and that SSSOM producers should use foo_id.
In SSSOM version X+2, we remove foo from the model. Implementations MUST support foo_id, but support for the uncontrolled foo is now optional. If an implementation does decide to support foo, it should treat it as in version X+1: accept it but print a (stronger) warning that “foo is now obsolete, you should really update your mapping sets to use foo_id, you know“.

We could even do a 3-phases deprecation, depending on how important the field is: in X+2, support for foo is optional but recommended (implementations SHOULD support foo), in X+3 and ulterior support for foo is fully optional (implementations MAY support foo).
Of course it’s complicated, cumbersome, but it may be the only way to ensure a smooth transition if/when we need an important breaking change post-1.0. (All the more reason to avoid such breaking changes whenever possible!)

Would you be interested to try and draft the basic guidelines to enacting your proposal?

I opened the ticket in the first place, so I better be interested! :D

I do not think we should try (and I don't think you are suggesting this) to figure out the dozens of breaking changes that happened in the past.

Agreed. I have used the past breaking changes as examples above since they were there, but I am not suggesting that SSSOM 1.0 should recommend supporting features from pre-1.0 versions, even less all features from pre-1.0 versions.
I do think that if we go any of the (3) options, SSSOM 1.0 should document how to support at least one or two old fields that don’t exist anymore (e.g. match_type), because it will give implementers a good idea of what they could expect for possible future breaking changes.
Such support would be entirely optional though (MAY). For example, sssom-java does still support match_type, but sssom-py does not (it flatly rejects a mapping set that uses match_type instead of mapping_justification), and I think it’s perfectly fine.

Wow.. I can't remember a more vigilant defender of adopters than you. Ok, make a proposal as a PR on the spec whenever you find the energy and time, and we has out the details. I like the idea of phased deprecation, but it will necessitate divorcing the TSV implementation entirely from LinkML, which is in any case necessary as per our discussion on serialisation versioning.

I am not sure there is anything left to do here. We now know how to deal with maintaining backwards compatibility, and version 1.0 of the spec already contains some examples of that.
What remains is the possibility of adding a sssom_version slot in future version, but if we do that I think this could be a distinct, focused issue – this one has seen a long enough discussion already.

Awesome progress, I think yes, scanning through this this can be closed and left to the archeologists!


Add Book name

The Basics of Communicative Design (tsutawaru dezain no kihon)

Thank you your choice! It's a book that looks interesting :)


Desktop install app support

Is your feature request related to a problem? Please describe.
Hello. great project!
Not sure if would be possible or worth it to develop something like this, but I was just wondering if would be possible to download/install the application like a desktop app. I've browsed the source code for a bit but didn't find anything regarding this feature.
Describe the solution you'd like
I didn't try it myself, but maybe by adding some listeners like beforeinstallprompt and appinstalled, this could be possible.
Describe alternatives you've considered
Adding this by myself in a project after starting it with bento starter, and don't add this to the main source code.
Additional context
Could be also a developer configuration saying that he wants or not the option to install as a desktop application.

Closing this because I think it's a duplicate of #165.

Hi @guastallaigor ,
This will be available in chrome 76 (coming soon 😉) Already available in chrome canary : see my tweet.
You can also create your own install desktop button.
Hope this helped you 😉


Reacting to ApplicationServices removal from HttpContext

Reacting to https://github.com/aspnet/HttpAbstractions/pull/487

:shipit:


Fix delimiter for mintinline when braces are in it.

If an inline code section contains an unmatched brace, then using braces as the \mintinline delimiter breaks. The inline section will extend to the next matching brace instead.
\mintinline can use any other character for a delimiter, so try to switch to something else when braces are in the text.
This also includes a fix for an invalid escape sequence.

Fwiw, I support this PR. Ran into this issue today.


[BEAM-6339] Add paddedcell fix to spotlessJava rules.

SpotlessJava fails to work when certain format issue exists in new code.
Plugin has official page refering to this issue with a fix, details see: https://github.com/diffplug/spotless/blob/master/PADDEDCELL.md

Follow this checklist to help us incorporate your contribution quickly and easily:

[X] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.


Allow for manual cursor control

@irgaly this should fix the issue you've shown in #75, although it'll require two changes to your code:

The openCursor() call needs to add an autoContinue = false parameter
You'll need to manually call cursor.`continue`() at the end of your collect block.

Closes #75.

It seems good change 👍 . I appreciate your quick response and fix.


swift / grpc: add grpc-status and grpc-message accessors

Adds a GRPCResponseTrailers and associated builder, which expose the grpc-status and grpc-message values - similarly to how we expose the :status from HTTPResponseHeaders.
I'll follow up with the Android changes when I port over the existing Android interfaces to match up with those introduced in https://github.com/lyft/envoy-mobile/pull/858.
Docs on these headers: https://chromium.googlesource.com/external/github.com/grpc/grpc/+/HEAD/doc/PROTOCOL-HTTP2.md
Signed-off-by: Michael Rebello<EMAIL_ADDRESS>

I need to think about this a bit more - looks like grpc-status can be returned in both/either headers or trailers 😬


Make Soul Stained modifier do the cool thing

!!!
I have quite frankly no idea how I managed to load the game using lodestone 1.4.1 and TCIntegrations, given that the directory of LodestoneAttributeRegistry has changed but whatever !!!

Ok so this is rlly confusing my IDE seems to have still been using 1.3.0 lodestone while writing the commit which means the game now crashes anytime u hold a soul-stained tool once again. Let me try and fix that?

OKay nvm it was correctly using Lodestone 1.4.1, but for 1.19.2 rather than 1.18.2 sobbing

I fixed it up, and tested in game. Works fine :)

As a sidenote, including the magic damage amount in the tooltip of the weapon, alongside regular damage, would be appreciated.

Awesome, thanks! I'll work on this tomorrow and get a new release out. I'll add the magic damage to the tooltip as well.


[Proposal] Development lifecycle

With this issue, I would like to summarize the current development practices in the QEDjl-project and propose some enhancements regarding testing and release procedures.
Preliminaries
Git branching rules

every package has two long-lived branches: 'main' and 'dev'
'main' contains only releases with a version tag
'dev' contains the current head of the development
feature branches come from and are merged to dev (usually from a fork)
releasing brings a collection of commits from dev onto main (see release workflow below)

Dependency rules

main branches (i.e. released versions) only depend on other released versions from the general registry
dev branches also depend only on released versions (not on other dev branches anymore)
feature branches (and fixes, see below) may depend on dev branches during development, but must be updated using released versions before merging to dev

Testing workflows
Unit tests

all PRs (for feature branches, fixes, releases, and hotfixes) must run the local unit tests with the versions of the dependencies given by the compat entries.
Warnings should be thrown if feature branches test against non-released branches, e.g., devs.

Integration tests

In a PR of a feature branch of a package, the unit tests for all dependent packages should be triggered with the changes made in the PR.
Status before: To illustrate the workflow, let's assume two packages A and B, both registered as Av0.1 and Bv0.1. In our case, B depends on A.
Using this setup, a new feature in A waits to be added. The following workflow must be applied:

Checkout a branch featA from dev (usually on a fork), implement the feature and open PR:featA targeting A#dev.
This triggers the unit tests of B against A#featA. If these unit tests pass, nothing needs to be done. PR:featA can be merged. If not, we have introduced a breaking change and need to proceed.
Check out a branch fixB from B#dev adopting the changes introduced in featA, which will depend on A#featA. Open PR:fixB targeting B#dev.
Inform PR:featA about the fix given on fixB and run the integration test (aka the unit test in B) again, but against the combination A#featA and B#fixB.
Because we introduce a breaking change in A, the version of A in the Project.toml should be bumped to Av0.2-DEV, where -DEV indicates, that this version is not been released yet, but other PRs on A can refer to/be built on.
Since the unit tests on PR:fixB are passed, the integration test in PR:featA should also pass. Therefore PR:featA can be merged. This breaks the integration tests again (dev must depend on released versions), which is not a problem, see release workflow.

Status after: A#dev has a new head including the feature from featA. PR:fixB is still pending and can not be merged because its unit test failed (remember, feature branches must depend on released versions to be merged). However, this is also not a problem, because A will be eventually released as Av0.2, bringing the changes necessary for PR:fixB to a release, which means in fixB the compat entry for A can be bumped and PR:fixB can be merged.
Extra: If there is another package C depending on A another fixC branch needs to be checked out on C following the same workflow. If C also depends on B, C#fixC needs to address this too, and PR:fixB needs to be informed about the fix given in C#fixC as well.

Release workflow

The phrase release means following the workflow below bringing a certain commit from dev onto main, registering the new commit on main in General, tagging the new commit on main with a version number, and building a new GitHub release.
We use the setting introduced above to illustrate the integration test pipeline
Status before: The head of A#dev works together with B#fixB currently pending in PR:fixB. However, PR:fixB can not be merged, because its unit tests fail by still using Av0.1 (the current top release), or by using the compat entry on Av0.2 which is not released yet.
We now want to release A to Av0.2 and must follow the release workflow:

Tag all PRs that went into A#dev and are supposed to be part of the release and add them to a common milestone.
create a release branch release-Av0.2
remove -DEV additions in the Project.toml to the version of A
update CHANGELOG.md
open PR:release-Av0.2 targeting A#main. One review is needed to check the correctness of 1-4 of the release workflow.
after merge: open another PR:release-Av0.2 targeting A#dev. Not much review needed here.
register new head of A#main
tag the new head of A#main with v0.2
build a GitHub release

Status after:

PR:fixB can now bump the compat entry to Av0.2 allowing it to be merged.
if a user does Pkg.add.(["A","B"]), the top compatible versions of A and B will be resolved, i.e. Av0.1 and Bv0.1, even if Av0.2 is already in the registry.
However, if Bv0.2 (including the new compat to Av0.2) is released eventually, the Pkg.add.(["A","B"]) will add Av0.2 and Bv0.2.

Documentation

Docs should always be handled like unit tests, even if they don't contain jldoctests
Docs must be built against released versions of their dependencies.
This means, PRs can only be merged to dev, if all upstream packages used are released.

Final remarks and additional requirements

We need good integration test tooling, which includes testing and reporting of fixed down the whole dependency graph. This also includes informing a PR about multiple fixes in other packages at the same time (see the integration test workflow above). I guess we already have this thanks to @SimeonEhrig :pray:.
Since the dev branches are not supposed to work together anymore, one could drop the trigger of unit and integration tests for the merge commit. The same applies to merging commits of release branches and hotfixes.
Regarding the dev branches, there is no need for them anymore, because they are just storing the current head of development. Therefore, one could discuss a move from the git-branching model with two long-lived branches to a model with just one long-lived branch main. This would simplify the release workflow by having one less PR to merge but introducing a freeze for merges during the release procedure.
The proposal above will produce more PRs pending and waiting for packages to be released. Therefore, we need a quick and frictionless release procedure. One idea would be to drop the CHANGELOG.md file and just go with the GitHub release page, which can be updated automatically with Julia's TagBot. This and having just one long-lived branch would reduce the release procedure to just one PR:release-Av0.2 where the -DEV is removed. Even the registration call could be done in this PR, which automates away all other steps of the release workflow, I guess.
We can lose the testing requirements for PRs coming from release branches, maybe triggering only the unit tests but not the integration test.
Open question to be verified: if fixB bumps the compat entry of A to Av0.2 and A bumps its own version to Av0.2-DEV, do the unit tests of fixB pass?

I have a lot of thoughts about this, so it's probably best to discuss further in person

After extensive offline discussions, we agreed on incremental changes to the current lifecycle instead of changing everything. However, we will monitor the progress under the current system and revisit the discussion in a couple of months.
For now, I will close this as not-planned.


Home page is not responsive in mobile device

Description
Posts are not responsive in smaller devices we have to make it responsive ..Can you assign this issue to me under GSSOC'23?
Steps to reproduce
make it responsive
Screenshots

Desktop (please complete the following information)
No response
Smartphone (please complete the following information)
No response
Additional information
No response

Yes sure you can go ahead!


Various Tool(s) to "Create" configuration Files

For different levels of user, we should have a variety of options for the configuration files...

For advanced users, we already have comments/instructions in the Config files themselves with instructions on how to write them.

These can always be expanded.
We discussed having explanation ReadMe.md files with more detail to guide Config writing.

For others, we have a lot of options (requiring various amounts of work)

"Kitchen Sink" option based on Data (for Tform Config):

Load up the user's data, inspect the columns, and generate ALL transformation commands that would work with their data set. (For instance, cannot Log() if has negative data...)
Then the user can manually delete any that they don't want to try.

"Runtime Limited" version of Kitchen sink could be implemented, where the user specifies a run time (4 hours, for example), and the loop will continue until that time has elapsed, with however many transformations are done in that time.

2b) Similar Manual-ish version could make a kitchen-sink-like estimate but simply cut off the list after a certain number of iterations.

"Priority by Inspection" :  We could use a simple (existing) linear-correlation algorythm (Numpy has some right?) to do an early correlation between each column and Linear, Log, Exp, Power-series, etc. data, and then put THOSE transformations as the first to try. This is pretty "A-Priori" so maybe unfair, but it might be the quickest path to good results!

"Priority by Meta-Learning" : This might be the best End-Goal... Start out with random transformations, then iterate the loop until the program "LEARNS" which transformation/column pairs are associated with the best models. Eventually, it will find the best ones to use on its own!?!?!

(Again, please feel free to suggest additional ideas, or comment on the value/priority of the above!)


Filetype parsing error

The following code in main.py, lines 174-181, can be improved by including an else when determining the filetype being passed.
    for path in tqdm(data):
        # Parse data
        if path.suffix == ".fasta":
            target = parse_fasta(path, ccd)
        elif path.suffix == ".yaml":
            target = parse_yaml(path, ccd)

        #### NEW CODE
        else:
            raise RuntimeError(f"Unable to parse filetype {path.suffix}")
        # Keep record
        records.append(target.record)

Thanks @delalamo for the recommendation. I pushed a fix to the main branch!


Removed no longer supported SQL resource types and renamed several operations

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[x] The title of the PR is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[x] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[x] If applicable, the PR references the bug/issue that it fixes.
[x] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[x] I have read the contribution guidelines.
[x] My spec meets the review criteria:

[x] The spec conforms to the Swagger 2.0 specification.
[x] Validation errors from the Linter extension for VS Code have all been fixed for this spec. (Note: for large, previously checked in specs, there will likely be many errors shown. Please contact our team so we can set a timeframe for fixing these errors if your PR is not going to address them).
[x] The spec follows the patterns described in the Swagger good patterns document unless the service API makes this impossible.

@jaredmoo,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Clarification: I actually removed inaccessible or no longer supported types, not APIs. The enum rename is included to get breaking changes done all together.

Thanks @veronicagg , I assume you're talking about the following checks that have PR_ONLY = TRUE?
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208461582
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208461584

I believe we are waiting on you guys to make changes to the examples validation, so I will just focus on the linter errors ( https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208461582 )

Comments on errors:

ListByOperationsValidation: I believe the existing names are correct and we should silence these warnings somehow.
ProvidersPathValidation: in these case current is a singleton, I'm interested in your guidance on this. Should we make it a {param} with only one allowed value (current?)
BodyTopLevelProperties: isn't kind a standard property? Either way this property is what the API has which can't be changed
ArmResourcePropertiesBag: I don't understand what this is saying. It sounds like it's complaining that we are replacing the base properties with our own properties. Can you clarify how to fix this?
BooleanPropertyNotRecommended, GuidValidation, DefinitionsPropertiesNamesCamelCase: This is what the API does, I can't change that. We should silence these warnings.
TrackedResourceValidation: Let me check if this is actually a tracked resource.
TrackedResourcePatchOperationValidation: Understood, I believe patch is already supported. Will investigate.

This is the output of latest version of AutoRest that I'm looking at, right?

@jaredmoo Regarding linter errors:

ListByOperationsValidation - I agree.
ProvidersPathValidation - Yes, so the recommendation would be to add a parameter, and make it an enum with 1 value (https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-extensions.md#single-value-enum-as-a-constant)
BodyTopLevelProperties -  Ok, @ravbhatnagar is kind a standard property?
ArmResourcePropertiesBag - ignore this one for now, we've temporarily removed this rule, as it needs modifications
BooleanPropertyNotRecommended, GuidValidation, DefinitionsPropertiesNamesCamelCase - Ok, let's keep it as is for now.
TrackedResouceValidation - sounds good
TrackedResourcePatchOperationValidation - sounds good

Regarding model validation errors:

We may have missed this error before: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/208461584#L1640, there looks to be an extra "2" in https://github.com/Azure/azure-rest-api-specs/blob/master/arm-sql/2014-04-01/examples/DatabaseList.json#L22
For the rest, yes, we agreed on suppressing those.

Thanks!

Done. System2 is actually correct, I had removed this enum element previous because I thought it was wrong.

Will there be a way of suppressing these errors that are acceptable? That way in the future it will be easier to catch regressions.

TrackedResource checks: yes these resources (server, db, pool) support PATCH. We will do this in a later PR. Opened issue #1018
ImportExport errors: fixing those now.

What do I do about this one? https://travis-ci.org/Azure/azure-rest-api-specs/jobs/209193852#L980
We already have /providers/Microsoft.Sql/operations defined in sql.core.json.

@jaredmoo Don't worry about https://travis-ci.org/Azure/azure-rest-api-specs/jobs/209193852#L980, as per the other specs, adding it to sql.core is fine. We'll enhance the tool later to take composite swagger into account.

@jaredmoo one clarification, after chatting with @ravbhatnagar a bit more, the issue around ProvidersPathValidation, which I recommended you to fix by adding a parameter with a constant value, is not actually required, you can keep it this way, or you can do it as you were doing it before, we'll be updating the validation tool for that error.

Ok thanks @veronicagg . In that case I'll revert the path back.

@jaredmoo There looks to be one error from examples validation you may want to take a look https://travis-ci.org/Azure/azure-rest-api-specs/jobs/209833639#L1006
Rest looks good to me. There's an issue with CI failing, it was supposed to be resolved today, but I see it's failing for your PR and some others, so I've pinged someone else about that.

Well spotted. That issue should be fixed by reverting the path change.

SDK change: https://github.com/Azure/azure-sdk-for-net/pull/2927

@jaredmoo thanks! couple of things I noticed:

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/210142403#L1020 not sure if you've looked at the suggestion for the name of that operation.
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/210142407#L1026 it looks like the model there is a bit confused for ImportExportResponse, should it look something like this?
"ImportExportResponse": {
"allOf": [
{
"$ref": "#/definitions/SqlTypedSubResource"
}
],
"properties":
{
"x-ms-client-flatten": true
"$ref": "#/definitions/ImportExportResponseProperties"
}
},
"description": "Response for Import/Export Get operation."
},
I'm still seeing CI failures, not sure why we'll follow up again on those, sorry about the delay on these.

Changed operation name to CreateImportOperation
Fixed this resource definition
Also changed a few more operation names to standardize on naming conventions

I read through all the warnings and I think we're good now. Phew. Thanks for your persistence @veronicagg :)

Np :) a few more I'm seeing though... let me know if you're planning on addressing them in this PR:

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211160959#L1006 (looks like the example https://github.com/Azure/azure-rest-api-specs/blob/master/arm-sql/2014-04-01/examples/DatabaseSecurityAlertGet.json has a couple of properties that are not defined in the swagger)
similarly in this case: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211160959#L1020
enum mismatch: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211160959#L1058, for example: https://github.com/Azure/azure-rest-api-specs/blob/master/arm-sql/2014-04-01/examples/DatabaseSecurityAlertCreateMax.json#L14
I believe this is still showing up https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211160959#L1128 because 'allOf' should be outside the "properties" object.
-https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211160959#L2430 some extra properties here too
and here https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211160959#L2444

"allOf" - fixing all of these :) thanks
enum mismatch - discussed with @anudeepsharma  at https://github.com/Azure/azure-rest-api-specs/pull/1012#issuecomment-286307270 . The API really should be an array, but the way I specced it (modelAsString enum) at least you have programmatic access to what options are supported in the comma-separated list. If you disagree then I can change the spec.
the API is actually returning kind, but not location. So I need to remove location from example and add kind to spec.

Hi @veronicagg ,
I was reading through https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-good-patterns.md and I found this interesting:
* Every "Resource" Model should have "location" as a "required" property as per the mandate from ARM team; no exceptions are allowed over here.
....
* All resource like models should inherit from Resource

So what about resource-like models that are untracked so they do not have required location? I made a new model named ResourceWithOptionalLocation which doesn't have x-ms-azure-resource tag, do you have guidance on what to do in this case?

Ok I think the warnings are good now other than the enum issues, which from my point of view is intentional

I just noticed that TransparentDataEncryption config looks like a long-running operation. Need to write SDK test to verify.

Swagger used to generate https://github.com/Azure/azure-sdk-for-net/pull/2927

@jaredmoo Regarding the "Resource" model, do you actually need location for anything? The basic definition of resource, should really just include "id", "name" and "type", if you're adding a required location, then it becomes a "tracked resource", you can take a look at the common definitions which are being reviewed at https://github.com/Azure/azure-rest-api-specs-pr/pull/40/files#diff-d3a0dcdc5d2939703fa9e32dff2295c1R22 When that PR is merged, there will be a request for teams to move to refer to this definitions, so the easier you can make it in your end to later on make the update the better. If you don't need location, don't add it, and use "x-ms-azure-resource" if the model is a "Resource" (the rule you pointed out in the "good patterns" page, may need update now that we have clarified this definitions, I'll take a look into that).
I hope that makes sense, feel free to let me know if you have more questions on this.
Thanks for updating the rest. I'm following up on the enum mismatch, to see if we have a better way of spec'ing it.

Thanks for the resource clarification. I'll add the definitions from Azure/azure-rest-api-specs-pr#40

We have some proxy resources that don't have a type property. IMO this is an API bug, but for Swagger purposes right now should I have them include ProxyResource, or make my own model type e.g. SubResource which has just id and name?

Changed that enum to a regular string. It's semicolon separated, description was wrong.

Thanks @jaredmoo .
Regarding the resource definitions, if they are shared among your own files, you could have them just in one of those, and refer to the ones in that one from the others. It's also fine if you want to keep it this way.
From the latest validations, have you looked into the following?

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L935
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1060
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1239
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1250
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1272

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L935 - false positive. DatabaseSecurityAlertPolicy has location, but it's not required, so it's not a tracked resource.

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1060 - unfortunately the API already uses guid in production, I can't change it

https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1239 - issue #1018

Resolving merge conflicts and removing resource definitions from all files except sql.core
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1250 - issue #1018
https://travis-ci.org/Azure/azure-rest-api-specs/jobs/211678413#L1272 - unfortunately the API already uses guid in production, I can't change it

No modification for NodeJS

 https://github.com/Azure/azure-sdk-for-ruby/pull/721

 https://github.com/Azure/azure-sdk-for-python/pull/1039


[Feature] Kanban automation using labels

Feature Description
This is an IMHO simpler reformulation of #14359 which should be easier to implement and maintain while giving the kanban/project feature a significant boost in functionality and usability.
Use kanban column names as label for issues
Add a new setting to projects called "Sync kanban with issues". When enabled, it will add a new label to an issue on the kanban. The name of the label should be constructed as PROJECTNAME/COLUMNNAME with the exclusive flag set.
With this very lightweight approach it becomes simple and natural to work with the kanban. As we already have a default column, that's going to be the label for new issues. When an issue is moved between columns, the label is also changed. With this approach no big changes are needed and typical agile patterns in project management can be enabled.
This approach needs no complex rules management, it really boils down to adding/changing/deleting labels on an issue.
On the kanban page this special label doesn't need to be displayed, as it is already reflected by the columns themselves.
On the issue it might be better to make the label protected, to make sure that progress is only managed on the kanban.
Screenshots
No response

Related to #14814 #13498


DRILL-3732: Drill leaks memory if external sort hits out of disk spac…

…e exception

ExternalSort.mergeAndSpill() cleans all it's data in case an errors occurs while it's spilling to disk
made BatchGroup AutoCloseable so it can easily be closed with AutoCloseables.close() if an error occurs
added injection site while External sort is spilling to disk
added unit test that forces a 2 batch query to spill to disk and injects an exception while it does so

+1 .  Rest looks good.  Pls add the comment for the 'threw = false' assignment.


Fix undefined inf/nan constant in CuPy JIT

Close https://github.com/cupy/cupy/issues/8696.

/test mini


Fix reconnect

Pull Request Test Coverage Report for Build 56

18 of 31 (58.06%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.8%) to 82.834%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/collector/target.go
18
31
58.06%

Totals

Change from base Build 53:
-0.8%

Covered Lines:
415

Relevant Lines:
501

💛  - Coveralls


feat: Display value for autoformatting toggle

For increased UX, the changed value for the autoformatting toggle is included in the notification message.

Awesome, that bothered me as well 😆
Thanks for your contribution!


MDDUDPSocket.h: socket failed with error: 10022

I came across this error in some of our models using Modelica DeviceDrivers
MDDUDPSocket.h: socket failed with error: 10022

The stack of functions is:
Modelica_DeviceDrivers.Communication.UDPSocket
Modelica_DeviceDrivers.Communication.UDPSocket(0, 0, true, 1, 0)

I found that the provided Example by Modelica DeviceDrivers throws the same error: Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDP
I was also able to find the already merged PRs conversation in https://github.com/modelica-3rdparty/Modelica_DeviceDrivers/pull/242 which had the same problem but as far as I understand was only solved for mingw32 setup.
The mentioned issue should be reproducable at least with the following setup:

OS: Windows 10 64 bit
Dymola 2023
Compiler: Visual Studio Code 2019 and gcc 64 bit

I don't remember #242 very well, but the problem in the PR with the 10022 error was also fixed for the VS compiler. I can't reproduce the error with my setup (Dymola 2022 with VS 2017). Maybe its different with VS 2019. I should upgrade anyway and will test it.

Thanks for the reply. Let me know if you can reproduce the error.

Tried to reproduce the error with Win10/64bit + Dymola 2023 + Visual Studio 2019 + the current version of DeviceDrivers master branch.
Log-file of program ./dymosim
(generated: Fri Oct 14 11:16:43 2022)

dymosim started
... "Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDP" simulating
... "dsin.txt" loading (dymosim input file)
MDDUDPSocket.h: Opened socket for sending.
MDDUDPSocket.h: Waiting for data on port 10012.
... "TestSerialPackager_UDP.mat" creating (simulation result file)

Integration started at T = 0 using integration method DASSL
(DAE multi-step solver (dassl/dasslrt of Petzold modified by Dassault Systemes))

Integration terminated successfully at T = 5
  WARNING: You have many time events. This is probably due to fast sampling.
  Enable logging of event in Simulation/Setup/Debug/Events during simulation
   CPU-time for integration                : 0.002 seconds
   CPU-time for one grid interval          : 0.004 milliseconds
   CPU-time for initialization             : 0.002 seconds
   Number of result points                 : 607
   Number of grid points                   : 501
   Number of accepted steps                : 445
   Number of f-evaluations (dynamics)      : 445
   Number of crossing function evaluations : 1155
   Number of Jacobian-evaluations          : 415
   Number of model time events             : 50
   Number of input time events             : 0
   Number of state events                  : 28
   Number of step events                   : 0
   Minimum integration stepsize            : 2.3e-07
   Maximum integration stepsize            : 0.483
   Maximum integration order               : 1
Calling terminal section
... "dsfinal.txt" creating (final states)
MDDUDPSocket.h: Receiving not possible, socket not valid.

SUCCESSFUL simulation of Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDP

Not so sure why I get MDDUDPSocket.h: Receiving not possible, socket not valid. but besides that everything seems to work just fine.
The error code isn't much help either: https://learn.microsoft.com/de-de/windows/win32/winsock/windows-sockets-error-codes-2#WSAEINVAL
Invalid argument - that could be anything.

Thanks @Thantalos for testing it for me (may take some time until I get a new VS installed).
This is the same log output that I get with VS 2017. The warning at the end of the simulation is probably because the socket is closed before the receiving thread has terminated. It should have no effect on the simulation results.
@DaJansenGit: Seems we can't reproduce the error. Did you try on another system as well, or maybe try after rebooting the machine?

Not so sure why I get MDDUDPSocket.h: Receiving not possible, socket not valid. but besides that everything seems to work just fine.

That's already reported by #346.

Sorry for taking that long to come back to you. I just tested it again at got the same error first. BUT was able to simulate successful after changing the working directory...
For any reason, there seems to be a problem with the network UNC path that was configured by default.
Maybe this will help someone else in the future. Thanks for your help! I will close this as it's not DeviceDrivers related.


Error While installing PIP and YAML package in the python packaged with blender

Hello, I found this code for generating the dataset using blender very useful.But I am facing the errors while installing PIP and YAML package in the python packaged with blender. And also it seems code is not compatible for Blender2.80 version.Steps I followed.
1.Downloaded and extracted the Blender 2.78 version and renamed the fodler name with blender and placed in my home
2. In ~/.bashrc, add line export BLENDER_PATH="/home/sagi/blender/blender"
3.Downloaded the get-pip.py file from the pip documentation
4. yaml package in the python packaged with blender :
Error :
/home/sagi/blender/2.78/python/bin/python3.5m /home/sagi/blender/2.78/python/bin/get-pip.py
Collecting pip
WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645)'),)': /simple/pip/
WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645)'),)': /simple/pip/
WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645)'),)': /simple/pip/
WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645)'),)': /simple/pip/
WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645)'),)': /simple/pip/
Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/pip/ (Caused by SSLError(SSLError(1, '[SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:645)'),)) - skipping
ERROR: Could not find a version that satisfies the requirement pip (from versions: none)
ERROR: No matching distribution found for pip
Then I tried the below command to install PIP, and it was successfull.
/home/sagi/blender/2.78/python/bin/python3.5m -m ensurepip
Result:
Ignoring indexes: https://pypi.python.org/simple
Collecting setuptools
Collecting pip
Installing collected packages: setuptools, pip
Successfully installed pip-7.1.2 setuptools-18.2
But the error while installing the YAML package :
Command Used :
/home/sagi/blender/2.78/python/bin/python3.5m /home/sagi/blender/2.78/python/bin/pip install pyyaml
Error:
Collecting pyyaml
Could not find a version that satisfies the requirement pyyaml (from versions: )
No matching distribution found for pyyaml
Please let know if you ever faced this issue and any suggestion to resolve the issue
Best Regards,
Hareesh

Issue is Resolved..My steps for the people whom are struck in this issue:
1.Downloaded and extracted the Blender 2.78 version and renamed the folder name with blender and placed in my home
2. In ~/.bashrc, add line export BLENDER_PATH="/home/sagi/blender/blender"
3. For Yaml package instead of downloading through pip, follow below
goto Site :  https://pyyaml.org/wiki/PyYAML
download the TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-5.1.tar.gz
Extract the file, and copy yaml folder in ~/Downloads/PyYAML-5.1/build/lib.linux-x86_64-3.5
and place the yaml file in path : /path/to/blender/2.xx/python/lib/python3.5/site-packages


Only deduce that we are in a console if IRB is loaded and there is an active session

Some gems include parts of IRB but do not enable the console functionality (e.g. ruby-debug-ide).

Thanks!


Autotests: Query Specific under Atom Properties

Creating tests for checking:

properties at Atom Properties > Query Specific
properties at right click menu for the atoms/Query Properties
format of atom properties (semicolon instead of comma)

Related to #3298
Test cases:
TC1

Launch Ketcher
Add any atom to the canvas
Click the right button of the mouse on the atom to show atom menu
Check the properties in the right-click menu for the atoms/Query Properties

TC2

Launch Ketcher
Add any atom to the canvas
Click the right button of the mouse on the atom to show atom menu
Check the properties in the right-click menu for the atoms/Query Properties
Click on the first property
Take screenshot
Repeat last two steps for every property

Closing ticket since test cases covered at #3099

Closing ticket since test cases covered at https://github.com/epam/ketcher/issues/3099


Server spacing

Describe the bug
After restarting discord today, the spacing between servers basically disappeared and changing the number in css doesn't help.
Screenshots

Infomation
Discord channel: Stable
OS: Windows 10
Mod: BetterDiscord
Discord language: English

thank you Gibbu


How to stop camera when moving to next Component with React Navigation

I am using Stack Navigator from React Navigation. And when I read QR code and moving to next component but camera still works and vibrates. I set reactivate={true} and reactivateTimeout={5000}

This issue is not specific to react-native-qrcode-scanner -- it is also valid for react-native-camera.
When the Camera component unmounts, the camera will no longer function. In react-navigation and in many other navigation libraries, the problem is that screens are often pushed into a stack, but the screens no longer in view do not actually unmount.
In order to avoid this, you would need to (either):

use a navigation library that unmounts old screens in a stack (not sure if one exists at all)
detect if the screen holding the camera component is in view or not, and simply not mount the scanner if it isnt --> by far the easiest approach. See react-navigation's docs and issues for tips on this.

Also, quick fix since I was just battling the same issue: https://github.com/patlux/react-navigation-is-focused-hoc

so easy! just use this.props.navigation.goBack();

So you are saying we have to use this.props.navigation.goBack(); we cannot navigate to any specific component?

I workadound is to set a state property to hide the scanner before you navigate

hide the scanner or unmount it?
is it working for you?

just use this.props.navigation.replace("New_Component");

I had the same problem. The camera component would not unmount when I switched between tabs. So I took advantage of the componentDidMount and added two listeners willFocus and willBlur and now it works.
 componentDidMount() {
    const { navigation } = this.props;
    navigation.addListener('willFocus', () =>
      this.setState({ focusedScreen: true })
    );
    navigation.addListener('willBlur', () =>
      this.setState({ focusedScreen: false })
    );
  }

  render() {
    const { hasCameraPermission, focusedScreen } = this.state;
    if (hasCameraPermission === null) {
      return <View />;
    } else if (hasCameraPermission === false) {
      return <Text>No access to camera</Text>;
    } else if (focusedScreen){
      return (this.cameraView());
    } else {
      return <View />;
    }
  }

I had the same problem. The camera component would not unmount when I switched between tabs. So I took advantage of the componentDidMount and added two listeners willFocus and willBlur and now it works.
 componentDidMount() {
    const { navigation } = this.props;
    navigation.addListener('willFocus', () =>
      this.setState({ focusedScreen: true })
    );
    navigation.addListener('willBlur', () =>
      this.setState({ focusedScreen: false })
    );
  }

  render() {
    const { hasCameraPermission, focusedScreen } = this.state;
    if (hasCameraPermission === null) {
      return <View />;
    } else if (hasCameraPermission === false) {
      return <Text>No access to camera</Text>;
    } else if (focusedScreen){
      return (this.cameraView());
    } else {
      return <View />;
    }
  }

Helpful link for reference: https://github.com/Bartlebyy/Ariadnes-Thread/blob/master/screens/AddMazeScreen.js

I had the same problem. The camera component would not unmount when I switched between tabs. So I took advantage of the componentDidMount and added two listeners willFocus and willBlur and now it works.
 componentDidMount() {
    const { navigation } = this.props;
    navigation.addListener('willFocus', () =>
      this.setState({ focusedScreen: true })
    );
    navigation.addListener('willBlur', () =>
      this.setState({ focusedScreen: false })
    );
  }

  render() {
    const { hasCameraPermission, focusedScreen } = this.state;
    if (hasCameraPermission === null) {
      return <View />;
    } else if (hasCameraPermission === false) {
      return <Text>No access to camera</Text>;
    } else if (focusedScreen){
      return (this.cameraView());
    } else {
      return <View />;
    }
  }

You saved my time :)

I'll be closing this one as this is not a problem caused by react-native-qrcode-scanner but the react-native-camera instead, as discussed here https://github.com/moaazsidat/react-native-qrcode-scanner/issues/12
then it sounds to be duplicated by this other issue as well, take a look on there to make it work 👊

adding  ReactDOM.unmountComponentAtNode(QrReader) works for me, hope it will work for you guys as well
`
import React, { useState } from 'react';
import { QrReader } from 'react-qr-reader';
import { ReactDOM } from "react";
const Test = (props) => {
const [data, setData] = useState('No result');
return (
<>
<QrReader
onResult={(result, error) => {
if (!!result) {
setData(result?.text);
ReactDOM.unmountComponentAtNode(QrReader)
}
      if (!!error) {
        console.info(error);
      }
    }}
    style={{ width: '100%' }}
  />
  <p>{data}</p>
</>

);
};
`


Change lambdify's default for backend to llvm when available

Background: I actually thought 'llvm' was our default, so I was surprised when I realized it actually isn't:
https://github.com/sympy/sympy/issues/24673#issuecomment-1426260263
People coming to symengine.py is probably doing so for the performance advantage over SymPy, so I think changing the default is helpful here.
This could perhaps be considered mildly backwards incompatible, but I think the pros outweigh the cons. What do you think?

I agree. Would it still be possible to use the current default via some option at runtime or can it only be set at compile time?

launching e.g. python3 using:
$ env SYMENGINE_LAMBDIFY_BACKEND=lambda python3

would set the default to lambda, no matter if libsymengine was compiled with LLVM support or not. And I think you can modify environment variables of an already running python interpreter (useful in jupyter notebooks) by assigning to os.environ["SYMENGINE_LAMBDIFY_BACKEND"] = "lambda", but I need to confirm that it works.
There are some test failures for this PR that I intend to debug, but my current local debug build of symengine uses some unfortunate combination of SYMENGINE_INTEGER=boostmp and a boost versions which essentially hangs during the collection phase of pytest... (integer nthroot probably uses some algorithm of poor time complexity in boost).

Would it still be possible to use the current default via some option at runtime or can it only be set at compile time?

You can do sym.Lambdify(expr, args, backend="lambda") to get the previous default.


lazy connect to database and make connection list readonly

lazy connect to database
show connection errors to the ui
make connection list not editable when providing connections through env variable
hide sensible data (like passwords)

well done @steven166 ! I am using your PR / fork, and its working beautifully. Thanks so much. This needs to be pulled in!


Info on security measures and Vault's docs on the matter

type: new page
status: pending
location: pending
Acceptance criteria:
AC1: it describes how Kubefirst deals with security
AC2: it describes how assume role feature works
AC3: it describes how Kubefirst make use of Vault to decrease surface of attack

https://github.com/kubefirst/kubefirst/pull/391


feat/add 0x40 blockhash opcode

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Resolves #91
What is the new behavior?

Python script to fetch last 256 blockhashes
Add blockhashes as fixture

Since the function signature have changed, we need
to modify deploy, execute, execute_at_address and
pass blockhashes as arguments to create the block context

Implement 0x40 BLOCKHASH opcode
Add unit and integration test for BLOCKHASH

Other information

Hello there, thanks for the reviews for this pr. I've opened another one here that's using a registry instead of a context. Let me know if I should close this one should the other approach turns out to be better, apologies for the inconvenience 🙏

Hello there, thanks for the reviews for this pr. I've opened another one here that's using a registry instead of a context. Let me know if I should close this one should the other approach turns out to be better, apologies for the inconvenience 🙏

it was good to try this out, and good to see that we can till be critical about our work even after several hours spent on it!
I think that we can close this PR yes


Error reporting for hotbackup restore

This PR accompanies arangodb/enterprise#634.
It is a pure CHANGELOG entry for the other bugfix.

http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr/13684/

http://jenkins01.arangodb.biz:8080/view/PR/job/arangodb-matrix-pr/13684/

Tests blue except unrelated known failure.

Tests blue except unrelated known failure.


fix(iframe-events): Support for iframe click events

Fixes #12, Fixes #47
Pull Request Template
Description
First of all, I have to say, whoever built this is a genius. It is very well divided but yet cohesive and it flows well. However, I was set on creating the iframe functionality myself but it seems like it was already done but the script wasn't applied to all frames, just the top frame. I also removed a reference to elements-to-bind-to as it was suppose to in #39. Btw, this is my first pull request and first time actually contributing to a open source project via coding.
Type of change

[X] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
All existing test passed. I also tested again the two examples in #12, namely https://giving.kcm.org and https://www.goodmanmfg.com/product-registration
Checklist:

[X] My code follows the style guidelines of this project. npm run lint passes with no errors.
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes. npm run test passes with no errors.

@rationalthinker1 this is awesome, and you're making me blush 😊I will review it tomorrow morning and if all good I will push a new release to the Chrome store.

LGTM and works as described


⚠ ClamAV has degraded performance

In 9de17af, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 80 ms

Resolved: ClamAV performance has improved in 5364051.


Feat : Mobile display of lateral bar

Feature: Mobile display of lateral bar

As a user of the portal,
I want to get the portal app and its lateral bar with mobile responsivity
So that I can use my mobile device to use the portal

Acceptance criteria
Scenario: mobile display
Given that I am a user of the web portal (unauthenticated or authenticated),
And I am using a mobile device,
When I am on any page of the portal
Then I should see a burger menu (see mock up 1)
Scenario: Open lateral bar
Given that I am a user of the web portal (unauthenticated or authenticated),
And I am using a mobile device,
When I click on the burger menu
Then The lateral bar should open (See mock up 2) from the left to the right pushing the page towards the right.
Scenario: Close lateral bar
Given that I am a user of the web portal (unauthenticated or authenticated),
And I am using a mobile device,
And the lateral bar is open
When I click on the cross
Then The lateral bar should close (See mock up 2), retracting to the left, pushed by the content of the page
Requirements
Resources
Mockups
1/

2/

Environment

staging URL: https://app.staging.okp4.network/

Additional informations
None.

Test 17/07
Safari - Mobile
Scenario: mobile display : OK ✅
Scenario: Open lateral bar : OK ✅
Scenario: Close lateral bar : OK ✅


Fix (mixed) line ending issues in text files

Some files were committed with CRLF endings, some even had mixed endings within the same file. Fix this.

@goneall WOuld you mind having a look, as I have other fixes in the pipeline that depend on this :-)

@ybronshteyn - Do you have any uncommitted changes?  I can merge these in, but I don't want to create a merge conflict if you are in the middle of some work.

@goneall, no. I meant to spin off a release on Tuesday, but got buried with
other stuff. I have no changes.
On Fri, Oct 16, 2015 at 11:16 AM, goneall<EMAIL_ADDRESS>wrote:

@ybronshteyn https://github.com/ybronshteyn - Do you have any
uncommitted changes? I can merge these in, but I don't want to create a
merge conflict if you are in the middle of some work.
—
Reply to this email directly or view it on GitHub
https://github.com/spdx/tools/pull/58#issuecomment-148743716.

I'm having trouble merging the changes.  It seems there is something corrupted in git (or just pilot error).  When I try to do the merge on my local file system, I'm getting an error that local changes will be overwritten to src/org/spdx/rdfparser/model/SpdxPackage.java.  Note - I did not modify this file.  When I revert the changes (e.g. through checkout) and the changes show right back up again.  I deleted the entire directory and cloned from git.spdx.org and the same thing happened.  I also tried reset, committing and stashing - nothing seems to get rid of this "Modified" file.
@ybronshteyn  - if you get a chance, can you try merging in these changes?  I'm kind of stuck.

@goneall I had similar issues when authoring the changes. Some files were very broken, containing mixed line endings, which totally confused Git. To make my fix work it seems to be essential that you apply changes one by one, not through a merge. So try cherry-picking each individual commit in order, that should do it.

I'll give it a try

@goneall Any luck yet? It should be pretty straight forward if you configure an additional remote named e.g. "github" for your local working tree, and make Git fetch PRs from that remote similar to here (replace origin with github and adjust the repo URL, obviously). Then you could simply do git cherry-pick c746cde 8d88a23 0b52167 and should be done.
Also, if you don't know it already, Hub might be of interest to you (see the section named "As an open-source maintainer").

Sorry, just saw this therad. Let me take a stab at it.

@sschuberth I found out I have to recover some of my local files after my failed attempt a merging on Saturday which will take a bit more time.  The github repo is a mirror of git.spdx.org/spdx-tools which also adds a bit of complexity to the process.  I'll wait and see if Yev is able to get things working.  If needed, I can spend some time this afternoon.

@goneall I'm aware the repo at GitHub is just a mirror, but the cool thing is, even if you initially cloned from http://git.spdx.org/spdx-tools.git, you can add the PRs from GitHub as a Git remote, integrate, push back to http://git.spdx.org/spdx-tools.git, and GitHub will automatically update. GitHub even closes PRs if it detects the code has been merged manually. There should be no need to explicitly close PRs.

I merged the diff white the whitespace=fix option. Tried making a clean clone of the repo, and none of the HTML or java files appeared modified. A small handful of other files did (.xls and RDF) and I addressed those in a separate commit. @sschuberth, could you do a clean pull and verify that you are now unblocked?

@ybronshteyn While I appreciate your help, it's unfortunate that you did not do a real git merge or git cherry-pick as I suggested above. Instead you seem to have squashed my three commits into one, and on top of that amended whitespace trimming to it. With this, it's impossible for me to easily and reliably tell whether my changes have been properly integrated.
In general, I noticed that this project does not seem to properly integrate PRs in a way that maintains authorship. Would you mind elaborating why that is?

Anyway, I have a follow-up at https://github.com/spdx/tools/pull/60.

@sschuberth, That was my bad. I had issues with the fetch, but I should have used the --author parameter when committing the diff. If I can, with all this line break instanity, I'll revert and re-commit your changes with the author tag.

I'll revert and re-commit your changes with the author tag.

Please don't do that. I value a clean history a lot, an reverting and re-applying a commit for no apparent reason is just confusing for any readers of the history.


How to train illumination_net and brdf_ae?

According to the code and paper, illumination_net and brdf_ae are trained before training nerual_pil. The repo do have train_illumination_net.py and train_brdf_ae.py, but I didn't find the data to train them.
What's the dataset of  illumination_net and brdf_ae training? Besides, it would be great if there is some guide of  illumination_net and brdf_ae training in README.

Luckily, I found the supplementary_material that described the detail design and training of the two networks. However, still look forward to some guide and script of train them.

Luckily, I found the supplementary_material that described the detail design and training of the two networks. However, still look forward to some guide and script of train them.

Did you train the model in your own datasets? I just train the "train_neural_pil" on my own datasets and the effects are not very good. After reading your question, I think the bad outputs may be resulted by other two untrained model. Could you tell me any information about your training resust?
By the way, the reason why I don't train other two model at first is that I think training "train_neural_pil" will cover the training of others. It is just a raw thought. I haven't studied the codes in details yet.


Fix typo

Docs Build status updates of commit d4acf54:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-conceptual/azure-cli-vm-tutorial-1.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


point install link to docs/

Can one of the admins verify this patch?

thanks @jordane!  If you would just prefix your git commit message with (MAINT), then this will meet our contributor requirements, and I can look at getting this merged.  Thanks!

@kevpl Done.


Implement Lab1

Fixes #147
Review of colleague's PR #
Changes proposed in this PR:
Implement Lab1 Fibonacci and negafibonacci.
Test Lab1

Codecov Report

Merging #174 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #174   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           2      3    +1
  Lines          18     38   +20
=====================================
+ Hits           18     38   +20

Impacted Files
Coverage Δ

01_fib/brvishnu92/main.go
100% <100%> (ø)

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 9605cdc...bc9f0a2. Read the comment docs.

@jonathanheaden Thanks for the feedback and I will implement these standards. I have modified the code as well. Please review it.

Git rebase isnt showing my previous commits. :-(
Its showing noop in place of commits when i do git rebase -i

rather than cherrypick, I'd just rebase the two commits onto an updated master:
git checkout master
git pull upstream master
git rebase --onto master lab1~2 lab1
git push -f

That will rebase the last two commits of lab1 (lab1~2) onto master.

@juliaogris Can you please approve changes? I am unable to merge. Thanks :-)

@anzboi Can you please help me to merge?  I spoke to Julia and she suggested to remove her review. Thanks.


fix: support 8.12

Description
Support for version 8.12
Set default for DA to 8.12
Release required?

[ ] No release
[x] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

8.7 appears to be in the process of being removed. It is not in US or EU and is deprecated in some other regions. I may need to

/run pipeline


Fix a variety of bugs

A journal entry amount of "0" would always results in a transaction type of "Debit". Add the ability to indicate which journal entry is Debit and which is Credit when journaling an amount of "0".
Allow unsetting the email address in a vendor.  Currently, once it's set, you can never unset it.
Add the "start" attribute to the XML when paging using GetList.

This is a small package of bug fixes and feature additions allowed by the documentation but not yet supported by the SDK.

Thanks for the PR, everything looks good! Going to merge into a verification branch from my side and I'll push to upcoming 4.0.0 branch.


[Bug]: Chromadb 0.5.1+ breaks retrieval agent

Describe the bug
In https://github.com/chroma-core/chroma/pull/2044 a new field was added in the query result included which is an array of strings (not None and not [[]]), so when https://github.com/microsoft/autogen/blob/main/autogen/agentchat/contrib/vectordb/utils.py#L110 tries to data_dict[key][i][j], it dies.
Steps to reproduce
No response
Model Used
Any
Expected Behavior
Should skip included key or otherwise protect against it.
Screenshots and logs
models to use:  ['gpt-4']
Accepted file formats for `docs_path`:
['txt', 'json', 'csv', 'tsv', 'md', 'html', 'htm', 'rtf', 'rst', 'jsonl', 'log', 'xml', 'yaml', 'yml', 'pdf']
/Users/jpr/.asdf/installs/python/3.12.4/lib/python3.12/site-packages/huggingface_hub/file_download.py:1132: FutureWarning: `resume_download` is deprecated and will be removed in version 1.0.0. Downloads always resume when possible. If you want to force a new download, use `force_download=True`.
  warnings.warn(
Trying to create collection.
2024-06-18 12:20:28,983 - autogen.agentchat.contrib.retrieve_user_proxy_agent - INFO - Use the existing collection `autogen-docs`.
2024-06-18 12:20:29,153 - autogen.agentchat.contrib.retrieve_user_proxy_agent - INFO - Found 146 chunks.
Traceback (most recent call last):
  File "/Users/jpr/src/AITools/autogen/rhino.py", line 58, in <module>
    chat_result = ragproxyagent.initiate_chat(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jpr/.asdf/installs/python/3.12.4/lib/python3.12/site-packages/autogen/agentchat/conversable_agent.py", line 1015, in initiate_chat
    msg2send = message(_chat_info["sender"], _chat_info["recipient"], kwargs)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jpr/.asdf/installs/python/3.12.4/lib/python3.12/site-packages/autogen/agentchat/contrib/retrieve_user_proxy_agent.py", line 631, in message_generator
    sender.retrieve_docs(problem, n_results, search_string)
  File "/Users/jpr/.asdf/installs/python/3.12.4/lib/python3.12/site-packages/autogen/agentchat/contrib/retrieve_user_proxy_agent.py", line 562, in retrieve_docs
    results = self._vector_db.retrieve_docs(
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jpr/.asdf/installs/python/3.12.4/lib/python3.12/site-packages/autogen/agentchat/contrib/vectordb/chromadb.py", line 260, in retrieve_docs
    results = chroma_results_to_query_results(results)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/jpr/.asdf/installs/python/3.12.4/lib/python3.12/site-packages/autogen/agentchat/contrib/vectordb/utils.py", line 111, in chroma_results_to_query_results
    sub_dict[key[:-1]] = data_dict[key][i][j]  # remove 's' in the end from key
                         ~~~~~~~~~~~~~~~~~^^^
IndexError: string index out of range

Additional Information
Downgrading to 0.5.0 works

Thank you @jprosevear for the good catching! Could you help verify if #2971 fixes the issue for you? Thanks.


Update README.md

@jkeskingvillage do we need this patch anymore?

Yes. This is for (C++) compiling a submodule for NL2LTL.

Just resolved a merge conflict.


[Azure OpenAI Service - Azure OpenAI Service] API Review

New API Review meeting has been requested.
Service Name: Azure OpenAI Service - Azure OpenAI Service
Review Created By: Eldar Akchurin
Review Date: 08/16/2023 09:00 AM PT
Onboarding Record: https://dev.azure.com/azure-sdk/Release/_workitems/edit/9320
PR:
Hero Scenarios Link: Not Provided
Core Concepts Doc Link: here
Description: Need to review the next version of OpenAI public preview API, in particular we are adding a new model that performs audio to text transcriptions and the inference part of the API requires 2 more operations.
Detailed meeting information and documents provided can be accessed here
For more information that will help prepare you for this review, the requirements, and office hours, visit the documentation here

Notes from API Review Meeting 8/16/23

Concern about using "response_format" body prop to control response format. It would be better to use standard HTTP accept/content-type. But the additional detail here is commendable.
Note: we won't be generating SDKs from this API definition -- there will be a separate TypeSpec definition.
This is exactly the same API as OpenAI (only better described) and we want it to be.
What is the limit on the file size?  25 MB  Will that evolve? Hard to say.

When it's time to make this public, we'll either merge this OpenAPI or the TypeSpec w/ generated OpenAPI if that's ready.
tl;dr: Good discussion but no changes requested by the Stewardship board.


BLOB column in a table

Hello,
I will be grateful if you find a solution to my problem.
I would like to use a blob image from my database for these cards.
I tried with this code but it gives nothing:
select
dbms_lob.getlength(IMG_PMV) as image
,'Click here' title
,'I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.' content
,'This is a link' btn_label_1
,' ' btn_label_2
from RP_PMV where COD_TYP_PMV=30
union
select
dbms_lob.getlength(IMG_PMV) as image
,'Click here' title
,'I am a very simple card. I am good at containing small bits of information. I am convenient because I require little markup to use effectively.' content
,'This is a link' btn_label_1
,' ' btn_label_2
from RP_PMV where COD_TYP_PMV=31

This is not a Material APEX issue, but here: https://docs.oracle.com/en/database/oracle/application-express/19.2/aeapi/GET_BLOB_FILE_SRC-Function.html#GUID-21F2D33A-A616-48B5-BAF5-A85C0EDC998F


Create static Pods

Hello I have a question on page:
https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/
Create static pods Step 2
2. Choose a directory, say /etc/kubelet.d and place a web server Pod definition there, for example /etc/kubelet.d/static-web.yaml:
Shouldn't the default manifest path be used instead?
/etc/kubernetes/manifests/
It's mentioned on these pages:
https://kubernetes.io/docs/reference/setup-tools/kubeadm/implementation-details/#constants-and-well-known-values-and-paths
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-workflow

Its just and example. It can be any path as long as you configure it with
--pod-manifest-path (kubelet flag).
/etc/kubernetes is more of a kubeadm path.
/close

Its just and example. It can be any path as long as you configure it with
--pod-manifest-path (kubelet flag).
/etc/kubernetes is more of a kubeadm path.
/close