Micro Frontends and RBP

Is your feature request related to a problem? Please describe.
I'm curious if anyone has explored the possibility of implementing Micro Frontends in the context of RBP? The main premise is that an application comprised of fragments of functionality owned and independently released exclusively by separate teams with their own microservice backends that can come together (at run time).
Describe the solution you'd like
First, could RBP meet the Core concepts dictated by Micro Frontends. Second, what would it look like if we relaxed the Be technologically agnostic (settling on RBP stack) and Favor Native Browser Features. Would we be able to (and want to?) share the redux store and hot load [1] whole containers [2] from disparate deployments in some way?
[1] Probably based on at least tenant entitlements, but maybe even user privileges.
[2] Each with their own selectors/reducers/sagas
Describe alternatives you've considered

Augment RBP to be a Micro Frontend but relax a few of the core concepts (described above)
Have a shell application closer to the Micro Frontend reference implementation and wire in RBP projects using lowest common denominator browser functionality.
Have a composed RBP main app that deploys at a high cadence that teams update with new releases as available (each "fragment" is probably an npm RBP project, and we're really just statically building and deploying with the latest version every 12 hours or something like that)

Additional context
Add any other context or screenshots about the feature request here.

Why is this thread closed ? This is something I am really interested in as well.

This thread isn't closed. (The Closed icon you see above your message is referring to issue #2605, which is closed.)

We've had some nice success using single-spa/single-spa. It's not really generic enough to release, but if anyone stumbles on this issue feel free to reach out to me.


Setup Timezone

How to Set Timezone, is it set to Indonesian Time Because When I send Schedule Msg It not send on Indian Time

I think this changes the timezone of the operating system, mine was GMT 00:00, I put Brazil time on Linux GMT -3:00 and it worked just fine.


res.say() doesn't work when in .then() of returned promise.

I have something like this:
    alexaApp.intent('fooIntent', {
        'slots': {
          'foo': 'footype'
        },
        'utterances': [
          'my {name is|name\'s} {-|foo}'
        ]
      },
      function (req, res) {

       // If I put a .say() here, it works.

       bar()
            .then(something => {
              console.log(something);
              // This .say() doesn't work here
              res.say('something has been done');
            })
            .catch(err => {
              res.say('error' + err);
              throw err;
            });
      }
    );

The issue I have is that while in the .then() the .say() doesn't work... the console.log() works fine though, with the response I expect. However, if I do a .say() before this function, it works just fine.
It's got me stumped... Any ideas?

Apologies... I've sorted it by following the Asynchronous Intent Handler in the read me.

There has been some conversation in https://github.com/alexa-js/alexa-app/issues/71 where a handler should just return a promise and then we don't have to do the whole return false thing. PRs welcome.


add unified args number check

Description

add ArgsCountValidator field to Command struct
and use it to check command args count in Execute, not in every command
add valid: del command should have at least one arg

well pass ci when move from go get to dep

What if we tried to add a MinArgs and MaxArgs field ? When we can use infinite num args we would set em to -1

done

you need to run gofmt on each files

what is the fix follows mean, sorry for my bad english

@Chyroc sorry i was on mobile, review was not added below comment, now you can see it

please run go fmt on each files

i have run make fmt before i commit, so what file have not be formated

Seems testify is missing from deps.

https://github.com/golang/dep/issues/854 we need to manually install it.

yes, i am makeing a pr to do it.

Use master branch as base then it can be easily merged...

Nice job


Added font reset feature, font size clamp and made commands repeatable.

Added Font reset command which resets to default value of 16px
Made font size doesn't go over 30px or under 10px, which is based on the behaivor of updateFontSize() - Math.clamp(e, 10, 30)
Made font increase/decrease command to be repeatable. Font size can be changed by holding user customized hotkeys.

Hi, I was looking for this kind of plugin so badly, I am glad I found it. I added some quality-of-life feautre and fixes, please look into them. Thank you.

Hi, thank you a lot for your contribution! I apologize for not responding for a while, I was missing this pull request.
These are all very useful addition, thanks again for your work:)


Time zone discarded on Alpine docker

Environment : Alpine Docker 9dockerhub-latest) on a Centos 7 host (centos-release-7-6.1810.2.el7.centos.x86_64)
go version: go1.11.1 linux/amd64
describe the issue: STRFTIME('%Y-%m-%d %H:%M:%f', 'NOW', 'localtime') always deduct the time from UTC
Code (error hand. removed for short code sample) :
`
func sampleForGithub()  {
fmt.Println("now : ", time.Now())
fmt.Println("now local : ", time.Now().Local())
db, _ := sql.Open("sqlite3", "whatever.db")    //any file new
sqlStmt := "select  STRFTIME('%Y-%m-%d %H:%M:%f', 'NOW', 'localtime') as id "
rows, _ := db.Query(sqlStmt)
defer rows.Close()
for rows.Next() {
	var id string
	rows.Scan(&id)
	fmt.Println(id)
}

}
`
Expected result:
now :  2019-02-14 14:53:53.499102547 +0200 IST m=+0.000432506
now local :  2019-02-14 14:53:53.499191615 +0200 IST
from db: 2019-02-14 14:53:53.499
Which is exactly what happens when I run on centos host
Actual:
now :  2019-02-14 14:53:53.499102547 +0200 IST m=+0.000432506
now local :  2019-02-14 14:53:53.499191615 +0200 IST
from db: 2019-02-14 12:53:53.499
Please note that the go "now" is on the right TZ.
Also confirmed +0200 on:
$export TZ
$cat /etc/timezone
$date
Installed tzdata
and next to any optional tip on:
https://serverfault.com/questions/683605/docker-container-time-timezone-will-not-reflect-changes
sqlite documentation suggest 'localtime' is taken from export TZ var , but apparently it does not, at least not on this package.
Can you please help determine where is the location taken from ?
And if its a bug rather than configuration... fix it ?

zoneinfo.zip is bundled on Go's $GOROOT/lib/time/zoneinfo.zip

@GuyBrand I don't think this has anything to do with Go, or this driver. You asked SQLite itself (the C library) to output the current time.

sqlite documentation suggest 'localtime' is taken from export TZ var

Which documentation in particular are you referring to?

Look for localtime_r() in this documentation:
https://www.sqlite.org/lang_datefunc.html
Follow localtime_r() in:
https://linux.die.net/man/3/localtime
And read:
According to POSIX.1-2004, localtime() is required to behave as though tzset
https://linux.die.net/man/3/tzset(3) was called, while localtime_r()
does not have this requirement. For portable code tzset
https://linux.die.net/man/3/tzset(3) should be called before
localtime_r().
Then read
https://linux.die.net/man/3/tzset
function initializes the tzname variable from the TZenvironment variable
Code:
http://webfiles.icebreak.org/webfiles/CBuilderCD/v4/Runimage/Cbuilder4/Source/RTL/SOURCE/TIME/TZSET.C
Also reads:

Check for "TZ" string in the environment.

On Fri, 15 Feb 2019, 3:52 rittneje<EMAIL_ADDRESS>wrote:

@GuyBrand https://github.com/GuyBrand I don't think this has anything
to do with Go, or this driver. You asked SQLite itself (the C library) to
output the current time.
sqlite documentation suggest 'localtime' is taken from export TZ var
Which documentation in particular are you referring to?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattn/go-sqlite3/issues/694#issuecomment-463875979,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFpMcswJn3G8AfqMEEEHFNx2steW9iqHks5vNhLCgaJpZM4a7jC8
.

@GuyBrand Can you please clarify how you installed tzdata and set your TZ environment variable for the docker image in question? Did you do it in the Dockerfile? Please post the exact steps you ran.

Actually, we tried so many options...

Yes, it was a dockerfile, from Alpine latest, we always added

RUN apk --no-cache add wget && \
wget -q -O /etc/apk/keys/sgerrand.rsa.pub
https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub && \
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.28-r0/glibc-2.28-r0.apk
&& \
apk add glibc-2.28-r0.apk

For Setting the TZ, and tzdata, we tried next to anything in:
https://serverfault.com/questions/683605/docker-container-time-timezone-will-not-reflect-changes

And some other posted,
The best rates in the Post Favour this:
ENV TZ=America/Los_Angeles
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN apk add --no-cache tzdata
ENV TZ America/Los_Angeles
Yet with asia/jerusalem as the TZ
And also some combinations, between the different suggestions
The thing is, unlike most posts on the topic that describes a container
level issue, in this case, container $date is displayed correctly, go
displayed the right tz, MySQL driver as well, the only issue is with the
sqlite.
On Fri, 15 Feb 2019, 14:43 rittneje<EMAIL_ADDRESS>wrote:

