Support Python 3.11

Python 3.11.0 final is due out in October and in beta now. We should test now, and as a pure Python library, can declare support too.
And bump some CI config.

Would it be wiser to test on the oldest and the newest Python supported (or even a matrix of all versions supported)?

Yes, we're already testing on all supported versions in test.yml:
https://github.com/flake8-implicit-str-concat/flake8-implicit-str-concat/blob/eee9fa6af249160de3125f39a924bfc1933c7bce/.github/workflows/test.yml#L14
Note lint.yml only uses a single (recent) version, as there's no real benefit linting multiple times on different versions:
https://github.com/flake8-implicit-str-concat/flake8-implicit-str-concat/blob/eee9fa6af249160de3125f39a924bfc1933c7bce/.github/workflows/lint.yml#L30

Ah, so that just bumps the version used for linting - thanks for clarifying. This looks good.

@peterjc This needs a formal review to be merged, would you like to do the honours? :)


Replaced mutable default argument in pyx_fused_cpdef

closes #3481
Not sure of the best way to add a test - insights appreciated

Using a mutable default argument in pyx_fused_cpdef allows that argument to serve as a store for persisting values between function calls.
Making it immutable and reassigning it would force its value to be re-generated every call, which would negate #3366 and cause all (dynamic) fused cpdef calls to have O(k**n) performance (where n is the number of unique fused types in the signature and k is the number of specializations per fused type).
I also tried keeping the values in the global namespace, and considered storing them as attributes of an object per fused cpdef, but using a mutable default argument was ultimately decided to be the cleanest option.
I'm sorry that I'm not really sure what to do with the linked issue either— The compiler warnings there are a couple steps lower-level than what I'm used to working with.

No, that change defeats the whole purpose of a mutable default argument. Now, the index would be rebuilt every time, because the argument is always None. The assignment is only local to the function.


Fix #19 - flatten before gsub

Fix #19 by flattening before gsub.

Thanks!

Thanks for merging it. And thanks for the whole mruby-esp32!


'MODE_COPY_SECTION_SOURCE': undeclared identifier in copy_effects.cpp when build the project

Tested versions
Current master
System information
Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; <IP_ADDRESS>19) - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 Threads)
Issue description
When build the project, I got MODE_COPY_SECTION_SOURCE : undeclared identifier in drivers\gles3\effects\copy_effects.cpp

It looks like in certain cases the copy.glsl.gen.h did not generate the definition for MODE_COPY_SECTION_SOURCE
	enum Uniforms {
		COPY_SECTION,
		SOURCE_SECTION,
		COLOR_IN,
		PIXEL_SIZE,
	};

	enum ShaderVariant {
		MODE_DEFAULT,
		MODE_COPY_SECTION,
		MODE_GAUSSIAN_BLUR,
		MODE_MIPMAP,
		MODE_SIMPLE_COLOR,
		MODE_CUBE_TO_OCTAHEDRAL,
	};

Is there any way to debug this?
Steps to reproduce
Not sure how I get there, but I checked out to an old branch and rebased it to master before I encountered this error. Maybe there is some unsync problem here? Also I can make sure that I did not have any local git changes in my repo.
Minimal reproduction project (MRP)
N/A

This is how I solve the problem:
Since copy.glsl.gen.h is generated, I checked Sconstruct build file and found the source : copy.glsl , then I add a space to that file and trigger a build, the build system successfully identified that the source has changed and do the generation again, and the problem is gone.


Enable strict mode in tests

QUnit file does not get transpiled anymore. This change slightly reduces build time (~0.5s) but leaves QUnit file non-minified (which is good for tests in my opinion). But the most important fact is that it allows to use strict mode in tests files (fixes #37). For now 1 test should expectedly fail (4 MockSocket inherits EventTarget: adding/removing "message" event listeners works) due to bug in the code and should be fixed by #38.

I merged #38 and reran the tests for this PR and now they pass. Thanks!


fix: Java inspection to support Map as a root-level object

Fixes: #162

@igarashitm I was thinking we could add the keys as fields. Using AtlasPath for coordinates. It is similar to using an index in arrays and lists.
Field1: atlasPath: /{key1}
Field2: atlasPath: /{key2}
Thoughts?

Hmm I understand that would work for mapping definition, but does it make sense on inspection? UI can only provides prefilled keys, but user would add more, and there're even more at runtime. I don't see any benefit to let inspection handle only that prefilled keys.

And I thought inspection doesn't handle any index. does it? At the time of performing inspection, we don't have any info about the index right?

Right, inspection doesn’t know about indexes and populated values. I was speaking in terms of how the UI (syndesis) might inject the data for mapping purposes.
Conceptually, I think Maps could work like user defined fields in XML and JSON. Syndesis may provide some keys, and the user may provide some keys.
Data model wise, I think we have a couple approaches:
Option 1:

defining the Map as a collection of type Map

‘Keys’ are child JavaFields of the Map JavaField and use the AtlasPath expression describe above. (Treating keys as JavaField has the bonus that all the type info is available from and including primitive to complex)

Values could be set in the ‘value’ field of the JavaField definition for each ‘key’

In the UI, you support adding a child field to the Map, just like in XML.
Option 2:
The other approach might be to link the Map JavaField collection field to a LookupTable. The downside there is that LookupTable is modeled Essentially like Entry<Primitive, Primitive> so it’d be tough to add <String, Object> and other complex map support.

Yep, and we decided to go with option1 IINM. But I don't understand how that topic fall into the scope of this pull request and #162. It's all about Java inspection.

Apologies, looks like inside tracked the convo.
Is this the current question at hand?
Should ClassInspectionService support inspecting a Map Object or Map Class?

@mattrpav whoa, you filed that issue (#162) ;-)
so the intention of the issue was to take a look at the Java class inspection and see if we want to do something for java.util.Map class inspection as a top level Document type. Actual entries are out of scope.

The attachment contains the inspection results when the Map is a root and field
Inspection results.zip

Just curious, for the Map as a field, how does it determine fieldType as STRING?
So still my question is open, how can we deliver the type parameters for Map (String and Object for Map<String,Object>)?
Other collections only have one type parameter, which is a type of the entry. How do we carry 2 parameters for Map?

As first target is Map<String, String>, it would be always String and String. But still worth to address it now so we don't have to rewrite everything later.

Map Key information(fieldType and className) will be captured in a  java
field of type Map and the the Map's value type will be captured in the Java
field value. Please check the attachments for the inspection results.
Please refer below for the Javafield section of a class inspection ,where
class contain a field of type Map<String,BaseOrder>
"javaFields": {
"javaField": [
{
"jsonType": "io.atlasmap.java.v2.JavaField",
"value": "io.atlasmap.java.test.BaseOrder",
"collectionType": "MAP",
"path": "orders",
"fieldType": "STRING",
"modifiers": {
"modifier": [
"PRIVATE"
]
},
"name": "orders",
"className": "java.lang.String",
"getMethod": "getOrders",
"setMethod": "setOrders",
"primitive": true
}
]
On Wed, Dec 13, 2017 at 2:04 PM, Tomohisa Igarashi<EMAIL_ADDRESS>
wrote:

As first target is Map<String, String>, it would be always String and
String. But still worth to address it now so we don't have to rewrite
everything later.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlasmap/atlasmap/pull/188#issuecomment-351489769,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agd6xUklEghwxvnizOnrEcEnNhpnb6hxks5tAB-wgaJpZM4Q9fF1
.

I don’t think we capture parameterized types yet during inspection. We’d need to extend the JavaClass and JavaField model types to support a place to put it.

With the Data Model we have , we can't capture a  parameterized types in a
JavaField. We have to update the data model by creating a new class by
extending the JavaField. The proposed solution is the alternative way to
capture the parameterized types with the available data model.
On Wed, Dec 13, 2017 at 2:31 PM, Matt Pavlovich<EMAIL_ADDRESS>wrote:

I don’t think we capture parameterized types yet during inspection. We’d
need to extend the JavaClass and JavaField model types to support a place
to put it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlasmap/atlasmap/pull/188#issuecomment-351497219,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agd6xdWMgeBKAigkwlck9Zjg8u5jeizyks5tACYQgaJpZM4Q9fF1
.

Please let me know, if we are not required to capture the parameterized
types until we create a new data model class
On Wed, Dec 13, 2017 at 2:47 PM, Sunil Unnava<EMAIL_ADDRESS>wrote:

With the Data Model we have , we can't capture a  parameterized types in a
JavaField. We have to update the data model by creating a new class by
extending the JavaField. The proposed solution is the alternative way to
capture the parameterized types with the available data model.
On Wed, Dec 13, 2017 at 2:31 PM, Matt Pavlovich<EMAIL_ADDRESS>wrote:

I don’t think we capture parameterized types yet during inspection. We’d
need to extend the JavaClass and JavaField model types to support a place
to put it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlasmap/atlasmap/pull/188#issuecomment-351497219,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agd6xdWMgeBKAigkwlck9Zjg8u5jeizyks5tACYQgaJpZM4Q9fF1
.

On Wed, Dec 13, 2017 at 3:34 PM, Sunil Unnava<EMAIL_ADDRESS>wrote:

Please let me know, if we are not required to capture the parameterized
types until we create a new data model class
On Wed, Dec 13, 2017 at 2:47 PM, Sunil Unnava <
<EMAIL_ADDRESS>wrote:

With the Data Model we have , we can't capture a  parameterized types in
a JavaField. We have to update the data model by creating a new class by
extending the JavaField. The proposed solution is the alternative way to
capture the parameterized types with the available data model.
On Wed, Dec 13, 2017 at 2:31 PM, Matt Pavlovich<EMAIL_ADDRESS>
wrote:

I don’t think we capture parameterized types yet during inspection. We’d
need to extend the JavaClass and JavaField model types to support a place
to put it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlasmap/atlasmap/pull/188#issuecomment-351497219,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agd6xdWMgeBKAigkwlck9Zjg8u5jeizyks5tACYQgaJpZM4Q9fF1
.

Existing model properties should not be used for different purpose.
This revealed that the current model doesn't work once we add Collection.MAP. Note that for other Collection types, we are populating field type and field class with a parameterized type read from Collection class. That doesn't work for Map without model change as it has two.

I will revert the changes to capture the Parameterized types, when the Map
is a field.
On Thu, Dec 14, 2017 at 9:34 AM, Tomohisa Igarashi<EMAIL_ADDRESS>
wrote:

Existing model properties should not be used for different purpose.
This revealed that the current model doesn't work once we add
Collection.MAP. Note that for other Collection types, we are populating
field type and field class with a parameterized type read from Collection
class. That doesn't work for Map without model change as it has two.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlasmap/atlasmap/pull/188#issuecomment-351727536,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agd6xZv60SIIeTyT0m3XJGFLClAvCF3-ks5tATIBgaJpZM4Q9fF1
.

I have reverted the changes to capture the parameterized type in a field. The only changes made are adding the collectiontype when the Java Field or Class is of type Map.

Also can you change Fixes: header to Relates to: or something? I don't want to close #162 until we support parameterized types, including model changes.

Do we have an issue number to add to Related to:
On Thu, Dec 14, 2017 at 11:12 AM, Tomohisa Igarashi <
<EMAIL_ADDRESS>wrote:

Also can you change Fixes: header to Relates to: or something? I don't
want to close #162 https://github.com/atlasmap/atlasmap/issues/162
until we support parameterized types, including model changes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlasmap/atlasmap/pull/188#issuecomment-351757144,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agd6xW0WfXJwgm1wD3BW3-ZYpkV0Ty3tks5tAUkCgaJpZM4Q9fF1
.

It's still #162 , but Relates to: won't close the issue, which I want

Please share your thoughts on how to capture the parametrized types. We
have the following 2 use cases.

Map as root :  We can't capture the Parameterized types. We can capture
the Parmeterized types only for the super classes or for the fields
Map as a field:  Parameterized types are captured in the following
property in the Java Field. If we want to capture more details in a
separate Data model(like JavaMapField that extends JavaClass), please share
your thoughts on the fields in the Java class

parameterizedTypes": {
"string": [
"java.lang.String",
"io.atlasmap.java.test.BaseOrder"
]
}
Please note we already updated our code to identify a field as Map and the
changes not merged to our code.
On Thu, Dec 14, 2017 at 11:12 AM, Tomohisa Igarashi <
<EMAIL_ADDRESS>wrote:

Also can you change Fixes: header to Relates to: or something? I don't
want to close #162 https://github.com/atlasmap/atlasmap/issues/162
until we support parameterized types, including model changes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/atlasmap/atlasmap/pull/188#issuecomment-351757144,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Agd6xW0WfXJwgm1wD3BW3-ZYpkV0Ty3tks5tAUkCgaJpZM4Q9fF1
.


Daily default image?

Maybe qovis should use a default image everyday... Otherwise I would use a static image which will be displayed in the case of missing information

This is still relevant

Problem fixed in https://github.com/MarcoSteinke/qovis-RKI-statistics/commit/3b0cb8fbf79ec2d5b97887631f73dd18d696e35b


Add pytest.ini default config + changes to .gitignore and .dockerignore

What changes were proposed in this pull request?
This adds a default config file for pytest with some helpful defaults (pytest.ini).
Why are the changes needed?
Using the importlib mechanism for test imports avoids errors when names conflict.
We are using this config to avoid weird errors popping up.
How was this tested?
No tests added, as this is configuration

That means you're not having tests inside packages, am I right?
Regardless, I like this approach, seeing as how the pytest devs intend to make this mechanism the default. We might as well get used to it.

Our tests have the structure as proposed by the Datafy templates, so tests are separate from application packages (which live inside the 'src' folder). But the tests folder is structured as packages (contains init.py).

I don't have enough knowledge about this topic to chime in. If @oliverw1 and @vlieven agree this is a good thing to add I trust your judgement :) @oliverw1 can you formally approve that this is the right way to do things then I'll merge this PR!

@stijndehaes yes, this makes sense to me. I would request that @vlieven also adds the minimum constraint to pytest in the various requirements files (dev-requirements.in, Pipfile), to avoid ambiguous dependencies.
Do note that I find it puzzling that the setup of @vlieven, which is the default of datafy and uses a packaging structure in the tests folder, caused issues. I don't know the specifics of his project though. But the change proposed here is one that the pytest developers intend to make permanent anyway.

@vlieven can you add the minimum constraint to pytest? Then we can merge this PR :)

@stijndehaes Noticed that I forgot to follow up on this. Minimum constraints have been added now


unable to download required widget in VSCode

Environment data

VS Code version: XXX
Jupyter Extension version (available under the Extensions sidebar): XXX
Python Extension version (available under the Extensions sidebar): XXX
OS (Windows | Mac | Linux distro) and version: XXX
Python and/or Anaconda version: XXX
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): XXX
Jupyter server running: Local | Remote | N/A

