WIP: upgraded to alien4cloud 2.0.0-SM9

The upgraded version of this conteins samples and normative types all with versions >= 2.0.0.
Some tests do not pass because of a missing Spring class
java.lang.NoClassDefFoundError: org/springframework/core/ResolvableTypeProvider Caused by: java.lang.ClassNotFoundException: org.springframework.core.ResolvableTypeProvider
I'll investigate that when I come back from vacation.

Currently brooklyn tosca depends on an alien4cloud customized by Alex.


Migrate Threaded Binary Tree to Swift 3

@JaapWijnen Travis seems to have failed for this one.

@kelvinlauKL Hm strange, can't really see what's going wrong from the job log. Any ideas?

@vincentngo maybe any ideas what's going wrong?

@JaapWijnen looking

@JaapWijnen there is one warning, line 179.
successor.remove()
Could you also make it 2 spaces and then try to submit again? I feel like the build stalled. If it doesn't work i'll take a deeper dive.

I hope #377 fixes this. So this can be closed.


Uniques to Def

Now:
Uniques described in istructsmem package. But uniques is a part of structures (docs, records …).
Solution:
Create new uniques in appdef package

[x] Add to IDefBuilder interface new member AddUnique(name string, fields []string)

[x] Add to IDef interface new members:

[x] UniqueCount() int,
[x] UniqueByID(id UniqueID) IUnique
[x] UniqueByName(name string) IUnique
[x] Uniques(func (IUnique))

[x] new IUnique interface:

[x] Name() string
[x] Fields() []IField
[x] ID() UniqueID uint64 based identifier, see tech.design

Deprecate old uniques from istructs packages

[x]  istructs.IAppStructs.Uniques() must be deprecated and must not be used anymore (// Deprecated: + linters)
[x]  istructs.IUnique must be only one per entity (panic, tests must be refactored)
[x]  istructs.IUnique  must contain only one field (panic, tests must be refactored)
[ ]  appdef.IDef.Uniques() must be used for NEW uniques @host6

Technical design:
Unique identification
Unique has ID identifier.
During istructmem.AppStruct() preparation:

IDs for existing uniques reads from storage from Uniques system view
if new uniques exists, then

new IDs are generates and assigns to
system view Uniques updates to storage.

Storage key:

PK = ViewID + ViewVersion,
CC = definition QNameID  + field names pipe-separated concatenation.

Uniques system view implemented in istructsmem/internal/uniques package.

[x] This must provide new func PrepareApDefUniqueIDs().

Functional design:

Uniques are added after fields. Panic if some unknown field passed to new unique.
Unique name may be omitted. In this case a default unique name must be used, e.g. tableUnique01, where: table is structure entity name, 01 is unique ordered number for structure.
The order of the fields in unique does not matter. Panic if unique duplicated.
If some specific unique [a, b, c] overlaps with a more general unique [a, b], then the validation should return an error.
IUnique.Fields() returns fields in alphabetical order.

istructs.IAppStructs.Uniques() is deprecated, use appdef.IDef.Uniques()

[x] During application prepare must call new uniques.PrepareApDefUniqueIDs()
[ ] CUD validation in airs-bp3 projectors must use new uniques @host6
[x] Package istructsmem/descr must describe new uniques

All items from "Techical design" are important for users of Uniques feature, so they should be in "Functional design"
"Additional" section is an example of "Technical design"

All items from "Techical design" are important for users of Uniques feature, so they should be in "Functional design"
"Additional" section is an example of "Technical design"

OK

Unique is deprecated
Unique must be only one per entity
Unique must not be used anymore
Unique2 must be used

PR#118


docker: allow elasticsearch test image to use 512m

the heavy dependencies job bumped the ceiling which was formerly 256m. this doubles it, as we want a small image but a functional one!
24/01/24 05:03:26 INFO ElasticsearchExtension: STDOUT: [2024-01-24T05:03:26,177][INFO ][o.e.i.b.HierarchyCircuitBreakerService] [zipkin-elasticsearch] attempting to trigger G1GC due to high heap usage [258705064]
24/01/24 05:03:26 INFO ElasticsearchExtension: STDOUT: [2024-01-24T05:03:26,192][INFO ][o.e.i.b.HierarchyCircuitBreakerService] [zipkin-elasticsearch] GC did bring memory usage down, before [258705064], after [197468696], allocations [6], duration [15]

ES is strict, so whatev
bootstrap check failure [1] of [1]: initial heap size [268435456] not equal to maximum heap size [536870912]; this can cause resize pauses


Openflow updates

There's some commit weirdness here... 802c592 and 88cbc2c are the same except the second has submodule ref updates. I was trying to changes the message of 802c592 and had staged the ref updates, so I guess git created a new commit including both changes?


Support for Enums

Currently Inline snapshot doesn't seem to support working with Enums.
Example:
from enum import Enum

from inline_snapshot import snapshot

class SomeEnum(Enum):
    VAL1 = "val1"

def test_snap():
    a = SomeEnum.VAL1
    assert a == snapshot()

Running pytest --inline-snapshot=create states that the snapshot were defined, but they are actually not. I presume this is due to the behavior of repr with Enums:
repr(SomeEnum.VAL1)
"<SomeEnum.VAL1: 'val1'>"

I am not sure as to how it can be handled, but maybe some regex filtering could be applied over reprs of only Enum objects and just use the Enum value for the snapshot. Would really love this.
P.S. I am not really confident, but I'll try taking a stab at this if you fine with accepting a PRs.

I think that the regex approach might become problematic. It might work for this case but there are maybe usecases in the future where the repr string is missing some information.
A custom repr implementation which you can specialize for your type with a generic fallback to repr() might be a better solution.
a singledispatch
might be useful here.

I can do a first implementation today in the evening.

Just some thoughts.
I just mentioned plain enums above, but my actual usecase of enums is within pydantic objects. I haven't not worked with singledispatch before this, but taking a quick look at the documentation I think it works only with plain types and not with class hierarchies.
So if you planning to add support to use custom repr for certain types, then I think that the dispatcher function needs to somehow identify container objects like lists, dicts, tuples, pydantic objects and individually call the dispatcher on the items contained. That would make enums work out of the box with no changes required by the users.
But I am not sure on what we could do to handle objects with user/client specified custom repr with enums in them.

did you wrote the enum class or is it from a other library?
you could do the following, if it is your own.
from enum import Enum

from inline_snapshot import snapshot

class SomeEnum(Enum):
    VAL1 = "val1"

    def __repr__(self):
        return type(self).__name__ + "." + self._name_

def test_snap():
    a = SomeEnum.VAL1
    assert a == snapshot(SomeEnum.VAL1)

another more generic approach might be this
from enum import Enum

from functools import singledispatch
from pydantic import BaseModel

class SomeEnum(Enum):
    VAL1 = "val1"

a = SomeEnum.VAL1

class PydanticContainer(BaseModel):
    v: SomeEnum

class Container:
    def __init__(self, v):
        self.v = v

    def __repr__(self):
        # this does not work, because the f-string does no lookup of repr in the global/builtin namespase
        # return f"{self.v}"

        # repr from __builtins__ is our code_repr
        # this means that a __repr__ which uses repr()
        return repr(self.v)

real_repr = repr

@singledispatch
def code_repr(v):
    return real_repr(v)

@code_repr.register
def _(v: Enum):
    return type(v).__name__ + "." + v._name_

@code_repr.register
def _(v: list):
    return "[" + ",".join(map(repr, v)) + "]"

# this would be only changed when we convert the value to source code
__builtins__.__dict__["repr"] = code_repr

# does work for a simple Container which uses repr()
print(repr([Container(a), a, 5]))

# does not work for PydanticContainer out of the box,
# because pydantic does not look up our mocked repr
print(repr(PydanticContainer(v=a)))

# special handling for pydantic BaseModel which uses repr()
@code_repr.register
def _(model: BaseModel):
    return (
        type(model).__name__
        + "("
        + ", ".join(
            e + "=" + repr(getattr(model, e)) for e in model.__pydantic_fields_set__
        )
        + ")"
    )

# now it works
print(repr(PydanticContainer(v=a)))

output (Python 3.12.1):
[SomeEnum.VAL1,SomeEnum.VAL1,5]
PydanticContainer(v=<SomeEnum.VAL1: 'val1'>)
PydanticContainer(v=SomeEnum.VAL1)

But I would like to know if it is possible for you to add a __repr__ to your Enum (comment above), because this might be the easiest solution here.

did you wrote the enum class or is it from a other library?

Some of them are under my control and some are not. I could certain make the enums under my control to have the custom repr. But how should I go about patching the ones from custom libraries?
Is there any way I could tell inline-snapshot to use a custom repr function or how should I go about doing that?

Some of them are under my control and some are not. I could make the enums under my control to have the custom repr. But how should I go about patching the ones from other libraries?

yes, this would become a never ending story. Allowing to customize repr() for specific types (like in my code example) might be a good idea.
This has the drawback that I also have to provide custom repr() implementations for Container types like pydantic.BaseModel (if they are not using repr() in there __repr__() implementation or are implemented in C and use PyObject_Repr)
Enums would be supported by default, also inside a pydantic.BaseModel.

Is there any way I could tell inline-snapshot to use a custom repr function instead of plain repr or how should I go about doing that?

You will also be able to register custom repr() implementations for specific types.
something like:
from inline_snapshot import register_repr

@register_repr
def _(obj: MyCustomType):
    return "MyCustomType(...)"

This is currently only a plan and not implemented. But I'm confident that it will work.

hi, @RazCrimson you can test the #85 if you want.
I think it should work for your use case and you can use it now if you want.
I only want to test it a bit more before I release this feature.

Cool, I'll test it out tomorrow morning and let you know if I find any issues.

I also stepped on this issue and traced it to Enum after some debugging.
Maybe we can report something to the user if the parsing fails here?
https://github.com/15r10nk/inline-snapshot/blob/56de34bc690899f97d9ca8c7393c6b83ba137665/inline_snapshot/_inline_snapshot.py#L719-L722

As for

As for https://github.com/15r10nk/inline-snapshot/pull/85, it didn't fix my use case of enums inside dataclasses:
from dataclasses import dataclass
from enum import Enum

from inline_snapshot import snapshot

class SomeEnum(Enum):
    VAL1 = "val1"

@dataclass
class Foo:
    e: SomeEnum

def test_snap():
    foo = Foo(e=SomeEnum.VAL1)
    assert foo == snapshot()

The resulting snapshot:
    assert foo == snapshot(HasRepr("Foo(e=<SomeEnum.VAL1: 'val1'>)"))

Thank you for trying this feature branch. The good thing about the approach is that you can replace repr if you want, the bad thing is that you have to replace it sometimes if you don't want.
What is missing in your case is a custom repr implementation for data classes which recursively uses repr() for the attributes.
You can try to build one or wait a bit because I have other things to do for the next two days.
Auto import of missing names is also something I want to implement.
You can import HasRepr from inline-snapshot for now if you want.

@ttrei you issues should be fixed in #85
dataclasses are handled with a special repr() implementation

Maybe we can report something to the user if the parsing fails here?

inline-snapshot generates HasRepr(type,repr) for every object where repr() generates none parsable python code.

@ttrei you issues should be fixed in #85

confirmed, thanks!

inline-snapshot 0.11.0 supports now enum.Enum and some other types which need special handling.


[all]: openstack API debugger shows client.go:128 for all calls

Is this a BUG REPORT or FEATURE REQUEST?:
/kind bug
What happened:
I noticed that all API debug logs have client.go:128 prefix from the https://github.com/kubernetes/cloud-provider-openstack/issues/2295#issuecomment-1634366621 logs
What you expected to happen:
Logs should show the actual place of the call, e.g. in 1.25 it is:
I0713 11:50:50.686815       1 openstack_volumes.go:82]   "volumes_links": [
I0713 11:50:50.686831       1 openstack_volumes.go:82]     {
I0713 11:50:50.686845       1 openstack_volumes.go:82]       "href": "https://cinder-v3/v3/4d0477a019414ee08ad0fd11b777eee2/volumes/detail?limit=2\u0026marker=faf60902-227c-4812-ac35-fb5f1aea7e7f",
I0713 11:50:50.686863       1 openstack_volumes.go:82]       "rel": "next"
I0713 11:50:50.686877       1 openstack_volumes.go:82]     }
I0713 11:50:50.686892       1 openstack_volumes.go:82]   ]
I0713 11:50:50.686909       1 openstack_volumes.go:82] }