@GuyBrand https://github.com/GuyBrand Can you please clarify how you
installed tzdata and set your TZ environment variable for the docker image
in question? Did you do it in the Dockerfile? Please post the exact steps
you ran.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattn/go-sqlite3/issues/694#issuecomment-464036642,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFpMcrUyykyjRk6UO5CuMiK-KOLqZQ9tks5vNqtdgaJpZM4a7jC8
.

@GuyBrand Not sure if this is just the result of you trying different things, but these two lines are backwards:
ln -snf /usr/share/zoneinfo/$TZ /etc/localtime
ENV TZ=Asia/Jerusalem

You need to set the TZ environment variable before referencing it in your RUN commands.
In any case, I am able to reproduce your issue. Stranger still, when I use the SQLite CLI in the container, the query outputs the correct result!
After researching a bit more, this appears to be an issue pertaining to glibc. Basically, any applications that are dynamically linked against glibc do not function properly in Alpine, because it doesn't really have glibc. (https://stackoverflow.com/a/52057474) The recommended solution is to use the Golang Alpine docker image (golang:1.11.5-alpine3.9, for example) as a base, and build the binary in the docker or Dockerfile.

Isn't the go Alpine image size few hundreds of mb?
On Sat, 16 Feb 2019, 2:09 rittneje<EMAIL_ADDRESS>wrote:

@GuyBrand https://github.com/GuyBrand Not sure if this is just the
result of you trying different things, but these two lines are backwards:
ln -snf /usr/share/zoneinfo/$TZ /etc/localtime
ENV TZ=Asia/Jerusalem
You need to set the TZ environment variable before referencing it in your
RUN commands.
In any case, I am able to reproduce your issue. Stranger still, when I use
the SQLite CLI in the container, the query outputs the correct result!
After researching a bit more, this appears to be an issue pertaining to
glibc. Basically, any applications that are dynamically linked against
glibc do not function properly in Alpine, because it doesn't really have
glibc. (https://stackoverflow.com/a/52057474) The recommended solution is
to use the Golang Alpine docker image (golang:1.11.5-alpine3.9, for
example) as a base, and build the binary in the docker or Dockerfile.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattn/go-sqlite3/issues/694#issuecomment-464256409,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFpMcsF1A-WBEnQ85cKNt9IT-O6HCJk0ks5vN0wpgaJpZM4a7jC8
.

It is 311 MB. But you don't have to keep it around in your final image. An easy way to accomplish this is with multi-stage builds.
For example, this would compile the test binary for this repo into the image. The result is only 14.2 MB.
FROM golang:1.11.5-alpine3.9 AS compile
RUN apk add --no-cache gcc libc-dev
COPY src/ /opt/src/
RUN GOPATH=/opt go test -c -o /opt/go-sqlite3.test github.com/mattn/go-sqlite3

FROM alpine:latest AS final
ENV TZ=Asia/Jerusalem
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN apk add --no-cache tzdata
COPY --from=compile /opt/go-sqlite3.test /opt/go-sqlite3.test

I'm familiar with multi stage build, what I don't understand, is, In the
final docker you did not get libc installed at all, I don't get where/ when
will the dependencies be pulled .
On Sat, 16 Feb 2019, 15:53 rittneje<EMAIL_ADDRESS>wrote:

It is 311 MB. But you don't have to keep it around in your final image. An
easy way to accomplish this is with multi-stage builds
https://docs.docker.com/v17.09/engine/userguide/eng-image/multistage-build/#use-multi-stage-builds
.
For example, this would compile the test binary for this repo into the
image. The result is only 14.2 MB.
FROM golang:1.11.5-alpine3.9 AS compile
RUN apk add --no-cache gcc libc-dev
COPY src/ /opt/src/
RUN GOPATH=/opt go test -c -o /opt/go-sqlite3.test github.com/mattn/go-sqlite3
FROM alpine:latest AS final
ENV TZ=Asia/Jerusalem
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN apk add --no-cache tzdata
COPY --from=compile /opt/go-sqlite3.test /opt/go-sqlite3.test
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattn/go-sqlite3/issues/694#issuecomment-464348912,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFpMclKYAHFjVxqLwMiT5DevvuHLS_SDks5vOA0_gaJpZM4a7jC8
.

The base Alpine image itself already has the libmusl library. Because the binary was compiled in Alpine itself, it will be linked against that instead of glibc.
/ # ldd /opt/go-sqlite3.test
	/lib/ld-musl-x86_64.so.1 (0x7f2612f4e000)
	libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f2612f4e000)

@GuyBrand Has your issue been resolved?

For the sake of a deadline, integration team has temporary resolved this by
pushing the micro service discussed outside the docker (to the house
machine),
In a couple of days when environment is stable, we will spend the time to
resolve this, and I will surely report, and update the ticket accordingly.
Thanks much for the effort you spent by now, it's much appreciated!
On Tue, 19 Feb 2019, 1:18 rittneje<EMAIL_ADDRESS>wrote:

@GuyBrand https://github.com/GuyBrand Has your issue been resolved?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattn/go-sqlite3/issues/694#issuecomment-464919318,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFpMcldIeQnqMO2A76Qoe-p0N6NdbiTtks5vOzThgaJpZM4a7jC8
.

@rittneje
It looks like (after making small changes to the script - git installation, gopath to /go etc) the compilation displays the right time.
However, this does mean we need to switch our CI to be built by Alpine (currently centos).
Do you know if there's a way to bind libc.musl running on centos ?

First install musl-gcc.
sudo apt-get install musl-dev musl-tools

Now use musl-gcc instead of regular gcc when compiling.
CC=musl-gcc go build ...

The resulting binary will be linked against libmusl and will thus work properly when copied into your Alpine docker. Note that I have tested this using Ubuntu, but I imagine the same will work on Centos. In any case, I would still recommend doing the compilation in the Alpine docker, as cross-compilation can get very tricky depending on what exactly you are doing.

Looks like this worked!
Great advice.
On Sun, 24 Feb 2019, 16:46 rittneje<EMAIL_ADDRESS>wrote:

First install musl-gcc.
sudo apt-get install musl-dev musl-tools
Now use musl-gcc instead of regular gcc when compiling.
CC=musl-gcc go build ...
The resulting binary will be linked against libmusl and will thus work
properly when copied into your Alpine docker. Note that I have tested this
using Ubuntu, but I imagine the same will work on Centos. In any case, I
would still recommend doing the compilation in the Alpine docker, as
cross-compilation can get very tricky depending on what exactly you are
doing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mattn/go-sqlite3/issues/694#issuecomment-466783318,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFpMchcmCIoWaORrs26HXPBTmZ-uSa6iks5vQqXYgaJpZM4a7jC8
.

Closable?

Sure, as alpine is the go-to docker when using go, I would advise to add:

when running on an alpine docker, it is best to compile using: ```
CC=musl-gcc go build ...

to this section:
https://github.com/mattn/go-sqlite3/#alpine


Problems with commented file

Hi,
wonderful work. I have problems with commented files.
https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/invalid-json
Best regrds

@franklupo
Thank you for your contribution!
In official docs, comments within appsettings.json are allowed.
But it is not implemented in this library.
I think it can be resolved by passing appropriate JsonSerializerOptions. I will try.
PR is welcome.

Yes, JsonSerializerOptions is the solution. Pass parameter in ConfigureWritable, ConfigureWritableWithExplicitPath or in Update?

@franklupo
Fixed on #313.
But currently, JsonWritableOptions.Update() removes comments & trailing comma even if there are on other section.
This known issue will be tracked in #314.


Deprecate mixed precision support

We do not want to offer a custom mixed precision backend in AxoNN.

[x] Deprecate all functions related to mixed precision.
[x] Have a single API to set the dtype for all-reduces. This setting should be used across intra and inter-layer parallelism
[x] Deprecate cpu_offload for now. We'll see later if there's a usecase for it.

Addressed in https://github.com/axonn-ai/axonn/pull/91


Implement Concept block

Description
Implement the Concept concept block as designed in #114.
Acceptance Criteria

[ ] Implement the concept block for desktop
[ ] Implement the concept block for tablet
[ ] Implement the concept block for phone
[ ] CTA goes to https://github.com/ipfs-shipyard/pm-idm/blob/master/docs/idm-concept.md

To be defined

[ ] Which video goes in there?
[ ] Is it one or more videos?

@andreforsousa can you review the "To be defined" and provide us with a answers for these points?

I'd say that could be a video with the current "POC" already in used with the features that we implemented until the IPFS camp. It should be just one, at least for now.

Alright, so lets awesome we are going to have a youtube video there. Make it some random video for now and we will change the link later on.

There a few layout issues in this component that were highlighted in #167. Will get them fixed there, closing this.

Actually, I'm going to reopen this as the background color is not correct, it should our green (I think we have a CSS variable for that).

Done!


Test failure: MultipleAppTests.Startup

http://aspnetci/viewLog.html?buildId=541687&buildTypeId=Releases_22xPublic_Win2012
Assert.Equal() Failure
Expected: OK
Actual:   BadGateway
   at Microsoft.AspNetCore.Server.IISIntegration.FunctionalTests.MultipleAppTests.Startup(AncmVersion ancmVersion) in /_/test/IISExpress.FunctionalTests/OutOfProcess/MultipleAppTests.cs:line 58
--- End of stack trace from previous location where exception was thrown ---
------- Stdout: -------
| [0.001s] TestLifetime Information: Starting test Startup-AspNetCoreModule at 2018-08-29T04:52:12
| [0.001s] Microsoft.AspNetCore.Server.IntegrationTesting.IIS.IISExpressDeployer Information: Deploying [Variation] :: ServerType=IISExpress, Runtime=CoreClr, Arch=x64, BaseUrlHint=, Publish=False
| [0.001s] Microsoft.AspNetCore.Server.IntegrationTesting.IIS.IISExpressDeployer Information: Executing: dotnet D:\b\w\33bdfc1cae7b2a38\modules\IISIntegration\test\WebSites\OutOfProcessWebSite\bin\x64\Release\netcoreapp2.2\OutOfProcessWebSite.dll

https://github.com/aspnet/IISIntegration/pull/1293

I don't believe this failure is related to #1293.  Agent event logs suggest the root cause was two independent apps happened to choose the same random port:
Application 'MACHINE/WEBROOT/APPHOST/HTTPTESTSITE' started process '16128' successfully and is listening on port '42436'.

Application 'MACHINE/WEBROOT/APPHOST/HTTPTESTSITE' with physical root 'D:\b\w\33bdfc1cae7b2a38\modules\IISIntegration\test\WebSites\OutOfProcessWebSite\' created
process with commandline 'dotnet D:\b\w\33bdfc1cae7b2a38\modules\IISIntegration\test\WebSites\OutOfProcessWebSite\bin\x64\Release\netcoreapp2.2\OutOfProcessWebSite.dll'
but failed to listen on the given port '42436'

With the current test and product code, the test is expected to fail approximately 1 in 1,000 times (probably of at least one collision when 10 sites choose a random port from the range 1025-48000).
I will add one retry to the test, which should reduce the failure rate from 1 in 1,000 to 1 in 1,000,000.


Fixed Header: Add top margin to navbar #68

Fixed Header: Add top margin to navbar #68

As discussed, editing should be done locally and changes pushed to GitHub using the git command. This will ensure that the code is automatically formatted before each commit, which prevents the linting error above.


Regression in v2.7.3

My project compilation is suddenly broken after updating from gulp-typescript 2.7.2 to 2.7.3.
/home/user/project/node_modules/gulp-typescript/node_modules/source-map/lib/source-map/array-set.js:83
    throw new Error('No element indexed by ' + aIdx);
          ^
Error: No element indexed by 29
    at ArraySet_at [as at] (/home/user/project/node_modules/gulp-typescript/node_modules/source-map/lib/source-map/array-set.js:83:11)
    at SourceMapConsumer_parseMappings [as _parseMappings] (/home/user/project/node_modules/gulp-typescript/node_modules/source-map/lib/source-map/source-map-consumer.js:410:44)
    at SourceMapConsumer.Object.defineProperty.get (/home/user/project/node_modules/gulp-typescript/node_modules/source-map/lib/source-map/source-map-consumer.js:73:14)
    at SourceMapConsumer_eachMapping [as eachMapping] (/home/user/project/node_modules/gulp-typescript/node_modules/source-map/lib/source-map/source-map-consumer.js:139:24)
    at Function.SourceMapGenerator_fromSourceMap (/home/user/project/node_modules/gulp-typescript/node_modules/source-map/lib/source-map/source-map-generator.js:52:26)
    at Output.applySourceMaps (/home/user/project/node_modules/gulp-typescript/release/output.js:97:54)
    at Output.addOrMergeFile (/home/user/project/node_modules/gulp-typescript/release/output.js:66:22)
    at Output.write (/home/user/project/node_modules/gulp-typescript/release/output.js:35:14)
    at ProjectCompiler.inputDone (/home/user/project/node_modules/gulp-typescript/release/compiler.js:59:33)
    at CompileStream.end (/home/user/project/node_modules/gulp-typescript/release/main.js:52:31)

Can you post your project or create an example that reproduces it?

Can you also retest it with the current master?

The reason for error is that my main.ts file references another ts file that is outside of the sources dir.
So the directory layout is as follows:
.
├── foo.ts
├── gulpfile.js
├── package.json
└── src
    └── ts
        └── main.ts

and the main.ts file references foo.ts:
/// <reference path="../../foo.ts" />

Can you post your gulp file?

I have posted a sample project to the first file hosting web site I have found online. Here is the link: http://s000.tinyupload.com/index.php?file_id=45372232451953110536
Download it, unzip, npm install then gulp, as usual.

This has been fixed in the master, I'll release it on npm soon.

I confirm it works as expected now. Thanks for the quick fix!


Remove src/Main.hs

src/Main.hs should be removed (was it created from stack's template?).

This is fixed, thanks.


Graceful shutdown

What happens when the window is closed or the binary needs to be stopped? In main, I can see start functions but no logic to gracefully shut down various go routines.

That's an interesting question.  I just tried out closing via the window and by stopping the cli part.  They both shut the UI and process down, but that doesn't answer your question about how to gracefully shut down.
Looking at the fyne.io docs it appears there are handlers that can be registered to be called when closure is wanted.
Probably a good combo would be to leverage FX to start things up & tear them down.


Table: fix highlightCurrentRow regression

Please make sure these boxes are checked before submitting your PR, thank you!
Fixes #11560

[ ] Make sure you follow Element's contributing guide (中文 | English | Español).
[ ] Make sure you are merging your commits to dev branch.
[ ] Add some descriptions and refer relative issues for you PR.

I just checked and the error is still occurring on the table on this site: https://deploy-preview-11563--element.netlify.com


Ensure proper Invariant Violation error is thrown

Ensure a proper Invariant Violation error is thrown when a  is rendered outside of a , instead of a TypeError

@ryanflorence @mjackson: Is this lib dead? Is there a better approach to use when we need to ensure that context is updated properly?
(In my case it's basically an object that is put in the context, that other components could extract data from. So it's not so much about mutation as it's about changing the object that's in the context, which, if I understand it correctly, is much worse.)

Thanks for the PR, @PAkerstrand. Sorry it took so long to get it merged. Lots of code to maintain! 😅
This will be released in the next patch release.

Just released in 0.5.3. Enjoy!


Submit library to packagist

Since "minimalcode/search" is now included as a suggestion in the Solarium composer config I think it should be submitted to Packagist.
Currently the install fails because the package cannot be found.

It seems like I overlooked something, it is available, just not in a stable version. Somehow I didn't find it in the packagist search engine, but now I do...

@basdenooijer  is you want I could tag a stable release. (
I was waiting possible API change, but the lib is pretty stable right now)

I think it might be a good idea to indicate to people considering to use it that the library has reached a stable state .

Done. Tagged 1.0.1 stable.
Thank @basdenooijer


Support federation

Hi, is it planed to support federation as Strawberry does ?
I think that a JwtFederationSchema class that inherits from strawberry.federation.Schema would work.
As a workaround I overwrited the JwtSchema definition.
Thanks for the tool by the way !

I currently passively maintain this project meaning that I'll merge PR's though I don't have time to work on features ATM.


Redesign JointLatent definition

The previous implementation had several flaws that came up when actually working with it:

There conceptually unnecessary distinction between shared and latent parameters. We keep the concept of assigning each individual model (and its parameters) with a key, but clear up the logic. The new JointLatent (naming OK?) simply defines a global vector of latent variables where each of those entries is connected to one or multiple (shared) key, parameter_name pairs.
The definition on which parameters are shared was previously only possible by them having the same name. This option is kept (latent.add_by_name("my_shared_prm")). But you can now add differently named parameters manually.

global_latent_index = latent.add("holiday_length", key="B")
latent.add_shared(global_latent_index, "vacation_length", key="A")

The MultiModelError could concatenate its individual contributions. split_by_key is added as the reverse. A more general recursively nested structure #2 is considered to automate this.

EDIT: I also moved the correlation and transformation from gitlab here. Sorry for the mix.

Thank you very much for the review! I tried to incorporate all of it. Two issues:

I agree that add_model_parameters is misleading and I renamed it to define_shared_model_parameters. But I now realized that this class can also be used to set the parameters of a single ModelParameters latent. Thus, the shared is also wrong. But I could not come up with a better name. Ideas?
In the correlation test, I now check for the means.

For the uncorrelated model (where the standard deviation is expected to change), the means are identical (up to 1e-3 or so).
For the correlated model, the means differ with a delta of 0.2, so quite a lot. Is that expected? Should, instead, be tested, if the means are one standard deviation within the correct mean? I left the failing test case in there. Maybe you can again comment on that.

Thank you very much for the review! I tried to incorporate all of it. Two issues:

I agree that add_model_parameters is misleading and I renamed it to define_shared_model_parameters. But I now realized that this class can also be used to set the parameters of a single ModelParameters latent. Thus, the shared is also wrong. But I could not come up with a better name. Ideas?
In the correlation test, I now check for the means.

For the uncorrelated model (where the standard deviation is expected to change), the means are identical (up to 1e-3 or so).
For the correlated model, the means differ with a delta of 0.2, so quite a lot. Is that expected? Should, instead, be tested, if the means are one standard deviation within the correct mean? I left the failing test case in there. Maybe you can again comment on that.

For the naming, why not something like set or define_latent_parameters, in the documentation you could add that these are the ones related to the global problem.
In our problem, you actually generate two different data sets. The 50 sample setup has different values than the 200 sample test (if the assumption of correlated data would be right, interpolation of the 50 sample data would be almost identical to the 200 sample data). For the uncorrelated data sets, this is not a problem, because you have so many (independent)  data points, that this averages out. For the case where you prescribe a correlation length to generate the data (0.2) on a length of the domain (1), you end up with an effective number of samples that is around 5, but with different seeds (the seed is the same, but due to a different number of x-values you get a completly different function). Solution - you would have to generate the noise samples with a fine discretization (and the correlation, so that the samples noise is identical in both cases), and then interpolate this noise values either onto 50 samples or 200.

For the naming, why not something like set or define_latent_parameters, in the documentation you could add that these are the ones related to the global problem.
In our problem, you actually generate two different data sets. The 50 sample setup has different values than the 200 sample test (if the assumption of correlated data would be right, interpolation of the 50 sample data would be almost identical to the 200 sample data). For the uncorrelated data sets, this is not a problem, because you have so many (independent)  data points, that this averages out. For the case where you prescribe a correlation length to generate the data (0.2) on a length of the domain (1), you end up with an effective number of samples that is around 5, but with different seeds (the seed is the same, but due to a different number of x-values you get a completly different function). Solution - you would have to generate the noise samples with a fine discretization (and the correlation, so that the samples noise is identical in both cases), and then interpolate this noise values either onto 50 samples or 200.

So if you agree with my changes, we could merge the branch into master.

So if you agree with my changes, we could merge the branch into master.

Thank you for adding a proper test for the correlated model! Honestly, I struggled with finding a nice name for the model parameters thing. You idea of "define_latent_parameters" would also be misleading, because we first have to pass the whole model parameters list via this debatable-name-method and afterwards define a subset from that list as latent. I simply went for "define_model_parameters" and hope that is alright...

Thank you for adding a proper test for the correlated model! Honestly, I struggled with finding a nice name for the model parameters thing. You idea of "define_latent_parameters" would also be misleading, because we first have to pass the whole model parameters list via this debatable-name-method and afterwards define a subset from that list as latent. I simply went for "define_model_parameters" and hope that is alright...


Rails 3.2.17; Error: Can't mass-assign protected attributes: key

SOLUTION:
# in config/initializers/settler.rb

class Setting < ActiveRecord::Base
  attr_accessible *column_names
end

Settler.load!

SOURCES:

http://stackoverflow.com/a/15932630
http://stackoverflow.com/questions/8961994/how-to-make-all-model-attributes-accessible-for-mass-assignment
https://github.com/moiristo/settler/blob/fb005d9ecc7b6f2330ac70b136d9f2abb165f983/lib/settler.rb#L15

BACKGROUND:
irb(main):011:0> Setting.count
   (0.3ms)  SELECT COUNT(*) FROM "settings" WHERE (deleted = 'f' or deleted IS NULL)
=> 0
irb(main):012:0> Settler.load!
  Setting Load (0.1ms)  SELECT "settings".* FROM "settings" WHERE "settings"."key" = 'ask_mailer' LIMIT 1
ActiveModel::MassAssignmentSecurity::Error: Can't mass-assign protected attributes: key
	from /Users/dev/.gem/ruby/2.1.8/gems/activemodel-3.2.17/lib/active_model/mass_assignment_security/sanitizer.rb:48:in `process_removed_attributes'
	from /Users/dev/.gem/ruby/2.1.8/gems/activemodel-3.2.17/lib/active_model/mass_assignment_security/sanitizer.rb:20:in `debug_protected_attribute_removal'
	from /Users/dev/.gem/ruby/2.1.8/gems/activemodel-3.2.17/lib/active_model/mass_assignment_security/sanitizer.rb:12:in `sanitize'
	from /Users/dev/.gem/ruby/2.1.8/gems/activemodel-3.2.17/lib/active_model/mass_assignment_security.rb:230:in `sanitize_for_mass_assignment'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/attribute_assignment.rb:75:in `assign_attributes'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/base.rb:498:in `initialize'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/persistence.rb:44:in `new'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/persistence.rb:44:in `create'
	from /Users/dev/.gem/ruby/2.1.8/gems/settler-2.0.1/lib/settler.rb:23:in `block (2 levels) in load!'
	from /Users/dev/.gem/ruby/2.1.8/gems/settler-2.0.1/lib/settler.rb:22:in `each'
	from /Users/dev/.gem/ruby/2.1.8/gems/settler-2.0.1/lib/settler.rb:22:in `block in load!'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/scoping/default.rb:41:in `block in unscoped'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/relation.rb:241:in `block in scoping'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/scoping.rb:98:in `with_scope'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/relation.rb:241:in `scoping'
	from /Users/dev/.gem/ruby/2.1.8/gems/activerecord-3.2.17/lib/active_record/scoping/default.rb:41:in `unscoped'
	from /Users/dev/.gem/ruby/2.1.8/gems/settler-2.0.1/lib/settler.rb:21:in `load!'
	from (irb):12
	from /Users/dev/.gem/ruby/2.1.8/gems/railties-3.2.17/lib/rails/commands/console.rb:47:in `start'
	from /Users/dev/.gem/ruby/2.1.8/gems/railties-3.2.17/lib/rails/commands/console.rb:8:in `start'
	from /Users/dev/.gem/ruby/2.1.8/gems/railties-3.2.17/lib/rails/commands.rb:41:in `<top (required)>'
	from script/rails:6:in `require'
	from script/rails:6:in `<main>'irb(main):013:0>

Hi, thanks for your feedback! Instead of your proposed solution, I refactored the load! method to not create settings by using mass assignment (cc5d030223f4dfc39f942ecabf658904cd245b07). Does this resolve the issue? When everything is ok I'll release this in v2.0.2.


Finished Burlap Carpet/Updated build.gradle / Added Naming

Youll need to refresh your gradle, added the partchmentMC mappings for deobf
added carpets with burlap
added Tag files/ran generatedata run
turned burlap items into blockitems
created manual blockstate files for carpets due to inability to gen from code(dont know how)
renamed registry for burlap to _ITEM and created block registry
may need to create a tag for carpets

@calheb Please Review!


How to build a cldr.json file as in the globalize compiler example

I am finally looking to migrate from 0.x to a current version of globalize and I admit I have a very hard time doing that.
So before, I only had to load the desired culture file and work with it - but now, I have loads of CLDR data and I do not need the most of that.
So first of all, I want to know how to build a custom cldr.json file like provided in the compiler example, so I wont have to load >500KB from lots of separate files like in the other examples, but only the actual data I need. Right now I only need basic Number and Date parsing and formatting .
So, how was this file actually built? Maybe I have overlooked something, but I could not find any hints in the docs.  Plus, is there a way doing this using grunt? The ideal way of doing this would be using an automated task where I can specify the desired locale(s) and excactly which kind of data I want to be included, resulting in a compact file like in the example.
Any help is greatly appreciated!

... migrating from 0.x to 1.x.

 Lot has changed from 0.x to 1.x. You can find migration help on https://github.com/jquery/globalize/#migrating-from-globalize-0x and on http://blog.johnnyreilly.com/2015/07/upgrading-to-globalize-1x-for-dummies.html.

How to build a cldr.json file as in the globalize compiler example

Manually tailored using CLDR.

"How do I get CLDR data?" https://github.com/jquery/globalize/blob/master./doc/cldr.md.
"Do I need to custom tailor CLDR myself?". No, unless you really want to. You should use the compiler to get optimal Globalize runtime in your app (fast and small). Examples: [1] and [2].

Plus, is there a way doing this using grunt?

No there's no grunt wrapper for it that I know of, but Globalize compiler is a JavaScript and it shouldn't be hard to write one (grunt wrapper). I could help if you have any questions while doing so.
Basic Globalize Compiler example shows how to use the compiler via npm scripts.
Application example using webpack and npm shows how to use the compiler transparently via webpack plugins.
Did I answer to your questions? Please, do you have any suggestion on how we could improve the docs to address the issues you pointed out?

Manually tailored using CLDR.

So what does "manually tailored" really mean? Is there some kind of script to build such a file (still talking about that cldr.json from the compiler example)? Or did you actually put it to gether by hand using copy & paste? (Cannot imagine it was the latter case, that would be quite tedious!)

You should use the compiler to get optimal Globalize runtime in your app

Also I am not sure to get my code play well with the compiler. I do not use direct Globalize.... calls, but I use a wrapper class which my modules call instead. As I understand the Compiler analyses the code for such calls and builds an appropriate js file. Think that wont work with my setup?
So right now I have a static JSON file for each language, which contains both the culture info (for parsing and formatting) as well as all my translations. My locale module then loads one of these files based on laguage settings and also wraps around the Globalize methods. So Globalize is never called directly by the modules that need localization. How can the compiler work in such a case?
So what I actually need (at least to do the first migration step without disrupting everything) is a static file analog to the former culture file, but without the huuuge overhead that I would have when loading everything. I mean the whole CLDR data for one language alone is more data than my whole compiled app, and a magnitude larger than the former culture files.

First of all, we're open to suggestions on how to improve every single part of this library, so suggestions are welcome.
Globalize is very flexible and allows for various different usages. Currently, we provide a handful of examples, where each emphasizes on one aspect. The example you're bringing to discussion here is the one that shows how to use Globalize Compiler, therefore it focuses on the compiler. The compiler will take CLDR from whatever source you choose as long as it's valid CLDR and has enough data for the functions you're using. So, for the example purposes, that file is made as small as was possible for simplicity for the reader to acknowledge that. So, yes it's put together manually. I don't recommend you to compile your CLDR manually that way in your application. For that you have different choices, we have a doc section explaining the different ways to download CLDR, we have different tools to assist you on selecting the CLDR portions you need (a simple table for reference, an online tool, or simply use the compiler for a most autonomous way.

Also I am not sure to get my code play well with the compiler. I do not use direct Globalize.... calls, but I use a wrapper class which my modules call instead

Can you provide a reduced example of your app?

the whole CLDR data for one language alone is more data than my whole compiled app, and a magnitude larger than the former culture files

You definitely should NOT embed the whole CLDR.

You definitely should NOT embed the whole CLDR.

Yeah of course, but how to do it without using the compiler or building the needed data by hand?

Globalize is very flexible and allows for various different usages.

So this is my main problem: while Globalize might be flexible, it is only so as long as you do it the way you planned, and "various" means not "all". In my case it is not so flexible anymore it seems, and apparently requires a LOT of additional work, see my remarks / questions below:

Can you provide a reduced example of your app?

OK, so I will try to explain more in-depth what I am doing, so bear with me as my reply will become a bit more verbose ;)
Allright, we are speaking of a SPA, built upon my own framework. This app uses requireJS heavily and consists of about 150 modules, also uses grunt for building the final version (there is a dev and a deployment version). While the dev version uses the single modules, the deployment version uses just a single file. This file is built using the requireJS grunt tool, i.e. the process automatically detects all dependencies and concatenates them to a single JS file, which loads a LOT faster.
And here the first challenge starts. I also looked at the AMD example and even for the simple hello world example, it loads a total of 13 files with over 500KB! Now, if I would run my build process just as it is, these files all would be included in the final deployment file automatically. And as I see it the compiler creates a totally different file, so that would be also one thing I have to work around. Since as you said there is no grunt plugin for the compiler, it even gets more tedious, because I would have to write one (which I never did).
But even if I would, there is still the question how the compiler would detect my API calls, since I do not  (and never would) require and call Globalize directly. That would mean that all these consuming modules would not need to include ONE dependency (my localizer module), but a lot more. This would add quite a bit of overhead at least in the dev Version (and that overhead is already noticable when loading up to 150 modules). And it would of course make the build process a LOT more complicated and slower.
OK, so my data source is one single JSON file for each language with this overall structure:
{
    "formats": { ... essentially the contents of the 0.x culture file ... },
    "translations": { ... all my translations ... }
}

I then have my "localizer" module which handles loading and switching languages, and provides a simple wrapper for translations and also formatting / parsing Dates and Numbers. Currently I only use Globalize for the latter, all translations are done by i18next. But I am also thinking about doing translations by Globalize as well.
So, there are two ways to call translation / formatting:
a) using custom knockout bindings:
<form-text-readonly params="vm: value, format: 'D'"></form-text-readonly> (using micro template)

 (direct way)

b) direct calls:
var formatted = localizer.format(value, "D");
var parsed = localizer.parse("DATE", myDate, "D");

The part in the localizer which translates this into the final calls is actually quite simple:
/**
 * Translates a piece of Text.
 * @param  {string}   key     A path to the desired object (using "dot notation").
 * @param  {object}   [vars]  Additional variables, is an object using key : value pairs. Note that there are two special vars called "count" (for pluralization)
 * and "context" (used for context aware translations). You can also use these for replacing vars (see example below)
 * @example
 * // stored translation object:
 * "path" : {
 *   "text" : "Singular Form",
 *   "text_plural" : "Plural Form: {count} elements"
 * }
 * // do translations like this:
 * localizer = require("locale/localizer");
 * myTranslation = localizer.translate("path.text"); // -> "Singular Form"
 * myOtherTranslation = localizer.translate("path.text", { count: 99 }); // -> "Plural Form: 99 elements"
 */
translate: function (key, options) {

    return translateLib.translate(key, options);

},

/**
 * Formats data using localized presentation rules.
 * @param  {number|Date}   data      The piece of data that should be formatted. Can be either a Number, a Date String in UTC Format or a Date object
 * @param  {string}        [format]  A string indicating which format to use
 * @example
 * localizer = require("locale/localizer");
 * formattedNumber = localizer.format(123.45, "c"); // -> "123,45" with locale: "en" / "123.45" with locale: "de"
 * formattedDate = localizer.format(new Date(), "D"); // -> Fully formatted date
 */
format: function (data, format) {

    return formatterLib.format(data, format);

},

/**
 * Parses various string formats and tries to convert them to native formats. Currently works with ints, flotas and dates
 * @param  {string}  data            The piece of data that should be parsed. Can be either a String representing a number or a Date String (in localized form)
 * @param  {string}  [type="FLOAT"]  The desired target Format, can have the values "INT", "FLOAT" and "DATE". Default is "FLOAT"
 * @param  {string}  [format]        Any additional formatting information, either for the possible date formattings or in case of numbers the radix (10 is default here)
 * @param  {string}  [culture]       You can override the default culture with this parameter
 * @example
 * localizer = require("locale/localizer");
 * parsedDate = localizer.parse("DATE", "1.1.2013"); // -> native Date Object (assuming locale "de" is loaded)
 */
parse: function (type, data, format, culture) {

    switch (type) {
    case "DATE":
        return formatterLib.parseDate(data, format, culture);
    case "INT":
        return formatterLib.parseInt(data, format, culture);
    case "FLOAT":
        return formatterLib.parseFloat(data, format, culture);
    default:
        throw new Error("Must specify parse format");
    }

}

In this case "translateLib" is i18next and "formatterLib" is the "old" Globalize.
So how can I make the compiler with such a structure? And it really seems to compiler is the only way to get a sane amount of code / data?
Right now, the only thing I can think of that could maybe work is to make a kind of "dummy" app which includes all types of Globalize usages, i.e. "dummy calls" using the desired formats and uses a separate process to create the file(s) I actually need, which in turn is then included with my actual app. But oh well, if I also want to handle my translations by Globalize this would mean that I have to run this process each time when I change something in my translations while developing. Well, so as a next step I have to add another watchdog .... hmmm. So it seems to achieve the same thing, things are getting way more complicated, and I begin to ask myself: where is the actual benefit?
Any idea to get a managable workflow with my setup?


Completion of error handling

Would you like to add more error handling for return values from functions like the following?

fprintf ⇒ zbc_print_device_info
strdup ⇒ zbc_block_handle_partition

Patches are welcome.


chore: Compute registerer address on the fly

Removes another annoying source of conflicts.

Benchmark results
No metrics with a significant change found.

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 6a7ccca5 and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
676
676
676

l1_rollup_calldata_gas
6,412
6,424
6,424

l1_rollup_execution_gas
585,745
585,757
585,757

l2_block_processing_time_in_ms
1,338 (+4%)
4,742
9,103 (+4%)

note_successful_decrypting_time_in_ms
179 (+8%)
535 (-7%)
997 (-1%)

note_trial_decrypting_time_in_ms
83.5 (+17%)
52.9 (-43%)
127 (-5%)

l2_block_building_time_in_ms
17,347
65,157
129,438 (+2%)

l2_block_rollup_simulation_time_in_ms
8,104 (+1%)
28,537 (+1%)
56,079 (+3%)

l2_block_public_tx_process_time_in_ms
9,224 (-1%)
36,563 (-1%)
73,256

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
14,155 (-2%)
28,361 (+3%)

note_history_successful_decrypting_time_in_ms
1,253 (-5%)
2,479 (+2%)

note_history_trial_decrypting_time_in_ms
103 (+7%)
165 (+7%)

node_database_size_in_bytes
18,624,592
35,053,648

pxe_database_size_in_bytes
29,859
59,414

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
240 (-3%)
44,344
28,181

private-kernel-ordering
216
52,847
14,263

base-parity
4,477 (-4%)
128
311

root-parity
1,660 (-1%)
1,244
311

base-rollup
18,185 (+2%)
165,727
861

root-rollup
50.2 (+1%)
4,359
725

private-kernel-inner
596
73,728
28,181

public-kernel-app-logic
399 (-1%)
35,185
28,151

public-kernel-tail
172 (-1%)
40,862
28,151

merge-rollup
8.53 (-3%)
2,568
861

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.0 (-2%)
16.1 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.6
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.582 (-1%)
0.497 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
46.0 (+1%)
72.1 (+1%)
231 (-1%)
447 (+1%)
866
1,718 (+3%)
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
96.0
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.471 (+1%)
0.444
0.420 (-2%)
0.417 (+1%)
0.412
0.411 (+2%)
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
54.1 (+1%)
107 (+1%)
338
664
1,317 (+1%)
2,618 (+3%)
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
104
207
691
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.480 (+1%)
0.480
0.461 (+1%)
0.456
0.454 (+1%)
0.453 (+3%)
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
61.5 (+1%)

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
109

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.536

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes

tx_size_in_bytes
21,991

Transaction processing duration by data writes.

Metric
0 new note hashes
1 new note hashes

tx_pxe_processing_time_ms
3,077 (-2%)
1,657

Metric
0 public data writes
1 public data writes

tx_sequencer_processing_time_ms
10.9 (+3%)
1,148 (-1%)


Have the documentation system support LaTeX formulas

As far as I can tell, it's not possible to write formulas in LaTeX in the documentation. In my opinion, it would be useful to add formulas to documentations of e.g. optimizers and activations. At the moment, some parts of the documentation write formulas as code, which is a bit ugly and would be even uglier for more complicated formulas.
There exists a MathJax extension to MkDocs that could be used, see: https://stackoverflow.com/questions/27882261/mkdocs-and-mathjax .
EDIT: Apparently the same issue has already been posted here, but it was closed due to inactivity, see https://github.com/keras-team/keras/issues/2911

@Dref360 I was planning I might look into it on the next non-sunny day around here. I'm not sure, though, if it needs something installed on the server that is hosting the docs. If that is the case, I can't do it.

@Dref360 I added the support to latex formulas on my local repository, it was rather easy. The problem is that I had to install python-markdown-math extension first. It has to be located in whatever path mkdocs looks for python libraries so simply copying the .py file to Keras docs/ folder did not work. Installing the extension was as easy as just doing pip3 install python-markdown-math.
Unless there are suggestions on how to go around this, I think whoever maintains the Keras.io server needs to install this extension and put it in the correct path.


Static Web App Config - allowed roles for API - case sensitivity - Security concern

Feature to allow/ block API request is not working as expected.
staticwebapp.config.json
{       "route": "/api/getSubscList",       "allowedRoles": ["contributor", "reader"]  }
Upon checking, if I'm unauthenticated and I try to send a GET request to this URL:
https://.azurestaticapps.net/api/getSubscList
I'll get Unauthorized response (expected outcome).
but if I change the URL to:
https://.azurestaticapps.net/api/getsubsclist
or
https://.azurestaticapps.net/api/getSubscLisT
my request will go through even though I don't have the required roles.

I'm interested in this issue, does it behave differently if you change the casing of the route parameter to all lowercase?

Thanks for raising this @arisabejuela. We are looking into this!

Hi @AverageCakeSlice, it behaves the same (case sensitive).
If you configure staticwebapp.config.json like this:
{ "route": "/api/**getsubsclist**", "allowedRoles": ["contributor", "reader"] }
then, unauthenticated, you send GET request to:
https://xxxxx.azurestaticapps.net/api/**getsubscLIST**
you'll get a successful response.

@miwebst that was quick. Thank you.
Upon checking, issue is already fixed. Great work!


Test supported versions of python and django only

Failing tests are bc of https://github.com/jbittel/django-mama-cas/pull/98

@stsewd this looks great, can you please rebase on current master?

Done! I have added python 3.8 to the test suit as well :)

Ha, looks like some deps aren't compatible with 3.8. I'll left that for another PR

Looks like tests have passed.  @jbittel , can you please merge this PR?

Thanks for this!


[Bug] Building storybook runs out of memory

Describe the bug
Since upgrading to Vite 2.9, storybook build step is now failing due to lack of memory. That was not an issue before
Steps to reproduce the behavior

Install Vite 2.9
Install builder-vite 0.1.23
Run build command on CircleCI
See error

Expected behavior
Build finishing without issues
Screenshots and/or logs
yarn run v1.22.11
$ build-storybook && percy storybook ./storybook-static --maxWorkers=4
info @storybook/vue3 v6.4.20
info
info => Cleaning outputDir: /home/circleci/project/storybook-static
info => Loading presets
(node:583) [DEP0148] DeprecationWarning: Use of deprecated folder mapping "./" in the "exports" field module resolution of the package at /home/circleci/project/node_modules/vuex/package.json.
Update this package.json to use a subpath pattern like "./*".
(Use `node --trace-deprecation ...` to show where the warning was created)
vite v2.9.1 building for production...
transforming...
Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
Use of eval is strongly discouraged, as it poses security risks and may cause issues with minification
✓ 2393 modules transformed.
rendering chunks...
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Sourcemap is likely to be incorrect: a plugin (vue-docgen) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help

<--- Last few GCs --->

[583:0x648bb60]    60638 ms: Scavenge (reduce) 2021.4 (2082.2) -> 2020.6 (2082.2) MB, 2.7 / 0.0 ms  (average mu = 0.190, current mu = 0.170) allocation failure
[583:0x648bb60]    60642 ms: Scavenge (reduce) 2021.4 (2082.2) -> 2020.6 (2082.2) MB, 2.9 / 0.0 ms  (average mu = 0.190, current mu = 0.170) allocation failure
[583:0x648bb60]    60649 ms: Scavenge (reduce) 2021.4 (2082.2) -> 2020.8 (2082.2) MB, 5.7 / 0.0 ms  (average mu = 0.190, current mu = 0.170) allocation failure

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xafd010 node::Abort() [/usr/local/bin/node]
 2: 0xa141fb node::FatalError(char const*, char const*) [/usr/local/bin/node]
 3: 0xce746e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 4: 0xce77e7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
 5: 0xeb5c85  [/usr/local/bin/node]
 6: 0xeb6766  [/usr/local/bin/node]
 7: 0xec471e  [/usr/local/bin/node]
 8: 0xec5140 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
 9: 0xec7fae v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
10: 0xe899da v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/local/bin/node]
11: 0x11fea76 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
12: 0x15e7fb9  [/usr/local/bin/node]
Aborted (core dumped)
error Command failed with exit code 134.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Exited with code exit status 134
CircleCI received exit code 134

Environment

OS: Linux
Node.js version: 16.10.0
NPM version: 4.1.1

Additional context
Add any other context about the problem here.

@patak-dev, do you have any reports of increased memory usage in vite 2.9?
@doutatsu if you downgrade to vite 2.8.6 while keeping the same version of @storybook/builder-vite, does the OOM error still happen?

@IanVS It only happens on Vite 2.9 - I already moved to the latest version of builder-vite on Vite 2.8

Please create an issue in Vite (if there is some way to have a smaller repro, that is great, if not, at least a GitHub or StackBlitz repro with the setup above). I haven't seen any report like this so far.

Vite 2.9 works on it's own just fine, it's specifically with regards to Storybook, hence me opening it here. I'll try to reproduce this, but could be tricky

patak pointed me to this issue on Discord. I had memory issues too but without Storybook, but I'm able to workaround it by adding back Vite 2.8's split vendor chunk strategy. Perhaps this could work here too.

@bluwy I am afraid that's something I've done first, as I wanted to keep the chunks separate, as soon as I saw the change-log. So seems like that's not it 😭

This might have been an upstream issue from the visual regression library, not vite + storybook setup specifically. There was a another issue here: https://github.com/percy/percy-storybook/issues/533, that was breaking this particular CI step, albeit with a different error. Upgrading another dependency fixed this step, so I'll be closing this for now, unless this issue comes back

Thanks for reporting back and closing the issue, @doutatsu!


Update to Numba 0.49 and make that the minimal version

This PR will wait until Numba 0.49 is released on PyPI.
As soon as that happens, I'll git merge master it, test it, and if all goes well, accept it.

The first Numba release candidate was just released:
https://numba.pydata.org/numba-doc/dev/release-notes.html
Note to self: since Numba is an optional dependency, it can't be pinned to a minimal version the way that Numpy is. I should explicitly check the version in any functions that use Numba (not the entry point—that gets called even if a user doesn't use it, which can be annoying if they have Numba 0.48 for reasons that have nothing to do with Awkward). So the check shouldn't be in register(), but it should be in something that gets called before every user-initiated action.

Numba 0.49 is now out, so it's time for this PR to be released. I've updated it to master and this CI run will determine if we're getting the new Numba on Azure. The old Numba would cause errors.

It works! Time to merge and deploy.


General code cleanup

Is your feature request related to a problem? Please describe.
There are some duplicate code in the different scanners and also some files that are not needed anymore (.ps1 and .bat files). Also there are some vulnerabilities in the requirements, so it would be advisable to update them.
Describe the solution you'd like
Move duplicated code into seperate file and reuse that file, delete no longer needed files. Update dependencies and test if everything still works.

It is would also be a good idea to get a proper understaning how to use logging in pyton and apply that to the scanner and other modules.


klayout backend

It would be great to have the tests passing on the klayout backend branch so we can compare speed of gdstk and klayout backend
here is a demo of the klayout backend
https://github.com/gdsfactory/kfactory
and a branch with some work in progress
https://github.com/gdsfactory/gdsfactory/tree/kfactory
advantages

klayout has more features than gdstk (netlist tracing, drc ...) and larger user base
thanks to integer based units reduces snapping errors due to rounding errors
reduce dependencies as we already use klayout
easy to install with pip (for windows, macos and centos)
Could support easily a klayout GUI flow

disadvantages

klayout API harder to use
klayout is a bit slower than gdstk

@sebastian-goeldi
@thomasdorch
@alexsludds
@tvt173
@flaport
@SkandanC
@heitzmann
@klayoutmatthias

Of course I'm a little biased towards gdstk, :) but I'd point out that gdstk also supports pip install now (thanks to @joamatab) and I'm not sure about using integer based units. I've tried to use fixed-point arithmetic before settling to floats, but the performance was way worse (by not using specific hardware and instructions for it and increasing register pressure on the integer path). I'm honestly curious to see how the implementations compare side-by-side on complex geometries.

@heitzmann  Give me an example you want to test the speed for and I can write you a klayout equivalent ;).
The main reason for me to insist on integer based is this test/example: https://github.com/gdsfactory/kfactory/blob/3d22a157bf4255db56081b1fc7f6184cbd8fa3f8/tests/test_ports.py#L38 . If you have something that isn't on-grid and you do a transformation, you will round in the opposite way and then need to do fixing/merging/healing to make sure you don't have a 1 database unit gap. But if you need to do healing & fixing, might as well import the reference, flatten and add to the polygon(s).

@sebastian-goeldi Agreed. But wouldn't that also happen if you used a rotation instead of just translating? This looks more of a problem of limited representation of numbers on a computer… you could just as easily treat floating points as a non-uniform grid of representable numbers. Because of the non-uniformity, you lose the exact translation (your point), but gain in accuracy (depending on the range, of course) and in speed due to modern CPU architecture. I'm not saying I'm against the move towards klayout; I'm just pointing out what I found from my experience.
Unfortunately, I don't have a large layout I could openly share due to NDAs to benchmark the speed, but gdstk has a few simple benchmarks I've used to compare with gdspy. Maybe they are enough for us to have an idea.

@sebastian-goeldi Agreed. But wouldn't that also happen if you used a rotation instead of just translating?

Correct. This is actually a rotation and not a translation (well, it is both, but afaik gdsfactory also does this, or at least used to do it this way ;)). And that's exactly my point. Due to the nature of having to round, if you are on the rounding border (in this case that would be the 0.5 * dbu), you can always get slight inaccuracies when applying a transformation, and then you will probably round one up and one down. In this case you have the transformation in x with -20.0005, which will get rounded to -20.001, but the waveguide is exactly 20 long and therefore you end up with a 1 nm gap.
As for testing, I just tested the floating vs integer based ones with a golden spiral. Difference is negligible (I suspect because on insertion to the actual cell, shapes get converted to integer based represenations).
(kf) sgoeldi@hyper:~/repos/kfactory/tests$ python -m timeit -r 100 -n 1 -s 'from test_spiral import test_spiral' 'test_spiral()'
1 loop, best of 100: 39 msec per loop
(kf) sgoeldi@hyper:~/repos/kfactory/tests$ python -m timeit -r 100 -n 1 -s 'from test_spiral import test_dspiral' 'test_dspiral()'
1 loop, best of 100: 39.8 msec per loop

this produces a sprial like this

I will try to implement a similar thing in gdstk and then compare

We almost have finished the kfactory (klayout backend) based evaluation for gdsfactory
see branch
How can we fix route-manhattan?
I would need some help @sebastian-goeldi @SkandanC
TODO;

[ ] Fix route manhattan
[ ] Run tests as a way to compare speed

Ideally we would most tests in this branch passing
https://github.com/gdsfactory/gdsfactory/tree/kfactory3
@SkandanC
@sebastian-goeldi


Device Idle state constraint cannot be set

Not able to set device idle state constraint. I mean there is no configuration equivalent to setRequiresDeviceIdle(boolean requiresDeviceIdle). Available constraints are Constraint.ON_ANY_NETWORK Constraint.DEVICE_CHARGING Constraint.ON_UMMETERED_NETWORK

Would also find this feature useful.  We run core features periodically in the background, and
those are persisted across device reboots -- but we don't want the background job to run when
the app is active in the foreground (resource contention skews result metrics etc).  By simply
having the ability to specify that the device needs to be idle, we prevent the conflict without
having to jump through hoops to try to cancel one or the other of the (foreground/background) jobs (or check state with all the attendant opportunities to introduce bugs) in different threads or worry about accidentally cancelling the background job persistence across reboots.  In short, a very useful flag to easily provide a safe and extremely simple way to force either/or on the fg/bg job.

I know I am super late, but now there is Constraint.DEVICE_IDLE. Whoever maintain this might want to close this.


ContactModel1D: Fix compilation with LLVM, fix unittests with clang

Fixes compilation issue introduced in #1015
Following #1024, we should also see CI status going green for clang on GitHub Actions

This is ready for merging now. I managed to fix the unittest locally but it still fails on the buildserver. After spending a day on it, I deactivated the failing test for Clang to make the buildserver pass. I managed to track it down to a double corruption which appears to come from boost's unittest framework. Let's leave #964 open and resolve the issue at a later date.

Python bindings of get_active_set and get_inactive_set.
Deprecation of Python bindings of get_active and set_inactive.

get_active and set_active are not directly exposed, but as a property of the class. As thus my plan was to not directly expose get_active_set and set_active_set either but at the next version increase switch which methods are bound to the property. Otherwise we'd end up with an inconsistent API where some things are a property and others are getters/setters. What are your thoughts?

It also seems to me that we need to disable the printing of warning messages (due to deprecation of functions in 2) during the Python bindings compilation.

Indeed, I already had this as part of another PR I am preparing (and which triggered the other prepatory PRs). I can cherry-pick that commit to this branch to get it in sooner.

get_active and set_active are not directly exposed, but as a property of the class. As thus my plan was to not directly expose get_active_set and set_active_set either but at the next version increase switch which methods are bound to the property. Otherwise we'd end up with an inconsistent API where some things are a property and others are getters/setters. What are your thoughts?

What do you mean with "methods are bound"? (I don't understand this comment).
Furthermore, we could call this attribute as active_set in Python as well.
Therefore we deprecate active one.

I've created a set-converter and exposed StdSet_String as well as the new signatures as active_set/inactive_set. The StdSet data structures are picklable. I did not get the visitor for operations on the exposed data type to work, so this will have to be future work.
The PR is ready for merge

Thanks @wxmerkt for this effort ;)


Fix assertion error of std::string, in testValue

std::string cannot be constructed from nullptr. With libstdc++, that throws an assertion.

This PR should fix the segfault reported at https://github.com/vector-of-bool/vscode-cmake-tools/issues/210.

Thanks.  Ported to GitLab PR 1096.  Please see CONTRIBUTING.rst for the preferred contribution path.


Windows arm64

Would be worth trying a build and then a tag if it works.
I can try here  on both amd64 and arm64.
in ci windows amd64 is enough to compile to windows arm64 ..
arm64 is a real thing . It Qualcomm and is Microsoft taking on Apple for the high power , long battery life laptop market .
win 11 arm is stable and identical to the amd64 offering .

related: # 5170


Allow NPM use for install/build

Related to #138.
https://github.com/rails/jsbundling-rails/pull/179 was merged, so let's align the behaviors

Flagging since I believe this introduces a subtle bug when having bun installed but a package-lock.json file (attempts to use bun). I've moved over a fix:
https://github.com/rails/cssbundling-rails/pull/144
Also - opened a PR for jsbundling-rails here: https://github.com/rails/jsbundling-rails/pull/180

that's indeed better and more readable, I'll close this one :) Thanks!


[OA] Add cluster env vars doc to intro workspace template

Add example for how to use cluster env vars

This is ready for review.


Withdrawal proof cache

Motivation
To withdraw from an OP stack chain, a user needs to provide a proof on L1 that a withdrawal was included on-chain on L2. To do this, eth_getProof is called to prove a storage slot on the withdrawal contract against an output root.
On Reth, eth_getProof is really expensive due to no historical tries being stored. To prove at an old block, old state is reconstructed in-memory using changesets. The further back you go, the more expensive this operation is, which is why it is [restricted] in Reth.
We could increase this maximum, but it would likely be too impractical to run a node with the resources necessary to actually compute historical proofs on a 1s blocktime chain with activity, gigagas or not.
To solve this, we are going to build an ExEx.
Proposed solution
We will build an ExEx that computes withdrawal proofs and caches them in a separate database. The eth_getProof RPC method is replaced with one that first checks this cache, and thereafter computes a historical proof as usual with the normal constraints on how far back you can go.
The ExEx will look for any new withdrawals and store these. Then, every time an output root is posted on L1, non-proven withdrawals are proven and the resulting proof is stored in the cache.

After internal discussion, it seems like we can introduce a satisfactory workaround to avoid the headache of managing additional cache/state. Per @onbjerg's investigation, the only fields from eth_getProof response needed for withdrawals are storage_root and storage_proofs. Since the rest of the state is not needed, we can simply compute the storage proof and corresponding root and expose that through new eth_getStorageProof RPC endpoint. This endpoint can have much more lax limitations on historical state loading.
Here's a plan for implementing this:

Extend StorageRootProvider with new storage_proof method
https://github.com/paradigmxyz/reth/blob/c35b8beb35594bb3192caec7d4335ca567d45539/crates/storage/storage-api/src/trie.rs#L42-L49

fn storage_proof(&self, address: Address, slot: B256) -> ProviderResult<StorageProof>;

Extend EthApi new RPC endpoint eth_get_storage_proof

pub struct StorageProofResponse {
  root: B256,
  proof: EIP1186StorageProof,
}

#[method = "getStorageProof"]
async fn get_storage_proof(&self, address: Address, slot: JsonStorageKey, block_number: Option<BlockId>) -> RpcResult<StorageProofResponse>;

Modify the relevant OP stack component to call eth_getStorageProof instead

Moved this over to Odyssey https://github.com/ithacaxyz/odyssey/issues/72


Export climate status and target temperature to Prometheus

Description:
Export climate status and target temperature to Prometheus.
Checklist:
If user exposed functionality or configuration variables are added/changed:

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

If the code communicates with devices, web services, or third-party tools:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] New dependencies have been added to the REQUIREMENTS variable (example).
[ ] New dependencies are only imported inside functions that use them (example).
[ ] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[ ] New files were added to .coveragerc.

If the code does not interact with devices:

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

Hi @hudashot,
It seems you haven't yet signed a CLA. Please do so here.
Once you do that we will be able to review and accept this pull request.
Thanks!


add css course

Fixes Issue
Closes #1929
Changes proposed
Add New Link On Css Course Youtube Playlist
Screenshots

Note to reviewers
Im first time contribute on LinksHub if make any mistake or need any change please report me. Thanks

Hi @huzaifaalmesbah. Welcome to LinksHub! :) We don't accept spam pull requests, so I'm putting yours in draft mode so I can review your issue. In the future, please wait until your issue has been approved and assigned to you before you submit a pull request. Refer to our Contributing Guide to learn how to effectively contribute to the project. Happy Contributing! 😊

Hi @huzaifaalmesbah. Welcome to LinksHub! :) We don't accept spam pull requests, so I'm putting yours in draft mode so I can review your issue. In the future, please wait until your issue has been approved and assigned to you before you submit a pull request. Refer to our Contributing Guide to learn how to effectively contribute to the project. Also, always fill out every section of the pull request form. It helps maintainers and others understand how to go about reviewing your contribution. For more tips, check out Writing Your First Pull Request: Tips, Best Practices, and AI-Powered Tools for Success. Happy Contributing! 😊

@CBID2  Thanks For Review. Create issue and update PR please check and if need any changes give reports. Thanks

@Anmol-Baranwal i update please check.

Thanks @CBID2
i commit.


feat(derive): holocene buffer flushing

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#575  👈
#567
#566
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @refcell and the rest of your teammates on  Graphite


Scala example on website doesn't compile

I don't know if this is the best place to communicate this, but I tried copy-pasting the only Scala example in the website and it doesn't compile.
I got it to compile by doing what's described below. I'm not sure whether that was the right fix (later I get a core dumped that I'll post in a separate issue). This is just a heads up for you guys to be aware of the problem with the website.
Environment info
Operating System:
Ubuntu 16.10 amd64
Compiler:
sbt
Package used (Python/R/Scala/Julia):
Scala package
scalaVersion 2.11.8
MXNet version:
"ml.dmlc.mxnet" % "mxnet-full_2.10-linux-x86_64-gpu" % "0.1.1"
Error Message:
sbt compile ~/repos/mxnet-playground 0 10:56:28
[info] Loading global plugins from /home/dani/myconfigs/.sbt/0.13/plugins
[info] Set current project to mxnet-playground (in build file:/home/dani/repos/mxnet-playground/)
[info] Compiling 1 Scala source to /home/dani/repos/mxnet-playground/target/scala-2.11/classes...
[error] /home/dani/repos/mxnet-playground/src/main/scala/playground/MRE.scala:7: not enough arguments for method apply: (v1: Map[String,Any])ml.dmlc.mxnet.Symbol in trait Function1.
[error] Unspecified value parameter v1.
[error]   val fc1 = Symbol.FullyConnected(name = "fc1")()(Map("data" -> data, "num_hidden" -> 128))
[error]                                                ^
[error] one error found
[error] (compile:compileIncremental) Compilation failed
[error] Total time: 2 s, completed Jan 5, 2017 10:56:43 AM

Minimum reproducible example
import ml.dmlc.mxnet._

object MRE extends App {
  val data = Symbol.Variable("data")
  val fc1 = Symbol.FullyConnected(name = "fc1")()(Map("data" -> data, "num_hidden" -> 128))
}

Steps to reproduce
or if you are running standard examples, please provide the commands you have run that lead to the error.

Clone https://github.com/danimateos/mxnet-playground/tree/broken
sbt compile

What have you tried to solve it?
I removed the () in
  val fc1 = Symbol.FullyConnected(name = "fc1")()(Map("data" -> data, "num_hidden" -> 128))
  val act1 = Symbol.Activation(name = "relu1")()(Map("data" -> fc1, "act_type" -> "relu"))
  val fc2 = Symbol.FullyConnected(name = "fc2")()(Map("data" -> act1, "num_hidden" -> 64))
  val act2 = Symbol.Activation(name = "relu2")()(Map("data" -> fc2, "act_type" -> "relu"))
  val fc3 = Symbol.FullyConnected(name = "fc3")()(Map("data" -> act2, "num_hidden" -> 10))
  val mlp = Symbol.SoftmaxOutput(name = "sm")()(Map("data" -> fc3))

and got it to compile.

try to use the lastest mxnet version

The api has been updated.
I'll deploy the latest scala pkg to maven repository soon.

@danimateos This weekend or next week.