Expected behaviour
XXX
Actual behaviour
XXX
Steps to reproduce:
[NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue]

XXX

Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

XXX

Thanks for filling this issue
However without any information it’s not possible to help you
Please could you fill in the required info and include steps to repro the issue

thanks for replying! the problem was eventually fixed - it had to do with
an antivirus software on my computer. it was my first time reporting an
issue and didn't realize that I needed to write more information. will do
next time!
-Gin
On Thu, Aug 24, 2023 at 7:08 PM Don Jayamanne @.***>
wrote:

Thanks for filling this issue
However without any information it’s not possible to help you
Please could you fill in the required info and include steps to repro the
issue
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-jupyter/issues/14176#issuecomment-1691475123,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AU5BJNFBD3CKJN5CT5DGFHLXW4Y2LANCNFSM6AAAAAA34RPARU
.
You are receiving this because you authored the thread.Message ID:
@.***>


docker-machine freezes

Hi,
I have a problem when I try to start a new VM using docker-machine:
docker-machine --debug create -d xenserver --xenserver-server ***** --xenserver-username root --xenserver-password ******* --xenserver-boot2docker-url https://github.com/boot2docker/boot2docker/releases/download/v1.12.3/boot2docker.iso --xenserver-memory-size 2048 test-vm

docker-machine freezes at this line
(test-vm) Waiting for VM to start...
But it works when I use 1.12.0 version of boot2docker iso file

Sorry for the long delay -- I can only imagine there's something going wrong with your Xen Server instance (or with boot2docker's admittedly experimental/poorly-maintained support for running as a Xen guest).
Since there's not much we can do about this without further debugging into the root cause (and how to fix it), I'm going to close. :+1:


OAuth2 and OpenID Connect section needs reference to certified libraries

While other sections like password storage are giving recommendations of libraries usage to support security functions, the OAuth2/OpenID Connect sections don't do the same.
This should link to OIDC certified implementations by the OpenID Foundation: https://openid.net/developers/certified-openid-connect-implementations/

The guides we have right now are on implementing OAuth/OIDC clients, where I'm not sure if there are certifications for it.

The OpenID Foundation list certified Libraries:

It is sad that you limit yourself to own implementation... using certified libraries still requires configuration and architecture to make it a production grade service which a part where your guidance is important
Still even if you want to hear just about self implementation, if you had explored a little bit more the link provide, you would have seen that the OpenID foundation provides also a program for one to certify their implementation OAuth2 / OIDC : https://openid.net/how-to-certify-your-implementation/

So why do you close this issue?

Sorry, it was very late at night and I mixed up relying parties and identity providers. I'll update page to mention the certified implementations. I don't plan to go into specific configuration recommendation since that's out of scope of the book. Honestly, I should probably create a dedicated page on OIDC


Drop kevlar collect and test_pipe.py

The kevlar collect command has been deprecated for a while now. I've kept it around for two reasons:

to keep the junction count assembly functionality easily accessible, in case
to avoid removing or replacing the test_pipe.py test script

This PR addresses the first point by splitting the kevlar assemble script into two modes, with two main methods selected dynamically at runtime based on command-line arguments. As for the second point, the tests are so far removed from the current workflow expectations that it will require a non-trivial amount of effort to replace. I think it should be replaced, but more progress on #95 will be required first.

This PR drops testing for banding in kevlar novel. I'm not Pharisaical about test coverage, and this has been working fine. But once more subcommands have been refactored this is an important piece of functionality that needs to get back into the tests.


[WIP] NATS Streaming Server / STAN support

Still some work needed on this.
It pretty much is done, except ending up the support for verbose mode which is 3/4 done.
Needs integration tests against a STAN server.

Good morning! I was wondering what the ETA on this work might be? I've been hunting around for a NATS Streaming library for Habitat, and the non-streaming NATS in this library is working pretty well in my POC.
Thanks in advance!

Hey @christophermaier. If you need to immediately start using nitox streaming, you can update your Cargo.toml to depend on nitox from the repo in this PR: https://github.com/YellowInnovation/nitox/pull/21

it is my fork and I have been using it successfully along with message ack'ing.
it is based on this branch, but resolves the merge conflicts, and adds manual message ack'ing.

One word of warning, I would recommend that you take a look at issue #24. It is not specific to streaming, but streaming is effected by this issue. If the nitox client is the only task you will be running on your tokio runtime, then nothing to worry about. If you have other tasks which need to run, the best workaround is to just create a separate tokio runtime for nitox. That will ensure none of your other tasks get blocked.
Let me know if there is anything I can help out with or clarify.

