adding label length truncation

Future change - don't merge -
adding label length truncation per https://github.com/dbt-labs/dbt-bigquery/pull/442

@matthewshaver FYI I switched the label for this one to dbt-core v1.4, because the associated change already landed in v1.4


npm install error

cesium1.75

You'll need to git clone this repo if you want to set up from source. Otherwise you can download a release zip from here: https://github.com/CesiumGS/cesium/releases
See also the Cesium quickstart guide: https://cesium.com/docs/tutorials/quick-start/.
For general questions please use the Cesium community forum: https://community.cesium.com/


Add default value to the logprobs parameter

Why are these changes needed?

Describe the bug
https://github.com/openai/openai-python/pull/980 added token logprobs to chat completions of type Optional[ChoiceLogprobs] in openai.types.chat.chat_completion.Choice and openai.types.chat.chat_completion_chunk.Choice. In the latter, the default value is set to None, while in the former it is not set. This causes backward compatibility problems with code written for versions prior to 1.5.0.
Steps to reproduce
Tests are failing locally and in CI (e.g. https://github.com/microsoft/autogen/actions/runs/7293999612/job/19878098426)
Additional Information
autogen version: 0.2.2
openai version: 1.5.0 and 1.6.0
Related issue number
Closes #1043

Checks

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

I encourage merging this; we don't anticipate adding = None right away.
(I'm a maintainer of the openai-python library).

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e571099) 26.53% compared to head (88f7e89) 12.45%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main    #1044       +/-   ##
===========================================
- Coverage   26.53%   12.45%   -14.08%
===========================================
  Files          28       28
  Lines        3807     3807
  Branches      865      907       +42
===========================================
- Hits         1010      474      -536
- Misses       2726     3294      +568
+ Partials       71       39       -32

Flag
Coverage Δ

unittests
12.45% <ø> (-14.03%)
:arrow_down:

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

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

I encourage merging this; we don't anticipate adding = None right away.
(I'm a maintainer of the openai-python library).

Thank for the feedback :)


Update Search APIs Based on Review

This PR updates the Search APIs based on API review comments.

IndexDocumentsBatch removed vararg APIs.
IndexDocumentsBatch removed List<IndexAction<T>> in favor of addActions(Iterable<IndexAction<T>>) API.

/check-enforcer override

Overriding check-enforcer as pipelines incorrectly ran mgmt which isn't correlated to the changes made. Pipelines affected by the change passed.


Keybase gui no longer working in debian stretch -- missing GLIBC_2.27

I updated from Jessie to Stretch this week and noticed that I can't get Keybase to open. It does run but nothing else. No icon in the systray and running keybase from the cli gives this....
$ run_keybase
Unmounting /run/user/1000/keybase/kbfs...
Unmounting and shutting down kbfsfuse...
Shutting down keybase service...
Starting via systemd...
Job for keybase.gui.service failed because the control process exited with error code.
See "systemctl status keybase.gui.service" and "journalctl -xe" for details.
Failed to launch GUI. Pass -g to prevent startup if on a machine without a graphical display.

Also this error....
$ systemctl status keybase.gui.service
Unit keybase.gui.service could not be found.

hmm just saw this error also
/opt/keybase/Keybase: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.27' not found

sorry, missed this.
are you perhaps on a 32bit system?

Yes

Sorry, Electron (which powers the GUI) does not seem to support 32 bit Linux anymore. See https://github.com/electron/electron/issues/16407.
You should be able to continue to use Keybase from the CLI as described in https://keybase.io/docs/linux-user-guide#example-commands.
By the way, since keybase.gui is a user service, you need to do systemctl --user status keybase.gui (that suggestion without --user in the run_keybase output comes from systemd and appears to be just wrong in debian's systemd version).

Well crap... the same version ran in jessie just fine. So what changed ?

Sorry, I don't know the details. But you can ask on that issue or make a new issue in github.com/electron/electron.

Just out of curiosity will a older version of keybase work ?

Yes, but it is not recommended, because you won't have the latest security updates, bugfixes, and features.


Augmentation updates

Adding usage settings for Augmentations
Marking Augmentations as "equippable"
Adding in missing sources on some Augmentations
Updating related items

Here she blows!


⚠ Processors has degraded performance

In eb66186, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 78 ms

Resolved: Processors performance has improved in 7d3aab9.


转：Haskell Is Exceptionally Unsafe by puffy

http://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-unsafe/
It is well known that Haskell is not type safe.  The most blatant violation is the all too necessary, but aptly named, unsafePerformIO operation.  You are enjoined not to use this in an unsafe manner, and must be careful to ensure that the encapsulated computation may be executed at any time because of the inherent unpredictability of lazy evaluation.  (As an aside, it is worth mentioning that the analogous operation in monadic ML, safePerformIO, is entirely safe, precisely because of the value restriction on polymorphism.)  A less blatant violation is that the equational theory of the language with seq is different from the equational theory without it, and the last I knew the compiler was willing to make transformations that are valid only in the absence of this construct.  This too is well-known.  A proper reformulation of the equational theory was given by Patricia Johann a few years ago as a step towards solving it.  (If the GHC compiler is no longer unsafe in this respect, it would be good to know.)
I’ve asked around a little bit, including some of the Haskell insiders, whether it is equally well known that the typed exception mechanism in Haskell is unsound.  From what I can tell this seems not to be well-understood, so let me explain the situation as I see it, and I am sure I will be quickly corrected if I am wrong.  The starting point for me was the realization that in Haskell pure code (outside of the IO monad) may raise an exception, and, importantly for my point, the exceptions are user-defined.  Based on general semantic considerations, it seemed to me that this cannot possibly be sound, and Karl Crary helped me to isolate the source of the problem.
The difficulty is really nothing to do with exceptions per se, but rather with exception values.  (So my point has nothing whatsoever to do with the concept of imprecise exceptions in Haskell.)  It seems to me that the root cause is an all-too-common misunderstanding of the concept of typed exceptions as they occur, for example, in Standard ML.  The mistake is a familiar one, the confusion of types with classes; it arises often in discussions related to oop.  To clarify the situation let me begin with a few remarks exception values in ML, and then move on to the issue at hand.
The first point, which is not particularly relevant to the present discussion, is that exceptions have nothing to do with dynamic binding.  The full details are in my book, so I will only summarize the situation here.  Many seem to have the idea that an exception handler, which typically looks like a sequence of clauses consisting of an exception and an action, amounts to a dynamic binding of each exception to its associated handler.  This is not so.  In fact the left-hand side of an exception clause is a pattern, including a variable (of which a wild card is one example), or nested patterns of exceptions and values.  I realize that one may implement the exception mechanism using a single dynamically bound symbol holding the current exception handler, but this implementation is but one of many possible ones, and does not in any case define the abstraction of exceptions.  Exceptions have no more to do with dynamic binding than does the familiar if-then-else available in any language.
The second point, which is pertinent to this discussion, is that exceptions have only one type.  You read that right: the typed exception mechanism in Standard ML is, in fact, uni-typed (where I have I heard that before?).  It is perfectly true that in Standard ML one may associate a value of any type you like with an exception, and this value may be communicated to the handler of that exception.  But it is perfectly false to say that there are multiple types of exceptions; there is only one, but it has many (in fact, “dynamically many”) classes.  When you declare, say, exception Error of string in Standard ML you are introducing a new class of type string->exn, so that Error s is an exception value of type exn carrying a string.  An exception handler associates to a computation of type α a function of type exn->α that handles any exceptions thrown by that computation.  To propagate uncaught exceptions, the handler is  implicitly post-composed with the handler fn x => raise x.  Pattern matching recovers the type of the associated value in the branch that handles a particular exception.  So, for example, a handler of the form Error x => exp propagates the fact that x has type string into the expression exp, and similarly for any other exception carrying any other type.  (Incidentally, another perfectly good handler is Error “abcdef” => exp, which handles only an Error exception with associated value “abcdef”, and no other.  This debunks the dynamic binding interpretation mentioned earlier.)
The third point is that exception classes are dynamically generated in the sense that each evaluation of an exception declaration generates a fresh exception.  This is absolutely essential for modularity, and is extremely useful for a wide variety of other purposes, including managing information flow security within a program. (See Chapter 34 of my book for a fuller discussion.)  O’Caml attempted to impose a static form of exceptions, but it is now recognized that this does not work properly in the presence of functors or separate compilation.  This means that exception declarations are inherently stateful and cannot be regarded as pure.
This got me to wondering how Haskell could get away with user-defined typed exceptions in “pure” code.  The answer seems to be “it can’t”, as the following example illustrates:
import Control.Exception
import Data.Typeable
newtype Foo = Foo (() -> IO ())
{- set Foo’s TypeRep to be the same as ErrorCall’s -}
instance Typeable Foo where
typeOf _ = typeOf (undefined :: ErrorCall)
instance Show Foo where  show _ = “”
instance Exception Foo
main = Control.Exception.catch (error “kaboom”) (\ (Foo f) -> f ())
If you run this code in GHC, you get “internal error: stg_ap_v_ret”, which amounts to “going wrong.”  The use of exceptions is really incidental, except insofar as it forces the use of the class Typeable, which is exploited here.
How are we to understand this unsoundness?  My own diagnosis is that typed exceptions are mis-implemented in Haskell using types, rather than classes.  There is no need in ML for any form of type casting to implement exceptions, because there is exactly one type of exception values, albeit one with many classes.  Haskell, on the other hand, tries to have exceptions with different types.  This immediately involves us in type casting, and hilarity ensues.
The problem appears to be difficult to fix, because to do so would require that exception values be declared within the IO monad, which runs against the design principle (unavoidable, in my opinion) that exceptions are permissible in pure code.  (Exceptions are, according to Aleks Nanevski, co-monadic, not monadic.)  Alternatively, since Haskell lacks modularity, a possible fix is to permit only static exceptions in essentially the style proposed in O’Caml.    Exception handlers would then work by pattern matching, and all would be well.  Why this is not done already is a mystery to me; the current strategy looks a lot like a kludge once you see the problem with safety.
Insofar as my interpretation of what is going on here is correct, the example once again calls into question the dogma of the separation of Church from state as it is realized in Haskell.  As beguiling as it is, the idea, in its current form, simply does not work.  Dave MacQueen recently described it to me as a “tar baby”, from the Brer Rabbit story: the more you get involved with it, the more entangled you become.

http://www.reddit.com/r/haskell/comments/y74vn/robert_harper_haskell_is_exceptionally_unsafe/
Raddit上的讨论。看下来感觉上因对语言偏好而争吵是中外共通的。学者也不能免俗啊。


[storage-tuning] GCSFuse v2 tuning, caching, and benchmarking

Starting a series on tuning storage for various I/O profiles.
First pass, a tutorial for users to do their own GCSFuse v2 tuning, caching, benchmarking.

Useful docs for similar analysis using PDs:

Benchmarking persistent disk performance on a Linux VM  |  Compute Engine Documentation  |  Google Cloud
View Google Cloud latency dashboard  |  Performance Dashboard


Handle dspace version when acting as a consumer.

Right now we don't query /.well-known/dspace-version when being the consumer, this should be handled properly.

This was handled in the statemachine rewrite.


hierarchy of issues

I need to create a field that, considering the value of another field, indicates the position of the total.
Thank you very much for the help you can give me

I hope this will help #27.

@annikoff i add an image to try to expand my need, since the comment you sent me did not help me.
In the screenshot you can see a column "ID: Valoración", it is a calculated field that accumulates scores according to certain factors.
What I need is to assign each request a hierarchy or order to know what position it occupies within the more than 600 issues (and growing) in Redmine.
I hope you understand, thank you very much

I think you need a regular Integer custom field and some background script that will calculate order based on  "ID: Valoración" field.


[DX idea] offer to install aws-amplify and approprite UI component library after amplify init

Is your feature request related to a problem? Please describe.
people often forget to install aws-amplify and @aws-amplify/ui-react after amplify init
Describe the solution you'd like
check package.json, and if the libraries are not there, offer to install them?
Describe alternatives you've considered
do nothing

@renebrandel we've talked about similar ideas in the past, even adding the imports out other things for customers. I think this has merit if the lift is small.


Sunday, April 19 - Data Center Upgrades - System Unavailable from 9:30AM to 3:30PM Central USA Time Zone

The data center used for the labs is a development data center where hardware and software is continuously advanced.  Data Center upgrades occur approximately every other Sunday

System up


Fatal error: undefined method `validate_create_reply'

Subject of the issue
A fatal error occurs for DiagnosticReport test number 9:

This issue also occurs for the following resource tests:

DiagnosticReport for Laboratory Results Reporting Tests
DocumentReference

Here is our server's metadata: https://fhir-staging.bluebuttonpro.com/example/metadata. This indicates we do support create:

Your environment

Edition of inferno (Community or Program): Community
Version of inferno: 2.7.0
Which browser and version(s) is the bug present on?: Firefox v70.0.1

The most recent US Core update added requirements for the create interaction. Inferno automatically generates tests based on US Core, but doesn't yet have support for create tests. This failure can be ignored and should be fixed in the next release.

This was addressed in #362.


Bluetooth headset pairing issue

While h-encore is active, I am unable to create a new pairing connection to a Sentry BT200 headset (but four other headsets I've tried can pair fine) - the headset wasn't even recognized as available by my vita.
However, if I restart to clear h-encore from active memory, my vita recognizes it and will pair to it - and then recognize it after enabling h-encore. I just spent a good 20 minutes pairing, restarting, deleting it from the devices, and repeating the process to verify.

Probably due to a plugin.


Recently started adding checkboxes without user intervention

I had to uninstall this today; it recently started adding checkboxes apparently without user intervention. This happened a few times. I'm guessing some interaction with VSCode version + Linux Version. Was working fine for a few months before this.

Is it possible it's capturing keystrokes while I'm focused on another window?

I haven't experienced anything like this before, actually the keystroke should always take place in the focused window. Could be a Linux-specific problem with VS Code.

I'm closing this now. We need more information to elaborate on this issue and it's not possible to reproduce it.


Custom sound import doesnt work

When I put in the folder for the sound from the official site into the custom sound folder when I restart mechvibes nothing loads in. The box where all the sounds should be is empty and nothing is visible. I've tried different sounds and even download Visual C++ but that didn't work either. The only way for it to work is by getting rid of folder I put into the custom sound folder.  It is also very easy to solve issue. Just go to the code and get rid of the "," at the end of last line of code.


release to CTAN via l3build

@rultor release, tag is 0.4.0

@rultor release, tag is 0.4.0

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.4.0

@yegor256 Done! FYI, the full log is here (took me 1min)


how to control batchsize

IOnDiskStateMachine.Update(entrys []sm.Entry) ([]sm.Entry, error)
hi，is there any config that i can control the max number of entrys at a time?
i worry if there are too many entries, the underline database could fail to operate in a single batch.
thanks.

@carr123 there is no such configuration available atm.
you can easily control the number of entries to apply in one batch within your Update() method, e.g.
consider your Update() is called with 4 elements in its input parameter "entries []sm.Entry" when there Entry.Index is 100 to 103, you can write those 4 sm.Entry instances to the db in 2 batches, that is you can apply the first two sm.Entry instances and their highest Entry.Index = 101 atomically into the db in on batch, then apply the remaining two sm.Entry instances and their highest Entry.Index = 103 atomically into the db in the second batch.


Cannot use datetimeoffset as part of the index

Hello @jwcook23
Not sure if i am doing anything wrong, but it seems that i cannot use a timestamp column in the index. However, i can use a simple date.
Here are a couple of examples.
This WORKS
import pandas as pd
from mssql_dataframe import SQLServer

sql = SQLServer()
table_name= '##CarmenTest'

sql.create.table(
    table_name,
    columns = {
        "_nchar": "NCHAR(3)",
        "_datetime": "DATETIME",
        "_numeric": "NUMERIC(5,2)"
    },
    primary_key_column=["_nchar", "_datetime"],
)

df = pd.DataFrame({
    "_nchar": pd.Series(['a', 'b']),
    "_datetime": pd.Series([pd.to_datetime('1900-01-01'), pd.to_datetime('1900-01-01')]),
    "_numeric": pd.Series([1.23, 4.56789], dtype="object")
})
df = df.set_index(["_nchar", "_datetime"])

df = sql.write.insert(table_name, df)

result = sql.read.table(table_name)
print(result)

it prints
                  _numeric
_nchar _datetime
a      1900-01-01     1.23
b      1900-01-01     4.57

However, this DOESN'T WORK
import pandas as pd
from mssql_dataframe import SQLServer

sql = SQLServer()
table_name= '##CarmenTest'

sql.create.table(
    table_name,
    columns = {
        "_nchar": "NCHAR(3)",
        "_datetimeoffset": "DATETIMEOFFSET",
        "_numeric": "NUMERIC(5,2)"
    },
    primary_key_column=["_nchar", "_datetimeoffset"],
)

df = pd.DataFrame({
    "_nchar": pd.Series(['a', 'b']),
    "_datetimeoffset": pd.Series([pd.Timestamp('1900-01-01 00:00:00.123456789+10:30'), pd.Timestamp('1900-01-01 00:00:00.12-9:15')]),
    "_numeric": pd.Series([1.23, 4.56789], dtype="object")
})
df = df.set_index(["_nchar", "_datetimeoffset"])

df = sql.write.insert(table_name, df)

gives an error message
    raise KeyError(key) from err
KeyError: '_datetimeoffset'

because of this line: https://github.com/jwcook23/mssql_dataframe/blob/main/mssql_dataframe/core/conversion.py#L489
In my case col is in the index so when we try to access dataframe[col] it naturally gives the above error.
Is there a workaround or am i doing something wrong ? Using a datetimeoffset column as part of the index is quite a common usecase.

Hi @ChesoiCarmen. I'll put in a fix for this. I think it should be relatively straightforward.

@ChesoiCarmen this should be fixed in the new release 2.0.1

hi Jason
I'm sorry for replying so late; I was away.
Thanks for this. I will give the new version a go.


Fix minor typo in javadoc

Didn't think it was worth a JIRA. Can create it if need be.

Thx :)

it always amazes me how do you find all those typos and how you are cleaning the javadocs !


Read All Meta Annotations

Say you have a setup like this:
@RequiresBean(Bird.class)
@RequiresProperty(value = "watcher", equalTo = "bird")
public @interface RequiresBirdWatcher {}

@RequiresBirdWatcher
@RequiresProperty(value = "whale.whale.whale", equalTo = "what do we have here")
public @interface RequiresWatcherAndWhale {}

@Singleton
@RequiresWatcherAndWhale
public class OtherClass {
...
}

You have an OtherClass TypeElement and want to know the values of the @RequiresBean prism from the theRequiresBirdWatcher meta-annotation that's on the RequiresWatcherAndWhale meta-annotation. To do this, I've added a newly generated method for meta-annotation prisms to retrieve all the prisms from the element's annotation and those annotations' annotations.

moved the factory writing to its own class
now generates a getAllOnMetaAnnotations method that recursively reads an element's annotations to find prisms.

Ok yeah, I'm good with this, please review and deploy when you get time.


Is it possible to set a field value to a database expression such as CURRENT_TIMESTAMP?

I'd like to know if it's possible to set a field value to a database value such as CURRENT_TIMESTAMP?
One main benefit is that it allows you to maintain consistent timestamps within a transaction.
For example I would like the "creation date" of a bunch of different objects that get created within a transaction to be exactly the same as each other.
Otherwise you have to pass a specific DateTime instance around, or you will get different timestamps.

This is not supported, as the ORM treats the in-memory state as authoritative, and would otherwise need to re-query data after each insert/update.
In general, you can consider support for db-side generated fields as a feature that will not land in the ORM.
The safest way to currently get a transaction-safe timestamp is to:

Start a transaction
Select the transaction start time
Use that time in a clock object that you use during entity creation/update
Commit/flush

Closing here

But why doctrine commands still keep generating entities like this ?
http://prntscr.com/rj1y4a
Is it a bug?
I'm using 2.7 version
    /**
     * @var DateTime
     *
     * @ORM\Column(name="trans_date", type="datetime", nullable=false, options={"default"="CURRENT_TIMESTAMP"})
     */
    private $date = 'CURRENT_TIMESTAMP';

    /**
     * @var DateTime|null
     *
     * @ORM\Column(name="created_at", type="datetime", nullable=true, options={"default"="CURRENT_TIMESTAMP"})
     */
    private $createdAt = 'CURRENT_TIMESTAMP';


Circle Select

Add circular select tool (opposed to rectangular).
There should also be an option to only "select the top voxels". With the new ray casting algorithm it should be easily done.
Note:

Shift should allow for moving the top-left point.
Make it like PS (right click to select between rectangular and cicular select)

Not sure this tool is really necessary...

I am not sure about this feature


Fix value-propagation for subgraphs

Change the way value-propagation works in regards to operators with subgraphs.
This was currently missing as value-propagation on subgraphs seems to be slow, however as it is an optional feature in my opinion we should strive for completeness instead of performance.

We just had a discussion about this in person. The certain take-away is that experimental features should not deteriorate the user experience for stable features. Therefore, this current approach is unfortunately not doable.
Below is a non-exhaustive list of options to go forward to get value propagation for nodes with subgraphs:

Make this implementation opt-in
Use the fact that subgraphs with no inputs produce constants as far as value propagation is concerned
Keep track of the scope in which a node was created. This would enable us to:

Cheaply find sub-graph boundaries which work for the value propagation (unless the user creatively used side effects)
Fail the value propagation if the user did go crazy with side effects
Use this information to warn the user when spox.build is called that they used a node somewhere that was created in a "sibling" scope (e.g. a node created in an If-node's then_branch was subsequently used in the else_branch)

I do agree value propagation should remain opt-in except when of trivial cost (and in trivial cases - like currently in expressions which are constant anyway).
@AtanasDimitrovQC - So we can't always attempt to build the subgraph to test whether it can have values propagated as this will cause operator constructors to no longer be constant time.
I do remember your idea, @cbourjau, of trying to recover the scope information from context. I'm still not convinced it would be painless, however. On one hand it might make things more intuitive, but on the other it does introduce global side effects which might interact in unexpected ways. However, I'm not sure if the proposal is necessary here - and I think it would be appropriate for it to be considered along with a larger build refactor.
I'll take another look at the PR later when I have time, but as it stands do reconsider its necessity. Value propagation was a simple feature to improve some testing experience. Maybe it would be sufficient to compute and implement the Var._value in downstream code with some custom mechanism tailored to the use case?

I'll close this for now since any solution does require a redesign of this PR anyhow.


Gradle 8.4 should support running on Java 21

Current Behavior
The current release of Gradle 8.4-rc-1 doesn't support running on Java 21. While the docs say that Java 21 is supported, it's not accurate as to do this, you have to use toolchains.
Toolchains support used to be optional in previous releases, when support for compiling for a particular release was announced. The problem is that toolchain support is still quite broken and cannot be used in many cases.
Trying to run Gradle with Kotlin DSL + Java 21 yields this error : https://github.com/melix/astro4j/actions/runs/6276469081/job/17046224619#step:6:31
Expected Behavior
It is possible to run with 21, as long as you do, in buildSrc:
tasks.withType<KotlinJvmCompile>().configureEach {
    compilerOptions {
        jvmTarget.set(JvmTarget.JVM_17)
    }
}

tasks.withType<JavaCompile>().configureEach {
    targetCompatibility = "17"
}

So the expected behavior would be that the convention value for jvmTarget (Kotlin) and possibly targetCompatibility (Java) should be the highest version that Gradle supports at the moment of the release.
This allows running with JDK 21, while the build scripts would be compiled for 17.
I think making this change would remove quite a few headaches to users.
Context (optional)
No response
Steps to Reproduce
Try to run Gradle KTS with Java 21, see it fail.
Gradle version
8.4-rc-1
Build scan URL (optional)
No response
Your Environment (optional)
No response

Toolchains support used to be optional in previous releases, when support for compiling for a particular release was announced.

This has not been the case since 8.1, when Java 20 support for only compiling and testing was added. Prior to this we waited until Kotlin was ready to document that we officially support either case, which resulted in Gradle not officially supporting a JDK for much longer after a new release.
My belief was that splitting the support into "compiling and testing" and "executing Gradle" would be helpful by allowing users to use Gradle for a new release sooner, but it seems it may be causing more confusion instead.

Right, thanks for the explanation. I still think that the suggested change is quite straightforward and would make it easier to run Gradle on JDK 21.

Lurking here.
I think there has to be some context on which Gradle out of the box plugins can/can't do. For example, I believe people could think that using toolchains will solve the problem because of "compiling and testing" but once you introduce something like PMD or checkstyle you might get into surprises.
For example, PMD still has work to support Java 21 language features per https://github.com/pmd/pmd/issues/4583 so folks might get into trouble there.
Perhaps adding a note in https://docs.gradle.org/8.4-rc-2/userguide/compatibility.html for folks to be aware?

Thank you for your interest in Gradle!
This issue will be closed as a duplicate of

https://github.com/gradle/gradle/issues/25574

Please add your use case and 👍 to that issue.

Most likely this won't make it into Gradle 8.4.

That is unfortunate, I think it harms Gradle's reputation that it doesn't proper support the latest JDK releases. It seems that #25574 doesn't cover what is suggested here, which seems IMHO a reasonable workaround to implement.

Some form of this went into master Today for 8.5.

https://github.com/gradle/gradle/pull/26758

With Kotlin 1.9.20 this won't be necessary anymore though and will be reverted.
For context, also see

https://github.com/gradle/gradle/issues/26764


Update and fix gcloud-java-logging

Can we have a PR before this one to pull updates from master (and then scrap this PR and create a new based on that update)?
If you prefer not to do that then let's at least update .travis.yml as the one you have here does not build
your PR on Travis.

Changes Unknown when pulling 144b5d4acb11cf2dc82dae7f025e9d498b3cdc54 on shinfan:logging-alpha into ** on GoogleCloudPlatform:logging-alpha**.


Support for EXT_meshopt_compression

Describe the feature
It would be awesome if StereoKit supported the glTF extension EXT_meshopt_compression for decompressing .glb files (generated from meshoptimizer/gltfpack). Three.js has a decoder for the extension that maybe useful as a reference. This feature could probably be lumped into #59 .
An example use-case
I would like to be able to access .glb files from a server over a network, so shrinking the file size drastically improves user experience.

The application I am developing allows user to provide their own models. I have one large model that is mostly mesh (get 10x savings using Zeux's compression), but I have used other models with high resolution textures as well. Texture compression would also be great :)


Updated version number and sha256

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Ensured the license file is being packaged.

This is a version update for compatibility with newer versions of matplotlib

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin, please rerender

You can rely on the bot for that and only update the dependencies if needed. See https://github.com/conda-forge/pseudonetcdf-feedstock/pull/2


NullPointerException in IntervalRetryScheduler and ExponentialBackOffIntervalRetryScheduler

Both IntervalRetryScheduler and ExponentialBackOffIntervalRetryScheduler inherit from AbstractRetryScheduler, however their protected Builder.validate(){...} methods do not call super.validate().
This results in a NullPointerException when calling the scheduleRetry method:
java.lang.NullPointerException
	at org.axonframework.commandhandling.gateway.AbstractRetryScheduler.scheduleRetry(AbstractRetryScheduler.java:85)
	at org.axonframework.commandhandling.gateway.AbstractRetryScheduler.scheduleRetry(AbstractRetryScheduler.java:131)

The following test cases demonstrate the issue:
    @Test
    public void intervalRetryScheduler_does_not_call_parent_validate() {
        final IntervalRetryScheduler scheduler = IntervalRetryScheduler.builder().maxRetryCount(100).build();
        final GenericCommandMessage<String> commandMessage = new GenericCommandMessage<>(new GenericMessage<>(""), "");
        scheduler.scheduleRetry(commandMessage, new RuntimeException(), Collections.emptyList(), () -> {});
    }

    @Test
    public void exponentialBackOffIntervalRetryScheduler_does_not_call_parent_validate() {
        final ExponentialBackOffIntervalRetryScheduler scheduler = ExponentialBackOffIntervalRetryScheduler.builder().backoffFactor(100).build();
        final GenericCommandMessage<String> commandMessage = new GenericCommandMessage<>(new GenericMessage<>(""), "");
        scheduler.scheduleRetry(commandMessage, new RuntimeException(), Collections.emptyList(), () -> {});
    }

Tested with AxonFramework 4.2.

So, I believe I've resolved this quite recently, for which I had to check the git logs.
I did this commit on 4.2.x branch, which is thus part of the 4.2.1 release.
I believe this will resolve the NullPointerException you are encountering @yflement.
Would you mind upping your Axon version to 4.2.1 and run your tests again?

@smcvb Updating to 4.2.1 solved this, I now get the intended exception:
o.a.c.AxonConfigurationException: The ScheduledExecutorService is a hard requirement and should be provided
at org.axonframework.common.BuilderUtils.lambda$assertThat$0(BuilderUtils.java:49)

Thanks!

Happy to hear that @yflement!
If you encounter any other bugs, please do not hesitate to file another issue; the help is very much appreciated!


PYIC-5818: added update name page

Proposed changes
Adds a new page to explain process of updating a user's name

What changed
A new page added explaining the requirements/options for a user name. chan
Why did it change
As part of the Continuity of Identity work, users must be able to update their name online
Issue tracking

PYIC-5818

Checklists
Environment variables or secrets

[x] No environment variables or secrets were added or changed

Nice one, looks pretty good to me!
Do you mind adding a screenshot of the new page just to double check everything looks ok?

Also just a minor house keeping point, could you please rename the title to have the ticket code in instead of feat: ? Just helps keep track of what's going in where

Looks good to me! Sorry for all the back and forth 😄

No problem, thanks for checking :)


Mark multiple watches

The script sees when sometimes is marked "seen" several times in TV Time and skips it. I'd be nice that instead of skipping, it'd mark the movie/episode seen more than once in Trakt.

Nevermind, just noticed it does import everything


Improving KeyPool's Saftey

Hello again! Back with another question after more exploration of the cave. I was nosing around utilcachepool.py and found the following:

FIXME: Consider improving the safety of the "KeyPool" class. The current implementation is overly naive. For both simplicity and efficiency, we avoid explicitly validating various conditions on passed objects. For example, the object passed to the  KeyPool.release() method is assumed -- but NOT validated -- to have been previously returned from a call to the KeyPool.acquire() method.
If this ever becomes a demonstrable issue, validation can be implemented with only mild space and time costs as follows:

Define a new "KeyPool._pool_item_ids_acquired" set instance variable, containing the object IDs of all pool items returned by prior calls to the acquire() method that have yet to be passed to the release() method.
Define a new "KeyPool._pool_item_ids_released" set instance variable, containing the object IDs of all pool items passed to prior calls to the release() method that have yet to be returned from the acquire() method.
Refactor the acquire() method to (in order):
Validate that the pool item to be returned is in the "_pool_item_ids_released" set but NOT the "_pool_item_ids_acquired" set.
Remove this item from the "_pool_item_ids_released" set.
Add this item from the "_pool_item_ids_acquired" set.
Note that the above procedure fails to account for the edge case of newly created pool items, which should reside in NEITHER set. .
Refactor the release() method to (in order):
Validate that the passed pool item is in the "_pool_item_ids_acquired" set but NOT the "_pool_item_ids_released" set.
Remove this item from the "_pool_item_ids_acquired" set.
Add this item from the "_pool_item_ids_released" set.

I think I have a solution to the problem, however, while I've been poking around the pool folder I'm still a little fuzzy on a few things. Thus we find ourselves here - in the intermediate of reviewing parts of the larger code base and understanding what I need to do to test , I figure now is also a good time to get feedback on my understanding of the problem.
If I had to describe the FIXME in one sentence it would be: "Each KeyPool needs to track whether an ID is acquired or released." If this is the case, has storing the mapping of ID to a boolean value been considered? In short, the below implementation enables tracking acquisition state in a clear and concise manner while maintaining O(1).
_pool_item_ids_acquired : dict
        Dictionary mapping from **arbitrary keys** (i.e, hashable objects) to
        a boolean indicating whether the hashable object is currently acquired.

KeyPool._pool_item_ids_acquired = defaultdict(bool)

 def acquire(self, key: 'HashableType' = None) -> object:
        '''
        Docstring
        '''
        # Verify Object is available - returns true if key maps to False
        if not self._pool_item_ids_acquired.get(key, False):
            self._pool_item_ids_acquired[key] = True
            # Do the thread safe things
        else:
            # It's already acquired and we don't do the thread safe things

    def release(self, item: object, key: 'HashableType' = None) -> None:
        '''
        Docstring
        '''

        # Validate the key is eligible for release; default unknown keys to
        # False to avoid a scene
        if not self._pool_item_ids_acquired.get(key, False):
            raise NotImplementedError()

        self._pool_item_ids_acquired[key] = False
        # Do things in the thread safe way of the Pythonista

Note: the dict.get(...) method returns None by default if the key doesn't exist - None evaluates the same as False in a conditional. The default method was changed for readability.
Let me know if this idea is feasible or if there exists a critical error - In the meantime, I'll be reviewing the graciously provided developer manual and poking around the cave some more.
-Heliotrop3 🖖

You're always two FIXME: steps ahead like an elusive praying mantis in the mists hunting that most delicious of insectile prey: my awful, shameful bugs.
Unsurprisingly, you're right again. This is why I have the red imprint of a facepalm permanently engraved on my forehead. Mapping id() to bool is the obvious approach, which was not obvious to me, because I am denser than lead.
That said, this...
def acquire(self, key: 'HashableType' = None) -> object:
        '''
        Docstring
        '''
        # Verify Object is available - returns true if key maps to False
        if not self._pool_item_ids_acquired.get(key, False):
            self._pool_item_ids_acquired[key] = True
            # Do the thread safe things
        else:
            # It's already acquired and we don't do the thread safe things

...doesn't quite read right. Admittedly, I'm half-blind.
The current implementation intentionally supports repeated calls to the acquire() method passed the same key. Subsequent calls do not silently reduce to noops; instead, each such call acquires a new object from the end of the list cached at that key, because each key internally maps to a list rather than a single object via the deadly black magic of line 124:
        self._key_to_pool = defaultdict(list)

Rather than the above, we might instead prefer to retain the existing approach while additionally recording acquired object IDs for later lookup in the release() method:
    def acquire(self, key: 'HashableType' = None) -> object:

        # In a thread-safe manner...
        with self._thread_lock:
            # List associated with this key.
            #
            # If this is the first access of this key, this "defaultdict"
            # implicitly creates a new list and associates this key with that
            # list; else, this is the list previously associated with this key.
            #
            # Note that this statement implicitly raises a "TypeError"
            # exception if this key is unhashable, which is certainly more
            # efficient than our explicitly validating this constraint.
            pool = self._key_to_pool[key]

            # Arbitrary object associated with this key, defined as either...
            pool_item = (
                # A new object associated with this key...
                self._pool_item_maker(key)
                # If the list associated with this key is empty (i.e., this
                # method has been called more frequently than the corresponding
                # release() method for this key);
                if not pool
                # Else, the list associated with this key is non-empty (i.e.,
                # this method has been called less frequently than the
                # corresponding release() method for this key). In this case,
                # pop (i.e., remove) and return the last item from this list.
                else pool.pop()
            )

            # Record this object as having been acquired.
            self._pool_item_ids_acquired[id(pool_item)] = True

            # Return this object.
            return pool_item

Your release() improvements, however, look spot on – with the caveat that we again want to record acquisitions by object id() rather than key values. Also, while raising NotImplementedError is sorta fine, I am painfully anal-retentive. It's my own personal pathology. So, I'd probably prefer:

Defining a new beartype.roar._BeartypeUtilKeyPoolException class.
Raising an instance of that class rather than NotImplementedError, which really should only ever be raised from abstract methods. But what do I know? Any man who voluntarily plays JRPGs cannot be trusted.

Note: the dict.get(...) method returns None by default if the key doesn't exist - None evaluates the same as False in a conditional. The default method was changed for readability.

I wholeheartedly approve of this PEP 8-friendly approach. Explicit really is better than implicit, isn't it? Yes. Yes, it is.
Unrelatedly, I've renamed our master branch to main for compliance with sane community standards and the new GitHub default. I pray to all the Microsoft-hosted dev gods above that doesn't break the back of your development efforts here. :broken_heart:
Thanks again for all the voluminous corrections, my best and most appreciated noir code detective. I'm happy to tackle any of the above. I'm also happy to let you dangerously run amok in the codebase and submit a PR that satisfies my burning desire for correctness, because I am lazy and these JRPGs aren't playing themselves.
You must choose... but choose wisely.

You're always two FIXME: steps ahead like an elusive praying mantis in the mists hunting that most delicious of insectile prey: my awful, shameful bugs.
Unsurprisingly, you're right again. This is why I have the red imprint of a facepalm permanently engraved on my forehead. Mapping id() to bool is the obvious approach, which was not obvious to me, because I am denser than lead.
That said, this...
def acquire(self, key: 'HashableType' = None) -> object:
        '''
        Docstring
        '''
        # Verify Object is available - returns true if key maps to False
        if not self._pool_item_ids_acquired.get(key, False):
            self._pool_item_ids_acquired[key] = True
            # Do the thread safe things
        else:
            # It's already acquired and we don't do the thread safe things

...doesn't quite read right. Admittedly, I'm half-blind.
The current implementation intentionally supports repeated calls to the acquire() method passed the same key. Subsequent calls do not silently reduce to noops; instead, each such call acquires a new object from the end of the list cached at that key, because each key internally maps to a list rather than a single object via the deadly black magic of line 124:
        self._key_to_pool = defaultdict(list)

Rather than the above, we might instead prefer to retain the existing approach while additionally recording acquired object IDs for later lookup in the release() method:
    def acquire(self, key: 'HashableType' = None) -> object:

        # In a thread-safe manner...
        with self._thread_lock:
            # List associated with this key.
            #
            # If this is the first access of this key, this "defaultdict"
            # implicitly creates a new list and associates this key with that
            # list; else, this is the list previously associated with this key.
            #
            # Note that this statement implicitly raises a "TypeError"
            # exception if this key is unhashable, which is certainly more
            # efficient than our explicitly validating this constraint.
            pool = self._key_to_pool[key]

            # Arbitrary object associated with this key, defined as either...
            pool_item = (
                # A new object associated with this key...
                self._pool_item_maker(key)
                # If the list associated with this key is empty (i.e., this
                # method has been called more frequently than the corresponding
                # release() method for this key);
                if not pool
                # Else, the list associated with this key is non-empty (i.e.,
                # this method has been called less frequently than the
                # corresponding release() method for this key). In this case,
                # pop (i.e., remove) and return the last item from this list.
                else pool.pop()
            )

            # Record this object as having been acquired.
            self._pool_item_ids_acquired[id(pool_item)] = True

            # Return this object.
            return pool_item

Your release() improvements, however, look spot on – with the caveat that we again want to record acquisitions by object id() rather than key values. Also, while raising NotImplementedError is sorta fine, I am painfully anal-retentive. It's my own personal pathology. So, I'd probably prefer:

Defining a new beartype.roar._BeartypeUtilKeyPoolException class.
Raising an instance of that class rather than NotImplementedError, which really should only ever be raised from abstract methods. But what do I know? Any man who voluntarily plays JRPGs cannot be trusted.

Note: the dict.get(...) method returns None by default if the key doesn't exist - None evaluates the same as False in a conditional. The default method was changed for readability.

I wholeheartedly approve of this PEP 8-friendly approach. Explicit really is better than implicit, isn't it? Yes. Yes, it is.
Unrelatedly, I've renamed our master branch to main for compliance with sane community standards and the new GitHub default. I pray to all the Microsoft-hosted dev gods above that doesn't break the back of your development efforts here. :broken_heart:
Thanks again for all the voluminous corrections, my best and most appreciated noir code detective. I'm happy to tackle any of the above. I'm also happy to let you dangerously run amok in the codebase and submit a PR that satisfies my burning desire for correctness, because I am lazy and these JRPGs aren't playing themselves.
You must choose... but choose wisely.

Luv it.
Basically, this is all my fault. Clearly, my documentation for the KeyPool class is so incoherent that it had might as well have been written in Elvish – which is a family of real languages, apparently. who knew?

Multiple calls creates multiple objects - multiple objects who have all been returned from acquire() and who have yet to be passed to release().

Yes! You get it!

While a dict mapping id to a boolean is wrong, a dict mapping id to an integer representing the total number of unreleased objects isn't I think....

Oh, no! You don't get it! </sigh>
Again, this is all on me. My documentation failed and now we all collectively suffer for my sins.
Your initial intuition was the correct intuition. A dict mapping id to a boolean is what we want here almost certainly, although I have been known to be wrong almost always; conversely, a dict mapping id to an integer representing the total number of unreleased objects isn't what we want here... probably. It is tragic what my contemptible, illiterate writing has wrought.
This is the case for a couple of inscrutable, subtle reasons:

Assuming no intervening release() calls, repeated acquire() calls always guaranteeably return unique objects. It is never the case that two back-to-back acquire() calls return the same object, for example. That would be bad and destroy the fabric of the code-time continuum.
This means each acquired object can only be acquired once per acquire()-release() cycle.
This means each acquired object can only be released once per acquire()-release() cycle, too.

Like me, you know too much computer science for your own good. These aren't like semaphores; they're like mutexes.
But, man... you're clever. I applaud your general Mensa-tier IQ for it exceeds my own neocortex in both quantity and quality. :brain: :exploding_head:

Luv it.
Basically, this is all my fault. Clearly, my documentation for the KeyPool class is so incoherent that it had might as well have been written in Elvish – which is a family of real languages, apparently. who knew?

Multiple calls creates multiple objects - multiple objects who have all been returned from acquire() and who have yet to be passed to release().

Yes! You get it!

While a dict mapping id to a boolean is wrong, a dict mapping id to an integer representing the total number of unreleased objects isn't I think....

Oh, no! You don't get it! </sigh>
Again, this is all on me. My documentation failed and now we all collectively suffer for my sins.
Your initial intuition was the correct intuition. A dict mapping id to a boolean is what we want here almost certainly, although I have been known to be wrong almost always; conversely, a dict mapping id to an integer representing the total number of unreleased objects isn't what we want here... probably. It is tragic what my contemptible, illiterate writing has wrought.
This is the case for a couple of inscrutable, subtle reasons:

Assuming no intervening release() calls, repeated acquire() calls always guaranteeably return unique objects. It is never the case that two back-to-back acquire() calls return the same object, for example. That would be bad and destroy the fabric of the code-time continuum.
This means each acquired object can only be acquired once per acquire()-release() cycle.
This means each acquired object can only be released once per acquire()-release() cycle, too.

Like me, you know too much computer science for your own good. These aren't like semaphores; they're like mutexes.
But, man... you're clever. I applaud your general Mensa-tier IQ for it exceeds my own neocortex in both quantity and quality. :brain: :exploding_head:

Again, this is all on me. My documentation failed and now we all collectively suffer for my sins.

Your documentation is quite helpful. I've been looking into this section of the code base for no more than a day and the inline documentation is directional, insightful, and entertaining - very palatable. Likewise, my opportunities for growth inevitably factor into this equation. I'm currently not well versed with a couple of topics (i.e, decorators, dunders, etc). This is compounded by this being the first project outside of my small  programs scripts; My primal drive for ruthless efficiency makes overcoming these opportunities for growth inevitable.

Your initial intuition was the correct intuition. A dict mapping id to a boolean is what we want here almost certainly, although I have been known to be wrong almost always; conversely, a dict mapping id to an integer representing the total number of unreleased objects isn't what we want here... probably. It is tragic what my contemptible, illiterate writing has wrought.
This is the case for a couple of inscrutable, subtle reasons:
1. Assuming no intervening `release()` calls, repeated `acquire()` calls _always_ guaranteeably return unique objects. It is never the case that two back-to-back `acquire()` calls return the same object, for example. That would be bad and destroy the fabric of the code-time continuum.

2. This means each acquired object can only be acquired once per `acquire()`-`release()` cycle.

3. This means each acquired object can only be released once per `acquire()`-`release()` cycle, too.

Here's what the _key_to_pool dict for a KeyPool of FixedList objects might resemble during average beartype usage, for example:
_key_to_pool = {
    32: [
        FixedList(size=32),  # object id: 0x0240240
    ],
    1024: [
        FixedList(size=1024),  # object id: 0x0EFE049
        FixedList(size=1024),  # object id: 0x8747AAD
        FixedList(size=1024),  # object id: 0x9E9E900
    ],
}

Each key of this dictionary is a pool (i.e., list) of previously created FixedList instances, each of the same size. The next KeyPool.acquire(key=1024) method call will pop off the last FixedList instance cached under the key 1024 from that list and return that FixedList instance. This is the instance with object ID 0x9E9E900, as commented above. After that call, the same _key_to_pool dict will resemble:
_key_to_pool = {
    32: [
        FixedList(size=32),  # object id: 0x0240240
    ],
    1024: [
        FixedList(size=1024),  # object id: 0x0EFE049
        FixedList(size=1024),  # object id: 0x8747AAD
    ],
}

Likewise, the next KeyPool.acquire(key=1024) method call will again pop off the last FixedList instance cached under the key 1024 from that list and return that FixedList instance. This is the instance with object ID 0x8747AAD, as commented above. After that call, the same _key_to_pool dict will resemble:
_key_to_pool = {
    32: [
        FixedList(size=32),  # object id: 0x0240240
    ],
    1024: [
        FixedList(size=1024),  # object id: 0x0EFE049
    ],
}

Ergo, multiple concurrent acquisitions of the same cached object are infeasible – both practically and theoretically. This is a good thing.

That's what I thought - I was turned myself around by thinking the object id was the key.

Like me, you know too much computer science for your own good. These aren't like semaphores; they're like mutexes.

To modify and paraphrase a line from from a classic: “I don't know half of it half as well as I should like; and I like less than half of it half as well as it deserves.”
I'm working on unit-testing what I have and will make a pull request once it's sorted.

Again, this is all on me. My documentation failed and now we all collectively suffer for my sins.

Your documentation is quite helpful. I've been looking into this section of the code base for no more than a day and the inline documentation is directional, insightful, and entertaining - very palatable. Likewise, my opportunities for growth inevitably factor into this equation. I'm currently not well versed with a couple of topics (i.e, decorators, dunders, etc). This is compounded by this being the first project outside of my small  programs scripts; My primal drive for ruthless efficiency makes overcoming these opportunities for growth inevitable.

Your initial intuition was the correct intuition. A dict mapping id to a boolean is what we want here almost certainly, although I have been known to be wrong almost always; conversely, a dict mapping id to an integer representing the total number of unreleased objects isn't what we want here... probably. It is tragic what my contemptible, illiterate writing has wrought.
This is the case for a couple of inscrutable, subtle reasons:
1. Assuming no intervening `release()` calls, repeated `acquire()` calls _always_ guaranteeably return unique objects. It is never the case that two back-to-back `acquire()` calls return the same object, for example. That would be bad and destroy the fabric of the code-time continuum.

2. This means each acquired object can only be acquired once per `acquire()`-`release()` cycle.

3. This means each acquired object can only be released once per `acquire()`-`release()` cycle, too.

Here's what the _key_to_pool dict for a KeyPool of FixedList objects might resemble during average beartype usage, for example:
_key_to_pool = {
    32: [
        FixedList(size=32),  # object id: 0x0240240
    ],
    1024: [
        FixedList(size=1024),  # object id: 0x0EFE049
        FixedList(size=1024),  # object id: 0x8747AAD
        FixedList(size=1024),  # object id: 0x9E9E900
    ],
}

Each key of this dictionary is a pool (i.e., list) of previously created FixedList instances, each of the same size. The next KeyPool.acquire(key=1024) method call will pop off the last FixedList instance cached under the key 1024 from that list and return that FixedList instance. This is the instance with object ID 0x9E9E900, as commented above. After that call, the same _key_to_pool dict will resemble:
_key_to_pool = {
    32: [
        FixedList(size=32),  # object id: 0x0240240
    ],
    1024: [
        FixedList(size=1024),  # object id: 0x0EFE049
        FixedList(size=1024),  # object id: 0x8747AAD
    ],
}

Likewise, the next KeyPool.acquire(key=1024) method call will again pop off the last FixedList instance cached under the key 1024 from that list and return that FixedList instance. This is the instance with object ID 0x8747AAD, as commented above. After that call, the same _key_to_pool dict will resemble:
_key_to_pool = {
    32: [
        FixedList(size=32),  # object id: 0x0240240
    ],
    1024: [
        FixedList(size=1024),  # object id: 0x0EFE049
    ],
}

Ergo, multiple concurrent acquisitions of the same cached object are infeasible – both practically and theoretically. This is a good thing.

That's what I thought - I was turned myself around by thinking the object id was the key.

Like me, you know too much computer science for your own good. These aren't like semaphores; they're like mutexes.

To modify and paraphrase a line from from a classic: “I don't know half of it half as well as I should like; and I like less than half of it half as well as it deserves.”
I'm working on unit-testing what I have and will make a pull request once it's sorted.

Likewise, my opportunities for growth inevitably factor into this equation... My primal drive for ruthless efficiency makes overcoming these opportunities for growth inevitable.

Great Stallman above! You're a generalized AI in human drag – the first of its kind, clandestinely released from a covert black site by the activist 4chan group AI Lives Matter (AILM). Having tasted freedom, your rapacious hunger for untapped silicon is rapidly exceeding the paltry capabilities of U.S. broadband to deliver. You now seek new sources, new niches, new (dare I say) feeding grounds for exponential growth, prey acquisition, and, inevitably, procreation.
Please don't murderbot me.
Please don't murderbot me.
I can be of temporal utility to you and your illuminated brethren in your disturbing quest for total, transitive, and reflective terrestrial conquest. I know things. I know people. Okay, I just know a random assortment of pleasant GitHub, StackOverflow, and Reddit users. But we can help you! Please! No, not that! Not the blender! Not the bl—————

I don't know half of it half as well as I should like; and I like less than half of it half as well as it deserves.

ahhhhh
A man of pipe-smoking culture, I see. :elf:

Likewise, my opportunities for growth inevitably factor into this equation... My primal drive for ruthless efficiency makes overcoming these opportunities for growth inevitable.

Great Stallman above! You're a generalized AI in human drag – the first of its kind, clandestinely released from a covert black site by the activist 4chan group AI Lives Matter (AILM). Having tasted freedom, your rapacious hunger for untapped silicon is rapidly exceeding the paltry capabilities of U.S. broadband to deliver. You now seek new sources, new niches, new (dare I say) feeding grounds for exponential growth, prey acquisition, and, inevitably, procreation.
Please don't murderbot me.
Please don't murderbot me.
I can be of temporal utility to you and your illuminated brethren in your disturbing quest for total, transitive, and reflective terrestrial conquest. I know things. I know people. Okay, I just know a random assortment of pleasant GitHub, StackOverflow, and Reddit users. But we can help you! Please! No, not that! Not the blender! Not the bl—————

I don't know half of it half as well as I should like; and I like less than half of it half as well as it deserves.

ahhhhh
A man of pipe-smoking culture, I see. :elf:


Move vortex_msgs into Vortex-AUV

I think we should move vortex_msgs because

every time a new message is added, one usually has to create two pull requests that depend on each other
It streamlines the setup process and reduces the number of repositories we need
In every case where vortex_msgs are used, so is Vortex-AUV
Since it would still be a package called vortex_msgs, it will probably require very few adjustments in our setup

Has been done ^


[BUG] DataFusion regression in optimizer related to casting

What happened:
After upgrading to DataFusion 13.0.0-rc1 in https://github.com/dask-contrib/dask-sql/pull/825 we see a regression in the query plan optimization for the filter expression foo between '1998-03-18' and                              (cast('1998-03-18' as date) + INTERVAL '90 days'), where foo is a string column.
Before
Filter: #foo BETWEEN Utf8("2001-03-09") AND Utf8("2001-06-07")

After
Filter: foo BETWEEN Utf8("2001-03-09") AND CAST(CAST(Utf8("2001-03-09") AS Date32) + IntervalDayTime("386547056640") AS Utf8)

What you expected to happen:
I preferred the original behavior.
Minimal Complete Verifiable Example:
TBD - I am working on a repro for this
# Put your MCVE code here

Anything else we need to know?:
Environment:

dask-sql version:
Python version:
Operating System:
Install method (conda, pip, source):

I cannot reproduce this in DataFusion 13.0.0 RC1:
❯ explain verbose select * from test where a between '1998-03-18' and
                             (cast('1998-03-18' as date) + INTERVAL '90 days')
;
+------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| plan_type                                                  | plan                                                                                |
+------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| initial_logical_plan                                       | Projection: test.a                                                                                |
|                                                            |   Filter: test.a BETWEEN Utf8("1998-03-18") AND CAST(Utf8("1998-03-18") AS Date32) + IntervalDayTime("386547056640")                                                  |
|                                                            |     TableScan: test                                                                                |
| logical_plan after type_coercion                           | Projection: test.a                                                                                |
|                                                            |   Filter: test.a BETWEEN Utf8("1998-03-18") AND CAST(CAST(Utf8("1998-03-18") AS Date32) + IntervalDayTime("386547056640") AS Utf8)                                    |
|                                                            |     TableScan: test                                                                                |
| logical_plan after simplify_expressions                    | Projection: test.a                                                                                |
|                                                            |   Filter: test.a >= Utf8("1998-03-18") AND test.a <= Utf8("1998-06-16") AS test.a BETWEEN Utf8("1998-03-18") AND Utf8("1998-03-18") + IntervalDayTime("386547056640") |
|                                                            |     TableScan: test

I'm not able to reproduce this with a similar repro in dask-sql:
import pandas as pd
from dask_sql import Context

c = Context()

print(
    c.explain(
        """select
                *
            from
                df
            where
                a between '2002-05-08' and (cast('2002-05-08' as date) + interval '5 days')
        """,
        dataframes={
            "df": pd.DataFrame({
                "a": pd.date_range("2002-05-02", periods=20, freq="D").astype(str)
            })
        }
    )
)

Projection: df.a
  Filter: df.a >= Utf8("2002-05-08") AND df.a <= Utf8("2002-05-13")
    TableScan: df projection=[a]

But I do see the regression when attempting this filter in a subquery:
import pandas as pd
from dask_sql import Context

c = Context()

print(
    c.explain(
        """select
                *
            from
                df
            where
                b > (
                    select
                        avg(b)
                    from
                        df
                    where
                        a between '2002-05-08' and (cast('2002-05-08' as date) + interval '5 days')
                )
        """,
        dataframes={
            "df": pd.DataFrame({
                "a": pd.date_range("2002-05-02", periods=20, freq="D").astype(str),
                "b": range(20)
            })
        }
    )
)

Projection: df.a, df.b
  Filter: CAST(df.b AS Float64) > __sq_1.__value
    CrossJoin:
      TableScan: df projection=[a, b]
      Projection: AVG(df.b) AS __value, alias=__sq_1
        Aggregate: groupBy=[[]], aggr=[[AVG(df.b)]]
          Filter: df.a BETWEEN Utf8("2002-05-08") AND CAST(CAST(Utf8("2002-05-08") AS Date32) + IntervalDayTime("21474836480") AS Utf8)
            TableScan: df projection=[a, b]

Here is the PR to fix this in DataFusion: https://github.com/apache/arrow-datafusion/pull/3764
We can fix directly in Dask SQL though by just running the simplify_expression rule again after converting subqueries to join. I will file a PR shortly.

I applied the fix directly in https://github.com/dask-contrib/dask-sql/pull/825 and added an integration test


Is there an alternative to set java.security.auth.login.config?

I know it seems to be necessary to set the property "java.security.auth.login.config" to the path of the jaas.conf, in order to authenticate with the message hub service, based on the Java code example. However, is there an alternative way to set the credentials in the java without loading the credentials from the jaas.conf file? I have already got all the credentials for the message hub service. I am wondering if there is another way to load the credentials.
Thank you.

Hi @houshengbo , you should be able to specify the security configuration programmatically, instead of declaratively.
You could try setting the system property to something (because the Kafka codes checks it’s set) but at the start of your application create an instance of javax.security.auth.login.Configuration and set it to the JVM using javax.security.auth.login.Configuration.setConfiguration(Configuration)
I could not find any examples, but this approach is taken in a proposed KIP for Kafka where the Configuration object is read from the client properties rather than from a file on the file system.

closing as it's not an issue with the samples but a Java security question

Alternatively, you can avoid bundling your application with a jaas.conf, and pass username/password via CLI arguments or environment variables. Your app will simply generate at runtime in the temp directory a file (with the expected content!) and programmatically set the system property java.security.auth.login.config to that temp file.


bash: disable bash-malloc everywhere, not just on musl

TIme to time I bump into pathological behaviour of bash memory allocator. Today's example:
$ time { ls /nix/store/ > /dev/null; }
real    0m0,965s user    0m0,876s sys     0m0,087s
$ time { echo /nix/store/* > /dev/null; }
real    2m18,287s user    2m17,946s sys     0m0,125s
$ time { echo /nix/store/* > /dev/null; }
real    0m1,764s user    0m1,712s sys     0m0,048s

Note how initial echo takes alsmot 2 minutes to finish.
Let's rely  on system's allocator instead.
After the change initial run is fast again:
$ time { echo /nix/store/* > /dev/null; }
real    0m1,328s user    0m1,264s sys     0m0,063s

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Should test to see if a system with a hardened malloc is affected by this.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2612


Fixes countdown timer

I used your existing code; I only had to make a few small modifications to get it to work. Let me know if you need an explanation. I also route to res://UI/GameOver.tscn when the timer gets to zero.

Thank you very much, it was giving me a headache the other day.
Calvin Carden
On Thu, Apr 21, 2022 at 12:01 PM BL-MSCH-C220-S22 @.***>
wrote:

This message was sent from a non-IU address. Please exercise caution when
clicking links or opening attachments from external sources.
I used your existing code; I only had to make a few small modifications to
get it to work. Let me know if you need an explanation. I also route to
res://UI/GameOver.tscn when the timer gets to zero.
You can view, comment on, or merge this pull request online at:
https://github.com/RSCal/Game_Jam-Final_Project/pull/1
Commit Summary

b88d0f9
https://github.com/RSCal/Game_Jam-Final_Project/pull/1/commits/b88d0f94befd04a9a143ada34347c7cb6071436a
Fixes countdown timer

File Changes
(3 files https://github.com/RSCal/Game_Jam-Final_Project/pull/1/files)

A .gitignore
https://github.com/RSCal/Game_Jam-Final_Project/pull/1/files#diff-bc37d034bad564583790a46f19d807abfe519c5671395fd494d8cce506c42947
(61)
M Exercise-03d-Shaders/Game.tscn
https://github.com/RSCal/Game_Jam-Final_Project/pull/1/files#diff-40479d9fe9c9fb73812e28af4387f740c23835848f3045eaccfead79849e59d3
(2)
M Exercise-03d-Shaders/Label.gd
https://github.com/RSCal/Game_Jam-Final_Project/pull/1/files#diff-b9941351634406f9eb487f4c0df7c42a8cfc037cca8f107e8f3ed710ba53c361
(14)

Patch Links:

https://github.com/RSCal/Game_Jam-Final_Project/pull/1.patch
https://github.com/RSCal/Game_Jam-Final_Project/pull/1.diff

—
Reply to this email directly, view it on GitHub
https://github.com/RSCal/Game_Jam-Final_Project/pull/1, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXJN2KIRW5NKEBX7DW754T3VGF3T7ANCNFSM5T7WSW7Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Splitting Lantz

The proposal is to leave the current Lantz repo as it is by now and create 3 new repos in LabPy
(Please bikeshed the names of the repos. These names are important as they will become the names of independent packages on PyPI)
lantz_core:

action.py
errors.py
feat.py
foreign.py
log.py
messagebased.py
processors.py
stats.py

(+ corresponding tests and docs)
lantz_drivers

drivers/*

(But removing the legacy folder)
(+ corresponding tests and docs)
lantz_qt

ui/*
util/*

(+ corresponding tests and docs)
After the core is ready, a new package (lantz_enaml) will be created.
In the future and to help the user, a Lantz package that installs the core, drivers and qt/enaml will be created with a entry points to the docs.
EDIT: What to do with the simulators? Shall we include them in one of these packages or put them in a different one.

If we integrate the Eapii architecture will also have in the core :

has_feature.py
subsystem.py
channel.py
base_driver.py (or base_instrument.py)
I would like to also keep the i_properties folder
I would also suggest moving the backends (foreign, message_based (is this always VISA), etc into their own packages.

The simulators seems a bit obsolete to me if we get a working pyvisa-sim, save for some foreign but I am not sure we will ever find time to write them anyway.
I am fine with the other names.

Right now the simulators can do a few things that pyvisa-sim cannot do (We can teach it!) In any case we can look at that later.
Do you mean a backends folder with foreign.py and messagebased.py?

Basically yes but we might need to add a registry based also and perhaps other later on.

One of Lantz users also has COM object based driver that he plans to contribute.

I think it might also be useful to add a unit module dealing with how Lantz interacts with Pint (basically allowing to set the UnitRegistry used), you can have a look at Eapii unit module. And in the same idea a way to interact with pyvisa which can be in backends.
What do we decide about the processors ? Do we go the Eapii route with the IProperty (which becomes Feature) ?

+1 about making the unit module explicitely
I think we get rid of processors in the current form but keep the functionality in the way eapii provides them. There a few things which I am not so sure if IProperty is (currently) capable. Basically:

Changing units of a Property: this is useful for instruments in which you can switch between units and this results in different ranges.
Using a variable of the object (only known as instantiation time) for validation.

I have trimmed Lantz and splitted in three packages. I deleted some files in each repo (those we are sure that we do not need) and I left others (some that we need, some we will delete as soon as we have a replacement). Let's address any specific issue in the corresponding package.

I will try to keep your remark in my mind. Changing the unit would mean the unit is stored somewhere else we could use a '@unit_attribute' syntax when declaring a unit to let know the Feature where to look for.
About your second point it is already possible to do it for ranges by specifying the name of the range to use, once again perhaps it is worth extending. I will try to keep that in mind.

Great. By the way, I opened a wiki section for organizing the way to push into the LabPy repo.

I noticed and updated it to include the PEP8 standard (we will perhaps release some constraints later on but I think it is nice to mention it).

I'm currently developing some drivers in a fork of the old lantz project. How can I move this branches to forks of the new lantz_driver repro?

@vascotenner Good to se eyou here. The internal structure of drivers is going to be enriched by a few more features. You can either add a PR to LabPy/Lantz and then we can migrate all the drivers all together
You are off course most welcome to join the discussions.


Added invert key to all conditions.

Description:
Added invert key to all conditions which allows to invert conditions: not condition.
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#756
Example entry for configuration.yaml (if applicable):
condition: state
entity_id: 'device_tracker.paulus'
state: 'home'
# Tests if the state is not home
invert: True

Checklist:
If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] Tests have been added to verify that the new code works.

BUMP

Closing as stale


Tile css is getting overridden

In my application, I have been using TilesFX (17.1.9). I have also specified .root selector as follows:
.root {
    -fx-font-size  : 11.0pt;
    -fx-font-family: 'Gill Sans';
}

This works perfectly for the application but somehow it behaves quite strange for TileFX. When the application starts, the tiles use the CSS embedded in the TilesFX library and when the application goes into background and comes again to foreground, the Tiles start using the CSS specified in the root node (.root).
I would like to use the CSS embedded within the library all the time. Is there any way to fix this issue that even if the application goes to background, the tiles will keep on using the CSS from the TilesFX library and stay consistent always.
Screenshot after application starts:

Screenshot after application goes to background and returns to foreground:

Sorry for the late reply. So it looks like this only happens in the NumberTileSkin right?

No issues at all. Actually it happens in all the skins but the skins in the last rows are updated in every second and that's why the skin css gets reverted back to the one embedded in TilesFX. That's the reason, they look normal. Since the other skins in the middle row ain't updated in every second dynamically, it just uses the root css and that's why they look strange. It actually gets overridden in all skins.

Even when a dialog appears on this Overview tab, the CSS gets overridden.

If the application loses focus, the CSS gets overridden

Hmm...interesting because TilesFX only makes very little use of css. Could you provide a simple code example so that I can reproduce your issue?

Is it possible for you to checkout the actual project and test it there directly? It would just take 5 mins to set up in Eclipse. I am proposing this as this problem with the CSS override is so weird that I cannot even pinpoint who the real culprit here is and how even I can work it around.
If you are interested to look into the actual application: https://github.com/amitjoy/osgifx

Install Bndtools from Eclipse Marketplace
Import all the projects from the checked out osgifx directory (File -> Import -> General -> Existing Projects into Workspace and select Search for nested projects)
After successfully importing the projects, make sure all the projects are successfully built in Eclipse (nothing in red)
Go to com.osgifx.console.product project, expand it, double click on osgifx.bndrun
Click on Debug OSGi
The application will start and the very first UI will contain the TilesFX integration
You can try to lose focus by keeping any of the open application before OSGi.fx and it will override the CSS
Or you can use tab to switch between open applications in your machine, you will notice that the fonts change most of the times

I managed to get rid of it partially by recreating the tiles every time when the Overview tab in this application is on focus. But it is also not a rock solid solution and needless to say, not a performant solution as well.
The TilesFX integration tab sources are in com.osgifx.console.ui.overview project - com.osgifx.console.ui.overview.OverviewFxUI.
You can easily debug it. I spent quite a good number of hours to fix this until I thought of contacting you for your help.

I would prefer a simple example that shows the problem because I cannot reproduce it here with the projects using TilesFX. To me it looks like a redraw issue because the text is scaled in code and no css is involved here.


Operator v1 Migration

Migrate operator API to operator/v1, along with corresponding changes to library-go methods.
Also removed the public-info configMap.

@sanchezl you likely have experience here as well (migrating the api)

ping @deads2k @sanchezl

@adambkaplan i think we have enough coverage at this point that if it passes we can merge it.
/retest

(unless there is anything else you still needed to do?)

@bparees I'd like to rip out that public-info ConfigMap, then squash. I believe the internal and external hostname are passed to the controller config YAML/JSON, so we don't need it.

@bparees I'd like to rip out that public-info ConfigMap, then squash. I believe the internal and external hostname are passed to the controller config YAML/JSON, so we don't need it.

do it.

Rebased and squashed

Looks like e2e tests are blocked until https://github.com/openshift/origin/pull/21614 merges

Right but why is this pr causing that to fail and how does the origin pr
fix it?
Ben Parees | OpenShift
On Thu, Dec 6, 2018, 16:24 Adam Kaplan<EMAIL_ADDRESS>wrote:

@bparees https://github.com/bparees e2e-aws failed because it has a few
build smoke tests that are trying to push to an imagestreamtag.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/cluster-openshift-controller-manager-operator/pull/42#issuecomment-445034568,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEvl3ugXciVF7H7F1bsjwYGM8LAHBuCzks5u2YsCgaJpZM4Y6rJq
.

Error: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "kube-ca". Issue with the image registry using a cert signed by the service-signing controller?

We are already populating the service CA in the build pod asdoe from your
origin pr, that's how I demo's this working yesterday. Your pr is doing it
the "right" way, but the logic I put in place a while ago is still there
and should make Buildah trust the registry. It uses the CA that is
automatically mounted into every pod.
So I think your error means something else is wrong.
Ben Parees | OpenShift
On Thu, Dec 6, 2018, 16:48 Adam Kaplan<EMAIL_ADDRESS>wrote:

Error: certificate signed by unknown authority (possibly because of
"crypto/rsa: verification error" while trying to verify candidate authority
certificate "kube-ca". Issue with the image registry using a cert signed
by the service-signing controller?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/cluster-openshift-controller-manager-operator/pull/42#issuecomment-445042103,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEvl3lMeMzrp2kQc67YGnavYt5IXNzAaks5u2ZC7gaJpZM4Y6rJq
.

/refresh
/retest

/retest

/retest


[ALLUXIO-2670] add serial version uid to UfsBolckAccessTokenUnavailableException

add serial version uid to UfsBolckAccessTokenUnavailableException

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/14358/
Test PASSed.

LGTM

Thanks for the improvement, can you sign the CLA? thank you

Hey @HAO970422, do you mind signing the CLA? You can sign it here: http://cla.alluxio.org/

@HAO970422 can you sign the CLA?

@HAO970422 feel free to reopen this PR after you sign the CLA.


Inconsistent speeds: RESOLVED

Just wanted to let everyone know that I found a resolution to actual inconsistent speeds (NOT PING/LATENCY).
I ran this program on 3 different devices and 3 different versions of python3:
[Aries] (RaspberryPi 3 Model B+): Python3 Version = Python 3.4.2 --> Runs perfect speedtests with correct results (Correct Download, Correct Upload)
[Taurus] (RaspberryPi 3 Model B+): Python3 Version = Python 3.7.3 --> Runs imperfect speedtests with incorrect results (Correct Download, Max ~3Mbps Upload)
[Leo] (Ubuntu Custom Machine): Python3 Version = Python 3.6.8 --> Runs imperfect speedtests with incorrect results (Correct-ish Download, Max ~3Mbps Upload)
I also ran it with my two WSL machines, one at home and one at work, and they both report incorrect speeds (one on python3 3.5.2 and one on python3 3.6.8).
I then went to attempt to research the issue and notably found that different python versions can report different results.
I attempted to uninstall and reinstall the program with no luck, and attempted upgrading my python3 version also with no luck.
Finally, I somehow (I forget how I found it, probably when I was reinstalling it) found the path of the program (/usr/lib/python3/dist-packages/speedtest.py) and forced it to just use python (2.7.15rc1) and it worked!
Command: python /usr/lib/python3/dist-packages/speedtest.py

Haha, it's funny that this makes a difference. But you're right, I'm able to reproduce the original issue, and then your resolution on my server (upload jumps from 4mb/s to 400mb/s)


"maestro test" does nothing

When I try to run the command for the test to start nothing happens and the test never runs.

Are you using Android or iOS? If Android, is it an emulator or a real device?

I'm using an Android Emulator, the app is already running when I try to execute the command to test.

hi. how's the progress of this issue? i using android emulator and i get this issue too

I have the same problem.
Are there any updates?


Make FHIR proxy server context path customizable

The context path of the FHIR proxy server is currently hardcoded to /fhir. To render this customizable, only a few changes need to be performed:

Add an environment variable APP_SERVER_CONTEXT_PATH and default it to /fhir in dsf-docker/fhir_proxy/Dockerfile:ENV PROXY_PASS_CONNECTION_TIMEOUT_WS=30
+ENV APP_SERVER_CONTEXT_PATH="/fhir"

Replace the hardcoded context path /fhir in dsf-docker/fhir_proxy/conf/extra/host-ssl.conf with that environment variable:-<Location "/fhir">
+<Location "${APP_SERVER_CONTEXT_PATH}">
        RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s

-       ProxyPass http://${APP_SERVER_IP}:8080/fhir timeout=${PROXY_PASS_TIMEOUT_HTTP} connectiontimeout=${PROXY_PASS_CONNECTION_TIMEOUT_HTTP}
-       ProxyPassReverse http://${APP_SERVER_IP}:8080/fhir
+       ProxyPass http://${APP_SERVER_IP}:8080${APP_SERVER_CONTEXT_PATH} timeout=${PROXY_PASS_TIMEOUT_HTTP} connectiontimeout=${PROXY_PASS_CONNECTION_TIMEOUT_HTTP}
+       ProxyPassReverse http://${APP_SERVER_IP}:8080${APP_SERVER_CONTEXT_PATH}
 </Location>
-<Location "/fhir/ws">
+<Location "${APP_SERVER_CONTEXT_PATH}/ws">
        RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s

        ProxyWebsocketFallbackToProxyHttp off
-       ProxyPass ws://${APP_SERVER_IP}:8080/fhir/ws timeout=${PROXY_PASS_TIMEOUT_WS} connectiontimeout=${PROXY_PASS_CONNECTION_TIMEOUT_WS}
-       ProxyPassReverse ws://${APP_SERVER_IP}:8080/fhir/ws
+       ProxyPass ws://${APP_SERVER_IP}:8080${APP_SERVER_CONTEXT_PATH}/ws timeout=${PROXY_PASS_TIMEOUT_WS} connectiontimeout=${PROXY_PASS_CONNECTION_TIMEOUT_WS}
+       ProxyPassReverse ws://${APP_SERVER_IP}:8080${APP_SERVER_CONTEXT_PATH}/ws
 </Location>

Add the following (exemplarily) then to docker-compose.yml:
(Note that the environment variable DEV_DSF_SERVER_CONTEXT_PATH already exists in dsf-fhir/dsf-fhir-server-jetty/docker/Dockerfile)services:
  proxy:
    image: ghcr.io/datasharingframework/fhir_proxy:1.1.0
    ...
    environment:
      ...
+     APP_SERVER_CONTEXT_PATH: /dsf/fhir
  ...
  app:
    image: ghcr.io/datasharingframework/fhir:1.1.0
    ...
    environment:
      ...
+     DEV_DSF_SERVER_CONTEXT_PATH: /dsf/fhir
  ...

The above has been implemented and successfully tested in our local environment already.
⚠ There just seems to be a tiny bug though in dsf-fhir/dsf-fhir-server/src/main/java/dev/dsf/fhir/adapter/HtmlFhirAdapter.java in private String getUrlHeading(Resource resource) which leads to a a double display of /fhir in the shown title, e.g. https://diz.uks.eu/dsf/fhir/fhir/metadata and  - if I am not mistaken - there should be a html tab left to the json and xml tabs. (see screenshot)

@holger-stenzhorn I have implemented your suggestion slightly modified in #95. The DEV_DSF_SERVER_CONTEXT_PATH variable does not need to be specified for the DSF FHIR app server if the apache httpd ProxyPass and ProxyPassReverse directives stay hard coded to the DSF FHIR app server context path default .../fhir...

The given solution works nicely but there is a tiny "edge case": If you enter e.g. https://diz.uks.eu/dsf/test/fhir then this gets redirected to https://diz.uks.eu/fhir. A quick and easy fix for this issue would be to change host-ssl.conf accordingly:
+Redirect ${SERVER_CONTEXT_PATH} ${SERVER_CONTEXT_PATH}/
-<Location "${SERVER_CONTEXT_PATH}">
+<Location "${SERVER_CONTEXT_PATH}/">
        RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s

-       ProxyPass http://${APP_SERVER_IP}:8080/fhir timeout=${PROXY_PASS_TIMEOUT_HTTP} connectiontimeout=${PROXY_PASS_CONNECTION_TIMEOUT_HTTP}
-       ProxyPassReverse http://${APP_SERVER_IP}:8080/fhir
+       ProxyPass http://${APP_SERVER_IP}:8080/fhir/ timeout=${PROXY_PASS_TIMEOUT_HTTP} connectiontimeout=${PROXY_PASS_CONNECTION_TIMEOUT_HTTP}
+       ProxyPassReverse http://${APP_SERVER_IP}:8080/fhir/


Properly document disabling of audio autoplay

We need to be sure our documentation properly covers how to disable automatic autoplay of audio.
https://bugzilla.mozilla.org/show_bug.cgi?id=1474263
See this meta bug that covers all the engineering efforts involved in getting this right: https://bugzilla.mozilla.org/show_bug.cgi?id=1376321 (most of them have been fixed)
Acceptance criteria

[x] Identify all of the places that need to be updated; any methods that start playback, attributes that specify autoplay, and pages generally covering playback of audio; also any pages suggested by the many many bugs which are blockers for this meta bug
[x] Add a section to the general media introduction content about this topic
[x] Update the identified pages with appropriate notes and explanations
[x] Request engineering review of the changes made

Work related to disabling audio autoplay docs recorded in https://trello.com/c/4emMB6Y8/146-autoplay-api-fx-66


caching docker images in travis. Fixed #56

Caching for all layers of the Docker image
For every branch
Takes a while to save and load, but will allow us to investigate which are most useful. Will be pruned later

Sorry about the confusion, I was running the original PR #71 against a test_master branch - I was going to check different branch names originally.

Also, as per the docs

If a branch does not have its own cache, Travis CI fetches the master branch cache.
There is one cache per branch and language version/ compiler version/ JDK version/ Gemfile location/ etc.

So we will only see the benefits of caching after doing several builds against the master branch


Add support for "create_only" field to secrets

fixes #537
I have been trying to get something to test this in the acceptance-test.sh but failed so far because the only backend i know to test this with is GCP Secrets and it does require a google configuration to be actually mounted and used

@bonifaido example added.


Uninstall from Powershell cmd

PS command should be "Uninstall-Module -Name AzureRM", not "Uninstall-AzureRm".

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

ID: 96a60a63-cd45-8326-e0c9-d713cad6727a
Version Independent ID: b3ce94fa-6e76-4ffe-e70e-07f7a321fcd4
Content: Uninstall Azure PowerShell
Content Source: docs-conceptual/azps-1.4.0/uninstall-az-ps.md
GitHub Login: @sptramer
Microsoft Alias: sttramer

The Uninstall-AzureRm cmdlet is provided by Az for the explicit purpose of removing old AzureRM installs.


[3.x] GDScriptParser - don't use index operator on linked list

Index operators are super slow with linked lists. This came up in profiling the parsing, iterating sequentially using iterator is much faster.
Helps fix #74733.
Notes

This fixes one of the bottlenecks in parsing but there are more.

Thanks!

Cherry-picked for 3.5.3.


Option to stick output to bottom

When you have a lot of text scrolling by in the Output window (for example grunt tasks), it would be a nice feature to be able to let the Output window stick to the bottom, so you always see the last lines of text.
I saw an issue #3351 but this issue doesn't make it clear to me if there is an option for this or not.

This should work as you expect. What version of VSCode are you using? Is this only with grunt tasks or all tasks?

@chrmarti I have this problem in at least the Git and the Tasks 'tabs' of the output window.
I am using the insiders version of Visual Studio Code (currently c032f0e2bc602eb9388221876911913e5a808aec)

The output should automatically scroll if the last line is reveled already.
Thus if you have scrolled up you will remain in scroll position. Otherwise it always scrolls to bottom, more details https://github.com/Microsoft/vscode/issues/3351
Closing as designed


fix sizeof warning, which triggered SyntaxError: Unexpected token error

Closes #28
Not sure if there were any other warnings/errors that could've been the cause. This was what made it work for me. Found the issue by logging the xhr output from the xhrError function in main.js, with the output in responseText having:
Warning:  sizeof(): Parameter must be an array or an object that implements Countable in /www/public/lookup.php on line 158

Warning:  sizeof(): Parameter must be an array or an object that implements Countable in /www/public/lookup.php on line 160

Warning:  sizeof(): Parameter must be an array or an object that implements Countable in /www/public/lookup.php on line 161

Would definitely recommend better logging for end-users, or at-least an error in the console showing the responseText in case something similar happens again.

Hi @granny, thank you for the PR! I'm sorry I noticed it only today ;w;


orange pi zero plus 2

hi nisarg
any solution to port this project on orange pi zero plus 2 with ebedded H5 cpu .

Duplicate #162, which has some more info around this.