Do ListProperty, SetProperty and MapProperty differentiate between "EMPTY" and "UNSET" ?

Follow up on (https://github.com/gradle/gradle/issues/7485#issuecomment-585289792)
I need to be able to distinguish between EMPTY and UNSET MapProperty because a user might override a previously set property with an empty one. I'm doing mapProperty.set(null as Map<String, String>?) to unset the value from the initial empty value.
But somehow it is possible to .put() values into this empty MapProperty:
Expected Behavior
mapProperty.set(null as Map<String, String>?)
mapProperty.put("key", "value")
mapProperty.isPresent // this should be true

Current Behavior
mapProperty.set(null as Map<String, String>?)
mapProperty.put("key", "value")
mapProperty.isPresent // this is currently false

Context
See https://github.com/apollographql/apollo-android/issues/1987 for some context. The user is able to add to the MapProperty but their configuration is not picked up.

I contributed the original MapProperty in 5.1, so I'll try to explain the concepts as I understand them. Some additions have been made since then, but I believe the fundamentals are still true.
Collection and map properties use the concept of "collectors" to allow for lazy evaluation. Each collector can contribute a number of elements to the collection or entries to the map (possibly zero). When the property is evaluated, it iterates through all of the registered collectors to determine the actual value.
All such properties are initialized with a single collector that just contributes an empty collection or map. This wasn't always the case, but makes them much more usable and predictable, because starting with an empty collection/map is what you'd expect in most cases. It is also one of the big differences to the "simple" properties which start without a value.
When adding to a collection property or putting into a map property, you're really just registering another collector that will provide the given values when it is evaluated. If the collection/map starts empty, this leads to what you would expect. When you set the property to an explicit value, you discard all the existing collectors and replace them with one providing the given value.
However, when explicitly un-setting the property (by setting it to null), you replace the initial "empty" collector with a special collector that says "no value at all", and will short-circuit any evaluation of the property to "no value". It is still possible to add further collectors (hence the call to put is allowed) because of the lazy evaluation, but they will have no effect.
I agree that this behavior is quite confusing, but I think it's the only way to uphold the general Provider/Property contract while still having a decent solution for working with collections and maps. I would suggest to avoid un-setting collection and map properties and try to design the plugin in a way that treats "empty" as the default.

It is still possible to add further collectors (hence the call to put is allowed) because of the lazy evaluation, but they will have no effect.

That feels weird. What would be the drawback of throwing an exception in that case to make the caller aware that the collector will have no effect?

try to design the plugin in a way that treats "empty" as the default.

The API still feels somewhat inconsistent. I just bumped into this again today:
  @get:Optional
  @get:Input
  abstract val headers: MapProperty<String, String>

Does it make sense to put @Optional up there?

Just bumped into this again today 😅 . A simple workaround would be to allow Property<Map<...>>.
When trying to create such property at the moment it fails with:
Please use the ObjectFactory.mapProperty() method to create a property of type Map<K, V>.

Allowing Property<Map<...>> would be a simple solution for users that don't need per-item collectors but needs to differentiate between empty and unset

Update:
Using mapProperty.convention(null as Map<String, String>?) instead of mapProperty.set(null as Map<String, String>?) works as expected:

The property will have an unset value.
Adding items will correctly set the value.

Thanks @octylFractal for pointing at this solution 🙇

I stumbled upon the same problem. Take this script:
abstract class MyTask extends DefaultTask {
    @Input
    abstract Property<String> getWhoAmI()

	@Input
	@Optional
	abstract ListProperty<String> getStrings();

	@TaskAction
	void doSomething() {
	    print("Task $name (list property ${whoAmI.get()}) ")
		if (strings.isPresent()) {
			println("strings: ${strings.get()}")
		} else {
			println("strings: not set")
		}
	}
}

tasks.register("a", MyTask) {
   whoAmI = "not set"
}
tasks.register("b", MyTask) {
   whoAmI = "set to empty list"
   strings.set([])
}
tasks.register("c", MyTask) {
   whoAmI = "set to non empty list"
   strings.set(["one","two"])
}

tasks.register("check") {
   dependsOn(tasks.withType(MyTask))
}

and run gradle check. The output is:
> Task :a
Task a (list property not set) strings: []

> Task :b
Task b (list property set to empty list) strings: []

> Task :c
Task c (list property set to non empty list) strings: [one, two]

Which is annoying because I cannot make the difference between "the user didn't express an opinion" and "the user set to an explicit empty list". Note that this could be fixed differently if there was a convention value and that there was a way to ask if the value is the convention one:
if (strings.usesConventionValue() {
    ....
}

For the next release, Gradle 8.7, we are introducing alternative verbs for the kind of expectation this issue states:
mapProperty.set(null as Map<String, String>?)
mapProperty.put("key", "value")
mapProperty.isPresent // this is false, but some expect it should be true

Instead of put, use insert.
mapProperty.set(null as Map<String, String>?)
mapProperty.insert("key", "value")
mapProperty.isPresent // this is true

That will be true even if convention is set to a null map (i.e. unset). If the convention is actually defined, it will commit the convention as the explicit value before performing the addition. Also, the property will have a value even if the value being inserted is undefined.
See https://github.com/gradle/gradle/pull/27859, hopefully the javadoc for the new methods will be clear enough. If not, please provide feedback as questions/comments.
That said, I would like to understand better the use cases for checking whether a property has its value explicitly assigned or via convention, as suggested by @melix, possibly as a separate issue. I wonder if such use cases can't really be addressed with API we introduced recently during 8.7. Note that now we do have an internal method for that, but it is meant to help with unit testing the Property implementation.
@martinbonnin and others: any reason why we should not close this as addressed via #27859?

Hi @abstratt ! Thanks for looking into this.
My hunch is that adding more methods is not the solution to this particular problem. Or at least not without deprecating some others. This is a problem about communicating the intent of the API, increasing the API surface will only make things harder IMO.
Re-reading my initial comment, I changed my mind. In retrospect, my preferred expected behaviour right now would be more like so:
Preferred Behaviour after letting it soak some time:
mapProperty.set(null as Map<String, String>?)
// this is not ok as there is no map to put into
mapProperty.put("key", "value") // throws exception: cannot put entry in absent map

This way, users can't just put values into an absent MapProperty, they have to either set everything at once:
// this is ok, set all the entries at once
mapProperty.set(mapOf("key" to "value"))
// this is ok, set all the entries from a provider
mapProperty.set(provider { mapOf("key" to "value") })

Or build their map proressively if they want collecting entries:
// this is ok, set entries one after the other
mapProperty.set(emptyMap<String, String>())
mapProperty.put("key1", provider { "value1" })

As a plugin author, I could distinguish between "empty" (in both the above scenarios) and "absent" (if the user didn't set the property at all). I believe this would also fix @melix issue above.
Something else that I would love to have is consistent initial state:
val listProperty = objects.property(String::class.java)
listProperty.isPresent // false

val mapProperty = objects.mapProperty(String::class.java, String::class.java)
mapProperty.isPresent // currently returns true, feels very inconsistent

I realize this is probably not the answer you were looking for and I also realize the MapProperty ship has sailed and changing such a low level behaviour is probably not an option anymore. But overall, I feel it'd be a much consistent story overall.

@martinbonnin We do consider deprecating add*() and put*(),  but only after append*() and  insert*() are out of incubation.
Btw, I cannot reproduce the inconsistent behavior between map and list properties (tried 8.2 and 8.6). If you have a reproducible test case, please open a separate ticket for that.
Now, back to your use case. We would like to promote a model where plugin authors set conventions to their own plugin task properties only, and let users overwrite/build on them via explicit values if they want to. it seems that model is not working for you. Could you help us understand the reason? It may be the case that the API we have now enables use cases that were blocked before.

I cannot reproduce the inconsistent behavior between map and list properties

Apologies, the variable was completely misnamed listProperty instead of stringProperty:
val stringProperty = objects.property(String::class.java)
stringProperty.isPresent // false

val mapProperty = objects.mapProperty(String::class.java, String::class.java)
mapProperty.isPresent // currently returns true, feels very inconsistent

This is with Gradle 8.6 and this seems to be done on purpose (cf doc) although I'm not really clear why.

plugin authors set conventions to their own plugin task properties only, and let users overwrite/build on them via explicit values if they want to

Sounds good 👍

it seems that model is not working for you.

It actually is working right now for me with the solution from https://github.com/gradle/gradle/issues/12222#issuecomment-674741780:
// plugin
mapProperty.convention(null as Map<String, String>?)

// case 1: user does nothing
mapProperty.isPresent // false

// case 2: user sets emptyMap
mapProperty.set(emptyMap())
mapProperty.isPresent // true

// case 3: user calls put on top of the default emptyMap
mapProperty.put("key", "value")
mapProperty.isPresent // true

So I'm technically not blocked and I can distinguish between user null and user absent in my plugin.
Still, I'm having a hard time understanding how this API works.
If the MapProperty is initialized with an empty map then why does the convention even matters? I thought conventions were only useful if a provider was missing a value (which is not the case here because it has an empty list value by default). So this is all surprising. And why is the MapProperty not initialized to absent in the first place?
Maybe this is all complexity required by the fact that MapProperty now has lazy entries and now there are questions like: "what happens if an entry value is missing? Should the whole MapProperty be missing? Or should the entry be ignored?" (it seems to be the former but I had to try it out, I couldn't really guess).
But that complexity isn't always required and not being able to use a Property<Map<K,V>> feels like a missed opportunity for simpler APIs.

@martinbonnin Thanks, I indeed was misled by the var name, sorry for my confusion.

Still, I'm having a hard time understanding how this API works.

Thanks for the feedback, we are trying to improve in that area.

If the MapProperty is initialized with an empty map then why does the convention even matters?

The same strategy you tried would have worked with set((Map) null) instead of convention((Map) null). Both will replace the "initial effective value", the former by unsetting the explicit value, the latter by unsetting the convention.

I thought conventions were only useful if a provider was missing a value (which is not the case here because it has an empty list value by default).

To be more specific, conventions are only supported on properties (and soon, ConfigurableFileCollections), but not in providers in general.  The effective value of a collection/map property is:

an empty collection/map, when instantiated
the value set with convention(), if an explicit value is not set with set()
the value set with set()

So this is all surprising. And why is the MapProperty not initialized to absent in the first place?

List/set/map properties are special as they have three possible states (empty, populated and unset), whereas non-composite properties allow only set and unset. One benefit for collection properties is that they can be used for incremental updates without preliminary setup. If everyone needed to set some value before setting them, then they would risk overwriting a value previously set.

what happens if an entry value is missing? Should the whole MapProperty be missing? Or should the entry be ignored?

As you saw, the entire property value is considered missing, as described here and here.

One benefit for collection properties is that they can be used for incremental updates without preliminary setup.

Would you be open to allowing Property<Map<K,V>> in task properties? I would personally prefer to use that API. It is more inline with what I'm used to and I don't need incremental updates and the cognitive load attached to them.

That said, I would like to understand better the use cases for checking whether a property has its value explicitly assigned or via convention, as suggested by @melix, possibly as a separate issue.

The use case is that the Micronaut plugins build on top of the Native Build Tools plugin. The NBT plugins set some conventions in a map property, and the Micronaut plugins need to add to these conventions. However, if the user has explicitly set some value, we don't want to set our conventions. So we need a way to append to the conventions, vs appending to what is set.

We do consider deprecating add*() and put*(), but only after append*() and insert*() are out of incubation.

I would not do this. It is already extremely painful for plugin authors to keep up to date and support multiple Gradle versions. It is extremely annoying to have new APIs you have to use because they are better, but then you realize that you made a mistake and deprecate with something else. It happened several times in the past years (e.g config cache) which makes it extremely unpleasant to write Gradle plugins.

Would you be open to allowing Property<Map<K,V>> in task properties?

@martinbonnin Could you please open a feature request for property value types such as Map (and I guess List) to be allowed? That is beyond the scope of this issue. I don't have enough context, but Gradle goes out of its way to guide users into using the specifically purposed properties instead of general properties.


Make results viewing interface stateful

Currently, if I view beta diversity results (and select certain options in emperor), then view my alpha rarefaction plots, then go back to my beta diversity results, it relaunches emperor, and I lose the settings I have selected.  It would be really cool if it could retain the state when switching between viewing these different sets of results.

This feature relies on Emperor being able to do this, once this https://github.com/biocore/emperor/issues/3 is closed we can add here.

That issue wouldn't necessarily fix this problem. The reason why this is
happening in Qiita is because iFrames are created and destroyed every time
a visualization is clicked. The frames should instead be hidden and not
recreated.
On Thu, Mar 5, 2015 at 7:58 AM, Antonio Gonzalez<EMAIL_ADDRESS>wrote:

This feature relies on Emperor being able to do this, once this
biocore/emperor#3 https://github.com/biocore/emperor/issues/3 is closed
we can add here.
—
Reply to this email directly or view it on GitHub
https://github.com/biocore/qiita/issues/211#issuecomment-77390181.

Closing this in favor of: https://github.com/biocore/qiita/issues/1389


app face lift

Was looking at the app and couldn't get over how it looked.  Made a mockup and showed Emily who approved the new layout look.
This new layout sections off the graphs and makes it easier to tell what's what. It also simplified the templates and got rid of a lot of unnecessary CSS. Win Win.  We can move around individual graphs as we please if we don't like the order I picked.
@jiwalker-usgs @ldecicco-USGS @eread-usgs Thoughts?

Looks great!


Pixel Observer could take angle argument?

The Pixel Observer0D currently defaults to a hemisphere cosine sampler.
Perhaps it could take an optional angle argument which if supplied changes the sampling to use a cone cosine sampler. This prevents the need for multiple observers doing similar things.

Perhaps better if this is its own class. DirectedPixel, TargetedPixel, ConstrainedPixel, FocuesedPixel, etc. Use math from importance sampling of primitives. Take a sphere as argument for calculating projected solid angle.

The target sphere should be inside the scenegraph.

Alex worked on this issue in the following commits.
b97c1a391560965d6189251df2ff26032e88f6ab
b1d73ce8f67400a5dda5245e34bfb0b75cc36daf
5a56c2ccc306a80ad5cf9ceed97eb624a089590e
08f68eb72bb58b6cb89ac5c6041ed0c8b07f92ba
1b2f483a8822c2857155683db38904829ed72411

This ticket was closed in the recent merge,<PHONE_NUMBER>518182abfd254d43c27105c1796c97.


CB-10363: Cleaning up the 'plugin spec' documentation

CB-10363
This is still in-flight. more commits to come before this PR can be pulled in.

@rakatyal can you please review these changes ?

There is already a Jira (CB-10363) for this under Docs 6.x tag. Can you please refer to that one instead and close this one?

@omefire: Can you close this PR? I took care of most of these changes in my commit.


Use the QUICKLIST encoding to dump the list payload to compatible with Redis >= 4

Close #2253
In order to support the compatibility of old versions of redis,
when using the dump command, QUICKLISTencoding is used instead of QUICKLIST2for LIST encoding.

Could you write some test cases for your patch? Thank you!

Could you write some test cases for your patch? Thank you!

Here I just changed a coding method. The previous tests can still be used. I have now added some corner cases.

Could you write some test cases for your patch? Thank you!

Here I just changed a coding method. The previous tests can still be used. I have now added some corner cases.

Generally, if we fixed a bug in a patch, we need to add a test case, that should fail without the patch, and succeed after the patch is applied.

@AntiTopQuark Thanks for your efforts.

I can confirm it also works in Redis 4:
<IP_ADDRESS>:6379> RESTORE list 0 "\x0e\x04\x0e\x0e\x00\x00\x00\n\x00\x00\x00\x01\x00\x00\x01d\xff\x0e\x0e\x00\x00\x00\n\x00\x00\x00\x01\x00\x00\x01c\xff\x0e\x0e\x00\x00\x00\n\x00\x00\x00\x01\x00\x00\x01b\xff\x0e\x0e\x00\x00\x00\n\x00\x00\x00\x01\x00\x00\x01a\xff\x06\x003\x06\xd4\x86\x93\xfbvB"
OK
<IP_ADDRESS>:6379> lrange list 0 -1
1) "d"
2) "c"
3) "b"
4) "a"