@thedodd Thanks for the reply (as well as the pointer to #24); I'll give this a spin tomorrow! 👍

Reporting @thedodd's comment on the todo here for information;

resolves the current (as of 2019.01.16) merge conflict in feature/nats-server.
fixes a bug where streaming client IDs were being generated with .s in the name. Server was rejecting the client connections & consumers were being blocked. I'm a now able to consume messages off of a stream.

todo

[x]  finish up with manual ack pattern.
Just a couple of observations for moving forward:
[x]  streaming modules & types could used some docs. I'll let you handle this one, @OtaK.
[x]  looks like the streaming_protocol module is private, so accessing the StartPosition variants is not possible. Maybe that is intentional, but it would def be nice to have access to the enum during development.
[x]  the MsgProto object (also generated by prost/protobuf)  is in the internal streaming_protocol.rs file and can't be accessed by stream handlers.
[x]  also, I see that the derive builder crate is used throughout (in existing code as well). I would recommend using the typed_builder as everything can be verified at compile time. This is super convenient, especially when dealing with futures. We can open another issue for this later.

I've merged #21, and rebased the whole branch on develop to get rid of the ugly merge.
I guess integration tests are coming up next!
I'll study a move on typed_builder, it seems super cool and less panicky :o

I'd really like to have tests ready before merging it.
Even if the feature is opt-in, it would be super cool to be confident that it works 100%.

I just added the support for the verbose mode!
It works by holding off future resolution until a +OK message comes down the line.
Next step will be writing an integration test suite for STAN / NATS Streaming Server.


Add MD5 as checksum type in template

Fixes #164

:white_check_mark: Build ServiceBusExplorer 4.1.0-PullRequest0172.153.build.334 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/beb4425148 by @tomkerkhove)


Active field handling for downloaded Enframe data

There is a ticdat_upload_download_utility.py for handling these sorts of issues.


Script for creating B2B guest user objects in AD needs to be updated to avoid an error with samaccountname ending with a period

The current script takes 20 characters from guest user's UPN, and set the string as its samaccountname.
If there's a guest user with UPN as below, the sameaccountname will contain a period at the end.
UPN<EMAIL_ADDRESS>But because samaccountname cannot end with a period in AD, it returns an error, and the user cannot be created.
Suggestion:
Update the line 131 below:
$samaccountname = $TenantGuestUsersHash[$key].userprincipalname.Substring(0, 20)
to something like this:
$prefix = $TenantGuestUsersHash[$key].userprincipalname.Substring(0, 20)
if ($prefix.Substring($prefix.Length - 1,1) -eq "."){
$samaccountname = $prefix.Substring(0,19) + "_"
}
else
{
$samaccountname = $prefix
}

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

ID: f8e1cf65-2201-42ab-7513-de1833ad1c66
Version Independent ID: e6e10378-90cf-6e9f-41ae-10510e35e012
Content: Grant B2B users access to your on-premises apps - Azure AD
Content Source: articles/active-directory/b2b/hybrid-cloud-to-on-premises.md
Service: active-directory
Sub-service: b2b
GitHub Login: @msmimart
Microsoft Alias: mimart

Thanks again for your feedback and apologies for the delay - just wanted to let you know we're working on clarifying the script and/or guidance internally. For now we'll close this issue but will update the article as soon as we have clarification. #please-close


Index tools break with updated pdslogger

v2.0.0 of rms-pdslogger has just been released. It is not fully backwards-compatible with v1.0.0, which is what the index tools were developed against. As a result the index tools now fail to run. There are two options to fix this: 1) Update the tools to handle the changes to pdslogger (preferred) or 2) Change requirements.txt to say rms-pdslogger==1.0.0 to force use of the old version. If you don't have time to do 1 right now, I suggest doing 2 as a stopgap.

Never mind, there was a badly cached version - every works correctly.


Cant find or install

I can no longer find this online in the "Manage Extensions" dialog and when I try to install from git releases. It says it is already installed on all supported products. Did the latest VS update change something. I have Microsoft Visual Studio Professional 2022 (64-bit) - Current Version 17.4.4. Let me know if you need any other information.

You can build on Release mode, go to generated bin folder and use the VSIX for install


issue-778

Time from assignment to PR for #779: $time_diff_input ms

Time from assignment to PR for #779: 41230 ms

Time from assignment to PR for #779: 42502 ms


good way to eliminate need for requiring user to supply facility qualifiers

Make the compiler search facilities now by default. What we'll do in PopulatingVisitor is have a function (find facility qualifier or something) that, given some Symbol s, finds all locally accessible facilities using a multimatch query, scans through the resulting facilities looking for one whose specification matches the module identifier for s. We return the first facility we find for this. If multiple match, it's an error (though not sure if the query would have thrown a dup symbol exception first).
once we get the name of the facility. use Utils.createTokenFrom(..) then assign ctx.qualifier = "created token"
I think this might work! Anyways, this would be a nice seg transition into messing with Infix Operations for the standard templates.

This was incorporated.


Where are  Peripherals, NVMC object placed ?

Dear Nihal,
I am walking through class FlashWriterEraser in nrf52840.rs which should be refer for implementing a HAL of another board
I see there are 2 class Peripherals, NVMC (Non Volatile Memory Controller) which are not presented in the source dir.
So I guess these classes were generated from nrf52840.svd, right ?
if yes, kindly show me:
What tool is used to generate these class?
Where are generated classes placed ?
Thank you.
Viet

So, we're using the [nrf52840-hal](https://crates.io/crates/nrf52840-hal) (i.e. a crate maintained by the embedded rust community).  It provides access (i.e. via abstractions) to all available system peripherals.  The rust community maintains a number of different crates for different boards such as stm32, microchip-SAM etc.
nrf52840.svd - an .svd file (short for system view description) is actually not important. Its required for debugging i.e. there's
a VSCode plugin called cortex-m debug that is used to debug embedded code and it uses .svd files.
fyi - rust isn't exactly objected oriented. So, the concept of classes and instances of classes (i.e. objects) doesn't really exist, instead rust provides types and traits which can be used to write object-oriented code, data-oriented code (i.e. ECS type stuff) or code that conforms to other programming paradigms.


Apply organization-level permissions to the reichlab GitHub org