How to reproduce it:
n/a
Anything else we need to know?:
https://github.com/kubernetes/cloud-provider-openstack/pull/867
Environment:

openstack-cloud-controller-manager(or other related binary) version:
OpenStack version:
Others:

good catch~
you mean #867 might be the root cause or it's reference that previously it works fine?

@jichenjc it's a reference for the initial implementation. I don't know at what point it stopped to work, but for sure it works fine in 1.25.x

/assign


Missing trie node

Hi,
when trying to use "ens-lite resolve anything.eth" (after sync), the log shows:
"here Missing trie node 9b5d2e60eedde2faa09b723dec9745ad76f1cfd6dca2cb49a294e238d72163fe"
I have removed lightchaindata directory and re-synced, without success.
Thanks,
Christian

@beckel that error usually means the client is not fully synced. It could probably be made more descriptive.

Also, I'm actually not aware of any names that are currently pointing at a DNSResolver contract. Missed the window for revealing the bid for enstest.eth and didn't try again (to test it I patched my code to point directly at the resolver). If someone owns a name on the network then we could set it up to test.


Request for Go Package

It would have been amazing if we had a JSON-TO-GO package which converts our unexpected JSON to definitive Go structure.

But JSON-to-Go is written in Javascript...
There are other packages which do this in Go.


add "pending" task to re-queue unhandled messages

In svix-server's redis queue implementation, there's a spawned task to look for messages that have been "claimed" (i.e. pulled off the queue) but not ack'd or nack'd within some deadline period.
This was missing from the omniqueue version, added in this diff.

Leaving this as a draft until I add some tests to show this actually works, as well as resolve some of the FIXMEs sprinkled throughout. Most of the open questions relate to exposing things via config and similar.


Add client-side testing functionality

Should only be accessable to superadmins, by default.
May need to look into GUI mocking.

The client does not share the directory structure that the server has.
The best approach may be to make ClientTests be a server-sided thing. The server finds the scripts that are the clients, then sends them across during GUnit.load(). The client grabs the lua file, now parsed as a string, and simply runs it.

All of the tests should be stored in a table as strings. When the client runs test or test-only, it requests that table from the server. The server then pipes the tests to the client, which then runs them.


onLogin of TinacmsGithubProvider is no longer triggered

Description
onLogin of TinacmsGithubProvider is no longer called when cms enabled.
Steps to reproduce
Just setup next.js + github exactly as it is in the guide: https://tina.io/guides/nextjs/github/initial-setup/
Click to "Edit this page" button
Expected result
The base branch should be checkout, the preview mode should be activated
Actual result
Preview mode is not activated and the branch is not checked out.
Environment
MacOS
Tinacms Package Versions
├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ ├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>│ ├── UNMET PEER DEPENDENCY<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ └─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>
Tools

Tool
Version

browser
chrome

os
macos

node
v12.18.3

npm
6.14.6

NOTES
I believe that this is a degradation because of this commit: https://github.com/tinacms/tinacms/commit/6580c8afa247e3d6a1beb9d7e4967b45c130fa1e
TinacmsGithubProvider calls github.checkout on a success authorization of a base branch with gihtub.branchName, and then checkout compares it with this.branchName and does nothing, which produces the bug.

+1 this has been very confusing trying to spin up a new project locally.

@all-contributors add @c58 for bugs


Why the training process take up 100% CPU?

Hi, Why the training process takes up 100% CPU?
Does the calling the function distorted_inputs() cause that?

I meet the same question，it seems that the gpu doesn't work in this job

Hi @WuXingrui , just wait, I will upload a Pytorch implementation of the same paper.


Use path from webpacker config instead hardcoded path

I couldn't find a public method for getting Webpacker config relative path, so I just substitute Rails root path with empty string.

This gem no longer supports a webpack installation, so this isn't relevant any longer. Will work on a different way to make it easy to add TW to a webpack setup.


Implement constant variables

We may do a lot of goofy, but PR titles aren't typically goofy things.

💀

... why. There'd literally be no point to this.

Constants help solidify the prac-lang side of vyxal which is something I want to invest in

There's plenty of prac-langs without constants