@AntiTopQuark Need to reformat codes.


Update io-surface and bump version

This change is

@bors-servo r+

:pushpin: Commit 04fd0b2 has been approved by jdm

:hourglass: Testing commit 04fd0b20543625e375ff784f977c998543402877 with merge 1522ed828facfed01f58ad8a327be6ef3d79c12e...

:sunny: Test successful - status-travis
Approved by: jdm
Pushing 1522ed828facfed01f58ad8a327be6ef3d79c12e to master...


Webview not working in explorer view

Version: 1.61.2
OS: Darwin x64 20.6.0
I'm using a Webview which is placed in the explorer view.
The same WebView (a different instance, of course) is also placed in the debug view.
The html and the js-code files are exactly the same for both.
Yet, the js-code file is found/loaded only in the debug view and not in the explorer view.
Here the error from the developer tools:

I checked the path and it exists.
The explorer view with the error looks like this (because the view is not filled correctly by the js-code):

Whereas the debug view works correctly (and loads the js-file):

This also loads the css correctly. Therefore one button is yellow.
What is the difference between a Webview inside the explorer view and a Webview inside the debug view?
Is it maybe something about access rights?
If you would like to try yourself, here is the link to the extension:
https://marketplace.visualstudio.com/items?itemName=maziac.asm-code-lens