Background
We are trying to standardize the workflow and permissions for GitHub repositories in the Reich Lab organization.
A related issue (#2) outlines work for updating branch protection rules on existing Reich Lab repos.
A related piece of work is ensuring that all members of the Reich Lab org have repo permissions that allow them to work.
GitHub now allows organization admins to set repository-related permissions at the org level, which should help: https://github.blog/changelog/2024-07-10-pre-defined-organization-roles-that-grant-access-to-all-repositories/
Definition of done

[ ] Review GitHub's pre-defined organization roles and decide which should be applicable to the active-members team ~everyone in the Reich Lab organization~.
[ ] Apply the above
[ ] Identify any additional organization roles that should apply to a subset of org members (for example, the admin role)
[ ] ~Clean up the Reich Lab org membership if needed~ (Evan created an active-members team that we'll use when assigning dev-related permissions, so we don't need to clean up inactive org members).

Assuming that we first do the work in #2 (ensuring that branch protections are in place), I'll start the conversation by proposing that all Reich Lab members are assigned to the following organization roles:

all-repository read
all-repository write (no more requesting access to push a branch, and no more need for internal devs to work with forks)
all-repository triage (delete and edit discussions, add and remove labels, close and re-open PRs, set milesones)
all-repository maintain (manage GitHub page settings, manage project settings, view and manage security alerts, etc.)

Ideally, we'd also have a team within Reich Lab that is assigned to the all-repository admin group.

We decided to assign the "All-repository admin" role to the new active-members team.
I added this role to the team and removed its previous role ("All-repository write").


twint.feed:Mobile:list index out of range

Error message
twint.feed:Mobile:list index out of range
Command Ran
twint -u srvmshr --favorites -o output.csv
Description of Issue
The feed of favorites stops at 3218 (out of a possible ~4100 favorited tweets) after the last scraped tweet (i.e. after 3218th oldest tweet the Error message is displayed) The account being scraped is mine @srvmshr
Environment Details
Using Linux 18.04 with a environment on Anaconda (Py3.6 + pip installed requirements) . The environment is up to date and git-pull done for build as of 2019-06-5
Additional notes:
Issue reported on #twint in OS-INT Slack channel
Object details
The offending tweet at two simultaenous runs is

https://twitter.com/fhuszar/status/875462826105552896

I have unfavorited the tweet to see if TWINT is making an isolated error on this particular status message.

Update:
The list still stops at the particular tweet (3236th tweet)

since and until can't be used with following/followers/profile/favorites, only with search
Favorites and Profile are subjected to restrictions by Twitter, which means that you can get about 3200 tweets

I think there is still some bug which is not understood well.
I pruned my own "Likes" down to 2148. Yet, the parsing and collection stops repeatedly before list runs out.  Still shows list index out of range. Technically, this should not happen as the number is now well below 3200.

@betasm Twitter might stop before for unknown reasons


Suggestion: add a reference link

It would be super helpful if each feature page linked to a developer resource page or guide, where developers could learn about the feature in more lay terms than w3c specification language. Fore example, linking light-dark() (https://webstatus.dev/features/light-dark), to a resource such as https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/light-dark would be super useful.
Thank you for your consideration.

I've filed https://github.com/web-platform-dx/web-features/issues/1122 for what we'd need from web-features to support this.


[Dubbo3-Triple] Fix codestyle

What is the purpose of the change
XXXXX
Brief changelog
XXXXX
Verifying this change
XXXXX
Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
[x] Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
[ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
[ ] Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
[ ] Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
[ ] If this contribution is large, please follow the Software Donation Guide.

Codecov Report

Merging #7307 (e679289) into 3.0 (7fe4b6c) will decrease coverage by 0.23%.
The diff coverage is 33.67%.

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


Bug in script for Stage 1 validation

When giving greek alphabet input, it still shows a Correct answer popup after showing close enough

@PriyavKaneria Can you show light on how to reproduce the bug at my end?

On the page https://priyavkaneria.github.io/Anonymously-New/access_key.html
If the user gets the hint and enters γνώση in the input, it should give close enough popup but not the success popup


Usability issues when composing indirect with incomplete T?

I have been playing around with indirect with incomplete types and found a bit of compiler-specific divergence, and usability questions.
Compiler Explorer
struct bar;

struct foo {
    xyz::indirect<bar> expr;
};

struct bar {};

int main() { foo b; }

This compiles on gcc, but is rejected by clang and msvc. I'm not an expert, but I could imagine that clang and msvc are correct here, since at the closing semicolon of the foo definition, the compiler needs to determine which of the special member functions to generate; that requires instantiation of indirect's constructors, which has to fail at that point.
Essentially, my concern here is that the template <typename TT = T> trick defers instantiation until the point of use, but if I want to compose indirect in my own type, then I have to repeat the same trick, because the compiler-generated functions don't know about it. In other words, the trick doesn't compose naturally.
For example like this, which compiles on all 3 major compilers:
struct bar;

struct foo {
    xyz::indirect<bar> b;

    template <typename T = foo>
    foo() {}

    template <typename T = foo>
    foo(T const& other) : b(other.b){};

    template <typename T = foo>
    foo& operator=(T const& other) {
        b = other.b;
        return *this;
    };

    foo(foo const& other) = delete;
    foo& operator=(foo const& other) = delete;
};

struct bar {};

int main() { foo b; }

This is likely not obvious for a lot of users.
If you put an indirect with incomplete T inside a variant or any other type that has requirements at type instantiation time, then we run into the same issue.
struct foo {};
struct bar;

struct baz {
    std::variant<foo, xyz::indirect<bar>> b;
};

struct bar {};

int main() { baz b; }

I'm mentioning this separately since I imagine this to be a common enough usecase: You have one of a fixed set of types, but one of them is incomplete, maybe because the data structure is recursive. Intuitively, this should work (and it does if you replace indirect with unique_ptr).
Again, I could go and define the usual members appropriately myself to fix this, but if I do that, then I might as well just use unique_ptr where I have to do the same thing if I want deep copy.
Unfortunately, I don't have a great idea how to make this better. So, unless gcc is right after all: Would it be better not to support incomplete types? But then again, there might be other compelling usecases that I am not aware of.
Oh, and since this all reads very negative: great work! I actually love indirect!

Thanks taking the time to play around with indirect and give us feedback. I'd be keen to learn more about your use cases.
I think that the issue you observe is similar to that seen with the traditional pointer-based pimpl pattern and can be fixed by telling the compiler that special member functions are provided elsewhere and then doing so.
In our compilation checks, we have:
indirect_pimpl.h
#include "indirect.h"
namespace xyz::testing {
class Class {
  indirect<class Impl> impl_;

 public:
  Class();
  ~Class();
  Class(const Class&);
  Class& operator=(const Class&);
  Class(Class&&) noexcept;
  Class& operator=(Class&&) noexcept;

  void do_something();
};
}  // namespace xyz::testing

indirect_pimpl.cc
namespace xyz::testing {

class Impl {
 public:
  void do_something();
};

Class::Class() : impl_(xyz::indirect<Impl>()) {}
Class::~Class() = default;
Class::Class(const Class&) = default;
Class& Class::operator=(const Class&) = default;
Class::Class(Class&&) noexcept = default;
Class& Class::operator=(Class&&) noexcept = default;

void Class::do_something() { impl_->do_something(); }
}  //  namespace xyz::testing

Presumably if you have an incomplete type in your code, it will at some point become complete after which you can nudge the compiler to provide the special members that need complete type information?
If I've misunderstood or misrepresented your use-case. Please let me know.

Thanks for taking the time to play around with indirect and post an issue.
The issue you raise is interesting. While an indirect<T> member with T as an incomplete type is allowed at type-instantiation time, indirect<T> is not really a complete type itself at that point so can't be a template type argument for anything which has type-instantiation-time requirements. I certainly would not want the trick we used in indirect to be liberally employed elsewhere as you rightly suggested.
    template <typename T = foo>
    foo() {}

The first part of your issue can be solved by declaring and later defaulting the special member functions, like we do in our compile checks compile_checks/indirect_pimpl.h, compile_checks/indirect_pimpl.cc.
#include <https://raw.githubusercontent.com/jbcoe/value_types/main/indirect.h>

struct bar;

struct foo {
    xyz::indirect<bar> expr;
    foo();
    foo(const foo&);
    foo(foo&&);
    foo& operator=(const foo&);
    foo& operator=(foo&&);
};

struct bar {};

foo::foo() = default;
foo::foo(const foo&) = default;
foo::foo(foo&&) = default;
foo& foo::operator=(const foo&) = default;
foo& foo::operator=(foo&&) = default;

int main() { foo b; }

I'll ponder variant further. Composites without requirements (like vector) work as you'd like.
Thanks for the kind words. I'd like to understand your use cases better to see how things might be improved.

Digging in a bit deeper, a union does not seem to have the same issues as a variant:
#include <https://raw.githubusercontent.com/jbcoe/value_types/main/indirect.h>

struct foo {};
struct bar;

struct baz {
    baz();
    ~baz();
    baz(const baz&);
    baz(baz&&);
    baz& operator=(const baz&);
    baz& operator=(baz&&);

    union U {
        foo f;
        xyz::indirect<bar> i;
        U();
        ~U();
        U(const U&);
        U(U&&);
        U& operator=(const U&);
        U& operator=(U&&);
    };

    U b;
};

struct bar {
    ~bar() = delete;
};

int main() { baz b; }

https://godbolt.org/z/1cfGKddxb
I wonder where the additional type requirements are coming from for variant?

I’m more optimistic. This use case is important to me and I’ll see what we can do to make variant play better with indirect and polymorphic.

I'm glad I brought it up, then! Thank you for your work :+1:

Looking at the compile-errors in your godbolt link, it seems there are two causes for the compile-errors.
The first is that the order of constraints in the indirect::operator=(U&& u) overload have placed the constraint that should eliminate it from consideration if the RHS is of type indirect at the end. Ideally it should be placed as the first constraint so that we short-circuit and avoid evaluating the other constraints.
Applying the following change seems to make it compile:
   template <class U>
   constexpr indirect& operator=(U&& u)
-    requires(std::is_constructible_v<T, U> && std::is_assignable_v<T&, U> &&
-             !std::is_same_v<std::remove_cvref_t<U>, indirect>)
+    requires (!std::same_as<std::remove_cvref_t<U>, indirect>) &&
+             std::constructible_from<T, U> &&
+             std::assignable_from<T&, U>
   {
     if (valueless_after_move()) {
       p_ = construct_from(alloc_, std::forward<U>(u));
     } else {
       *p_ = std::forward<U>(u);
     }
     return *this;
   }

NOTE: Prefer using the concepts in the constraints rather than traits where available as this will give better diagnostics in compile-errors.
This fixes the above example so that it compiles: https://godbolt.org/z/8sj3rWed4
However, the second issue I saw was that the indirect default constructor was using constraints rather than mandates/static_assert.
Won't this cause placing an indirect<incomplete> as a data-member of a plain struct to fail to compile as this will try to determine whether it should add a declaration of a default-constructor to the plain struct?
This could also be seen if you swap the order of the types in the variant in the example above, so that the indirect type is first, and is thus default-constructed when the variant is default-constructed.
Also, the use of traits, like std::is_default_constructible_v<T> require that T is a complete type and your program is ill-formed if you try to ask the question when T is incomplete.
However, if you use std::default_initializable<T> then if T is incomplete then the constraint will simply fail to be satisfied, and the method is eliminated from the overload-set.
So, if you change your default constructor as follows:
   template <class TT = T>
   explicit constexpr indirect()
-    requires(std::is_default_constructible_v<A> &&
-             std::is_default_constructible_v<TT> &&
-             std::is_copy_constructible_v<TT>)
+    requires std::default_initializable<A> &&
+             std::default_initializable<TT> &&
+             std::copy_constructible<TT>
       : indirect(std::allocator_arg, A{}) {}

Then you can compile the following snippet:
#include <variant>
#include <concepts>

using namespace std;
using namespace xyz;

struct number {
    int value = 0;
};

struct binop;

struct expression {
    variant<indirect<binop>, number> info;
};

struct binop {
    char op;
    expression lhs;
    expression rhs;
};

static_assert(!std::default_initializable<expression>);

int main() {
    expression exp{number{42}};
}

But note that the expression type is no longer default-initializable.
This is because at the end of expression definition, the compiler checks if it should generate a default constructor, which checks if the variant is default constructible, which checks if indirect<binop> is default constructible (as it's the first alternative type) which checks the constraints above, which fails to satisfy the constraints because at this point, binop is still incomplete.
This kind of makes me wonder if we shouldn't be using "mandates" for the default constructor, rather than constraints. This would potentially give the answer that some types are default constructible when they actually aren't, but would let indirect<incomplete> actually be default constructible in this case.
Also, it's not clear why you are using "Mandates: is_copy_constructible_v<T>" on the copy-constructor, but "Constraints: is_copy_constructible_v<T>" on the default constructor. Should all of the constructors simply use "Mandates: is_copy_constructible_v<T>"?

Thanks Lewis
I need to update indirect (and polymorphic) following the updated spec #464.
@lewissbaker I'll get back to you once spec and reference implementation are aligned.

We have #472 as an immediate fix. We'll fully revise the reference implementation in due course.

The fix applied in #472 does not fix indirect-in-variant on MSVC. More work needed.

Replacing type_traits with concepts (as Lewis suggested) in #475 fixes MSVC issues.
This may need a Library issue to be submitted as it's a change to the design (albeit a necessary one).

@lewissbaker re:
"This kind of makes me wonder if we shouldn't be using "mandates" for the default constructor, rather than constraints. This would potentially give the answer that some types are default constructible when they actually aren't, but would let indirect actually be default constructible in this case."
I'm keen for traits not to lie. indirect is copy-constructible by design but not all indirect's need to be default constructible.

Fixed in #475
We'll submit a library issue to update the spec.

Update: we are continuing to look into this in https://github.com/jbcoe/value_types/pull/478


Add comment in task overview only visible if comment already exists

Expected behaviour
When opening a task you cannot directly add a comment in the task overview. This is only possible when a comment is already existing.
Actual behaviour
Add a comment segment not present.
Steps to reproduce

Open task without comment
Check if Add a comment is visible

Configuration
Copy and paste the configuration section from the Kanboard settings page or fill these fields:

Kanboard version: 1.0.26
Database type and version: SQLite
PHP version: 5.6
OS: Windows 7
Browser: Mozilla Firefox 45

one of my users had a similar issue. I changed Actions to Menu - we'll see if it helps ;-)

I know it is possible to add via the dropdown. I meant the possibility to add a comment directly in the overview. I think the screenshots will explain it better:

As soon as a comment is present you have the option to directly add a comment in the overview.

I work around this 'feature' :) by adding an automatic action to add a comment log when moving into my WIP. However, i do agree this would be nice to have it always there regardless.

Just a little note, you could add the comment box via a little plugin ;)

I am aware that it is possible to add via plugin. My thought was to report it as an issue because it is not a coherent experience in my opinion – one time it is here, another time not. It is a minor inconvenience as it does not prevent me from using Kanboard in any way.

I agree with @donpatzone . It feels like a bug. It's been there for a long time and users are now used to a certain way of doing things. In terms of UI it doesn't make much sense to remove comments, but to keep the rest.

With v1.0.27, the comment form always appear at the bottom. You can also use the keyboard shortcut "c" or menu on the left.


Update logging mechanism so that it doesn't show up in tests

Currently the monitor tests log a bunch of stuff. Let's try to keep test output clean.

Nice. This seems to be fixed in #27. We can close this when it's merged.

https://github.com/doubleproject/double-cli/pull/27


This is cumbersome, frail, and messy

I like the idea of managing a bright idea in a Pull Request. I like it for the dialog and review interface, and for collecting edits in commits.
I have been managing a bright idea as a card on a list on a board. So I drafted a step-by-step to replicate the organization and workflow in Pull Requests.
What I put together would require tools and automation to be useful, and it lacks controls to ensure those will work.
It could work in the Web UI but is confusing if you edit files locally. Plus, how to intuitively organize .md files for each idea?
This was an exercise in curiosity, rather than a solution to a problem. So I'll keep my incubator and other wetware projects on something like Trello or Asana for now.

Closing as stale. Re-open when ready to work.


do not start threads while shutting down

prohibit workstealing thread pool lifeguard starting of threads while shutting down

Any update on this?

Is this causing you any sort of problem? If so, please elaborate.
Threads are intentionally still created until the queue is drained. Otherwise, it's possible to starve gRPC on shutdown. Consider the case where some necessary work is waiting in the queue, and all available threads are blocked waiting for that work to happen.

What I saw is that all threads are shutdown (pool_->living_thread_count()->count() is 0) and then one additional thread is started.
I am in the grey zone of having to use grpc linked to dynamic library. The intention was for this specific library to be loaded on start of a program and unloaded at the end of the program, but only if the customer wants to use grpc.
Currently the library gets loaded but never unloaded otherwise a crash might happen, as this thread is running in code that gets unloaded.
To determine if it is safe to unload we use the method grpc_is_initialized and wait for it to return false.

grpc_is_initialized is an experimental C API, there's a good chance it'll break or go away entirely. I do not recommend you rely on it.
https://github.com/grpc/grpc/blob/25813a0b7fae0dc13d669cdf3d8dc21c7dca9b13/include/grpc/grpc.h#L71-L75
There is no great way to safely do what you're trying to do. Once gRPC is initialized, the library assumes it can run to the end of the process.

grpc_is_initialized is an experimental C API, there's a good chance it'll break or go away entirely. I do not recommend you rely on it.
https://github.com/grpc/grpc/blob/25813a0b7fae0dc13d669cdf3d8dc21c7dca9b13/include/grpc/grpc.h#L71-L75
There is no great way to safely do what you're trying to do. Once gRPC is initialized, the library assumes it can run to the end of the process.

@drfloob Some questions arise here for me, would be really great if you could answer it: Is it supported that we load and initialize grpc after and in a dll, but do not unload it (so it is loaded until the end of the application). And is it safe that there won't be any "referenced" leaks or access violations on objects from grpc after other things got unloaded at the very end of the application? -> Because we don't have a way to say to grpc that we now want to end.

@CDAlexanderW your question is not directly related to this PR, and we like to try to keep things focused. Please feel to send your question to the google group and I can reply there. https://grpc.io/community/

I just sent it there and dont know how to inform you, so I will leave it here (also for all people interested): https://groups.google.com/g/grpc-io/c/BvddiQlbozQ
@drfloob would appreciate an answer there very much!
thx!


Generic collection isn't being cast, causes compile error

With this simple class:
@Parcel
public class MyModel<T> {
    Set<Long> someLongs;
}

I'm getting the same error reported in #293. someLongs is indeed a Set<Long>, but the generated class can only see it as a Set<Object>. In 1.1.6, the generated code manually cast it to Set<Long>, which worked. In 1.1.7 through 1.1.11, the cast is gone, so compilation fails.

This is because you're asking Parceler to generate a Parcelable wrapper for an undefined generic type which resolves to Object.  How are you using MyModel?  Do you have a concrete implementation that extends it?

Appreciate the quick response! I'm not using MyModel anywhere, I created it just for trying to boil down a model in a large project to just the part that was causing the issue. It was still tested in that project, but isn't referenced or extended anywhere. Could the project's setup/dependencies possibly be an issue?

Ah, just reread the issue.  Adding the generic <T> seem to cause the problem... something is happening here, ill have to dig in further.

This is interesting... Java issues a compiler error for defined generics in undefined genericised classes:
public class Tester {

    public static class Pass {
        Set<String> stuff;
    }

    public static class Fail<T> {
        Set<String> stuff;
    }

    public static class PassAgain extends Fail<Integer> {}

    public void run() {
        for (String stuff : new Pass().stuff) {}  // Good
        for (String stuff : new Fail().stuff) {}  // Compiler error
        for (String stuff : new Fail<>().stuff) {}  // Good
        for (String stuff : new Fail<Integer>().stuff) {}  // Good
        for (String stuff : new PassAgain().stuff) {}  // Good
    }
}

... I guess because of type erasure?

That's really weird. I wish I could help more, no idea why that would be happening. I'm sure there's some arcane historic JVM-related reason. Adding a cast should be a decent fix though, right? At worst, it'll be unnecessary (and probably compiled out).

We actually removed the cast a while ago because it was typically unnecessary.  Here's another fun case:
public class Tester {

    public static class Fail<T> {
        Set<String> stuff;
    }

    public static class Referencing {
        Fail<Object> fail;
    }

    public void run() {
        for(String stuff : new Referencing().fail.stuff) {} // Good
    }

}

I wonder what a fix for this would look like.  Honestly you shouldn't annotate a class with undefined generic parameters.  Maybe we should issue an error in this case instead of attempting to generate code with errors?

In your codebase how is it used?  Are there concrete implementations or is it referenced in a non-generic way as a field type (or something similar)?

There are no subclasses, not totally sure if I'm following your examples, but essentially the generic type is an interface with an ID property, and we want those IDs in the parcel.

Sounds like it's the following case then:
@Parcel
public class SomeClass {
    MyModel<String> model;
}

That might work, but I'm still not sure why the code generated for the original case is bad.

Sorry, the above case would not work, as long as MyModel<T> is annotated with @Parcel.

No chance of the cast being reinstated?

I'm not eager to reinstate it.  There is a deeper problem here that needs a more direct solution.  I think the answer lies in understanding why generics behave in this way.


Remove Left Hand Sidebar

The left-hand sidebar and the drop-down profile menu in the upper-right hand corner are essentially redundant. To free up more screen space, remove the left-hand sidebar from all views.

Is there an idea of what else would want to live in this page? Personally I feel as though the left hand side bar is more easily navigable than the top right drop down, and gives the ability for us to add more pages in the future. If this existed in the top right drop down, this list would get long and complicated in such a compact space. I feel like the concept of an easily accessible Navbar is necessary. As an alternative, we could have this left hand as a hamburger type menu that is collapsed by default. Something like this https://daisyui.com/components/drawer/#drawer (click open drawer). Thoughts @chrissantillan @pd3000 ?

@calisio I have no problem with using a left-hand drawer, or even a left-hand menu that collapses to just the icons in a narrow sidebar (v1 had that feature. The sidebar would collapse to just the icons, including the logo, which reduced in size as well. Whatever we can do to reclaim some of that real estate on the left-hand side (for what TBD, perhaps to show more Pick Up Where You Left Off courses, for example)

Amazing. I'll look into a collapsable option then!

Per our discussion @calisio and @jtucholski, left-hand sidebar should, similar to Notion's sidebar, should have collapsible functionality. The left-hand sidebar will be in the open (locked) position by default. A user should be able to:

toggle the sidebar closed via clicking a << icon or hamburger icon at the top of the sidebar (perhaps appearing only when user hovers on sidebar like in Notion?). Doing so would collapse sidebar and reduce the logo to an icon in the upper left-hand corner of view with hamburger icon to the right of that
Hovering on the hamburger icon would reveal sidebar as a flyout. Hamburger icon replaced with >> icon
Hovering on the flyout sidebar would keep the sidebar in place
Clicking on the >> icon would lock the sidebar in place


Pub/Sub: Update docs to be clear about threading.

Fixes #4607.

@dpebot will you merge when tests pass?


Report when a dependency doesn't compile

I've refactored some code in my Types.hs, which broke module B, which my module A was dependent on. I was puzzled on why intero wouldn't report a status on B - when I fixed A, it compiled again. So it would be nice to have intero report an error on the import which imports a failing module.

This is really a limitation of Flycheck, for which Chris submitted a large PR that never got merged. It got picked up later and refreshed, but still failed to get merged.

Now fixed upstream in Flycheck via https://github.com/flycheck/flycheck/pull/1427, w00t!


Update to embedded-hal v1.0

At this point embedded-hal v1.0 has been out for several months now. Is there a good reason to stay on embedded-hal v0.2.4 for this crate? If not, upgrading should be considered in the near future.

The serial::Read and serial::Write traits have been removed from embedded-hal v1.0 and the crate already implements Read and Write from embedded-io, so in a way it supports both v0.2.4 and v1.0.0.


Maintaining a shared draw state library

There are 2 commonly used graphics API at the moment: Gfx and Glium. One problem when abstracting over these libraries, is that you might depend on some specific trick with z-buffer, stencil buffer and blending functions to achieve an effect. Instead of creating another abstraction of this, perhaps we Gfx and Glium could depend on a shared draw state library that works with both?

Gfx's draw state consists of concrete types only
https://github.com/gfx-rs/gfx-rs/blob/master/src/device/state.rs
https://github.com/gfx-rs/gfx-rs/blob/master/src/render/state.rs

Glium's draw state uses some traits, and @tomaka is planning to add some feedback abstraction https://github.com/tomaka/glium/blob/transform-feedback/src/draw_parameters.rs#L440

When looking over both structures, I notice that they use an struct that combines lots of enums. While enums are good individually, it might be beneficial to pack the overall structure more efficiently, and use methods to extract the information into enums.

To solve the clipping problem for Conrod and piston-graphics, we need to control the stencil buffer, and then we have two options:

We can create a high level API that the back-ends implement
We can build a more direct mapping to hardware accelerated features, and let libraries handle their own clipping logic

I've created a new repo to do some experiments https://github.com/PistonDevelopers/draw_state

Whether Gfx or Glium converges is perhaps not relevant at this point. We might need a such library whether that happens or not.
Perhaps this discussion should be delegated to find a good abstraction instead?

I've discussed this with @kvark . The problem is that piston-graphics is useful as it is, but once we need something more advanced, we need control over the whole draw state. Gfx is targetting cross-API and already thought through some of the problems. If we refactor Gfx's draw state into a separate library and maintain it under Gfx, and try to map as best as we can in glium_graphics, then we can pass in Option<DrawState> to the BackEnd trait in piston-graphics. This will solve the problems we have now in Conrod. Later on, we can switch to something else, or perhaps redesign a bit, but designing this upfront is hard. There is so much else to do right now, so sorry about going with the lazy solution. It is the first time Piston favors an API toward another, but because the draw state structure in principle will be decoupled from the major part of Gfx it should not be a problem.

I'll delete https://github.com/pistondevelopers/draw_state 1 week from now unless there are objections.

Repo deleted. Closing.


Support for generics

With the support for the CustomQuery and CustomMsg we can define chain specific Contracts and Interfaces.
We should also add support for generics to allow chain generic Contracts and Interfaces to work with custom queries and messages.
Expand current generic support for interface macro
Interface macro should parse bounds defined on trait and generate messages with them. We should keep current CheckGenerics functionality to filter generics used for execute and query messages for API clarity.
Also generics are currently not used in case of features like Querier and should be propagated everywhere needed.
#[interface]
pub trait MyInterface<ExecParam, QueryParam>
where
    ExecParam: CustomMsg,
    QueryParam: CustomMsg,
{
    type Error: From<StdError>;

    #[msg(exec)]
    fn exec(&self, ctx: ExecCtx, param: ExecParam) -> StdResult<Response>;

    #[msg(query)]
    fn query(&self, ctx: QueryCtx, param: QueryParam) -> StdResult<String>;
}

Generic return type
It might be that in current shape cosmwasm_schema::QueryRespones returns attribute does not support generic return type. It has to be checked and if needed implemented in cosmwasm-schema.
Otherwise it should be an easy task. Parsing return type in CheckGenerics should do the trick.
Because generic param in message structure will be used only in #[returns] attribute it will fail to compile with generic unused error. Most likely we will have to generate phantom variant for that, possibly with std::convert::Infallible.
pub enum ExecMsg<ExecParam> {
    _Phantom(std::marker::PhantomData<ExecParam>),
    Exec { },
}

Unfortunately this approach will pollute schema.
"execute": {
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "ExecuteMsg",
  "oneOf": [
    {
      "type": "object",
      "required": [
        "__phantom"
      ],
      "properties": {
        "__phantom": {
          "type": "object",
          "required": [
            "param"
          ],
          "properties": {
            "param": {
              "type": "string"
            }
          },
          "additionalProperties": false
        }
      },
      "additionalProperties": false
    },
    {
      "type": "object",
      "required": [
        "exec"
      ],
      "properties": {
        "exec": {
          "type": "object",
          "additionalProperties": false
        }
      },
      "additionalProperties": false
    }
  ]
},

Create trait to track message types of interface
While implementing Interface on Contract there is a need to distinguish exec and query generics. It would mean that our API would look like this:
#[contract]
#[messages(my::module: exec(Msg: msg + bonds), query(Param: query + bonds)]
impl MyContract {}

It would be an inconvinience for the user to track which generic params are used with which message. Especially once new messages would be introduced to the Interface there would be a need to reevaluate which generic params should be added to which messages.
To avoid this issue we will introduce sylvia::Interface trait which will hold interface message types.
pub trait Interface {
    type Exec;
    type Query;
}

interface macro will then generate struct generic over params used by the user and implement this Interface trait on it.
It should look something like this:
pub struct Interface<ExecParam, QueryParam> {
    _phantom: std::marker::PhantomData<(ExecParam, QueryParam)>,
}

impl<ExecParam, QueryParam> crate::sylvia::Interface for Interface<ExecParam, QueryParam> {
    type Exec = ExecMsg<ExecParam>;
    type Query = QueryMsg<QueryParam>;
}

pub trait Interface<ExecParam, QueryParam> {
    type ExecMsg<ExecParam>;
    type QueryMsg<QueryParam>;
}

Implement generic interface on contract
Now that we have support for generic interface and also Interface helper type generated we can allow user to implement it on the Contract. Thanks to Interface helper type we don't have to use the current implementation and we will just require user to provide all generic types in messages attribute.
#[contract]
#[messages(iface<String, u32> as MyInterface)]
impl MyContract { }

In case of implementation Interface on Contract we should be able to avoid adding generic types in messages attribute as we will be able to extract them from impl block structure.
#[contract]
#[messages(iface as MyInterface)]
impl MyInterface<String, u32> for MyContract {}

Implement multiple generic interfaces on contract
User might want to implement multiple Interfaces on the Contract. In such case generic types will also be provided via messages attribute.
#[contract]
#[messages(iface<String, u32> as MyInterface)]
#[messages(another<MyMsg> as Another)]
impl MyContract { }

Behavior should not change here and forwarding generic attributes from messages should work the same as in case of a single generic interface.
The only issue might appear in ContractExecMsg and ContractQueryMsg generation. Here proper test has to show that generics are properly concatenated
Support generics on Contracts
User might want to define the Contract to store some generic data. We should support this case.
We should use CheckGenerics functionality here to block generics from being forwarded to generated messages and use these generics only when reffering to Contract in generated code.
pub struct MyContract<UserData> {
    pub user_data: UserData,
}

#[contract]
impl<UserData> MyContract<UserData> { }

User might also want to generate generic contract messages.
pub struct MyContract<ExecParam> where ExecParam: CustomMsg {
    pub _phantom: PhantomData<ExecParam>,
}

#[contract]
impl<ExecParam> MyContract<ExecParam> where ExecParam: CustomMsg {
    #[msg(query)]
    fn query(&self, ctx: QueryCtx) -> Result<> {}
    #[msg(exec)]
    fn execute(&self, ctx: ExecCtx, param: ExecParam) -> Result<> {}
}

// Generated messages
pub enum QueryMsg {
    Query {},
}

pub enum ExecMsg<ExecParam> {
    Execute {param: ExecParam},
}

impl<ExecParam> ExecMsg<ExecParam> where ExecParam: CustomMsg {}

Implement non-generic Interface on generic Contract
Below example should not require any additional work. ContractQueryMsg<T> should be able to "dispatch message further" to the Interface.
pub struct MyContract<T> {}

#[contract]
#[messages(iface as MyInterface)]
impl<T> MyContract<T> {
    #[msg(query)]
    fn query(&self, ctx: QueryCtx, param: T) -> Result<> {}
}

#[contract]
#[messages(iface as MyInterface)]
impl<T> MyInterface for MyContract<T> {
    #[msg(query)]
    fn ifce_query(&self, ctx: QueryCtx) -> Result<> {}
}

Entry points
entry_points macro has vision over all attributes and body of impl block so we will be able to extract all generics required.
pub fn execute<ExecParam>(
    deps: sylvia::cw_std::DepsMut<sylvia::cw_std::Empty>,
    env: sylvia::cw_std::Env,
    info: sylvia::cw_std::MessageInfo,
    msg: ContractExecMsg,
) -> Result<sylvia::cw_std::Response<sylvia::cw_std::Empty>, sylvia::cw_std::StdError> {
    msg.dispatch(&Contract::<ExecParam>::new(), (deps, env, info))
        .map_err(Into::into)
}

Update docs
Describe usage of generics in sylvia-book and README.
Tasks split

[ ] #224
[ ] #225
[ ] #233
[ ] #226
[ ] #227
[ ] #228
[ ] #229

One comment about entry points - they cannot be generic at the end of the day. There has to be concrete monomoprhisation to be called in the entry points. I would see #[entry_points<Generic, Arguments>] form for generic contracts.


Improve parsing for add and schedule

Initially, I wanted to reject other formats other than

add a task name
add do something by (time)
add attend something from (time) to (time)
so things like
add read something to (time) will fail but the problem is natty reads number as time (so it does not help when we try to add back to the title string)
This fails:add i have alot of things to do for 2103

What we can do

acknowledge that it will be wrong. provide ways to overcome it e.g. don't parse what is enclosed in inverted commas etc
check for a) by or b) from+to otherwise c) add everything to the task string. No throwing incorrect command format.
Make it compulsory to use /by or -by instead