But the majority of the most popular ones (Java, Scala, C, C++, Rust, C#, JavaScript and more) do.
Constants provide programmer safety, which there isn't much of in a language like this. Every measure counts.
And it may be pointless for golfing, but for longer programs it's the same as using val for 40-50% of values in scala.
"But people won't use vyxal for longer programs" maybe, maybe not. I intend for people to be able to do so if they want, and I like having options available to make the prac-lang side something people won't complain about if they use it.

🤷


Announcements

Chrome Extension Up and Running! 🎉
Includes documentation and usage instructions.
https://github.com/inesc-id/hypercerts
Now I feel like it's time to start talking about the role Ethereum will play in this.

DClaims Documentation Released
The DClaims Thesis and Extended Abstract have been released!
The thesis document comprises detailed explanations of the DClaims system, including implementation details and a comprehensive system evaluation.
The extended abstract is a summarized version of the thesis document, it is about 1/3 the length, and serves as a good system overview.


pin libffi to 3.3 to fix libgobject undefined symbol ffi_type_uint32 error in score card

Score card component is failing in test "test_boston_pipeline_from_yaml" with the error:
Traceback (most recent call last):
  File "create_score_card.py", line 295, in <module>
    main(get_parser().parse_args())
  File "/mnt/azureml/cr/j/47aea72509c5452fb23c5a4cdefed485/exe/wd/_telemetry/_loggerfactory.py", line 149, in wrapper
    return func(*args, **kwargs)
  File "create_score_card.py", line 202, in main
    wf.generate_pdf()
  File "create_score_card.py", line 254, in generate_pdf
    to_pdf(
  File "/mnt/azureml/cr/j/47aea72509c5452fb23c5a4cdefed485/exe/wd/_score_card/common_components.py", line 841, in to_pdf
    pdfkit.from_string(
  File "/azureml-envs/responsibleai-0.24/lib/python3.8/site-packages/pdfkit/api.py", line 75, in from_string
    return r.to_pdf(output_path)
  File "/azureml-envs/responsibleai-0.24/lib/python3.8/site-packages/pdfkit/pdfkit.py", line 201, in to_pdf
    self.handle_error(exit_code, stderr)
  File "/azureml-envs/responsibleai-0.24/lib/python3.8/site-packages/pdfkit/pdfkit.py", line 158, in handle_error
    raise IOError("wkhtmltopdf exited with non-zero code {0}. error:\n{1}".format(exit_code, error_msg))
OSError: wkhtmltopdf exited with non-zero code 127. error:
/usr/bin/wkhtmltopdf: symbol lookup error: /lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: ffi_type_uint32, version LIBFFI_BASE_7.0

Based on a diff of previous jobs that have passed and failed, it seems the error consistently occurs when the environment has a newer version of libffi = 3.4.2 installed.  Pinning to the older libffi = 3.3 version seems to resolve the runtime error.  It seems the docker ubuntu OS installs a certain version of libgobject that is dynamically linked to libffi, and when a newer version of libffi is installed in the conda environment some symbols have been changed which causes the runtime error.
Relevant links:
https://mail.gnome.org/archives/gtk-list/2011-November/msg00003.html
https://medium.com/@Aenon/glib-symbol-lookup-bug-in-debian-or-ubuntu-def678dab5a6
https://github.com/keeweb/keeweb/issues/1563

close reopen for CI (notebooks tests failed on second build for some reason)


Port to export to WPF

Do you plan to port the "Draw" to support WPF - WriteableBitmap instead of Winform - Bitmap ?
(I haven't found any better place where I could ask my question, hope it is appropriate as an issue?)

The fork is gone meanwhile, so I guess this is obsolete. Closing.


python311Packages.dvc-data: 2.22.6 -> 2.23.1

Diff: https://github.com/iterative/dvc-data/compare/refs/tags/2.22.6...2.23.1
Changelog: https://github.com/iterative/dvc-data/releases/tag/2.23.1
Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 273723 run on x86_64-linux 1

14 packages built:

dvc (python311Packages.dvc)
dvc-with-remotes
dvc-with-remotes.dist
dvc.dist (python311Packages.dvc.dist)
python310Packages.dvc
python310Packages.dvc-data
python310Packages.dvc-data.dist
python310Packages.dvc.dist
python310Packages.dvclive
python310Packages.dvclive.dist
python311Packages.dvc-data
python311Packages.dvc-data.dist
python311Packages.dvclive
python311Packages.dvclive.dist


Add support for optional hypertable arguments

The current hypertable options only allow for a small subset of the arguments supported by the plugin. It's relatively straightforward to add generic support for any hypertable options to be passed through.
As part of this effort, I've improved the SchemaDumper to handle the majority of persistent options that impact the final database schema.

Hello @ahorner! Thanks for contributing! It seems very useful to have all options available!  I'll review it soon.

Thanks again @ahorner! Released a minor version including the changes 🙇


added song lyrics api functionality

Ive just made the basic request feature. Still need to somehow integrate it into the bot.
Maybe make it ask the user if they need lyrics for the current playing song.

For now the bot is hosted on repl and I havent added db for storing the url of songs and for now in this .py file I am storing it in list. I will go thro your code today and merge it. Thanks a lot for the effort


An aspect system for the construct tree

(Follow-up discussion in response to #1007)
We should add an Aspect system to the construct tree, doing similar things as
Entity/Component/System systems do in games.  (I'm mostly ignoring the System
part of ECS in the rest of this discussion)
Bear with me on (inconsistent use of) the proper names, and I'm open to suggestions.
Background
EC systems have the same purpose in game/physics modeling as they do in our system: make sense of a mess of objects that
share common functionality, but for which it becomes problematic to derive a correct inheritance hierarchy. For example, a game
consists of many different "objects" in a very large list of objects, and on every game tick:

All the objects that can have physics applied to them should move.
All the objects that can collide should do so.
All the objects that have AI applied to them should do so.
All the objects that are controlled by the player have controls applied to them.
Etc.

Modeling these different aspects every object can have correctly requires a complex class hierarchy,
and sometimes even becomes inexpressible.
In our system, we have something something similar: we have a giant tree of objects (similar to the list
in game land, but hierarchically organized for added fun) that we can walk over, and we have several behaviors
that a construct can have:

Some can be rendered to CloudFormation
Some can accept Tags
Some can have dependencies added to them, or retention policies changed.

Motivation
Because we have encapsulation, if we want to go the "classic OO" route, if we wanted to expose all the
functionality of underlying constructs, we'd have to repeat all features of every encapsulated construct
at every intermediate constructs.
For example, in the following example, even though Bucket and Pipeline are
the only Taggable objects (let's say exemplified by the present of a
setTags() method), SecretBucket and BestPipeline would need to both
implement this method and forward to the correct subobjects.
┌─────────────┐
│BestPipeline │
└─────────────┘
       │
       │   ┌─────────────┐
       ├──▶│SecretBucket │
       │   └─────────────┘
       │          │
       │          │    ┌────────────────┐
       │          └───▶│     Bucket     │
       │               └────────────────┘
       │
       │   ┌─────────────┐
       └──▶│  Pipeline   │
           └─────────────┘

Even though this is strictly correct in an OO sense, there is a certain burden
associated with doing this forwarding work that will make it harder for users
to write "correct" constructs (as there will be a lot of busywork involved with
doing it), and so the most probable end result will be that users writing
constructs won't consider all potential uses which will make it unnecessarily
hard (or even impossible) to reuse their constructs.
This will probably lead to user frustration and fragmentation of the construct
ecosystem that we're hoping to foster.
Benefits
The essense of a component system is to disentangle certain aspects of an
object's behavior from its identity (whereas typical OO modeling would tie
those together).
It allows us to express commands like:

For all physics objects, do physics.
For all renderable objects, draw them onto this surface.

In our case we have the added constraint that we want to select
a subtree to apply our operations to.

For all taggable objects in this subtree, set these tags.
For all renderable objects in this subtree, render to CloudFormation.
For all objects that have a monitoring pack, collect all monitoring packs.

Current Situation
Our tree model currently has provisions for iterating over all children of
a subtree. However, we have no generalized model for applying an operation
to all nodes it makes sense to apply this operation to. Right now, we
do it in an ad-hoc fashion:

For CloudFormation rendering, we recurse through the tree top-to-bottom,
and if a construct happens to have a certain method, we'll call it.
For tags rendering we go the opposite way, iterating up the tree from a leaf to find
constructs that happen to have a certain public property and if it exists,
assume it's a set of tags that also need to be applied to us.

Never mind that the mechanism we have for tags doesn't even allow specifying
tags on an arbitrary part of the tree: it HAS to be on a construct that is
already tag-aware, otherwise there is no construct.tags.setTag() attribute to
even be called.
Proposed Implementation
We already have most of the tools necessary to achieve this solution. The only
thing we need to do is an composite way of encoding aspects to a Construct,
and some mechanism to walk the tree to do something to every construct that
a certain aspect applies to. Let's call those "visitors" for now, but we could
call them something more memorable as well (aspectors, twiddlers, what have
you). We have the question of how to match up the visitor with the aspect,
given that things like instanceof are not reliable. A string indicating
a type should do, it seems simple enough.
The following mechanism would do it:
class Construct {
    public readonly aspects: IAspect[];
    public apply(visitor: IAspectVisitor);
}

interface IAspect {
    readonly type: string;
}

interface IAspectVisitor {
    readonly aspectType: string;
    visit(aspect: Aspect);
}

Hopefully it's clear enough how apply() might work to satisfy the goals
we want.
(Normally we'd use generics to make aspect visiting typesafe, but since we don't
have generics we're going to have to do typecasting in the visitor. An
acceptable compromise.)
Example 1: Tags
So if we want to apply tags to a subtree, we can now do this (assuming some
sort of TaggableAspect class):
class Tag implements IAspectVisitor {
    readonly aspectType = 'taggable';

    constructor(private readonly name: string, private readonly value: string) {
    }

    public visit(aspect: Aspect) {
        (aspect as TaggableAspect).setTag(this.name, this.value);
    }
}

How would using TaggableAspect look from the perspective of a taggable Resource?
class Bucket {
    public readonly aspects = new Array<IAspect>();
    private readondly taggable = new TaggableAspect();

    constructor(...) {
        this.aspects.push(this.taggable);
    }

    public toCloudFormation() {
        return {
            ...
            tags: this.taggable.render()
        };
    }
}

Example 2: Rendering CloudFormation (and other synthesis)
For example:
// Resource (for example, not saying this is what we would actually
// do because we can be more typesafe, but you get it)
class Resource {
    public readonly aspects = new Array<IAspect>();
    private properties: any = {};

    constructor(...) {
        this.aspects.push(new CloudFormationRendering(this.properties));
    }
}

And in Stack we'd go:
class Stack {
    public toCloudFormation() {
        // ...
        const collect = new CollectCloudFormation();
        this.apply(collect);
        return collect.template;
    }
}

Laziness
The apply() statement as modeled right now will be applied as soon as it's
called, which (though very simple, which is a plus) requires its users to be
aware of ordering, and makes it possible to make mistakes against ordering.
I'd prefer it if we keep the CDK constructs as declarative as possible, with
as little potential to make ordering mistakes as possible.
For example:
class MyConstruct {
    constructor(...) {
        super(parent, id);

        this.apply(new Tag('name', 'Stewart'));

        // Should "Child" have the tag applied? In a declarative world, yes.
        // In an ordered world, nya nya, you should have put the statements
        // in a different order.
        new Child(this, 'Child');
    }

    public addChild() {
        // What if children get added in a method and paying attention to
        // ordering in the constructor is not good enough anymore? Do
        // we now force the parent construct to do more work to retag
        // this child?
        new Child(this, 'Child');
    }
}

// But what if it's the consumer?
const constr = new MyConstruct();
constr.apply(new Tag('color', 'yellow'));
constr.addChild();  // Did I mean for this child to be tagged?

A simple extension is make a reactive visitor system, where apply() recurses
over the children immediately, but constructs also remember all visitors that
are applied to them and will apply the visitors to any new children that get
added later. This pattern crops up a number of times already in the CDK code,
since in many places we want to be invariant against the order in which things
happen (ELBv2 example: first adding a Target to a TargetGroup and then adding
the TargetGroup to a Listener, vs first adding a TargetGroup to a listener and
then adding a Target to it -- in both cases do we want to associate open up the
appropriate SecurityGroup ports, and so an (unformalized) reactive system is in
place).
If desired, we could even make this behavior configurable:
construct.apply(new Tag('name', 'value'), {
    applyToFutureChildren: false    // Default would be true
});

cc @RomainMuller @eladb  @moofish32  for opinions

[+ @clareliguori @sam-goodwin]
A few things come to mind:
I love the game-system analogy. I think it's apt. You mention that the CDK is a bit different since it's organized as a hierarchy, but game worlds are also organized as a hierarchy! Anyway - totally relevant.
I am wondering how this interplays with what we called "Aspects" in #282. I think there's a connection but there are also a few use cases there that I am not sure this addresses? Should we merge those up?
My main feedback about the API design is that I think there's a use case to apply an aspect without explicit support from the target (i.e. I'd like to apply an aspect that traverses the tree and calculates the cost of stack). So maybe instead of IAspectVisitor#aspectType it should be IAspectVisitor#shouldApply(construct). This way, the Tag visitor would just check if the construct has a taggable property. In a sense it's more "strongly-typed".
I wonder if this removes the need to maintain a list of aspects at the Construct level. But maybe it's still useful as a general purpose mechanism... Not sure. If we leave it, can it be protected or even just encapsulated altogether by Construct (i.e. construct.addAspect(new TaggableAspect(this))).
visit should probably also accept the target Construct (I am sure that will become handy).
Laziness: I like to think about this as "attach" instead of "apply", and definitely vote for the declarative model (any order-dependent model will not hold water in my mind). The reactive solution sounds shaky... I think a phased approach would work better - perhaps we devise a phase model where aspects say in which phase they expect to be applied (currently we have one phase: "synthesis", but maybe we needed two). Maybe that's where this is connected to #282...

The advantage of the reactive method is that it will be invariant against ordering even if the visitors were to add new children. Any non-reactive system wouldn't be

First, from the tags aspect I think this makes a lot more sense. I've really struggled with tags without aspects. For some reason as I designed tags I thought we wanted to avoid putting more intelligence on Construct so I didn't go after this solution at all. However, looking through PR comments and notes I don't see it written down. So I definitely think the ECS approach will be cleaner.
I do think we are going to give up some things.

IDE's (VIM for the people with good taste) will not be able to autocomplete and inform users that resources support tags.
We are moving further from the known CFN schema. One thing that has frustrated some early adopters (and even myself a few times) is I know what the property name is in CFN, but I can't find it in CDK. Aspect concepts will definitely increase the cognitive load for many users that might be more Ops background and less dev. (I'm still in favor, but I think this is worth calling out).

I agree with @eladb, that the reactive model is shaky right now. For example, removing a tag is quite difficult with the reactive model we have today. Now I might also argue that use case should not happen very often, but I just don't have any data for it either way. The concept of phases does make sense to me, but I don't have any good feel for what we will have besides synthesis?
The other part of tags that seems to get ugly in code is what to do about initialization. Once we allow two entry points we have to resolve conflicts. For example, if a parent has a tag added after the L1 is initialized, which tag takes precedence? The reverse is also possible. L1s also support a few input formats, I haven't seen a situation where CDK alters the L1 types, but life would be easier for CDK if tag inputs were standardized. ASG will likely be a snow flake, but that's fine for just one special case.
I'm overall in favor of this design, but I definitely expect a few users that will disagree. There are definitely plenty of valuable use cases, including pre-deploy security checks that have been discussed in other threads and can be addressed here.

The advantage of the reactive method is that it will be invariant against ordering even if the visitors were to add new children. Any non-reactive system wouldn't be

I think the phased approach might be a good compromise. I realize it won’t solve the problem in the general case but I think it should suffice.
——-
I was also wondering about CloudFormation rendering- is this really an aspect? I am not sure!

I was also wondering about CloudFormation rendering- is this really an aspect? I am not sure!

I think any behavior that we want to apply to a swath of constructs (but only the ones that support it) is an aspect. Or end goal was to be cloud agnostic, so we should be able to mix AWS and GCP constructs in one tree, for example. What is the fact that some constructs render to CFN and others don't, if not an aspect?
But more general than CFN vs GCP, some constructs "synthesize themselves" and others don't. An aspect (command) could totally be "synthesize yourself to this directory".

If we want to do a definite aspect ordering, I feel it should be top-down so that aspects that apply in-place mutations (such as tags) applied lower in the tree override higher-level aspects without extra work.

I think any behavior that we want to apply to a swath of constructs (but only the ones that support it) is an aspect. Or end goal was to be cloud agnostic, so we should be able to mix AWS and GCP constructs in one tree, for example. What is the fact that some constructs render to CFN and others don't, if not an aspect?

But synthesizing an output is not "applying a behavior to a construct". It actually expects a result. In a sense, it's a synchronous operation and not just "attaching" a behavior to the tree. I feel those are things are not the same.

If we want to do a definite aspect ordering, I feel it should be top-down so that aspects that apply in-place mutations (such as tags) applied lower in the tree override higher-level aspects without extra work.

Isn't this a per-aspect behavior (and I even think that for tagging we should support both)?

I guess if we don't do "constructs have aspect objects" but feature detecting by means of "constructs have public members that we test against", this all works happily and fine in JavaScript, but how will this translate to JSII languages?

Can people write constructs with aspects in JSII?
Can people write visitors in JSII?

For the former, can we feature-detect public methods in Java from JavaScript?
For the latter, can someone in Java feature-detect a public method in JavaScript?
I think the answer to say "both of these can only be written in JavaScript" is not good enough.

Isn't this a per-aspect behavior (and I even think that for tagging we should support both)?

Yes, I suppose you're right. We do need to decide on a visiting order though, top/down or bottom/up. I was trying to think of reasons to prefer one over the other.

But synthesizing [...] actually expects a result.

Sure. I guess I was thinking of the mechanism (tree walking and applying some code to every construct) moreso that the naming and timing. The generic walking is still a useful feature to have, to implement these.
Maybe the answer is that aspects are implemented using the tree walker?

Yes, tree walking is useful, but I am not sure that interesting as a shared utility. Given a node with children, implementing a simple DFS/BFS is quite trivial. Without jsii supporting lambdas, a generic tree walker would require too much ceremony in my mind, but I don't object to it.
Bottom line, I think we should leave synthesis out of this story for now besides aiding in defining the application phases.

I was avoiding asking this question, but I do want to ask it now that the conversation has shifted. IConnectable is this an aspect? It meets a lot of the discussion above

Applies to many constructs
Is a mutation that is a not a sync call

I'll be honest I don't really like the idea of it as an aspect because I want clear control of Security Groups.

I guess if we don't do "constructs have aspect objects" but feature detecting by means of "constructs have public members that we test against", this all works happily and fine in JavaScript, but how will this translate to JSII languages?

Can people write constructs with aspects in JSII?
Can people write visitors in JSII?

For the former, can we feature-detect public methods in Java from JavaScript?
For the latter, can someone in Java feature-detect a public method in JavaScript?
I think the answer to say "both of these can only be written in JavaScript" is not good enough.

I was surprised in Typescript that public static members of a child class are not available in the parent during super(parent) for the constructor.  So that often means you can't do any prep work in cloudformation.Resource constructor based on public members in the child L1.

ping - @rix0rrr @eladb - should we revisit this soon?

The reactive solution sounds shaky... I think a phased approach would work better - perhaps we devise a phase model where aspects say in which phase they expect to be applied (currently we have one phase: "synthesis", but maybe we needed two).

Are there any use-cases for aspects running during or after synthesis? It seems to me that aspects all run prior to synthesis, perhaps the term 'phase' is overloaded here.

I agree with @eladb, that the reactive model is shaky right now. For example, removing a tag is quite difficult with the reactive model we have today.

It's not clear to me what the objections to reactive application of aspects are. How is removing a tag complicated by a reactive model? What does it mean to be declarative in this context? If you can both add and remove a tag then order and scope matters, and I don't see how phases help us here. If we guarantee a predictable order of application for existing and future children with a reactive model, is that not the simplest behavior to reason about?

I think we should move for implementing this, even though we haven't quite specced out all the use cases it could be used for.

Yes, tree walking is useful, but I am not sure that interesting as a shared utility. Given a node with children, implementing a simple DFS/BFS is quite trivial.

The aspect system I'm proposing is composed of 2 things:

A tree walking standard
A place on tree nodes to declaratively attach such tree walkers. In effect, a way to attach arbitrary behavior in a way that looks like data to arbitrary nodes in a meaningful way.

Right now, it can be used to simplify the implementation of Tags, and my spidey senses are saying we can find other uses for it in the future.

I'm going to try to answer a few questions from above and propose a slight modification of this proposal with some specifics about tags.

Laziness
The apply() statement as modeled right now will be applied as soon as it's
called, which (though very simple, which is a plus) requires its users to be
aware of ordering, and makes it possible to make mistakes against ordering.

I'd prefer it if we keep the CDK constructs as declarative as possible, with
as little potential to make ordering mistakes as possible.

I think the shaky part that @sam-goodwin is asking me about is really captured here. If apply triggers as soon as it is called we are going to have to code for a lot of challenges and non-intuitive situations. For example, should the result of the following two cases be different?
parent.apply(AddTag('hello', 'value'))
child.apply(RemoveTag('hello'))

and

child.apply(RemoveTag('hello'))
parent.apply(AddTag('hello', 'value'))

I would like these to both result in the same situation that parent has tag hello and child does not. If we move apply to synthesis instead of when called I think we can resolve the above examples to the same answer. This also means we move tag resolution to walk the tree from root to leaf instead of the current leaf to root.
Precedence
What happens when tags disagree. The example above is a simple use case. In the first design I tried to provide complete set of controls to the developer for precedence and I think that created an overcomplicated solution. Three options:

Should we pick a precedence and not enable the user to toggle this?
Should we enable some control, but not full control (such as setting a precedence integer?)?
Should we enable full control via tag properties to specify the potential situations?

In my opinion full control is too complex and not necessary for the 80 % use case. I currently took more of a full control option and I think we should eliminate it. This means removing sticky and overwrite from the current tag-manager,  propagate still makes sense and should default true.
The simplified rules for precedence then become:

Closest to me wins
Last one in wins

Closest to me is the construct has the highest priority and in a cascading fashion delegates that priority to it's nearest parent. If the construct has a tag set multiple times the last one in wins. I'm voting to not enable further user control of precedence, but I'm open to hearing use cases.
Removal
Removal in the current implementation has a special RemoveTagProps I think we should kill that and consolidate to just one interface with two aspects Tag and RemoveTag that accept the same props interface. Propagating a remove, will remove it from all children, not propagating a remove will allow the tag to propagate to children. I think that is clear enough.
Features being removed

Ability to tag an object and allow your parent to override
Ability to write a tag only if it does not exist locally already
Discoverability in IDE related to specific objects that support tags

I don't think these issues are deal breakers most developers can either write unit tests or synth templates and inspect to understand what is going to happen.

Alright, back from vacation and I have a few more questions/decisions to talk about.
Aspect API
/**
 * Aspects that can be applied to Constructs.
 */
export interface IAspect {
  readonly type: string;
  visit(node: Construct): void;
}

The main change here is that I am handing the Construct to the Aspect on visit. I think this makes the most sense, but we didn't have that design above. The reason I need the Construct for tags is I need to know about the Construct in order to determine precedence. For example, if there are 4 aspects trying to apply a tag, which one is the closest to the Construct or which one was the last one applied is difficult to answer unless I have the Construct and the list of aspects (in order).
Alternatively I did consider making Aspect extend Construct, but fundamentally I didn't think that was a good idea and ergonomically it is a bit rough.
myConstruct.apply(new SetTag('MyKey', 'MyValue'));
# versus
myConstruct.apply(new SetTag(myParent, 'MyPathId', { key: 'MyKey', value: 'MyValue' }));

Propagate
Propagate false is an interesting scenario. If the tag is applied to an L2 then there are literally no tags  that could possibly be applied to because the tags are on the children L1s. I think it makes sense that even when propagate is false if the Construct is not a Resource (L1) that we propagate the tag to any direct children resources. This logic is a bit ugly, but looks like
Propagate to Resources Only
if propagate
  then apply to all children
else if node is not a Resource
  then filter all children that are Resources
  apply to all children resources

This sounds ok, but my next question is should the tag propagate until it hits a resource or the leaf node? Obviously in our current implementation this should almost always have a Resource in the path. This would change the pseudo code to something like:
Propagate to at least one Resource
if propagate
  then apply to all children
else if node is not a Resource
  then apply to all children // regardless of resource or not

This situation has some interesting results regarding our current VPC and Subnet L2s.
├── VpcNetwork(L2)
│   ├── VPC (L1)
│   ├── IGW (L1)
│   ├── IGW Attachment (L1)
│   ├── Subnet (L2) [array]
│   │   ├── Subnet (L1)
│   │   ├── NAT (L1)
│   │   ├── Route Table (L1)
│   │   ├── Route Table Association (L1)
│   │   ├── Routes (L1)
│   │   ├── EIP for NAT (L1)

For Propagate to Resources Only the tag appears on VPC and IGW. For Propagate to at least one Resource the situation results in the same behavior as propagate: true.
Now we can say these constructs are unique, and we can override the visit function to customize this tag propagation on the L2 for subnet and vpc. However, it does bring up that the tree structure we choose can impact us. For example, should the L1 VPC actually be the parent for IGW and attachment? Should the L2 subnet have the L1 VPC as a parent? Should the EIP belong to the NAT? When I was coding this it wasn't even something I considered, but now I'm wondering if we shouldn't be aware. If we move these around now we create some very ugly upgrade paths due to logical IDs changing.
Which propagation strategy do you prefer from above? Or is there another option here? If we do nothing propagate: false on a non-resource just disappears.
Resource Public API change
When we flip tag propagation and resolution to happen at synthesis we have to open up the resource public API a bit, specifically properties need to be modified.
/**
 * Represents a CloudFormation resource.
 */
export class Resource extends Referenceable {
 // snip

  /**
   * AWS resource properties.
   *
   * This object is rendered via a call to "renderProperties(this.properties)".
   */
  public readonly properties: any;
// snip

I don't see any way around this if we are resolving during synthesis. I considered using overrides, but that seems like a horrible idea since overrides should not normally be needed. 👎
The other option is make renderProperties check aspects for tags. I didn't like this because now Construct and Resource will both know about Aspect. I felt that this was leaking a dependency out that I was unnecessary if I could only modify the properties.
Synthesis Time
I have two options to discuss here.

Have app invoke visit() cascading down the tree
Have app apply it's aspects to it's direct children (stacks). Let stacks cascade the visit() call right after locking in the toCloudFormation() call.

I prefer the second option because this means during testing you don't have to manually trigger visit() on your test stack. However, I could argue that 1 is a more pure solution.
I have a good portion of this coded and working, but I think these key decisions should be discussed. I plan to clean up the original PR tonight and push up some code to help this discussion.
Your feedback is greatly needed on the topics above.

@rix0rrr I had some code started and I thought the concept was quicker to finish to help our discussion then try to doc-code and compare. I created #1451 just for discussion, if we like the approach I roll that back into the other branch in the original PR.


Fix broken heading links.

I see, the heading links on all of the plugin pages are wrong because of the <base href="../.." /> tag. This fix looks good to me.

Thanks!


Fix issue of newline byte error causing data to be missed

There was an issue where, if the data being sent happened to contain a new line, it would be missed due to parse errors. This is a quick fix to recover if that is the issue

This change is

The data format will likely need to be updated, but this reduces the potential for error a bit. As it's not critical, we can use this branch for WDR

Tested with RLCS switches and voltage, will merge. We should keep in mind error handling for the future


Roll engine e4f46f32f1fd..1daba531872a (17 commits)

https://github.com/flutter/engine/compare/e4f46f32f1fd...1daba531872a
git log e4f46f32f1fd..1daba531872a --first-parent --oneline
2020-02-10<EMAIL_ADDRESS>Partially fix canvas vs text paint order when running on Blink/Webkit browsers (flutter/engine#16483)
2020-02-10<EMAIL_ADDRESS>Use Skia to determine "actual" font name in CanvasKit backend (flutter/engine#16504)
2020-02-09<EMAIL_ADDRESS>Roll src/third_party/dart f120417ddbfc..b158bf7bd537 (2 commits) (flutter/engine#16514)
2020-02-08<EMAIL_ADDRESS>Roll src/third_party/dart 9464eb51f539..f120417ddbfc (1 commits) (flutter/engine#16513)
2020-02-08<EMAIL_ADDRESS>Roll fuchsia/sdk/core/mac-amd64 from FLFOw... to PMcw3... (flutter/engine#16512)
2020-02-08<EMAIL_ADDRESS>Roll src/third_party/dart 4310f50edc95..9464eb51f539 (2 commits) (flutter/engine#16511)
2020-02-08<EMAIL_ADDRESS>Roll src/third_party/skia 8dad1ffd81f8..c03e6982f96f (2 commits) (flutter/engine#16510)
2020-02-08<EMAIL_ADDRESS>Roll fuchsia/sdk/core/linux-amd64 from LvSlH... to 8L7NY... (flutter/engine#16508)
2020-02-08<EMAIL_ADDRESS>Roll src/third_party/dart fd992e423ef6..4310f50edc95 (17 commits) (flutter/engine#16506)
2020-02-08<EMAIL_ADDRESS>Roll src/third_party/skia a9405c2a2967..8dad1ffd81f8 (1 commits) (flutter/engine#16505)
2020-02-08<EMAIL_ADDRESS>Roll src/third_party/skia b2031d4255e2..a9405c2a2967 (5 commits) (flutter/engine#16502)
2020-02-08<EMAIL_ADDRESS>Apply Google Java format (flutter/engine#16501)
2020-02-08<EMAIL_ADDRESS>Check Java formatting in format.sh (flutter/engine#16500)
2020-02-07<EMAIL_ADDRESS>Roll src/third_party/skia 9f3eef796f63..b2031d4255e2 (12 commits) (flutter/engine#16499)
2020-02-07<EMAIL_ADDRESS>Fix safe area reporting with transparent FlutterActivitys. (#46060) (flutter/engine#16208)
2020-02-07<EMAIL_ADDRESS>Roll fuchsia/sdk/core/mac-amd64 from fvWgE... to FLFOw... (flutter/engine#16498)
2020-02-07<EMAIL_ADDRESS>[SkParagraph] Text layout benchmarks using SkParagraph (flutter/engine#16373)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Commit queue failed; closing this roll.


[BUG] Wrong GTFS urls for MPK Kraków

Describe the bug
https://github.com/MobilityData/mobility-database-catalogs/blob/main/catalogs/sources/gtfs/schedule/pl-malopolskie-mpk-sa-w-krakowie-gtfs-1270.json contains only GTFS data for Tram and doesn't provide direct download URL. Also, it's the ZTP Kraków authority (ztp.krakow.pl) which organizes the public transport in Kraków.
To Reproduce
As above.
Expected behavior
https://gtfs.ztp.krakow.pl/ contains everything for Busses and Trams in Kraków as seperate ZIP files.
Screenshots
Not needed.
Additional context
Not needed.

Hi @divadsn! Thanks for flagging this issue. To clarify, you're suggesting the download URL for source 1270 https://transitfeeds.com/p/mpk-sa-w-krakowie/1105/latest/download be replaced with https://gtfs.ztp.krakow.pl/GTFS_KRK_T.zip and a separate source should be created for the bus URL https://gtfs.ztp.krakow.pl/GTFS_KRK_A.zip?

@emmambd Yes exactly! 😄
And the license url pointing to https://ztp.krakow.pl


vtctl: Add command WaitForFilteredReplication.

@alainjobart
Example output:
Waiting for filtered replication to catch up on tablet: cell:"cell1" uid:1  Last seen delay: 3600.1 seconds
Filtered replication on tablet: cell:"cell1" uid:1  has caught up. Last seen delay: 1.1 seconds
I've added a new field in RealTimeStats which you need to populate :-)
Please also see the TODOs I left for discussion.
Regarding the test:
This test uses as much of real code as possible. To make this work, I had to add a method to SqlQuery and disable some config options.
An alternative would be to implement the gRPC queryservice.Query RPC service directly as fake where StreamHealth would just stream a given channel.
Pros:

simpler, less fragile test

Cons:

less stuff of the real thing gets tested

Let me know if you prefer this alternative.

It's actually pretty cool you were able to use SqlQuery as is, I thought you would have to fake it over RPC like we do in the other tests where we do queries.. so thumbs up there, the SetTargetForTests is cool.
LGTM!

@alainjobart PTAL
Pleae also see my comment regarding the alternative to create a new message specifically for filtered replication stats.
As always, I recommend to go through the diffs by commit and not using the "Files changed" view.
Thanks!

I don't think we should add another structure, for just these couple fields which make sense in RealTimeStats anyway...

@alainjobart
PTAL
I've addressed all changes and adapted tabletconntest.go.

LGTM!


Missing --cpp-gen for cmd.py

The new_operator.md documentation has a section "2. Generate the C++ template code of the Custom operator from the ONNX Model (optional)" which states that a template can be generated with python -m onnxruntime-extensions.cmd --cpp-gen <model_path> <repository_dir>
The problem is that onnxruntime_extensions/cmd.py doesn't have --cpp-gen option
Was it deleted intentionally? Is there an easy way to have a template?

@wenbingl thanks, is there anyone who could help update the documentation with the correct steps? Maybe @natke?


User labels are overwritten during runtime label sync

When the runtime drivers periodically synchronises container labels, it overwrites the user provided overrides via /v1/endpoint/{id}/labels POST. This is a bug.
Relatedly, /v1/endpoint/{id} POST ignores the labels when set. This is also bug (/v1/endpoint/{id}/labels is a convenience endpoint, not the exclusive way to set the labels).

This might be fixed by the changes @rlenglet is working on for #3911 .

True, but it was @rlenglet that mentioned it in #development so it might have made his work more difficult instead?

@raybejjani yeah, I had to fix setting labels on endpoint creation, which was not working.
And in the process I realized that:

setting labels in PATCH /endpoint/{id} is not working (we are just ignoring the labels that are passed)
setting labels in PATCH /endpoint/{id}/labels is currently useless, because those are immediately overridden by the labels sync

If we fixed PATCH /endpoint/{id} it would be useless just like PATCH /endpoint/{id}/labels because of the labels sync.
I don't think there's an easy way to fix that.

Is this because the sync assumes the runtime is the source of truth for user labels as well? We also have the list of "disabled" labels that we ignore, but I'm hoping that isn't clobbered.

Not relevant anymore


Balance overflow

We set up a balance field, whose initial value is set to the total amount of the red envelope, and the balance will be reduced each time you grab it. In theory there shouldn't be a negative balance, but it does happen.
We intend to use Redis to solve the problem of read and write latency.

We set ConsistentRead = true to ensure that data is written correctly.


Render single clips as chapters in resulting movie

For navigation it would be cool to render single clips as chapters in the merged movie.
For new clips it would be nice to store even things like place from geotag and subtitle.
FFmpeg already supports this:
Adding chapters is done by editing the metadata file like FFMETADATAFILE.txt and adding sections like this:
[CHAPTER]
TIMEBASE=1/1000
START=1
END=448000
title=August 27th, 2023 - Berlin, eating bananas with friends

[CHAPTER]
TIMEBASE=1/1000
START=448001
END= 3883999
title=August 28th, 2023 - São Paulo, party with Caio

Afterwards it will be applied like this ffmpeg -i INPUT.mp4 -i FFMETADATAFILE.txt -map_metadata 1 -codec copy OUTPUT.mp4.
See also the documentation of FFmpeg.

I like the idea!
title=August 28th, 2023 - São Paulo, party with Caio 🤣


bug: item sliding options are not applying layout properly

Bug Report
Ionic version:

[x] 4.x
Current behavior:
Slotted items in an item option are not styling properly.
Expected behavior:
If the slot is top or bottom the item should be on top of or below the label
Steps to reproduce:
See the following Codepen, open the "top" and "bottom" layout items: https://codepen.io/brandyscarney/pen/VRWLOd?editors=1000
Related code:
Example of one that doesn't work:
  <ion-item-sliding>
    <ion-item>
      <ion-label>
        Sliding Item, Icons Bottom
      </ion-label>
    </ion-item>
    <ion-item-options>
      <ion-item-option color="primary">
        <ion-icon slot="bottom" name="more"></ion-icon>
        More
      </ion-item-option>
      <ion-item-option color="secondary">
        <ion-icon slot="bottom" name="archive"></ion-icon>
        Archive
      </ion-item-option>
    </ion-item-options>
  </ion-item-sliding>

Ionic info:
master

I was struggling with the same, slot="icon-only" to get bigger icons, but the text was to its right in the same big font-size. My workaround until this is fixed is wrapping with a div and a span:
<ion-item-option color="danger" (click)="delete(item)">

        <ion-icon name="trash"></ion-icon>
        Delete

</ion-item-option>

and adding the following CSS:
ion-item-option div[slot="icon-only"] {
    display: flex;
    flex-direction: column;
    align-items: center;
    span {
        font-size: 14px;
    }
}


Tree xxxxxx not found in repository and abort

Output of restic version
restic 0.9.0 compiled with go1.10.2 on linux/amd64
How did you run restic exactly?
restic -r swift:backup:/ forget --group-by paths --keep-last 15 --prune
What backend/server/service did you use to store the repository?
OVH object storage
Expected behavior
Warn about the missing object and continue the execution.
Actual behavior
[...]
2 snapshots have been removed, running prune
counting files in repo
building new index for repo
[1:49] 100.00%  1605 / 1605 packs
repository contains 1605 packs (225480 blobs) with 6.871 GiB
processed 225480 blobs: 3485 duplicate blobs, 4.761 MiB duplicate
load all snapshots
find data that is still in use for 30 snapshots
tree c649f1f83e9be8d420fd29d21cd9fb03f0e0838c86e8bf8fc6877e25738b6bb5 not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
	src/github.com/restic/restic/internal/repository/repository.go:654
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:11
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:31
main.pruneRepository
	src/github.com/restic/restic/cmd/restic/cmd_prune.go:191
main.runForget
	src/github.com/restic/restic/cmd/restic/cmd_forget.go:240
main.glob..func10
	src/github.com/restic/restic/cmd/restic/cmd_forget.go:24
github.com/restic/restic/vendor/github.com/spf13/cobra.(*Command).execute
	src/github.com/restic/restic/vendor/github.com/spf13/cobra/command.go:756
github.com/restic/restic/vendor/github.com/spf13/cobra.(*Command).ExecuteC
	src/github.com/restic/restic/vendor/github.com/spf13/cobra/command.go:846
github.com/restic/restic/vendor/github.com/spf13/cobra.(*Command).Execute
	src/github.com/restic/restic/vendor/github.com/spf13/cobra/command.go:794
main.main
	src/github.com/restic/restic/cmd/restic/main.go:86
runtime.main
	/usr/local/go/src/runtime/proc.go:198
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:2361

Steps to reproduce the behavior
Running resting forget --prune against a repo
Did restic help you or made you happy in any way?
Restic is really awesome! Thanks for developing this!

Thanks for the report, this needs to be handled better. Please be aware that it looks like a file is missing from the repository, this is unfortunately not the first time it was reported to happen with the OVH Swift backend. I'm not aware of anything we could do from restic's side of view here.

I'm aware that it seems there are problems on OVH side.
I opened this issue only for handle this error in a better way 😄

We've the same issue with s3:
# restic prune
repository a63869d2 opened successfully, password is correct
counting files in repo
building new index for repo
[5:26] 100.00%  16188 / 16188 packs
repository contains 16188 packs (84737 blobs) with 62.905 GiB
processed 84737 blobs: 9208 duplicate blobs, 1.882 GiB duplicate
load all snapshots
find data that is still in use for 112 snapshots
tree 6eb0c38dd7e85f6ae2bca0d7947cc79b482f415b9ce78bcb83cd257af86b1bff not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
	src/github.com/restic/restic/internal/repository/repository.go:654
github.com/restic/restic/internal/restic.FindUsedBlobs
	src/github.com/restic/restic/internal/restic/find.go:11
main.pruneRepository
	src/github.com/restic/restic/cmd/restic/cmd_prune.go:191
main.runPrune
	src/github.com/restic/restic/cmd/restic/cmd_prune.go:85
main.glob..func18
	src/github.com/restic/restic/cmd/restic/cmd_prune.go:25
github.com/restic/restic/vendor/github.com/spf13/cobra.(*Command).execute
	src/github.com/restic/restic/vendor/github.com/spf13/cobra/command.go:756
github.com/restic/restic/vendor/github.com/spf13/cobra.(*Command).ExecuteC
	src/github.com/restic/restic/vendor/github.com/spf13/cobra/command.go:846
github.com/restic/restic/vendor/github.com/spf13/cobra.(*Command).Execute
	src/github.com/restic/restic/vendor/github.com/spf13/cobra/command.go:794
main.main
	src/github.com/restic/restic/cmd/restic/main.go:86
runtime.main
	/usr/local/go/src/runtime/proc.go:198
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:2361

Backup started with 0.8.0, we've seen this error with 0.8.1 and even after updating to 0.9.0

@rmoriz Can you try with version 0.9.1?
Since I've upgraded Restic to this version, I do not get this error anymore (3 backups so far... can you confirm it too?)

@fab120 Still having the issue wie 0.9.1

I also have the same issue with a Backblaze B2 storage backend. How come that all these backends loose files?

Closing this as the issue is quite old and there have been several fixes which could be related to this issue. Contained in a released restic version: #2773 #2674 #1494 . To be released: #2842
Recovering from really missing trees is tracked via #1759.
Please open a new issue if the problem persists with a recent restic version.

Closing this as the issue is quite old and there have been several fixes which could be related to this issue. Contained in a released restic version: #2773 #2674 #1494 . To be released: #2842
Recovering from really missing trees is tracked via #1759.
Please open a new issue if the problem persists with a recent restic version.


Add support for the latest version of React Native for Windows

Hello @vinzscam ,
I'm starting this issue to track which is the best approach to bring support for the latest version of React Native for Windows.
Last time we chatted on this topic, you suggested to add the vNext implementation into a separate folder, to avoid breaking changes for people who might still be using the legacy C# core.
However, now that React Native for Windows supports autolinking, this option isn't feasible, because having the implementation in a folder different than "windows" would break the autolinking.
How can we move forward? I already have a working version in my fork but, before submitting a PR, I wanted to understand which is the right way to do it.
Thanks!

Hi, thank you @vinzscam for the most awesome package! :)
I just tried them both. @qmatteoq fork works perfectly. Some minor dependency changes made it work with the latest RNW 0.66.2. See here https://github.com/RamiJabr/react-native-file-viewer

Hi RamiJabr can you make it work or give us some lights on how to do it on react native windows 0.68?

@RamiJabr  can you please specify which version of react-native and react-native-windows  is compatible with react-native-file-viewer?


Fuzzing integration by way of OSS-Fuzz

Hi!
I was wondering if you would be interested in getting jsqlparser fuzzed by OSS-Fuzz? Fuzzing is a technique for stress-testing applications and OSS-Fuzz is a free service run by Google for fuzzing important open source projects, and it would be great to get jsqlparser integrated with OSS-Fuzz. OSS-Fuzz will run the fuzzers continuously and report back with bug reports when bugs are found. These reports will have full stack traces, input triggers and more. If you are interested, then the only thing needed is an email(s) connected to a Google account that can be used for receiving the bugs reports, which can be put in the configuration file (project.yaml) over at the OSS-Fuzz repository.
I have set up an initial integration with OSS-Fuzz here: https://github.com/google/oss-fuzz/pull/6746 and this PR on the OSS-Fuzz repository includes a simple initial fuzzer. We can always extend with more fuzzers if you are happy to integrate. I would just need an email and then get this PR merged, following that we should be good to go and down the line we can also migrate fuzzers from OSS-Fuzz to jsqlparser owns repository.

@DavidKorczynski So were the advantage of using your product? We are checking with each run as well.

I ran Static Code Fuzzing Tests before and I doubt that it works for JSQLParser:

the Fuzzer correctly complained about a LOT of DEFAULT constructors not enforcing NULL checks

however, there is no good way to correct those because we need exactly these Default Constructors and ALWAYS set the variables after the initiation in the JavaCC productions

The software is what it is: a automatically generated Parser. It is not really a SQL building API (although it could be used for that task too, but not in a fool-proof way.)

@wumpz am not really sure what you mean by "we are checking each run as well"? Fuzzing is essentially a genetic algorithm that will gradually explore more code coverage of the target code by mutating a given testcase.
@manticore-projects - fuzzing is dynamic and not static analysis. The goal here (in java versus other languages) would be to, e.g. identify unexpected exceptions

Hi David,
so you would like to dynamically mutate SQL statements and test if JSQLParser parses them correctly?
If so, how will you know if your statement is valid on what RDBMS?

@Wumpz: I am actually somewhat curious to try it out just to prove my expectation wrong.

What I am simply interested in is seeing whether the code:
    try {
      CCJSqlParserUtil.parse(RAND_STRING);
    } catch(JSQLParserException e) { }

will ever crash based on a RAND_STRING being any given string.
We can always try this and if you find it useful: great - if not: we can just remove the project from OSS-Fuzz. Notice other Java projects are being integrated into OSS-Fuzz, e.g. we recently found some issues in GSON json parsing

David, please what do you mean by "crash"?
Your example will either
a) parse correctly when the SQL is correct and the Parser understands the SQL
b) throw an error when the SQL is correct but the Parser does not understand the SQL (yet, e.g. missing feature)
c) throw an error when the SQL is incorrect
Nothing of that was a "crash", it just would throw a Parse Exception.
On top of that it might be possible to throw a NPE when build a Statement from Java Code.

Crash in this case simply means throwing an unexpected exception. The goal is to catch all that the function is expected or promises to throw and then use the fuzzer to test that this is indeed the given case.

@wumpz : If you ask me, let them try. Its a win win situation: Either they find something, then we will be grateful and I would lose my wager. Or we just will get the expected Parser Exceptions and can sleep well at night.

So why not. But as @manticore-projects already explained, the parser is what it is. Even if your RAND_STRING does produce some kind of valid SQL, if JSqlParser throws an Exception, how do you know, that this Exception is invalid?
With "checking each run" I ment, that tests are running every time a build is made. I said this because I had the impression, that OSS-fuzz would run not every time, but now I think you are triggering each commit.

However, how are the methods specified you are testing? The parser itself has a lot of stuff in it, that is simply generated and does not need to be tested, at least from JSqlParser dev.
How to you specify the tested Strings (SQLs) or do you indeed use randomly generated String?

Closed, since no further question has been asked.


There is no indicator for size in map analysis view

Is your feature request related to a problem? Please describe.
On the map analysis screen, indicators for color are present but not indicators for size
Describe the solution you'd like
An indicator for size should also be displayed on the main screen. In this case, there is a possibility that the main screen may not be displayed properly and we should consider it.
Describe alternatives you've considered
For a minimum requirement, it should display which measure the size is represented by.
Additional context

@i1befree @kyungtaak
크기의 표현과 구현방법에 대해서 고민하여, 안을 공유드리겠습니다.


Feat: Implement change password during login

To support -z switch for sqlcmd

Codecov Report

Merging #141 (735f602) into main (514012a) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #141      +/-   ##
==========================================
+ Coverage   74.61%   74.63%   +0.01%
==========================================
  Files          31       31
  Lines        6193     6197       +4
==========================================
+ Hits         4621     4625       +4
  Misses       1295     1295
  Partials      277      277

Files Changed
Coverage Δ

tds.go
71.97% <100.00%> (+0.12%)
:arrow_up:

Fixes #140


Export to Bodymovin format

Bodymovin format is used by https://github.com/airbnb/lottie-android
Also see : https://github.com/romannurik/AndroidIconAnimator/issues/99

Thanks for filing! Will definitely add this as an option! :)

For future reference, here is a Twitter thread that has some good information: https://twitter.com/airnanan/status/862137455096594432

@alexjlockwood Any update on this?

So I just found this https://github.com/flutter/flutter/tree/master/dev/tools/vitool - also we are not supposed to use it. Maybe we can just use it :)
Did anyone try this?


Support for the CRWD API calls we need via internal library

This is perfect! I'll work on testing this more fully once we have functional CRWD API keys.


[Bug]:

Preflight Checklist

[X] I agree to follow the Code of Conduct that this project adheres to.
[X] I have searched the issue tracker for an issue that matches the one I want to file, without success.
[X] I am not looking for support or already pursued the available support channels without success.

Version
1.0.3
Installation Type
Official SaaS Service
Service Name
DongTai-Web
Describe the details of the bug and the steps to reproduce it
删除项目和探针之后，组件管理列表这些内容还存在，按理说会跟着删掉。

Additional Information
No response
Logs
No response

After the project is deleted, the relevant data will not be deleted; after the probe is deleted, the components and vulnerability data related to the probe will be deleted. Please confirm that the probe corresponding to the undeleted component data has been deleted, and then feedback.

我删掉未运行的探针就可以了，谢谢


Don't get list of class members and methods for object

Description
I recently downloaded Spyder from Anaconda b/c I would like to use some of the new features in Pandas. Previously, I've been using a version of Spyder from several versions ago (2.2.5). The old version had nice feature that let me figure out what members and methods belonged to an object. Basically, after I defined an object (like a numpy array) and put a "." after the object, a little window would appear that would show the list of members and methods that belonged to the object. I'm not seeing this feature in the new version of Spyder and it's really killing my productivity.
What steps will reproduce the problem?

import numpy as np
x = np.array([1,2])
x.

What is the expected output? What do you see instead?
I expect to see a list of available methods for the object x in the editor and in the python terminal. In the older version of Spyder, I see a scroll-able dropdown that has:
all
any
argmax
argmin
...
I'm not seeing anything in the new version of python.
Please provide any additional information below
Version and main components

Spyder Version: 3.2.3
Python Version: 2.7.13
Qt Versions: 5.6.2, PyQt5 5.6 on Windows

Dependencies
pyflakes >=0.5.0  :  1.5.0 (OK)
pycodestyle >=2.3 :  2.3.1 (OK)
pygments >=2.0    :  2.2.0 (OK)
pandas >=0.13.1   :  0.20.3 (OK)
numpy >=1.7       :  1.13.1 (OK)
sphinx >=0.6.6    :  1.6.3 (OK)
rope >=0.9.4      :  0.10.5 (OK)
jedi >=0.9.0      :  0.10.2 (OK)
nbconvert >=4.0   :  5.3.1 (OK)
sympy >=0.7.3     :  1.1.1 (OK)
cython >=0.21     :  0.26.1 (OK)
qtconsole >=4.2.0 :  4.3.1 (OK)
IPython >=4.0;<6.0:  5.4.1 (OK)
pylint >=0.25     :  1.7.2 (OK)

Ok. Scratch that. The information is showing up in the editor. It's not showing up in the console.
Here's a more relevant example:
import openpyxl
pathToExcel = 'myDirectory/myFile.xlsx'
wb = openpyxl.load_workbook(pathToExcel, data_only=True)
es = wb.get_sheet_by_name(excelSheet)
es.
And I see nothing after the '.', which should have methods like rows, etc...

You need to press the Tab key to get completions in the console. Unfortunately we can't provide automatic completions in the console for now, sorry.


feat: follow_fast_check_modules option to walk all specifiers

Previously, when a slow type was added to a file, fast check was skipped and all specifiers were checked. This new option adds the ability to check all specifiers anyway, if toggled.
Towards fixing https://github.com/denoland/deno/issues/23023

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[Bug]: Data-Geographic Areas: diacritics not rendering

Steps to reproduce the bug
1.Go to Data, Geographic Areas
2.Type in Vietnam
3.See Adm1s under Children

Some (but not all) diacritics are not rendering properly. The character rendering is also reflected in the filter results.

These Adm1s are not represented in our data.  For example, there are no special characters in our Adm1 data on AntWeb for CASENT0178557. And we have no Adm1s entered for CASENT0718547 or CASENT0104301.
https://www.antweb.org/specimen.do?name=casent0178557
https://www.antweb.org/specimen.do?name=casent0178547
https://www.antweb.org/specimen.do?name=casent0104301

@bpescador, @chrisgrinter, @rich-keller
...

Screenshot

AntWeb screenshots:
no diacritics

no Adm1

Expected behavior
No response
Additional Screenshots
No response
Environment
Sandbox
Sandbox Used
No response
Version
build 9bc0de664 on 2023-06-08T23:14:02Z
Browser Used
Chrome Version 114.0.5735.110

You will need to make sure all your incoming data are UTF-8 encoded.  Please reopen if this is not the issue.

Meh, sorry, this may be us.


Updating R notebook 105

Updating R notebook 105 to include record table, sparklyr and field selecting utility example.
Changes to notebook since last review - ran to ensure working

Install sparklyr to fix r update
example of Exporting data in PLINK phenotype format added to the end of notebook - in current 105 notebook

Update cost estimate in ReadMe to reflect Notebook estimates.

Update cost estimate in ReadMe to reflect Notebook estimates.

Run info added to ReadMe


⚠ Faculté génie website (prod) has degraded performance

In c69171a, Faculté génie website (prod) (https://www.usherbrooke.ca/genie/) experienced degraded performance:

HTTP code: 200
Response time: 946 ms

Resolved: Faculté génie website (prod) performance has improved in f306c15.


Added us133 scenarios that were removed

Acceptance tests. Reintroducing US133 Scenarios

Looks fine to me happy to :+1:


ProcessBuilder

hey,
dont know exactly when it changed but the used ProcessBuilder inside the Indexer is now located somerwhere else
#use Assetic\Util\ProcessBuilder #old;
use Symfony\Component\Process\ProcessBuilder; #new

Could you change it?
If not i would create a new Fork
Greetings,
Nico

I'm noticing the same issue.  And there appears to be a pull request that fixes the issue.  But it's pretty old.


RSpec/UnspecifiedException appears to trigger if the subject function is named raise_exception

It seems like the RSpec/UnspecifiedException cop should not be triggered on the following code, but it is:
require "spec_helper"

class Foo

  def raise_exception
    raise StandardError, "huh"
  end

end

describe Foo do
  let(:subject) { described_class.new }

  describe "#raise_exception" do
    it "throws a StandardError" do
      expect { subject.raise_exception }.to raise_error(StandardError)
    end
  end
end

In particular, the cop highlights subject.raise_exception as violating the cop, which doesn't make sense - the cop should be looking it how we handle the exception, yeah?

raise_exception sounds like it’s an internal class api, a private method. Is it?
To fix the cop, I see two options:

Break on non-send nodes here.
Add a check that the receiver is implicit (nil) here

Would you like to submit a pr?

In our code, it is a public method (obviously not public public, but y'know).  I will take a look at this tomorrow (US Central) and see if I can submit a PR myself. :)

I am having trouble understanding how to implement this fix, sorry. I don't fully understand the parsing abstractions being done, and I have no experience here. :( I will try to stare at it some more, but I feel like I am out of my depth here.

This is really easy, as in either case you won’t have a o dig i to the abstract syntax tree or node patterns.
Just write a spec for two cases, and set breakpoints to those places i’ve referenced above.

This iterates from the send node (the statement that is a method call) up through all the method calls. Since RSpec is all DSL, a lot will be “send” nodes. But some will be send nodes wrapped in block nodes, which is eg expect { raise_exception }. As soon as we encounter a “block” node, we need to break from the cycle, as this is not the raise_exception we’re after, since it’s not called on the expect { … }.to. Basically, remove the :send argument from each_ancestor to avoid filtering only on those “send” nodes, and break as soon as you encounter a “block” node. You can check it with ancestor.block_type? and ancestor.send_type?.
Check if the node.receiver.nil? and return otherwise (the case you’ve described when there’s an explicit receiver)

You can implement either fix or both. Please let me know if you need more details, and please don’t hesitate to ask if you get stuck.

Thank you for this explanation! I apologize for not responding sooner - I have had a lot going on. I would be happy to take a look at doing a quick PR. I did get as far as creating a failing test case, at least. :)On Aug 14, 2024, at 1:36 PM, Phil Pirozhkov @.***> wrote:
This is really easy, as in either case you won’t have a o dig i to the abstract syntax tree or node patterns.
Just write a spec for two cases, and set breakpoints to those places i’ve referenced above.
This iterates from the send node (the statement that is a method call) up through all the method calls. Since RSpec is all DSL, a lot will be “send” nodes. But some will be send nodes wrapped in block nodes, which is eg expect { raise_exception }. As soon as we encounter a “block” node, we need to break from the cycle, as this is not the raise_exception we’re after, since it’s not called on the expect { … }.to. Basically, remove the :send argument from each_ancestor to avoid filtering only on those “send” nodes, and break as soon as you encounter a “block” node. You can check it with ancestor.block_type? and ancestor.send_type?.
Check if the node.receiver.nil? and return otherwise (the case you’ve described when there’s an explicit receiver)
You can implement either fix or both. Please let me know if you need more details, and please don’t hesitate to ask if you get stuck.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Hey! I tried implementing both of these like this in Rspec::UnspecifiedException:
        def find_expect_to(node)
          return if node.receiver.nil?

          node.each_ancestor.find do |ancestor|
            break if ancestor.block_type?

            next unless ancestor.send_type?

            expect_to?(ancestor)
          end
        end

and added the following tests to the spec:
    it 'allows a subject function to be named raise_exception' do
      expect_no_offenses(<<~RUBY)
        def raise_exception
          raise StandardError
        end

        expect {
          raise_exception
        }.to raise_error(StandardError)
      RUBY
    end

    it 'allows a subject function to be named raise_error' do
      expect_no_offenses(<<~RUBY)
        def raise_error
          raise StandardError
        end

        expect {
          raise_error
        }.to raise_exception(StandardError)
      RUBY
    end

This caused my new test cases to pass, but it caused several regressions in the UnspecifiedException suite. Among others, this test failed:
    it 'detects the `unspecified_exception` offense' do
      expect_offense(<<~RUBY)
        expect {
          raise StandardError
        }.to raise_error
             ^^^^^^^^^^^ Specify the exception being captured
      RUBY
    end

with this message:
0) RuboCop::Cop::RSpec::UnspecifiedException with raise_error matcher detects the `unspecified_exception` offense
     Failure/Error: super

       Diff:
       @@ -1,5 +1,4 @@
        expect {
          raise StandardError
        }.to raise_error
       -     ^^^^^^^^^^^ Specify the exception being captured

     # ./spec/support/expect_offense.rb:17:in `expect_offense'
     # ./spec/rubocop/cop/rspec/unspecified_exception_spec.rb:6:in `block (3 levels) in <top (required)>'

Apologies for the dump - I am still fairly new with Ruby, and in particular, the internals of RuboCop.

@aarestad I believe that @pirj was meaning you should implement one of those fixes, not both of them, and it seems that option 1 is the better way to go: if you remove the return if node.receiver.nil? (aka option 2) then for me locally all the tests pass, indicating you've fixed the issue 🎉
Also two tips I've learnt from my contributions:

there's a sort-of-bug in how the assertions work which is why you end up with Failure/Error: super - you can see the real error by commenting out expect_offense and expect_no_offenses in spec/support/expect_offence.rb

(I'm not a core maintainer of RuboCop nor have I extensively tested the whole plugin with this change, so there is probably a very legit reason for this code, and generally anyway most of the time the error is "offense was/wasn't raised when it shouldn't/should be")

you can inspect the AST using puts RuboCop::AST::ProcessedSource.new(File.read('script'), 2.7).ast.inspect (make sure to require 'rubocop/ast':

rubocop-rspec on  master [$!?] via 💎 v3.1.4
❯ cat script
def raise_exception
  raise StandardError
end

expect { raise_exception }.to raise_error(StandardError)
expect { raise StandardError }.to raise_exception

rubocop-rspec on  master [$!?] via 💎 v3.1.4
❯ ruby print-ast.rb
s(:begin,
  s(:def, :raise_exception,
    s(:args),
    s(:send, nil, :raise,
      s(:const, nil, :StandardError))),
  s(:send,
    s(:block,
      s(:send, nil, :expect),
      s(:args),
      s(:send, nil, :raise_exception)), :to,
    s(:send, nil, :raise_error,
      s(:const, nil, :StandardError))),
  s(:send,
    s(:block,
      s(:send, nil, :expect),
      s(:args),
      s(:send, nil, :raise,
        s(:const, nil, :StandardError))), :to,
    s(:send, nil, :raise_exception)))

You might have already figured these out but since you mentioned this was the first time you'd worked with the Rubocop code, I figure no harm in sharing as those two things were probably the most impactful to figure out when I was getting started 🙂

I've confirmed locally as well that this fixes #1954 - @aarestad feel free to include a third spec for that if you want, otherwise I'm happy to do a new PR after yours adding a spec to showcase its fixed and to prevent regression in the future

Huh - I could have sworn I tried to do them each on their own. Looks ok - I am going to create a PR now. Thank you all for checking my work in advance :)


gobby5: fix build

Motivation for this change
Had to update it to unstable in order to be able to build with the current libinfinity.
I also had to switch libinfinity to gtk3, since gtk2 support was removed. While at it, I modernized the package a bit.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

cc @Phreedom (maintainer)

Success on x86_64-linux (full log)
Attempted: gobby5, libinfinity
Partial log (click to expand)
glibPreFixupPhase
post-installation fixup
Wrapping program /nix/store/3x5gx11pkrbarygiazqiw7d59wh5cbfh-gobby-unstable-2018-04-03/bin/gobby-0.5
shrinking RPATHs of ELF executables and libraries in /nix/store/3x5gx11pkrbarygiazqiw7d59wh5cbfh-gobby-unstable-2018-04-03
shrinking /nix/store/3x5gx11pkrbarygiazqiw7d59wh5cbfh-gobby-unstable-2018-04-03/bin/.gobby-0.5-wrapped
gzipping man pages under /nix/store/3x5gx11pkrbarygiazqiw7d59wh5cbfh-gobby-unstable-2018-04-03/share/man/
strip is /nix/store/1hi76hr87bd1y1q1qjk0lv8nmcjip1c8-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/3x5gx11pkrbarygiazqiw7d59wh5cbfh-gobby-unstable-2018-04-03/bin
patching script interpreter paths in /nix/store/3x5gx11pkrbarygiazqiw7d59wh5cbfh-gobby-unstable-2018-04-03
checking for references to /build in /nix/store/3x5gx11pkrbarygiazqiw7d59wh5cbfh-gobby-unstable-2018-04-03...

Failure on aarch64-linux (full log)
Attempted: gobby5, libinfinity
Partial log (click to expand)
   Compiling rls-span v0.4.0
   Compiling rls-data v0.15.0
   Compiling rustc_errors v0.0.0 (file:///build/rustc-1.27.0-src/src/librustc_errors)
   Compiling backtrace v0.3.6
building of '/nix/store/nzxz2hn6ssvanp1v6ayprfbprlvx1sf3-rustc-1.27.0.drv' timed out after 3600 seconds
cannot build derivation '/nix/store/746np0zvbhpa2sr6vkkkpnwsgb9dxdga-cargo-1.27.0.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/q28r339dz25l1mmw8rfbkz1ldcczwzmj-librsvg-2.42.4.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/y3j81m2w0m8ziyz6c0an81icgrxfxh31-hook.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/k1wkgyqvf1ii7s1pjig7xp3lym6kf7f6-gobby-unstable-2018-04-03.drv': 1 dependencies couldn't be built
error: build of '/nix/store/k1wkgyqvf1ii7s1pjig7xp3lym6kf7f6-gobby-unstable-2018-04-03.drv' failed


Dangling processes on exit with --watch-stdin and multiple configurations

Bug report

What is the current behavior?
Starting webpack with --watch-stdin doesn't properly cleanup after itself. My webpack config returns a function, which returns two configuration objects. When starting webpack via my backend it starts 5 node processes, but when stopping the backend it leaves one node process running. It works when only one configuration object is returned by the function.
If the current behavior is a bug, please provide the steps to reproduce.

All processes to be properly stopped without any dangling processes, like it does for only a single configuration.

Other relevant information:
webpack version:  4.31.0
Node.js version: 11.9.0
Operating System: MacOS X
Additional tools:

Could you submit the reproducible repo?

https://github.com/LostKobrakai/webpack-issue-reproduction


Migrated flutter_typeahead to the latest version 5.2.0

Tell us about the task you want to perform and are unable to do so because the feature is not available
Currently, API Dash uses flutter_typeahead 4.8.0 that introduced various breaking changes starting 5.0.0
We need to migrate the code base to use the latest version of flutter_typeahead without losing the current functionality

Hey @animator  I would like to work on this issue, please assign it to me
Thank you

@andoriyaprashant, We do not assign issues. You are free to work on it and send across a PR.


Ec2 Ansible playbooks

"ansible/ec2-docker-playbook.yml" - this is a simple playbook to grab the Impostor image from Docker Hub and run it on an Amazon Linux 2 EC2 instance; this is my primary method for deploying the app
Also included in case it's helpful if we want to move to ECS:
"ansible/docker-compose-playbook.yml" - same as above, but uses Docker Compose instead
"ansible/docker-compose.yml" - the docker-compose YAML for the playbook "docker-compose-playbook.yml"

Closing this pull request for now so I can focus on a non-Docker deployment first and foremost; the Docker-based playbooks are giving me trouble since they seem to be ignoring the .env and config.json files, and it's most likely my limited experience working with Docker, but I can pick that up later.


Enhance SDS write of patient-authored resources

Enhance SDS write of patient-authored resources:

Select the authorization endpoint from among all data sources, instead of always using the first (which will likely fail when multiple sources are loaded).
Use the Patient ID from the authorization accessToken, instead of from the first source loaded (which may not match the SDS patient).

Completed. Patient or caregiver authored Goal, Condition, and QuestionnaireResponse are now saved to SDS.  Also fixed an issue with QuestionnaireResponse to also include 'author' element set to the logged in user, which may be different from patient, e.g. caregiver.


azure-http-specs, update azure example scenario name

Move @scenario from client.tsp to main.tsp
When in client.tsp, the namespace there would be the scenario name of this test, which appears not correct.

After this, it should be under Azure > Example > Basic.
This should not affect code generated by emitters.

All changed packages have been documented.

:white_check_mark: @azure-tools/azure-http-specs

Show changes
@azure-tools/azure-http-specs - internal ✏

Update scenario name on azure example scenario

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs


Display extension version

This PR fixes #94123
I'm not sure if latest version should be displayed, it'll be if update is available

IMO showing it in the header is very subtle.

I felt it is more appropriate in the second row

@sandy081 fixed!