Ok closing this as not-reproducible based on the comments


Explicitly disable ANSI mode for ast_test.py [databricks]

As a part of the effort to add support for Spark 4.0.0 we are explicitly disabling ANSI mode.
We will be adding more tests with ANSI enabled but that will have to come as #5120 is done
fixes #11008

build

build


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/67925

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/108519

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/109747


EB-84602 Zoom to mouse/pinch center

@amber-eb Thanks for 👀 . Yeah, I think some basic tests could be beneficial to safeguard some logics. The test needs to have a fake camera, for zoom, it's mainly the z value is what matters.
However I just found out yarn test process is stuck. I think I need to spend some time fixing it at first, then I can add some tests with fake camera in another PR.

@amber-eb do you have other minor comments? I don't see them showing up here 🤔

I figured out how to test locally. Two new commits pushed, and added some unit tests to pan_and_zoom.js
cc @amber-eb @jseifi-eb @rchapman-eb

NICE!


@erictraut I have to explain that in your example, the last key [3, 4] is invalid because it's mutable. See the reasons https://docs.python.org/3/faq/design.html#why-must-dictionary-keys-be-immutable

@erictraut I have to explain that in your example, the last key [3, 4] is invalid because it's mutable. See the reasons https://docs.python.org/3/faq/design.html#why-must-dictionary-keys-be-immutable
Originally posted by @CodeCrazy-ywt in https://github.com/microsoft/pylance-release/issues/1493#issuecomment-882244253