comment here or update user guide on implementation

I like option 2. Here's what we can do:
Either of these criteria must be true:

command has both from && to
command has one by

If either of them are not true, we take the entire command as a name string

Remember to add it back to the task string. Usually we don't and we shouldn't if it can be parsed as a date time

I found out why the use case wasn't working!
The parser takes the input do for 2103 and returns a DateTime object for today 9:03pm.

Wait never mind, this is what you already said originally

and nothing will fix add copy notes from cs2101 to cs2103.
natty think it is 2 years 👎

i think just accept that there is an error. but there must be a way for the user to input add "copy notes from cs2101 to cs2103". like don't read between inverted commas.

Will do. Working on "" support

can normal tasks have inverted commas in their name then? some of our screenshots have a task: return "Animal Farm". might need to change afterwards


How to use it?

Comment:
Hi! I'm an HPC user, and I intend to use cartopy with this offline base.
How does it works? I am failing to find documentation on this.

@ricardobarroslourenco, you're right, unfortunately there isn't a good place to document this.
You just install the conda package, which includes the data that cartopy would otherwise download on demand. An environment variable is set when the conda environment gets activated (so don't use the base environment, since I don't think the activation script gets called there) that point cartopy to the data.


When first digit of generated pin is 0, it is being handled as octal number

