 for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.5.4 (2021-03-11)
 _/ |\__'_|_|_|\__'_|  |
|__/                   |

julia> @time using OpticSim
[ Info: Precompiling OpticSim [24114763-4efb-45e7-af0e-cde916beb153]
GlassCat/GlassCat.jl           11.762666 seconds (30.28 M allocations: 1.618 GiB, 4.74% gc time)
Matrix.jl                       0.036407 seconds (64.09 k allocations: 3.435 MiB)
Constants.jl                    0.003422 seconds (545 allocations: 34.703 KiB)
Utilities.jl                    0.006186 seconds (2.23 k allocations: 148.656 KiB)
Geometry/Geometry.jl            3.365056 seconds (11.78 M allocations: 571.448 MiB, 5.47% gc time)
Optical/Optical.jl              2.902856 seconds (5.01 M allocations: 273.382 MiB, 1.88% gc time)
Visualization.jl              117.750740 seconds (24.66 M allocations: 1.366 GiB, 0.34% gc time)
TestData.jl                     0.147232 seconds (392.51 k allocations: 21.714 MiB)
Examples.jl                     0.070924 seconds (26.25 k allocations: 1.691 MiB)
Optimization/Optimizable.jl     0.012913 seconds (7.41 k allocations: 480.486 KiB)
Diagnostics.jl                  8.893067 seconds (25.26 M allocations: 1.276 GiB, 8.84% gc time)
Benchmarks.jl                   0.019117 seconds (11.48 k allocations: 747.540 KiB)
Data/Spectra.jl                 0.489070 seconds (503.60 k allocations: 31.469 MiB)
Sysimage.jl                     0.041237 seconds (66.03 k allocations: 3.767 MiB)
239.481057 seconds (121.85 M allocations: 6.440 GiB, 1.05% gc time)

Time to dive back into the Visualization code!

maybe redefining Base.* for makie types is causing a huge amount of recompilation and invalidation (see below). That's the only thing I can see that looks suspicious, other than the fact that we are importing Plots and Makie, both of which tend to be slow to build.
Base.:(a::RigidBodyTransform, p::Makie.AbstractPlotting.GeometryBasics.PointMeta) = a * p.main
Base.:(a::Real, p::Makie.AbstractPlotting.GeometryBasics.PointMeta{N,S}) where {S<:Real,N} = Makie.AbstractPlotting.GeometryBasics.Point{N,S}((a * SVector{N,S}(p))...)
Base.:*(a::RigidBodyTransform, p::Makie.AbstractPlotting.GeometryBasics.Point{N,S}) where {S<:Real,N} = Makie.AbstractPlotting.GeometryBasics.Point{N,S}((a.rotation * SVector{N,S}(p) + a.translation)...)

I think about 100 of the 118 seconds are taken up by the using/import statements.  for help, "]?"  That's the only thing I can see that looks suspicious, other than the fact that we are importing Plots and Makie, both of which tend to be slow to build.
if we can't make this faster then we should think harder about putting visualization in a separate package. Makie has been giving us a lot of trouble, would be nice to isolate it from the core libraries.
Base.:(a::RigidBodyTransform, p::Makie.AbstractPlotting.GeometryBasics.PointMeta) = a * p.main Base.:(a::Real, p::Makie.AbstractPlotting.GeometryBasics.PointMeta{N,S}) where {S<:Real,N} = Makie.AbstractPlotting.GeometryBasics.Point{N,S}((a * SVector{N,S}(p))...)
Base.:*(a::RigidBodyTransform, p::Makie.AbstractPlotting.GeometryBasics.Point{N,S}) where {S<:Real,N} = Makie.AbstractPlotting.GeometryBasics.Point{N,S}((a.rotation * SVector{N,S}(p) + a.translation)...)

Makie normally takes around 20 seconds to import so that's a possibility. Either way we'll definitely need to ship a sysimage with releases. There doesn't seem to be a way around this except for splitting off the Vis module. I've got no preference - up to you guys.

@alfredclwong  should we close this issue for now and revisit when we do the visualization rewrite?


Support for user supplied actor_factory callable

Describe the feature
ActorRuntimeContext has the support to take the user-supplied callable that would instantiate the Actor object. However, the classes (e.g. ActorRuntime and various register_actor functions in the extensions (flask and fastapi)) do not expose the possibility of providing the callable from the user code.
Release Note
RELEASE NOTE: ADD Support for user-supplied actor_factory callable.

Can you go into more detail as to why we would want this? And can you see whether any of the other SDKs support this?

This would enable dependency injection in the Actors.
See an example of it in the .net SDK
https://github.com/dapr/dotnet-sdk/blob/master/examples/Actor/DemoActor/DemoActor.cs


docs: fix typo on nuxt usage

Description

The usage example for nuxt has a typo (too much square brackets)
Linked Issues
N/A
Additional context

Thanks


Updating libraries versions

This PR updates the scala versions to 2.11.11 and 2.12.3 , sbt-org-policies to 0.5.12 and all the scala-exercises libraries to their last version
@juanpedromoreno could you please review?
Thanks!

@dominv how far are we from getting this ready?, seems like merging it would fix some exercises that are currently broken in the live version. See #663

Codecov Report

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

@@           Coverage Diff           @@
##           master     #665   +/-   ##
=======================================
  Coverage   35.76%   35.76%
=======================================
  Files          40       40
  Lines         934      934
  Branches       21       21
=======================================
  Hits          334      334
  Misses        600      600

Continue to review full report at Codecov.

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


Doc Improvement

https://github.com/tensorflow/tensorflow/blob/c256c071bb26e1e13b4666d1b3e229e110bc914a/tensorflow/python/eager/backprop.py#L812
dz_dy = tape.gradient(z, w)
The Variable dz_dy could be more intuitive by renaming to dz_dw.

Hi @chunduriv ! Could you please look at this issue?

@kaimo455,
The issue will move to closed status once the PR is merged. Thanks!


tsd demands to have index.d.ts where it is not required

Consider we have package with single module foo.js and definitions in foo.d.ts. We got "main": "foo.js".
If we run tsd on such package, we got:
The type definition `index.d.ts` does not exist. Create one and try again.

However, this file is redundant at such case.

Even with a tsd.directory property set in package.json this error comes up.

Any progress on this?
Roughly eight months ago I remember having to deal with this rather annoying bug; now I'm having to use this package again and it seems the way I previously got around this does not work.
As of now, tsd is simply unusable in what I'd consider being a realistic configuration due to this false negative throwing an error.

@StreetStrider Does your package.json specify "types": "foo.d.ts"?
My understanding is that tsd looks for the type definitions file specified by package.json, but defaults to looking for index.d.ts.

@UselessPickles that is not exactly my case. package.json types means we're intending to export types. I'm not exporting anything in that particular case. I just have JS module and corresponding d.ts and no index.js at all. If tsd follows TS semantics this should work (because tsc can compile such setup and I have proper tsconfig.json), however it isn't and it points to the redundant nonexistent file. :thinking:

@StreetStrider Sounds like this might be a duplicate of (or similar to) #32.
See my comment for a workaround: https://github.com/SamVerschueren/tsd/issues/32#issuecomment-778650556

@UselessPickles thanks. That's indeed looks similar. I ended up using dtslint, but it also has its issues (and it is more complex). I solve them similar to your workaround, by creating test subproject with it's own tsconfig which satisfies all limitations. Both systems are not ideal for me and have issues. My use-case is to have expect-typish like tests in my project. I believe, TS projects must have type tests just like they have unit-tests. Having positive and negative type tests is the only way to guarantee your types are correct and that they can be consumed by library user.

@SamVerschueren I've tested it out, it seems that it suffices to have a .d.ts file that has the same name as the main entrypoint in package.json, an explicit types field is not required for TypeScript to pick up the definitions. I.e. if the main entrypoint to a package is foo.js then it suffices to have a foo.d.ts for the typings to work correctly.
Do you mind if I implement this logic or do you insist on having an explicit types field in the package.json?

@sindresorhus Not sure whether I should start implementing it because I don't know whether this is intended behavior or not. @SamVerschueren  doesn't answer, do you have an opinion on this?

@BendingBender feel free to pick it up! Didn't knew that a typings field was not necessary. Seems like a good one to have 👍.


Fix/incorrectly rendering large contents

When creating 2d animations, there is a problem when rendering the frame (be it by displaying the frame or playing the animation)

The problem was not with how frames were being rendered, but rather the data queries that were being set for each block in the contents list allowed for duplicate keys. This lead to overwriting previous values.


Launching .exe also launches console window

https://github.com/AvaloniaUI/Avalonia/wiki/Hide-console-window-for-self-contained-.NET-Core-application

Let's wait for .NET Core 3.0 GA - scheduled for September 2019


Publish to a Binary Cache

Building crate2nix can take really long. It would be cool, to offer a binary cache from which users can pull the precompiled nix package.
If you are OK with using GitHub Actions instead of Travis for your CI, you could use the cachix action to build an publish the package to a binary cache: https://github.com/cachix/cachix-action

@vbrandl Thank you for the suggestion! My travis setup was horrible. I try this out currently....

Thank you for the suggestion. The github action results in a build now. But the caching doesn't seem to work since it is still rebuilding everything from scratch. If you have an idea on how to change that, please let me know!

I'm not sure (never used the action before, I just thought, it might work)
Maybe you need to build default.nix instead of tests.nix for the caching to work and run the tests in a separate step? Just spitballing here...

I think one of the problems with the current cachix approach in the GitHub action is that it isn't caching intermediate results aka all the dependencies of crate2nix.
Ideally we would be able to use the post-build-hook together with cachix. That would ensure all the build results get uploaded to the binary cache.


Arrangement and execution of the meeting for development of course on Modelling in Python (issue #942 related)

The goal is to arrange and execute the meeting for development of course on Modelling in Python. The following things should be prepared:

[x] scope and schedule of meeting (in one week);

[x] conducting team (in two weeks);

[x] guide or instructions with examples (one week before meeting);

[x] announcement (in Slack and Teams channel) with basic information (conducting persons, date,scope,schedule) (one week before meeting);

[x] exemplary code in Jupyter (link) (one week before meeting).

Meeting has been arranged and executed.


Clean-up make_cmdidxs.pl

This PR does a minor cleanup in script create_cmdidxs.pl:

script was pushing irrelevant value $1 in an array @skipped,
whereas we only need to count skipped commands.
script had an odd magic value 2 to compute command_count
which is not needed if we compute value differently.
it also adds a 'const' which is OK now that we use ANSI C.

Codecov Report

Merging #1594 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1594      +/-   ##
==========================================
- Coverage   74.55%   74.55%   -0.01%
==========================================
  Files          76       76
  Lines      124841   124842       +1
==========================================
  Hits        93070    93070
- Misses      31771    31772       +1

Impacted Files
Coverage Δ

src/ex_docmd.c
74.16% <ø> (ø)
:arrow_up:

src/channel.c
83.7% <0%> (-0.14%)
:arrow_down:

src/if_py_both.h
76.03% <0%> (ø)
:arrow_up:

src/version.c
80.3% <0%> (+1.01%)
:arrow_up:

Continue to review full report at Codecov.

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


Make it so we can change the Session Title without changing the slug (optional)

Make it so we can change the Session Title without changing the slug (optional).

I don't see a reason for it, especially if you are using the title of the paper as a unique identifier within Firebase. I think this is out of scope and has the potential to cause problems with searching and duplicate papers as long as you continue to use the name-based unique identifier. Consequently, I think the document ID in Firebase should remain the default randomized alpha-numeric one. Its generated from a timestamp and is entirely unique.

I don't see a reason for it, especially if you are using the title of the paper as a unique identifier within Firebase. I think this is out of scope and has the potential to cause problems with searching and duplicate papers as long as you continue to use the name-based unique identifier. Consequently, I think the document ID in Firebase should remain the default randomized alpha-numeric one. Its generated from a timestamp and is entirely unique.


Fix map reload issue

Investigate reloading of map during pagination and layer toggle. Similar error occurred during initial experiment with opacity sliders but was rectified - may be of use to review that commit

Duplicate of #170


purcell/inheritenv changes master to main, broke doom sync

What did you expect to happen?
bin/doom sync -pu to success.
What actually happened?
bin/doom sync -pu fails with fatal: Couldn't find remote ref refs/heads/master
Additional details:

Include a link to your private config : https://gitlab.com/bersace/dotfiles/-/tree/master/files/.config/doom

doom.error.log
(straight-vc-git-fetch-from-remote (:type git :flavor melpa :host github :repo "purcell/inheritenv" :package "inheritenv" :local-repo "inheritenv"))
(apply straight-vc-git-fetch-from-remote (:type git :flavor melpa :host github :repo "purcell/inheritenv" :package "inheritenv" :local-repo "inheritenv"))

$ dirs -p
~/.emacs.d/.local/straight/repos/inheritenv
$ cat .git/config
[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = https://github.com/purcell/inheritenv.git
        tagOpt = --no-tags
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
        remote = origin
        merge = refs/heads/main
        rebase = true
$ git remote -v
origin  https://github.com/purcell/inheritenv.git (fetch)
origin  https://github.com/purcell/inheritenv.git (push)
$ git fetch
fatal: Couldn't find remote ref refs/heads/master

Steps to reproduce:

Install Doom from late 2020
Update using git
run bin/doom sync -pu

System information:

Place the output of `M-x doom/info` or `~/.emacs.d/bin/doom info` here.

Duplicate of #3435