Oh, what did I do? Nooooo! :-( Closing this issue.


Swift2 2.0 development

add Swift 2.0 and Xcode 7 support
use ErrorType provided from Apple
remove nsError from ErrorType (knowing that a _domain, _code is provided when conforming to ErrorType so it's easy to build an NSError from it (aka:  NSError(domain: _domain, code: _code, userInfo: nil)
upgrade Result to a version that no longer has Box (thanks to Swift 2.0)

Thanks for the PR! I hope to look at it over the weekend. There will be a BrightFutures 2.0 version that will be compatible with Swift 1.x, so I'll merge this into a new branch.

There will be a BrightFutures 2.0 version that will be compatible with Swift 1.x, it's a very good idea, I could not submit a PR to a new branch, just wanted to get it out there

I merged your work into the new https://github.com/Thomvis/BrightFutures/tree/swift-2.0 branch. Thanks so much for your contribution! I'll probably be making some additional changes as I get to know Swift 2 and will try to have a beta release out soon.


New version: MsgPack v1.0.0

Registering package: MsgPack
Repository: https://github.com/JuliaIO/MsgPack.jl
Created by: @jrevels
Version: v1.0.0
Commit: 6f24facbd799e5f57e1847a8324173a78ab0423b
Reviewed by: @jrevels
Reference: https://github.com/JuliaIO/MsgPack.jl/commit/6f24facbd799e5f57e1847a8324173a78ab0423b#commitcomment-35009590

Please add (at least)
[compat]
julia = "1"

to your project file and retrigger the bot.

Thanks @fredrikekre!


request js has been deprecated

npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
It looks like this library needs to migrate from requestjs, to something like AxiosJS.
Ref: https://github.com/tumblr/tumblr.js/blob/master/package.json#L45

You may also consider dropping support for node versions prior to Node 10 perhaps with a new major version release of this npm module, since those versions of NodeJS are now in end-of-life: https://nodejs.org/en/about/releases
Ref: https://github.com/tumblr/tumblr.js/blob/master/package.json#L15

Sent a message thru https://www.tumblr.com/support regarding this issue.

Deprecation warnings introduced in projects if using tumblr.js:
npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported
npm WARN deprecated<EMAIL_ADDRESS>Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142

Security warnings introduced in projects if using tumblr.js:
 npm audit report

request  *
Severity: moderate
Server-Side Request Forgery in Request - https://github.com/advisories/GHSA-p8p7-x288-28g6
Depends on vulnerable versions of tough-cookie
No fix available
node_modules/request
  tumblr.js  *
  Depends on vulnerable versions of request
  node_modules/tumblr.js

tough-cookie  <4.1.3
Severity: moderate
tough-cookie Prototype Pollution vulnerability - https://github.com/advisories/GHSA-72xf-g2v4-qvf3
No fix available
node_modules/tough-cookie

3 moderate severity vulnerabilities

Some issues need review, and may require choosing
a different dependency.

CVE-2023-26136
CVE-2023-28155

It looks like this library needs to migrate from requestjs, to something like AxiosJS.

I would cast my vote on using fetch instead. more lightweight with a smaller Bundle Size. built right into all env. cloudflare worker, react native, Node, Deno, Bun. browsers and web workers and so on.
Axios are very NodeJS/browser specific that only works with XHR or node:http(s)
and service worker don't even have XHR either. ...only fetch API.
Axios for browser don't even have streaming support b/c it depends on old XHR.

I'm actively working on this. There should be a major release that removes the dependency on request in the next week or so.

The request dependency has been removed on the default branch.
I agree, it would be nice to use fetch, but it's still experimental in Node.js (at least in current LTS releases).
Since this project targets Node.js, I went with Node's http/https request.

how about using undici then?
it would be simple to just dropping it once it's no longer needed.
also it would more useful as a conditional import.
i think it's best to avoid loading any nodejs specific dependencies if at all possible to better build cross comp packages
const fetch = globalThis.fetch || await import('undici').then(mod => mod.fetch)

...or just let the developer bring in their own fetch impl coming from either node-fetch, undici, window or whatever.
then ppl don't need to install any additional dependencies

We can certainly look at changing what we use for network requests. If you're interested in that, please open an issue for it.


Add Redux module

Add redux, react-redux, redux-form in Project.
Rebuilt project structure.

#4 resolved


Land a design for NavBar and NavTo that works across editors

With the changes in #6644 , JavaScript and TypeScript currently have different NavBar implementations - which is different to the NavTo implementation. We should aim to unify the behavior and reuse logic as much as possible.
There are a couple of design challenges to work through:

The presentation and usage of NavBars is different across editors. For example, in Visual Studio, you have a list of containers, and beside it a list of members in that container, and this is commonly used to understand/navigate the structure of the code. In VSCode, this is more a "Go to symbol" implementation, that is presented as a single list and is typically used to fuzzy search on a symbol name in the file (perhaps it should use 'navto' for file?).
The data structure is currently different. The API returns a NavigationBarItem[], and a NavigationBarItem contains a member childItems: NavigationBarItem[]. This lends itself to a tree-like structure which VSCode handles and shows all items in its single list, whereas VS expects ALL containers to be members of the top-level array returned, with only a single-level depth of childItems (the members for that container).
What constitutes a container? Currently TypeScript has a relatively classical structure, with the source file, namespaces and classes being containers. However it is not unusual in JavaScript to have functions within arrow functions within class members, etc... We need to figure out how this maps to editor models for presenting structure.

@basarat suggests adding a new API to return flattened list instead of having one API for all IDEs. see https://github.com/Microsoft/TypeScript/issues/8755.

Without looking at it too much isn't getNamedDeclarations (used on nav to) in a source file significantly slower than getNavigationBarItems (just the ast I think). I might be completely wrong :rose:

isn't getNamedDeclarations (used on nav to) in a source file significantly slower than getNavigationBarItems (just the ast I think). I might be completely wrong

They should be comparable. both do a full walk over the tree.

Is there any public API for getting symbols in a source file that is not UI-oriented? It seems like getNamedDeclarations does what I want, but it is marked as internal. It feels wrong using getNavigationTree to do static analysis, especially since the objects emitted are not linked to the node that defines them in any way.

@felixfbecker if you want to live on the edge : https://github.com/basarat/byots 🌹❤

We have landed a design for unified nav-bar between JS and TS for VS and a new navtree for VSCode. We have had this in place for over a year now with no complaints from API uses. I do not think this is needed any longer.


Gradient array contains NAN values.

When I run my code with single GPU, the gradient array does not contain any nan values. However, if I use more than one GPU, some gradient arrays contain nan values. Is this normal? If not, how can I fix this problem?

there are many situations about appearing NAN. You can follow these steps to check your program:

check whether there are something about input data
setup smaller learn rate

I've examined both, my findings are:

The input data has no nan values.
Learning rate is 0.01. I think it is small enough. Isn't it?

On the other hand, the issues above should not be the reason of single and multi GPU cases since everything is the same for both single and multi GPU cases. Same batch, examples in the same order, same parameters etc. but different results for single and multi GPU. Only randomness may be occurred from Dropout layer. I'll try cancelling that layer again but I don't think it's the reason of nan values.

I've removed Dropout layer and nan values are disappeared. I think one of cases mentioned in http://stackoverflow.com/questions/25506281/what-are-all-the-possible-calculations-that-could-cause-a-nan-in-python is performed but I couldn't find where the issue is raised. Any help from senior contributors will be appreciated.

0.01 is not enough, and there exist different lr for different task.

@mcxkarakoc Could you provide a reproducible example?

@sxjscience Here is an simplified example. Please note that it does not generate nan values in every run. You may have to run many times. In fact, that's the important part of the problem. As a note, to my observation, as the shape of the batch gets bigger, the chance of occurring nan values increases.
import mxnet as mx
import logging
import sys

def mean_abs(x):
    return mx.ndarray.divide(mx.ndarray.sum(mx.ndarray.abs(x)), reduce(lambda x, y: x * y, x.shape));

logger = logging.getLogger();
logger.setLevel(logging.DEBUG);
formatter = logging.Formatter('%(message)s');
h2 = logging.StreamHandler(sys.stdout)
h2.setFormatter(formatter);
logger.addHandler(h2)

mx.random.seed(0)
data = mx.nd.normal(loc=74.0131, scale=61.9225, shape=(8192, 12288));
data = data - 74.0131
dataIter = mx.io.NDArrayIter(data=data, label=data, batch_size=4096, last_batch_handle='roll_over');

x = mx.symbol.Variable('data')
x = mx.symbol.Dropout(data=x, p=0.99)
x = mx.symbol.FullyConnected(name='encoder_0', data=x, num_hidden=16384)
x = mx.symbol.Activation(data=x, act_type='sigmoid')
x = mx.symbol.FullyConnected(name='decoder_0', data=x, num_hidden=12288)
x = mx.symbol.LinearRegressionOutput(data=x, name='softmax')

mon = mx.mon.Monitor(1, stat_func=mean_abs, pattern='.*', sort=True);

modSolver = mx.mod.Module(x, context=[mx.gpu(0), mx.gpu(1)]);
modSolver.fit(dataIter,
              kvstore=mx.kvstore.create('local'),
              optimizer='sgd',
              eval_metric=mx.metric.create('rmse'),
              monitor=mon,
              initializer=mx.initializer.Uniform(0.07),
              num_epoch=1);

Here is the results of one of the runs.
 I couldn't write my real code here since my data is complex and private. However, the logic is the same.

@sxjscience @piiswrong I think the problem is related with the issues (numerical computation issue) in these links: https://github.com/fchollet/keras/issues/511 and https://github.com/fchollet/keras/issues/1244. They couldn't reach a stable solution, too. Theano has nanguardmode solution which I don't know its effectiveness. An efficient solution for the numerical computation stability would be good. For now, I'll apply the suggestions mentioned in http://deeplearning.net/software/theano/tutorial/nan_tutorial.html. Just FYI.

@mcxkarakoc For this example, I feel that the input here is one issue for the unstable behavior.
data = mx.nd.normal(loc=74.0131, scale=61.9225, shape=(8192, 12288));
data = data - 74.0131

This means that data will be non-centered and the sigmoids are at the saturate region.
Also, the hidden nodes of FC layer is quite large and may cause some computational problems.

@piiswrong Regarding the issue  #782 , are they the same problem for softmax_backward_label? However, in my experiments (as you may see above), softmax_backward_label is not consistent. It takes different values including nan.  According to your saying "we don't backprop to label" , softmax_backward_label should be constant, shouldn't it?


🐛(frontend) fix issue where title placeholder does not turn black after editing from default

Purpose
This pull request fixes a bug (issue #328) where the document title placeholder remains grey after being edited. The fix ensures the title turns black upon editing, providing clear visual feedback that the placeholder has been replaced.
Proposal
Problem
In DocTitle.tsx, when the default placeholder text is highlighted and edited (mutated), handleTitleSubmit gets executed. Initially, the code block handling the mutated title only updates updateDoc with the new title. However, without updating the titleDisplay state, the isUntitled flag does not get updated properly, leaving it as true when it should be false. This results in the title being styled in grey (indicating it’s still untitled) when it should be black.
Solution
Set the titleDisplay state to the new title value in the code block that handles title mutation in handleTitleSubmit. This ensures the isUntitled flag is updated correctly, allowing the title to be styled in black once edited, as expected.
https://github.com/user-attachments/assets/9ea5c30d-387f-437f-872e-5790c4e53c91

Hi @AntoLC! Could you send me the invite again? Apparently it has been revoked. I'm currently on a field trip in a remote area with very limit access to the internet so won't be able to look at this until I come back home this weekend. Thanks so much!

Thank you for your interest.
Solved here:
https://github.com/numerique-gouv/impress/pull/454/commits/a063863f7f8aa90499746324bc0a3dd2f29a0a94#diff-85a45203f721ed832b1d70ca61103363a678da2fd66754e6dbcf2e01f6bdf019R136


Supervisor Meeting - February 12 2024 @ 10:00 AM

Demo revision 0 to supervisors and gather feedback

Update advanced fields with descriptions (i icon).
Change uses inhaler to regular/daily inhaler use.
Change advanced fields to only show advanced fields if clinician or (advanced tab by default).
Display exact location of study on map or similar.
Important
Trouble getting contact info from clinical trials for all trials.
Useful to show contact info for trial to user.
Contact is the big value add.
Display principal investigator.
Change to clinical trials or research studies.

Next meeting potentially of 26th.
Dr. Ho will follow up with email containing updated fields list + info on gathering contact


Question about intersectsBox and crs transform.

Hi, I'm new to 3d tiles and trying to use this lib to display my cesium asset tiles, and found during the checkLoad, there is no boundingvolume intersets with the camera frustum. Below are my understanding toward this issue and how this lib works, and I wish you can help me to clarify some of the doubts and point a direction. Thank you so much.
To my understanding, this is how 3d tile works: The vertex info in b3dm/pnts are merely forming meshes in a non-georeferenced Cartesian coordinate system. It is the boundingvolume that defines its geo location and bounding. And the bounding volume can be in any crs or even non georeferenced(in 3d scene Cartesian coordinate system). The transform is applied to project children's crs to the parent's crs, or from root crs to base map crs(in this case, web mercator EPSG:3857 for mapbox).
So I assume the problem with my case lies in the crs. The cesium ion assets are not in EPSG3857(There is no crs info in the tileset.json, I assume it is in EPSG: 4979 since it is recommended in the 3d tile standard), and the transform provided is not from 4979 to 3857.
So there can be two approaches:

Transform the boundingvolume into 3857 to make it consistent with mapbox crs, and remove the transform info(or use default identity matrix).
Leave the boundingvolume as it is, and change the transform info to the transform needed from the boundingvolume's crs to 3857.

I've tried gdal and epsg.io to transform 4979 to 3857, but failed. And I don't really have a clue about how to form the transform matrix needed from 4979 to 3857.
Could you please help to clarify the doubt and shed some light upon this issue?
Thank you.

Hi, Cesium uses EPSG:4978 not 4979.
You can follow tutorial on https://github.com/Geodan/pg2b3dm/blob/master/getting_started.md to see how it all works.


chore(deps): fix cli,  bulk-import-backend and orchestrator-backend versions

Update/rebase the CLI and remaining plugins that have yarn changeset errors
Package "@janus-idp/backstage-plugin-bulk-import-backend" must depend on the current version of "@janus-idp/backstage-plugin-bulk-import-common": "1.0.1" vs "0.2.0"
Package "@janus-idp/backstage-plugin-bulk-import-backend" must depend on the current version of "@janus-idp/backstage-plugin-audit-log-node": "1.4.1" vs "1.4.0"
Package "@janus-idp/backstage-plugin-openshift-image-registry" must depend on the current version of "@janus-idp/shared-react": "2.10.3" vs "2.10.0"
Package "@janus-idp/backstage-plugin-orchestrator-backend" must depend on the current version of "@janus-idp/backstage-plugin-audit-log-node": "1.4.1" vs "1.4.0"

This PR does not need changesets as the plugins/packages are already published


Not an issue!

Hello!
Quick question. Is it possible to have checkboxes for each node?
Best
Isak

I saw you already had answered this in this thread. Sorry about the open ticket, it is closed now.
https://github.com/500tech/angular2-tree-component/issues/83


Google Maps API update

Hi,
May I know if there are existing Google Maps keyless support for the current release version?
There was an update by Google on Jun 2016 stating the deprecation of keyless support for Google Maps and it will require an API key on the client side. This will be enforced on June 11, 2018, and I would like to know if this will have any effect on this library.

It shouldn't, since this library (or my version) doesn't use any Google APIs, but only the Google Maps app's URL scheme.
It's documented here if you're interested 😊


FEATURE: add go interface-like trait system

#6
This one simple implementation that takes advantage of the existing type checking system. It removes the methods defined on replaced placeholder, so the replaced type is forced to implement those methods to be type-checked.
@DmitriyMV

I'll look into this as soon as I can - thank you!


Suppport reading .gz files

A lot of obj files are often gzipped by default obviously because of the nature of the format and the 4:1 or higher compression rate with larger files. It would be fairly trivial to support this considering python 2 and 3 has pretty extensive support for reading and writing gzip files.

Yeah I agree, this would be really helpful.

Fixed in my PR.


[Error] Call to undefined function Deployer\warning()

Deployer version: 6.8.0
PHP version: 7.4.11
Deployment OS: Ubuntu 20.04

Deploy an Laravel app with missing .env file. The deploy failed, at Executing task deploy:unlock it showing Error [Error] Call to undefined function Deployer\warning()
If I add an empty function as bellow to deploy.php, it work without error.
function warning(string $message) {

}

warning is function from v7. Not in v6.

warning is function from v7. Not in v6.


How to exclude paths for features such as jump-to-definition?

When attempting to use features such as jump-to-definition or find-references, I'm getting results from the project's output folder rather than the actual source code. Is there a way to get kak-lsp to ignore such directories?
I'm facing this problem in a ClojureScript project, but I imagine the same problem would exist in other languages, particularly web languages.
A related issue for that particular language server: https://github.com/clojure-lsp/clojure-lsp/issues/185

Thanks for quick response!
I too would have expected an ignore-output-directory setting to exist on the server side, as that is what deals with the language specifics. There is actually a setting for the clojure-lsp server that sounds like it should be doing the right thing by default. But since that isn't what I'm experiencing in practice, and since someone in that linked issue stated that they thought this should be up to the client--here I am.
It sounds like the short answer here is that kak-lsp does not support this and has no plans to. That makes sense as far as my limited understanding of the inner workings of LSP goes, but I had to at least check.

There is actually a setting for the clojure-lsp server that sounds like it should be doing the right thing by default.

which setting?

kak-lsp does not support this and has no plans to

if we knew how to do, we would probably support it
Can you give minimal steps to reproduce the problem? (Probably trivial but I've never used clojure).
I can try if VSCode has the same problem.
If not, it must be something they're doing on the client side, and we can probably mimic that.
Otherwise, we should probably complain to clojure-lsp to fix this for everyone.

I'm looking into solutions on the lsp server end. In this Slack thread, they are requesting server info, which other clients provide commands for. Is there a command for this via kak-lsp? I don't see one for it in the editor or readme.
  > we need the server info information, emacs and calva have commands to retrieve that

That link requires sign up and it doesn't tell me how to create an account.
"server info" doens't ring a bell but I guess they mean initializationOptions.
Anyway, I managed to reproduce and fix a similar problem.
TL;DR: you can set :source-paths-ignore-regex in one of 4 different ways, see https://clojure-lsp.io/settings/
Here's what I did

Install clojure, leiningen and clojure-lsp

lein new figwheel hello-world

cd hello-world

Define a function in another namespace
$ mkdir src/other && cat > src/other/other.cljs << EOF
(ns hello-world.other)
(defn myspecialfunction [])
EOF

Call the function from src/hello_world/core.cljs
(defn foo []
(myspecialfunction))

Observe that myspecialfunction has an error (marked with the red * in the gutter by kak-lsp), because it's not in scope.
This is easy to fix because clojure-lsp provides the appropriate code action.
Use enter-user-mode lsp press a and select Add require suggestion. Now the top paragraph should look like.
(ns hello-world.core
    (:require
     [hello-world.other :refer [myspecialfunction]]))

Add a second source directory that sorts before src and also provides myspecialfunction. This simulates your output directory.
$ mkdir asrc
$ cp src/other asrc/other

To have the build system pick it up, change the line :source-paths ["src"] in project.clj to :source-paths ["src", "asrc"].

run lein figwheel to build everything (probably not necessary though)

Now we can reproduce the problem: run kak src/hello_world/core.cljs and run gd on myspecialfunction. This will jump to asrc/output/other.cljs (but we want src/output/other.cljs).

Since clojure-lsp has added :source-paths-ignore-regex we can use that to avoid asrc.
$ cat >? .lsp/config.edn << EOF
{:source-paths-ignore-regex
["resources." "target." ;; defaults
"asrc.*" ;; added
]
}
EOF

After restarting Kakoune (or clojure-lsp), we successfully jump to src/output/other.cljs

This fix works independently of Kakoune/kak-lsp, so it should help VSCode users too.
FWIW, if you want to use LSP settings instead of  .lsp/config.edn you can do that too.
You just need to add 3 lines to your kak-lsp.toml.
[language.clojure]
filetypes = ["clojure"]
roots = ["project.clj"]
command = "clojure-lsp"
settings_section = "_"
[language.clojure.settings._]
source-paths-ignore-regex = ["resources.*", "target.*", "asrc.*"]

I suspect that you are seeing this issue due to a non-standard project setup.
IIUC by default, output artifacts are placed in resources or target, which are ignored by default.

Wow, nice work! So it would seem source directories are scanned alphabetically--good to note.

Add a second source directory that sorts before src and also provides myspecialfunction. This simulates your output directory.

One important detail I would add to this step is that the second directory should have to include a definition for the same namespace with the same function name, i.e. copy the first file you defined into the second directory. If the lsp server would pick up a function with the same name in a different namespace, then we'd have much bigger problems...

Observe that myspecialfunction has an error (marked with the red * in the gutter by kak-lsp), because it's not in scope.
This is easy to fix because clojure-lsp provides the appropriate code action.
Use enter-user-mode lsp press a and select Add require suggestion.

Yes! Great feature that is.
Out of scope for this issue, but while it's fresh I'd like to mention an issue with that feature. I used to see a list of possible namespace suggestions to require, but recently it seems to have been just using the first one. Maybe this has to do with changes to lsp-code-actions.
Now, back to the issue at hand...
So I figured out that I was using a version of clojure-lsp that didn't yet have the :source-paths-ignore-regex setting. I thought that the issue was persisting after updating this, but that was only partially the case. It did seem to fix the go-to-definition command, BUT I still see files from the output directory in the results of the list-symbol-references command. This one feels like it could be a bug, unless that feature cues off a different setting.

I used to see a list of possible namespace suggestions to require, but recently it seems to have been just using the first one. Maybe this has to do with changes to lsp-code-actions.*

Unlikely. We just forward code actions from the server. Maybe the server behavior changed? LMK if you have a reproducer.

BUT I still see files from the output directory in the results of the list-symbol-references command. This one feels like it could be a bug, unless that feature cues off a different setting.

I can't reproduce, lsp-references does respect ignored source paths here


Create log in page

This page is created for when the user is not authenticated!

What does this PR accomplish?

the section establish clearly why does the user needs to log in with it Spotify
the section makes easy and clear to the user how to log in with its spotify account
the section is fully responsive
the section does not cover the Login functionality jet, see #2 tickets!
a provisional background is setted, this because the background functionality will be build in #8 tickets!

Change the LogIn component name to Login


feat(android): WebView crash handling

Summary

On Android, the WebView process may get killed/crash. When this happens, if not handled appropriately, the whole app gets terminated in a quite brutal way (not even error reporting frameworks seemed to report this crash).
The fix: implement a handler for onRenderProcessGone (SDK >= 26) and return true.
The implementation also adds a new onCrash event so a webview crash can be handled on user land.
TODO: Review implementation for iOS, although it is most likely not needed.
Test Plan
Tested on Motorola G5 and Google Pixel 2

What's required for testing (prerequisites)?
Device / simulator
What are the steps to reproduce (after prerequisites)?
Test a webview that may run out of memory or render a extremely large image.
Compatibility

OS
Implemented

iOS
❌

Android
✅

Checklist

[X] I have tested this on a device and a simulator
[X] I added the documentation in README.md
[X] I mentioned this change in CHANGELOG.md
[X] I updated the typed files (TS and Flow)
[X] I added a sample use of the API in the example project (example/App.js)

Thoughts?

+100. This is very necessary to handle webview crashes gracefully. The diff looked pretty clean to me (please keep in mind I haven't reviewed any pull-requests though).
Kindly review and merge this.

It will be terrific if we can add support for iOS as well. Probably, by using the method
webViewWebContentProcessDidTerminate(_ webView: WKWebView) ?

@scriptspry I believe the terminate callback on iOS is already implemented here https://github.com/react-native-community/react-native-webview/blob/master/apple/RNCWebView.m#L974
However, that fires every time the webview terminates, not just on crashes, and doesn't let you "prevent the app crash" like the android version. For this reason, I haven't considered iOS yet on this PR.  It seems like it needs some more research and testing so it is probably better for it to be on another PR.

@cristianoccazinsp Would you mind resolving conflicts first?

Resolved from the web since it was just a readme issue. Can you take a look if the readme update was appropriate? Looks like I may be missing a reference so the links work, but I couldn't figure out how's the readme getting updated.

Pushed commits with the above recommendations.

LGTM! Any chance this would prevent the hard crash for a blob:// URL described here: https://github.com/react-native-community/react-native-webview/issues/1090

LGTM! Any chance this would prevent the hard crash for a blob:// URL described here: #1090

I don't think so. That crash is entirely on Java/native land and not related to the webview process dying.  Fix shouldn't be too hard though.

That crash is entirely on Java/native land and not related to the webview process dying. Fix shouldn't be too hard though.

Good observation, I've opened a new PR to address the crash: https://github.com/react-native-community/react-native-webview/pull/1546

That crash is entirely on Java/native land and not related to the webview process dying. Fix shouldn't be too hard though.

Good observation, I've opened a new PR to address the crash: #1546

Awesome, looking forward to the update!

Thanks for this, I can't wait for the release :)
It would be nice to also handle a related feature: https://developer.android.com/guide/webapps/managing-webview#renderer-importance

Thanks for this, I can't wait for the release :)
It would be nice to also handle a related feature: https://developer.android.com/guide/webapps/managing-webview#renderer-importance

@florian-milky how would that help RN apps? Isn't the default priority already the highest?

@florian-milky how would that help RN apps? Isn't the default priority already the highest?

I'm sorry you're right, I thought the default priority was the middle one

Any ideas when this can be merged? Would love to get it merged soon for our own product next release.

Tagging and requesting @Titozzz to kindly review this.

I'm trying to get back to Open Source. Thanks for contributing. Sorry about the delay
❤

@cristianoccazinsp I tried to use this but without any luck.
2 different emulators and a samsung s9, but onRenderProcessGone is not called and the whole app crashes still.

Interesting, perhaps it is another type of crash? Do you have any sample code to forcibly trigger the crash? I only tried it on a very specific crash I was having, but perhaps the webview doesn't behave the same with every crash.

@florian-milky I've just tried it with a fresh install from npm and it is working fine for me on a google pixel 2.
My use case was a webview with an oddly large canvas that for some reason causes a crash on Android 10.  Keep in mind this change requires API 26 (Android 8) or above.

I use a webworker in the webview to trigger the memory consumption. maybe that is why.
I need to investigate more.
Thanks for checking

Hi all,
My application still got crashing and the callback "onRenderProcessGone" never called. Do you have any idea?

Hi all,
My application still got crashing and the callback "onRenderProcessGone" never called. Do you have any idea?

Perhaps the webview implementation of the device you're getting crashes on does not fire the native event.
The SDK notes state that at least Android Oreo is required for this, but not all vendors may implement it.
Can you provide more info on the crashes?

What about the crashes for data:base64 URL? Is there any handle for that?


Tailwind

Motive behind moving to tailwind is to decrease the bundle size of the website Tailwind CSS vs. CSS: An in-depth comparison (speed, file size, etc.)

Desktop

Tablet

Mobile

as soon as something is typed:

Hey,
Did you test it?

This change increases the bundle-size by 60kb
Drops the lighthouse performance score by 1 point

Some other considerations:

Was it discussed with the rest of the team? I don't particulary mind, but make sure everyone is comfortable with an extra css framework.
You seem to have replaced only minor bits of the site with tailwind related things. Is that really worth a new css framework? I know tailwind is the new hotness now, but every new component increases the risk that in a few years you need to update dependencies, or one of your dependencies is deprecated. Esp. with frontend dependencies.

I think if we want to increase the speed of the site, we'd better start with re-encoding the images we use (looking at the lighthouse trace). We can probably save about 23MB (!!) like that.
Regarding tailwind, I'm personally not against it, but you probably need to tweak this a bit more to make sure that it actually is a positive change. Right now, it just makes things slower/more complex. Discuss it w/ the rest of the team?

Don't think anyone had time to respond to that discussion yet. Maybe take that to your weekly call, or wait a bit in slack?
Regardless, I see in chrome lighthouse minor performance degradation https://deploy-preview-247--clothing-loop.netlify.app/ vs clothingloop.org. Maybe take a look at that first? Might be some stuff that's misconfigured.

Regardless, I see in chrome lighthouse minor performance degradation
It does not seem to be something that can be mitigated without moving more classes to tailwind, as my assumption is that it is caused by the slight increase in bundle size. This can be done gradually while making the website responsive.

This change increases the bundle-size by 60kb
The added tailwind classes only total to 1.7KBs

And comparing the deployment output:
#tailwind - https://app.netlify.com/sites/clothing-loop/deploys/62b04353a850a20009826601
11:55:09 AM:   754.43 KB  build/static/js/2.251dc756.chunk.js
11:55:09 AM:   114.97 KB  build/static/js/mapbox-gl-csp-worker.735ad9bd.worker.js
11:55:09 AM:   49.75 KB   build/static/js/main.3c755b7f.chunk.js
11:55:09 AM:   5.42 KB    build/static/css/2.e6baa8cc.chunk.css
11:55:09 AM:   4.39 KB    build/static/css/main.5582cd96.chunk.css
11:55:09 AM:   1.64 KB    build/static/js/3.f624ca05.chunk.js
11:55:09 AM:   1.18 KB    build/static/js/runtime-main.1be108d1.js

#move-to-ts - https://app.netlify.com/sites/clothing-loop/deploys/62aaf04b6d20ac0008b50cae
10:59:48 AM:   754.43 KB  build/static/js/2.2bbe2147.chunk.js
10:59:48 AM:   114.97 KB  build/static/js/mapbox-gl-csp-worker.735ad9bd.worker.js
10:59:48 AM:   49.61 KB   build/static/js/main.c824df8f.chunk.js
10:59:48 AM:   5.42 KB    build/static/css/2.e6baa8cc.chunk.css
10:59:48 AM:   3.96 KB    build/static/css/main.bc45461b.chunk.css
10:59:48 AM:   1.64 KB    build/static/js/3.0269d971.chunk.js
10:59:48 AM:   1.18 KB    build/static/js/runtime-main.64d1b99b.js

The only change I see is of around 0.4KB (gzipped I assume) from build/static/css/main.<hash>.chunk.css


Expose Animation constructor

Addresses https://github.com/web-animations/web-animations-next/issues/360


provide new PDF CoverPage implementation

Provide an new PDF coverpage generator:

The new implementation uses a JasperReport template
The existing implementation was moved into a separate class to make it possible to make the choice configurable

This PR is provided by The Library Code with support of Gesis Leibniz Institut für Sozialwissenschaften.
Description
The existing coverpage generation mechanism has been removed.
A new coverpage generation implementation based on JasperReports has been implemented: JR templates can easily be customized with the help of a freely available editor (preview capabilities). Umlauts are supported.
There is a simple example template available that will generate a basic coverpage.
Instructions for Reviewers
List of changes in this PR:

new dependency added:

jasperreports (https://github.com/TIBCOSoftware/jasperreports) - LGPL

Old coverpage code was removed

see CitationDocumentService

New implementation was added

see CoverPageService and changes in CitationDocumentService

config for old implementation was removed
simple JasperReports template was added cover-template.jrxml

To test the feature:

enable feature: citation-page.enable_globally=true
Download the PDF from an item (not as admin)

You should get a PDF with coverpage (compare example in attachment)
Note: The download itself does not work reliably because of https://github.com/DSpace/DSpace/issues/9665
You can use curl to download and tell it to ignore the content-length header:
❯ curl -http://localhost:8080/server/api/core/bitstreams/bd80ceb5-2c30-4bde-b020-467686177fe9/content --output test.pdf --ignore-content-length

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[ ] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
[ ] My PR passes Checkstyle validation based on the Code Style Guide.
[ ] My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
[ ] My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
[ ] My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
[ ] If my PR includes new libraries/dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[ ] If my PR modifies REST API endpoints, I've opened a separate REST Contract PR related to this change.
[ ] If my PR includes new configurations, I've provided basic technical documentation in the PR itself.
[ ] If my PR fixes an issue ticket, I've linked them together.

Example.pdf
Coverpage generated by the new mechanism. The underlying template can be customized using a free editor: https://www.jaspersoft.com/products/jaspersoft-community

@abendt : Could you or someone else from Library Code (@pnbecker or @kshepherd perhaps) please add details as to why this new PDF Coverpage implementation is useful?  The use case for this change is unclear to me, and we need to document why someone would want to use this new approach versus the current CoverPage generation approach.  Basically, why does this new approach benefit DSpace? Why are we replacing/removing the old implementation in favor of this one?
It also looks (to me) like we'll eventually need more detailed documentation, as it's entirely different from the existing implementation. So, we need basic details on how someone would customize this new Cover Page and how to migrate from the old implementation to the new one.

@tdonohue sorry, you were faster than me. I enhanced the description of this PR explaining why we would like to replace the old implementation.


For beginners, may want to include the app.listen code snippet in the README.md

Novices may read the README.md and struggle to understand how to actually keep the server alive. Including the code snippet in the README.md may be useful for such beginners:
server.listen(3000, () => {
  console.log('App is listening on port 3000: http://localhost:3000');
});

listen should be used after adding request handler.


Rethink Sim API

Description
Summary
All inputs to the sim and modules now use a ss.Pars() class, which handles updating and validation. It is now not necessary to ever use pars= (although you still can if you want), so what was previously:
sim = ss.Sim(pars=dict(diseases='sir', networks='random'))
is now just:
sim = ss.Sim(diseases='sir', networks='random')
Updates happen recursively, so distributions etc. can be flexibly updated.
This has significantly changed how modules are initialized; what was previously
def __init__(self, pars=None, **kwargs):

    pars = ss.omergeleft(pars,
        dur_inf = 6,
        init_prev = 0.01,
        p_death = 0.01,
        beta = 0.5,
    )

    par_dists = ss.omergeleft(par_dists,
        dur_inf = ss.lognorm_ex,
        init_prev = ss.bernoulli,
        p_death = ss.bernoulli,
    )

    super().__init__(pars=pars, par_dists=par_dists, *args, **kwargs)

is now:
def __init__(self, pars=None, **kwargs):
    super().__init__()
    self.default_pars(
        beta = 0.5,
        init_prev = ss.bernoulli(0.01),
        dur_inf = ss.lognorm_ex(6),
        p_death = ss.bernoulli(0.01),
    )
    self.update_pars(pars, **kwargs)

Parameter changes

Added a ss.Pars class (and a ss.SimPars subclass) that handles parameter creation, updates, and validation.
Initialization has been moved from sim.py to parameters.py; ss.Sim.convert_plugins() has been replaced by ss.SimPars.convert_modules().
The key method is ss.Pars.update(), which performs all necessary validation on the parameters being updated.

Module changes

Whereas modules previously initialized a dict of parameters and then called super().__init__(pars, **kwargs), they now call super().__init__() first, then self.default_pars(par1=x, par2=y), then finally self.update_pars(pars, **kwargs).
What was previously e.g. ss.Module(pars=dict(par=x)) is now ss.Module(par=x).
par_dists has been removed; instead, distributions are specified in the default parameters, and are updated via the Pars object.
ss.module_map() maps different module types to their location in the sim.
ss.find_modules() finds all available modules (including subclasses) in Starsim.
Removed ss.dictmerge() and ss.dictmergeleft (now handled by ss.Pars.update()).
Removed ss.get_subclasses() and ss.all_subclasses() (now handled by ss.find_modules()).
Modules now contain a link back to the Sim object.
Added to_json() and plot() methods to Module.
Removed connectors.py; connectors still exist but as an empty subclass of Module.

People and network changes

Time parameters (ti, dt, etc.) have been removed from People. Use sim.ti, sim.dt etc. instead. One consequence of this is that people.request_death() now requires a sim argument. Another is that network methods (e.g. add_pairs()) now take sim arguments instead of people arguments.
SexualNetwork is now a subclass of DynamicNetwork.
Removed ss.Networks (now just an ss.ndict).
Network connectors have been removed.
Person has been implemented as a slice of sim.people[i].
The default maximum age if none is specified is 50 instead of 100.
Agents do not age if no demographics modules are supplied.

Other changes

All inputs to a sim are now copied by default. To disable, use ss.Sim(..., copy_inputs=False).
There is a new Plugin class, which contains shared logic for Interventions and Analyzers. It has a from_func(), which will generate an intervention/analyzer from a function.
Diseases no longer have a default value of beta=1 assigned; beta must be defined explicitly if being used.
Individual diseases can now be plotted via either e.g. sim.plot('hiv') or sim.diseases.hiv.plot().
Distributions can be created from dicts via ss.make_dist().
A new function ss.check_sims_match() will check if the results of two or more simulations match.
Merged test_dcp.py and test_base.py into test_other.py.
Renamed test_simple.py to test_sim.py.
Renamed test_dists.py to test_randomness.py.

Checklist

[x] Code commented & docstrings added
[x] New tests were needed and have been added
[x] A new version number was needed & changelog has been updated
[x] A new PyPI version needs to be released

Closes #301, #178, #412, #440

One additional API suggestion, perhaps more closely related to states, is regarding accessing uids from booleans. Previously, we had
uids = ss.true(condition)

and now it is
uids = (condition).uids

I'd prefer function syntax here, something like:
uids = ss.uids(condition)

... realizing that ss.uids is likely taken already. Whatever it's called, it could simply return .uids.

The new test that was added that's failing is fixed by #500

@daniel-klein I made it so you can do ss.uids(BoolArr) instead of BoolArr.uids ... I would personally discourage this usage, since ss.uids() isn't valid on anything other than a BoolArr, so I think the property makes it clearer that tis related specifically to that array. In particular, the previous implementation of ss.true() would just give indices, which would match UIDs if and only if (a) the input array matched the length the raw data, or (b) the user then did a subsequent transformation. In practice one of these two things was usually true, but sometimes not, leading to subtle bugs! In contrast, with arr.uids, it's guaranteed to be correct.


[info arch] Make NavigationAccordion toggleable

This PR makes a proposal on how to handle the NavigationAccordion items on smaller devices ref https://github.com/mapbox/dr-ui/pull/344#issuecomment-721859813 and if accepted will merge into #344. This PR makes NavigationAccordion sub page menu's toggleable and will collapse the items on smaller devices be default:

Separates the title/link and the chevron icon. The chevron icon is now a button that controls the sub page menu. The user can toggle a section's sub page menu from any page.
A section's sub page menu opens automatically when the section or any of its sub pages are active. However, on smaller devices all toggles are collapsed on load, but the user can toggle to reveal the subpages.
On smaller devices, the padding for the NavigationAccordion links increases slightly to improve tap target sizes.

Screenshots

Sub page menu toggle collapses on mobile by default

Toggle a section's sub page menu from anywhere

How to test

Visit the catalog site (npm run start-docs -> http://localhost:8080/dr-ui/guides/)

From any page, toggle the "Guides" chevron icon. It should expand and collapse its sub page menu.
Visit http://localhost:8080/dr-ui/guides/ on desktop, the sub page menu for "Guides" should open on load.
Visit http://localhost:8080/dr-ui/guides/ on mobile, the sub page menu for "Guides" should not open on load, but can be open if you press the chevron icon.

QA checklist

[x] No errors logged to console.
[x] Accessibility score in Chrome DevTools Audit/Lighthouse is 100% with Lighthouse version: #.#.#.
[x] Component is accessible at mobile-size viewport.
[x] Component is accessible at tablet-size viewport.
[x] Component is accessible at laptop-size viewport.
[x] Component is accessible at big-monitor-size viewport.
[x] Create a PR in a site repo, copy the component, and test it. Push to staging and let the reviewer know they can also test the component there.

Open the test cases app locally on:

[x] Chrome, no errors logged to console.
[x] Firefox, no errors logged to console.
[x] Safari, no errors logged to console.
[x] Edge, no errors logged to console.
[x] IE11, no errors logged to console.
[x] Mobile Safari, no errors logged to console.
[x] Android Chrome, no errors logged to console.

@danswick per scrum today, this is ready for review (and also open to other suggestions on how to make NavigationAccordion more responsive friendly).


ci: GitHub publish job

Signed-off-by: Rolson Quadras<EMAIL_ADDRESS>

Need to check if we can merge snapshot publish and release publish jobs.