As the title says, there are some times when the first digit of the randomly generated One Time Pin is 0. In those cases, Java handles the integer as octal, and the generateOneTimePassword method returns the decimal value of the octal number generated.
For example, if generateOneTimePassword generates 012345 (6 digits), it will return the integer 5349 (4 digits), which is the decimal representation of the octal 012345.
Related issues:
https://github.com/jchambers/java-otp/issues/14
https://github.com/jchambers/java-otp/issues/4
Workaround, as stated in issue #14 :
String oneTimePasswordString = String.format("%06d", oneTimePassword);

I'm sorry—I'm not quite following. generateOneTimePassword returns an int, which has no notion of the base in which it's represented. Can you provide a test case that demonstrates the problem?

Thanks for the prompt reply. I don't have a specific test case, I just assumed this behaviour after noticing that the generated pin consists of 5 digits (when TimeBasedOneTimePasswordGenerator was constructed with the default passwordLength=6 ) and reading https://stackoverflow.com/questions/35521278/what-does-an-integer-that-has-zero-in-front-of-it-mean-and-how-can-i-print-it
Just FYI, after generating 100 pins that were supposed to be 6 digits, 13 of them had 5 digits. Some of them, like 23698 equal with a 6-digit octal number that starts with 0 (056222) but some others don't.
TL;DR
My initial guess was that if the generated pin is 23698, then the algorithm actually produced  int 056222  and then Java automatically converted 056222 to 23698, but that doesn't seem to be the case.
Nevertheless, I have a strict requirement that my service should always generate 6-digit pins, so I will manually add leading zeroes if a 5-digit pin is created.

This is not a bug, and is explained in detail in https://github.com/jchambers/java-otp/issues/14#issuecomment-657075722.
There is no octal conversion happening. Looking ahead, if you're trying to parse strings into integers for verification, I'd recommend specifying a radix to avoid unwanted octal conversion:
final int code = Integer.parse(codeString, 10);


aseprite: 1.3.2 -> 1.3.6

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/aseprite/aseprite/releases.
meta.description for aseprite is: Animated sprite editor & pixel art tool
meta.homepage for aseprite is: https://www.aseprite.org/
Updates performed

Version update

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.3.6 with grep in /nix/store/vhaz646dip4v7j4sh2f0224dj08kr7dd-aseprite-1.3.6
found 1.3.6 in filename of file in /nix/store/vhaz646dip4v7j4sh2f0224dj08kr7dd-aseprite-1.3.6

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
aseprite

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/vhaz646dip4v7j4sh2f0224dj08kr7dd-aseprite-1.3.6 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A aseprite https://github.com/r-ryantm/nixpkgs/archive/e014052f61e6e4c39b827ac30ec1222e769b592e.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/e014052f61e6e4c39b827ac30ec1222e769b592e#aseprite

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/vhaz646dip4v7j4sh2f0224dj08kr7dd-aseprite-1.3.6
ls -la /nix/store/vhaz646dip4v7j4sh2f0224dj08kr7dd-aseprite-1.3.6/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

aseprite

Maintainer pings
cc @orivej for testing.

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

1 package built:

aseprite


/memo/program does not build "feature edition2021 is required"

`phil@phil-desktopubuntu-18-04-1-lts:~/sol-workspace/solana-program-library/memo/program$ rustup default nightly && rustup update
info: using existing install for 'nightly-x86_64-unknown-linux-gnu'
info: default toolchain set to 'nightly-x86_64-unknown-linux-gnu'
nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.61.0-nightly (8d60bf427 2022-03-19)
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: checking for self-updates
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.59.0 (9d1b2106e 2022-02-23)
nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.61.0-nightly (8d60bf427 2022-03-19)
info: cleaning up downloads & tmp directories
phil@phil-desktopubuntu-18-04-1-lts:~/sol-workspace/solana-program-library/memo/program$ cargo build-bpf
BPF SDK: /home/phil/.local/share/solana/install/releases/1.7.11/solana-release/bin/sdk/bpf
Running: rustup toolchain list -v
Running: cargo +bpf build --target bpfel-unknown-unknown --release
error: failed to download solana-frozen-abi v1.9.9
Caused by:
unable to get packages from source
Caused by:
failed to parse manifest at /home/phil/.cargo/registry/src/github.com-1ecc6299db9ec823/solana-frozen-abi-1.9.9/Cargo.toml
Caused by:
feature edition2021 is required
consider adding cargo-features = ["edition2021"] to the manifest`
$rustc --version
rustc 1.61.0-nightly (8d60bf427 2022-03-19)
phil@phil-desktopubuntu-18-04-1-lts:~/sol-workspace/solana-program-library/memo$ git status
On branch master
Your branch is up to date with 'origin/master'.

I had to update Solana then it worked sh -c "$(curl -sSfL https://release.solana.com/v1.9.13/install)"


error: moving a temporary object prevents copy elision on make check

Following the build instructions in the readme. gclient sync worked fine, but make -C certificate-transparency check produces the following:
  CXX    cpp/proto/serializer_v2.o
cpp/proto/serializer_v2.cc:97:10: error: moving a temporary object prevents copy elision
      [-Werror,-Wpessimizing-move]
  return std::move(OID(oid));
         ^
cpp/proto/serializer_v2.cc:97:10: note: remove std::move call here
  return std::move(OID(oid));
         ^~~~~~~~~~        ~
cpp/proto/serializer_v2.cc:114:10: error: moving a temporary object prevents copy elision
      [-Werror,-Wpessimizing-move]
  return std::move(OID(oid));
         ^
cpp/proto/serializer_v2.cc:114:10: note: remove std::move call here
  return std::move(OID(oid));
         ^~~~~~~~~~        ~
2 errors generated.

I'm on Ubuntu 12.04 LTS.
Relevant versions:
$ clang++ --version
clang version 3.9.0-svn274430-1~exp1 (trunk)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ cmake -V
cmake version 3.2.3

Any ideas? Thanks!

Luckily for you, I think commit e11013b75b01e94aeaaea0555aa316c568a04a00 might have fixed that?
Could you give that a try and either close this or let us know if it didn't? Thanks!


Android - Chat - Deleted message is displayed for brief moment after back online

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Issue found when executing PR https://github.com/Expensify/App/pull/10780
Action Performed:

Launch the app
Log in with expensifail account
Select any user
Send message
.Go offline and delete that message
The message should not disappear but instead appear with a strike-through
Go online, the message should disappear

Expected Result:
Deleted message should disappear after back online
Actual Result:
Deleted message is displayed for brief moment after back online
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web
iOS
Android
Desktop App
Mobile Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: No -new feature
Email or phone of affected tester (no customers): any
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/93399543/188166297-95d68c2c-091e-48f4-8c48-2806e03e7ba5.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

Hey @tgolen, I think we can quickly fix this by using the reportAction's  pendingAction field inside the reportActionItem or reportActionItemFragment or maybe OfflineWithFeedback.
We can check if the reportAction is a comment and something like pendingAction === styles.offlineFeedback.deleted && !props.network.isOffline and render the text as an empty string in that case!
I can take this if that's ok or it can be an External issue too!

@PauloGasparSv Feel free to gab and work on it

Same issue from here: https://github.com/Expensify/App/issues/10753


Parity Trace

check what is missing for Parity to work with remix

[ ] Trace
[ ] Preimage
[ ] StorageRangeAt

@5chdn


Wave 4 ship icons

Added the URLs for the icons for new ships in wave 4. The URLs are taken from the official squad builder.

Thanks!

The icon URLs are part of a bigger change and will be merged together with other changes in this PR: https://github.com/guidokessels/xwing-data2/pull/299
So I'll close this one to prevent any merge conflicts :)


[ADAM-1664] Add SUPPORT.md file to complement CONTRIBUTING.md.

Fixes #1664.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2448/Build result: FAILURE[...truncated 15 lines...] > /home/jenkins/git2/bin/git fetch --tags --progress https://github.com/bigdatagenomics/adam.git +refs/pull/:refs/remotes/origin/pr/ # timeout=15 > /home/jenkins/git2/bin/git rev-parse origin/pr/1781/merge^{commit} # timeout=10 > /home/jenkins/git2/bin/git branch -a -v --no-abbrev --contains 7f5d034023858515e94104a01b54c89feef31fb0 # timeout=10Checking out Revision 7f5d034023858515e94104a01b54c89feef31fb0 (origin/pr/1781/merge) > /home/jenkins/git2/bin/git config core.sparsecheckout # timeout=10 > /home/jenkins/git2/bin/git checkout -f 7f5d034023858515e94104a01b54c89feef31fb0First time build. Skipping changelog.Triggering ADAM-prb ? 2.6.2,2.11,1.6.3,centosTriggering ADAM-prb ? 2.6.2,2.11,2.2.0,centosTriggering ADAM-prb ? 2.6.2,2.10,1.6.3,centosTriggering ADAM-prb ? 2.6.2,2.10,2.2.0,centosTriggering ADAM-prb ? 2.7.3,2.10,2.2.0,centosTriggering ADAM-prb ? 2.7.3,2.10,1.6.3,centosTriggering ADAM-prb ? 2.7.3,2.11,1.6.3,centosTriggering ADAM-prb ? 2.7.3,2.11,2.2.0,centosADAM-prb ? 2.6.2,2.11,1.6.3,centos completed with result FAILUREADAM-prb ? 2.6.2,2.11,2.2.0,centos completed with result FAILUREADAM-prb ? 2.6.2,2.10,1.6.3,centos completed with result FAILUREADAM-prb ? 2.6.2,2.10,2.2.0,centos completed with result FAILUREADAM-prb ? 2.7.3,2.10,2.2.0,centos completed with result FAILUREADAM-prb ? 2.7.3,2.10,1.6.3,centos completed with result FAILUREADAM-prb ? 2.7.3,2.11,1.6.3,centos completed with result FAILUREADAM-prb ? 2.7.3,2.11,2.2.0,centos completed with result FAILURENotifying endpoint 'HTTP:https://webhooks.gitter.im/e/ac8bb6e9f53357bc8aa8'
Test FAILed.

Would it make sense to remove some of these contact links from the readme and to just point to SUPPORT.md?

Yeah, the README and CONTRIBUTING.md could use a bit of an update after this and #1780 are in.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2449/
Test PASSed.

@heuermh do you want to make those changes now? At the least, this is a good PR to update CONTRIBUTING.md in.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/2451/
Test PASSed.

Merged! Thank you @heuermh!


fsh-csv cabal can't find

The csv parser you mentioned in the README.md doesn't show up in cabal. Has it been created yet? Or is it just not in cabal?

It has been created and is up on hackage actually. Here is the link
Cheers!


RFC: project initialization, module creation, and the Git Root

The current process to create an FTL project follows. The result is an ftl-project.toml file and a module mymodule.
git init .
ftl init go . mymodule

FTL currently makes an assumption that a project is in a Git repository, so commands such as ftl init will fail if git init is not run first. This made sense when the ftl-project.toml file wasn't required, since the root of the project was assumed to be the Git root, but when a single ftl-project.toml file is required, does this still make sense?
Up until recently, ftl init only created a module, since ftl-project.toml was not required. It now creates a ftl-project.toml file in addition to a module mymodule. Does it still make sense to overload the init command?
Proposal: separate out ftl init from a new command, something like ftl module.
ftl init .
ftl module go mymodule

Here, ftl init would create a ftl-project.toml file, and maybe create a git repository if one doesn't exist?

Option 1: create a git repository, with .gitignore etc as we do now
Option 2: prompt the user about creating a git repository
Option 3: don't create a git repository, and no longer rely on there being a Git root

In this case, to find the project root, we'd walk up the dir tree until we find an ftl-project.toml

Does this seem cleaner?

Nice! Thanks @safeer
Maybe we should consider having ftl module be a top level command with some sub commands like new? It might be useful for future module focused commands as well perhaps.
ftl module new go . mymodule

It's a bit more verbose, but could leave room for future commands.

I agree the new requirement doesn't work well in some cases, but I think we can still keep just ftl init and simply create an ftl-project.toml file in the current working directory if one isn't found.
The rationale is that if a file is manually created we want to use it, but we also want to pick a default location when possible.
Have a look at #1784, the semantics are the following:
The semantics are the following:

If the FTL_CONFIG environment variable is set, it is used directly.
Otherwise the parent directories are searched for an existing file.
If not found and a git root is present, ${GIT_ROOT}/ftl-project.toml is returned whether the file exists or not.
Finally if not found elsewhere, the current directory is used whether the file exists or not.

Basically under all circumstances, a config file path will be returned.
I think this makes sense, and will give a decent user experience WDWT?

OTOH maybe it is preferable to have separate "init" and use phases, akin to "git init ." and "git add foo".
How about this to create the ftl-project.toml:
ftl init <dir>

And just:
ftl new <module>

To create a new module in the current directory?

Actually this will be nice too, because we can expose all of the undocumented config entries like module-dirs and startup as flags to ftl init, and can set ftl-min-version.
I think this is a good idea.

I don't think it should create a git repo, but what Hermit does is that if a git repo exists, it will add the newly created files to git automatically, unless --no-git is passed.

Actually this will be nice too, because we can expose all of the undocumented config entries like module-dirs and startup as flags to ftl init, and can set ftl-min-version.

I'm digging it.

Basically under all circumstances, a config file path will be returned.

So in a world with a separate ftl init phase and a required ftl-project.toml, would it make sense to error out if the file isn't found instead of an implicit creation? This would funnel all project file creation through a single path which seems like it'd  make reasoning easier

I don't think it should create a git repo, but what Hermit does is that if a git repo exists, it will add the newly created files to git automatically, unless --no-git is passed.

I dig this too. Supporting FTL outside of a git hierarchy would also mean making .gitignore updates conditional and removing usage of the git root entirely, I believe?

One thing I've noticed that the scaffolding, specifically for Hermit's bin/ directory is language specific. I was hoping to move that to the ftl init phase but that would require specifying the language i.e. ftl init go
This won't really work if we support different languages in the same project- is that the case?
Any thoughts on whether scaffolding should be left in the ftl new go phase? Just would be nice to move that --hermit flag to init :)

I'm thinking that there should be some scaffolding during ftl init . --hermit that at leasts brings things into bin/ like: hermit, hermit.hcl, README.hermit.md, the ftl* symlinks, etc
Then when ftl new go . mymodule is run, if there is a bin/ it will pull in the Go specific tooling: go, gofmt
And ftl new kotlin . myothermodule would do the same if there's a bin/ and pull in the Kotlin tooling: jar, javac, mvn, etc.
This way the hermit flag is only specified at init and future language tooling would be additive. Thoughts?

Yeah that sounds reasonable to me. We could also add hermit = true to the ftl-project.toml file.

So in a world with a separate ftl init phase and a required ftl-project.toml, would it make sense to error out if the file isn't found instead of an implicit creation? This would funnel all project file creation through a single path which seems like it'd make reasoning easier

Definitely. I think we just search ancestor directories to find the config, and if not found we error.

I don't think it should create a git repo, but what Hermit does is that if a git repo exists, it will add the newly created files to git automatically, unless --no-git is passed.

I dig this too. Supporting FTL outside of a git hierarchy would also mean making .gitignore updates conditional and removing usage of the git root entirely, I believe?

Use of git should  be conditional currently, and should remain so yeah.


WIP: Add EventSender interface and GooglePubSubSender

@lndbrg @spotify/helios-team

We should add this to the ZookeperAgentModel too @zalenski

should add this to the ZookeperAgentModel too

added to ZookeperAgentModel too

Current coverage is 46.37% (diff: 100%)

Merging #1024 into master will decrease coverage by 4.66%

@@             master      #1024   diff @@
==========================================
  Files           271        107    -164
  Lines         13064       5095   -7969
  Methods           0          0
  Messages          0          0
  Branches       1694        858    -836
==========================================
- Hits           6669       2363   -4306
+ Misses         5891       2514   -3377
+ Partials        504        218    -286

Powered by Codecov. Last update d37e26c...d8fa83c

@mattnworb Do you recognise the error:
java.lang.SecurityException: class "javax.servlet.Filter"'s signer information does not match signer information of other classes in the same package ??

@zalenski no that is new to me. I tried to check out your branch and run mvn clean compile and I don't see it. Can you post the full output to a gist maybe?

@zalenski - it looks like com.google.cloud:google-cloud-pubsub:0.5.1 drags in a transitive dependency on javax.servlet:servlet-api:2.5 (via com.google.api-client:google-api-client-appengine, of all things - google-cloud-core seems to have a ton of auth-related dependencies). This causes the SecurityException because some of the servlet classes are loaded from org.eclipse.jetty.orbit:javax-servlet:3.0 that dropwizard depends on.
This goes away if you add an exclusion to the pubsub library:
    <dependency>
      <groupId>com.google.cloud</groupId>
      <artifactId>google-cloud-pubsub</artifactId>
      <version>0.5.1</version>
      <exclusions>
        <exclusion>
          <groupId>javax.servlet</groupId>
          <artifactId>servlet-api</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

but then this causes a new error in those tests:
Caused by: java.lang.NoClassDefFoundError: com/google/protobuf/GeneratedMessageV3
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at com.google.pubsub.v1.PublisherGrpc.<clinit>(PublisherGrpc.java:41)
	at com.google.cloud.pubsub.spi.v1.PublisherSettings$Builder.<init>(PublisherSettings.java:462)

it seems that a depenency on riemann-java-client drags in a protobuf 2.5.0 library. You can probably exclude that as well as I do not think the riemann stuff is really even in use.

can probably exclude that as well

@mattnworb yup, seems to work

\o/ it builds

:+1:

I took a quick look and things look good. The design looks reasonable to me. Wondering if I'm not thinking of something obvious though.

:+1:

thanks again for all the changes and addressing the several rounds of feedback

\o/ it's merged! :)