test: add failing test on chain id conversion

Description
This PR is made in other to provide a failing example for issue https://github.com/dojoengine/dojo/issues/1595.
Related issue
https://github.com/dojoengine/dojo/issues/1595
Tests

[x] Yes
[ ] No, because they aren't needed
[ ] No, because I need help

Added to documentation?

[ ] README.md
[ ] Dojo Book
[x] No documentation needed

Checklist

[x] I've formatted my code (scripts/prettier.sh, scripts/rust_fmt.sh, scripts/cairo_fmt.sh)
[x] I've linted my code (scripts/clippy.sh, scripts/docs.sh)
[x] I've commented my code
[ ] I've requested a review after addressing the comments

Summary by CodeRabbit

New Features

Introduced a new test for validating chain ID conversions, focusing on edge cases with invalid UTF-8 representations.

Bug Fixes

Enhanced test coverage for chain ID conversion logic to capture potential issues, improving overall system reliability.

What is the status of this @glihm @greged93?

@Eikix im workin on this rn, i've identified why it still failing, just gonna add some more test now

@Eikix im workin on this rn, i've identified why it still failing, just gonna add some more test now

<3333 okk thx

@Eikix @greged93 ok this time it should definitely work as expected


dataset_utils.py _get_filenames_and_classes returns empty arrays

Hey Kwotsin,
Thanks for this repo! I really need something like this!
I found a little problem though, the _get_filenames_and_classes() function returns empty lists for both the photo_filenames and class_names, any idea what could be wrong?
Thanks in advanced!

Hi @Jowizo, from your problem description, it seems that you might have used a different dataset_dir from what is required. For example, you could have used /path/to/flowers/flowers_photos instead of /path/to/flowers as the dataset directory. You should try the dataset_dir argument with the folder one branch above what you are currently using.
For example:
flowers\
    flower_photos\
        tulips\
            ....jpg
            ....jpg
            ....jpg
        sunflowers\
            ....jpg
        roses\
            ....jpg
        dandelion\
            ....jpg
        daisy\
            ....jpg

@kwotsin You're absolutely right!!! Can't believe I made such a silly mistake, thanks so much for your help!! Love your blog, keep it up!!

Thank you for your encouragement! Glad you have found it useful :D

Thank you very much!@ @kwotsin

Hello, I have the same mistake but I don't understant your reply, Can you explain me with an example? Please.
#State your dataset directory
flags.DEFINE_string('dataset_dir', None, 'String: /home/jmz/Dataset_flowers')
#Output filename for the naming the TFRecord file
flags.DEFINE_string('tfrecord_filename', None, 'String: /home/jmz/Documentos/Crear_Dataset/flower.tfrecord')
I have this now.
I hope your comment.

Need Help I have image dataset of 26 folders............


Dual license

I'm wanting to include Bootstrap in a Drupal distribution that I'm working on. Because I'm using the Drupal.org packaging system, I cannot include Bootstrap because the APLv2 is not compatible with GPLv2 (which is what all code on Drupal.org must be licensed as, per our license policy: http://drupal.org/licensing/faq#q4)
I was wondering if you'd be willing to either release Bootstrap under another license (in parallel to the Apache license) that would be compatible with our packaging system, or license Bootstrap specifically to Drupal.org contributors under a compatible license.

I believe the code on Drupal.org is under the GPLv2 or later, which is fine.
"Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works." [1]
[1] - http://www.apache.org/licenses/GPL-compatibility.html

Nope - everything is licensed as GPLv2 right now. When the packaging system puts things together, it includes the GPLv2 license, and APLv2 cannot be relicensed as GPLv2.

Drupal.org is GPLv2-and-later.  We do not permit GPLv3-only code at this time.  APL is only compatible with GPLv3, not v2.
cweagans, you may want to see if we can allow a GPLv3 library via the auto-packager for distributions. I'm not sure if that team will accept a GPLv3 library in that case.  If not, then yes something GPLv2-compatible would be necessary.

I'm all for finding ways to make this work. There's pretty much no chance the bootstrap license will ever change. Is there a way we can have Drupal move to the newer version of GPLv3? http://www.gnu.org/licenses/gpl-faq.html#v3HowToUpgrade
I'd be willing to put in some cycles to talk to the right people over in Drupal land to make this work.

There's no chance of licensing it under an additional license? That is, it would be concurrently available under APL and (some other license that's compatible with our packaging system).
If not, I'd guess that Crell is at least one of the people to talk to - he's the licensing guy for the Drupal Association. He'd probably know who else to talk to about it. I imagine that there will be a significant amount of pushback on this, though...changing the license of Drupal and every single contrib project on Drupal.org is no easy task.

Changing Drupal's license from GPLv2 to GPLv3 would be a very simple change administratively/legally and a monumental task culturally.  It's not something that's going to happen any time soon, although I would like to see it happen eventually for various reasons.

I understand that pain well, isn't the GPL wonderful?
I would advise that the drupal.org community look at having module authors choose between the GPLv2 or v3 license, this would then allow folks to embed Apache licensed code into their projects without issues. The APLv2 is a very liberal license.
In the end, I'm all for making this work somehow. I mean, according the Drupal FAQ [1], you're able to redistribute Drupal under the v2 or v3 license of the GPL so I don't see why this is an issue to begin with.
[1] - http://drupal.org/licensing/faq#q1

Because there are GPLv2-only libraries out there that people want to be able to integrate as well. :-)  There's unfortunate subtly involved that I have the misfortune of having been the point person to sort out.
We want the code coming off of Drupal.org to always be legally compatible with code coming off of Drupal.org.  Many modules bridge to other 3rd party libraries.  Some of those are GPLv2 only, some are GPLv3 only.  Therefore, to get the widest possible compatibility we require that Drupal.org code be GPLv2-AND-later.  The option of which to use is made by the receiver, NOT the module developer.  It cannot be, or else you could end up with a GPLv2-only module and a GPLv3-only module, both on d.o, and then that's just a total fail because you couldn't distribute them together.
Yes, this causes issues for APLv2 code. Bootstrap is not the first time we've seen this.  At some point I do want us to move to GPLv3, but that is not on the table for the foreseeable future.  Licensing changes for Drupal.org are not worth discussing here, as that boat takes too long to turn.

I suspected that a licensing change for Drupal.org code would be painful, but I had to hold out hope. So, given that, is there any chance at all of distributing Bootstrap under an additional license that might be a little more friendly to our packaging system?
I know of at least three projects (including mine) that would love to be able to include Bootstrap, but cannot due to the license. http://drupal.org/project/twitter_bootstrap and http://drupal.org/sandbox/rerooting/1429486 and http://drupal.org/project/droptracker. I suspect that more projects would use Bootstrap if it were easily included by our packaging system.

Let's ask @caniszczyk about this stuff.

He's been commenting on this issue already ;)
It would be really awesome if Bootstrap could be distributed under anything compatible with the GPLv2 license along with the current Apache license.

Totally missed that one! Sounds like it's not really an issue then?

@markdotto, I don't follow. It's still certainly an issue - please read all of the comments on this issue.

Changing the license of Bootstrap isn't practical given that the APLv2 is already a very permissive license and already allows Bootstrap to be embedded in all sorts of commercial and non-commercial applications. I would advise that the Drupal community take a better stance on adopting the GPLv3 and the mixing of libraries. Technically, Bootstrap can be considered a separate program (or in Drupal's case, a module) so mixing it shouldn't be an issue depending on your interpretation. Also, Bootstrap can be used by folks who run Drupal modules on their own server. It's only in the case of drupal.org that this is an issue.
It would be good to start turning the boat sooner than later. It's nice to give your users a choice in the matter.

Sorry, I meant to say that this doesn't sound like an issue we can resolve easily. To expand on that though, I'm all for anyone and everyone using Bootstrap.  If @caniszczyk thinks it's kosher for us to have two licenses, so be it.

Technically everyone can given the terms of the APLv2, it's just that the GPLv2 puts drupal.org in a precarious situation since they are distributing code which triggers the nasty in the GPLv2. The APLv2 is a permissive license that is great for commercial development and proprietary redistribution. Code that is distributed under the APLv2 and other permissive licenses can be integrated into proprietary products and redistributed under a broad variety of other terms.

I'm not suggesting the the license for Bootstrap be changed. I'm suggesting that it's released under a dual-license. That is, when users download it, they'd be able to choose between the Apache license and (some other license). This practice is common, and is used by (as an example) jQuery and Sizzle (the library that jQuery uses for selectors). jQuery is released under the MIT license AND the GPL. Sizzle is released under the MIT, GPL, and BSD licenses. When you download, you choose which license you're going to use.
The problem with changing the license for the Drupal community is a very very large one. Not only would we be changing the license for core, but we'd also be changing the license for every single other module, theme, and installation profile posted on Drupal.org. There are currently around 16000 projects on Drupal.org and making that change is a multi-year ordeal, I'd guess.

That is, anyone who is still using Bootstrap under the Apache license can continue to do so. If Bootstrap were released under another license (in addition to the Apache license), then users downloading Bootstrap could choose to use that new license instead if they wanted to.

When I'm back in the office next week, I'll look at what we can do. We may be able to work something out where we license Bootstrap specifically to Drupal.org contributors only under a compatible license.
@Crell, can you email me at<EMAIL_ADDRESS>to start this discussion?

There's some talk of making the next Joomla admin template based on Bootstrap. Nothing's final and especially the license situation hasn't been discussed at all yet but we're pretty much in the same boat. If we make Joomla GPLv3 we basically force all extensions to change their license as well, some of them probably have some GPLv2 only code. Dual licensing bootstrap APLv2 and "GPLv2 or later" would certainly be very helpful.

For anyone that's interested, the related issue about adding Bootstrap to the Drupal.org packaging system is here: http://drupal.org/node/1445226

WordPress suffers the same doom as Drupal and Joomla... Dual Licensing would be awesome...


Add new provider autocompletion resource

@VladRassokhin, would it be possible to add autocompletion for Databricks provider?

It's enough to adjust terraform-metadata project to generate metadata for your provider. New provider definition needs to be added to providers.base.json.

I actually tried this for a 3rd party provider https://github.com/aiven/terraform-provider-aiven
I added
  "aiven": {
    "repository": "https://github.com/aiven/terraform-provider-aiven",
  },
  "keycloak": {
    "repository": "https://github.com/mrparkers/terraform-provider-keycloak",
  }

but I am not sure if this is correct since I am erroring
Cloning https://github.com/aiven/terraform-provider-aiven
make: *** [schemas] Error 128

And there is no error log

Would be good at somepoint to support terraform-ls to make autocompletion more dynamic

@VladRassokhin
Is there another way to add new custom schemas to be picked up by the plugin?
Currently, as you have mentioned, new schemas can be added terraform-metadata. But this needs to be done for every machine.
Asking 100s of engineers to clone this repo on their machines may not be the best idea. Also, we cannot add the internal schemas to this repo.
We customize IntelliJ IDEA for all our engineers and we do validate JSON files with certain schemas, and IntelliJ SDK has JsonSchemaFileProvider for us to add custom schemas.
If terraform plugin also exposes some extension points like this, that would be great.
Any plans to do that in future? Or some other approach?
Thank you.

Bump


libngspice: 26 -> 27

Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/libngspice/versions.
These checks were done:

built on NixOS
Warning: no invocation of /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/bin/cmpp had a zero exit code or showed the expected version
0 of 1 passed binary check by having a zero exit code.
0 of 1 passed binary check by having the new version present in output.
found 27 with grep in /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27
directory tree listing: https://gist.github.com/43fba9ac020f809f013db59765fd9838
du listing: https://gist.github.com/13ba48063ddf0d879f2fa09cdcb4bee8

meta.description for libngspice is: '"The Next Generation Spice (Electronic Circuit Simulator)"'.
cc @bgamari for testing.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: libngspice
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: libngspice
Partial log (click to expand)
shrinking /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/lib/ngspice/digital.cm
shrinking /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/lib/ngspice/xtraevt.cm
shrinking /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/lib/ngspice/spice2poly.cm
shrinking /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/lib/ngspice/xtradev.cm
shrinking /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/lib/libngspice.so.0.0.0
gzipping man pages under /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/share/man/
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/lib  /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27/bin
patching script interpreter paths in /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27
checking for references to /build in /nix/store/fagdv8kk8md9flgnx8m3azmkzpz6q1q1-libngspice-27...

Success on aarch64-linux (full log)
Attempted: libngspice
Partial log (click to expand)
shrinking /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/lib/ngspice/xtradev.cm
shrinking /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/lib/ngspice/analog.cm
shrinking /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/lib/ngspice/digital.cm
shrinking /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/lib/ngspice/spice2poly.cm
shrinking /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/bin/cmpp
gzipping man pages under /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/share/man/
strip is /nix/store/jk6j4lh9v5mvjdbdc35sj0zffhhf6s56-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/lib  /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27/bin
patching script interpreter paths in /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27
checking for references to /build in /nix/store/qxv50wkxkqdfzbh89k2m1rrkznqb8d8i-libngspice-27...

I have held off on doing this myself as I found that version 27 segmentation faults when used with Kicad's built-in simulator.

Closing as per above comment.


Fixed error

thanks @fedarko for the comments. I applied both your suggestions so the PR should be good to go.

Thanks @kwcantrell! This looks good to me.


Restore breakpoint for small quick nav windows

Bug/issue #, if applicable: rdar://108569652
Summary
Restore breakpoint for small quick nav windows, which sets the proper min-width when the window is narrow.
Testing
Manual testing

@swift-ci test


Common:Math Utils:add unit tests

Added unit tests for sigmoid,RotateAxis and other math functions in the utilities library.
Updated copyright header.

@SohamGhormade Thanks for the contribution! Could you fix the lint error in the commit ? You can run ./apollo.sh check to make sure you pass all build, test, and lint check before check-in.

@Capri2014 Thank you for catching.
I verified that lint passed for me locally.
i.e the issue should be fixed now.
Thanks!

@Capri2014
Two side questions:
Is there a check in window for merges in Apollo repo?If yes,from what time to what time?
If you have any suggestions of how I can contribute to the repo it would be appreciated.
I have contributed with unit tests and typos so far.
I am interested particularly in the perception and localization modules but am open to contributing to other modules as well.
Looking forward to hearing from you!
Thanks!

@ycool and @lianglia-apollo thanks for reviewing my pull request and merging it!
If you have any suggestions of how I can contribute to the repo I would highly appreciate it.
Thanks!
Background:

I have contributed by adding unit tests and fixing typos so far.
I am interested particularly in the perception and localization modules but am open to contributing to other modules as well.

Thanks both in advance for your time and attention.


Added Courses in Assembly Language Programming

What does this PR do?
Add resource(s)
For resources
Added Courses in Assembly Language Programming
Why is this valuable (or not)?
It is valuable because it offers free access to knowledge and skill development
How do we know it's really free?
It is free because it's available on YouTube.
For book lists, is it a book? For course lists, is it a course? etc.
Course
Checklist:

[x] Read our contributing guidelines.
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction).
[x] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

So happy you're back this year!

I’m thrilled to be back this year!


Remove getDOMNode(), deprecated and not required anymore

https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html#dom-node-refs

Thanks for pointing this out. I did a larger overhaul of the module and took this out, so it should be good now.


too many C levels (limit is 200) in function at line 84 near 'chunk'

Hi, after installing luasocket using luarocks on MacOS 10.12.1 (Sierra) got this error:
lua: /usr/local/share/lua/5.2/luarocks/loader.lua:117: error loading module 'socket' from file '/usr/local/share/lua/5.2/socket.lua':
    /usr/local/share/lua/5.2/socket.lua:88: too many C levels (limit is 200) in function at line 84 near 'chunk'

I'm not sure what is causing this error since I don't use LuaRocks. :/ @mascarenhas, can you help?

This is a Lua parser error for too much syntactical nesting, which is odd. @amochkin, could you post your luarocks/loader.lua and socket.lua here?

Is this still a problem?  Is the requested information forthcoming?
We're reviewing open items in preparation for a release.  If action is needed here, please add a comment.  Otherwise, this issue will be closed on or after 24-Feb-2019.
Thanks!


Add User Search Functionality

Describe the feature request
Problem Description:
Currently, the application lacks a search function that allows users to search based on username.
New Feature Description:
Implement a search functionality on the home page that enables users to input a username and retrieve relevant user information based on the search criteria. The search should return a list of results matching the search query.
Steps to Implement:
Add Search Input: Introduce a text input field on the home page for users to enter a username.
Implement Search Function: Develop a backend function to handle user input, perform username-based searches, and return corresponding results.
Display Search Results: Display search results appropriately on the home page, formatted to match user expectations.
Acceptance Criteria:
Users can input a username into the search input field.
Search results display a list matching the entered username.
Implementation integrates seamlessly into the existing application architecture.
Additional Information:
Include any technical specifications, UI design considerations, or other relevant details for implementing this feature effectively.
Ensure the description aligns with TaikoXYZ's development practices and standards for clarity and completeness. Adjust details as necessary based on project requirements and feedback from the team.
Spam policy

[X] I verify that this issue is NOT SPAM and understand SPAM issues will be closed and reported to GitHub, resulting in ACCOUNT TERMINATION.

Please provide me with a GitPOAP, please

@Rifkichrl with that spam you'll just land on a blacklist and will certainly not get a POAP.


Adding User Interface for Custom Keybindings

Introduction
First of all, thank you for the great plugin!
This amazing utility has helped me a lot and I am excited to contribute and add value to it.
Objective
The aim of this pull request is to introduce a user interface for custom keybindings.
Implementation

introduction of the following new global variables:

claude_implement_keybinding;
claude_open_chat_keybinding;
claude_send_chat_message_keybinding;
claude_cancel_response_keybinding;

creation of the SetupClaudeKeybindings function to setup all non-buffer-specific keybindings;
addition of new VimEnter autocmd to set the keybindings, following vim plugin guidelines;
Readme.md edit to let users know about this new configuration option;

Thanks! Makes a lot of sense, but wdyt about having a consistent prefix for the variables rather than the suffix, e.g. g:claude_map_implement etc.? (or keybinding instead of map, I thought map is a bit more standard terminology but i'm not a vim plugin guru though)

Yes! I agree. Map and prefixes are better indeed. Good call.

thx! the README is still using the old names though

Sorry for the oversight. Done

Thank you!

Glad to help


 Netty is one of the most popular libraries however there are a few limitations that make it impossible to use with native images out of the box. Adding a few metadata (in specific modules will allow the compilation to success and produce working binaries)
Modification:
Added properties files in META-INF and substitutions classes (under internal.svm) will solve the compilation issues. The substitutions classes are not visible and do not have a public constructor so they are not visible to end users.
Result:
Fixes #8959
This fix is very conservative as it applies the minimum config required to build:

pure netty servers
vert.x applications
grpc applications

The build is having trouble due to checkstyle which does not seem to be able to find the copyright notice on property files.

@netty-bot test this please

@pmlopes I need to adjust the Checkstyle rule... will let you know once done and once you can rebase. I the meantime is there any way to test that this works as expected ? Like make it part of the build to ensure we not break it again ?

I could add a new module like testsuite-native-image what builds a few examples but it would require a graalvm (community edition is fine) to be installed in the CI environment. Basically this can only be tested as a "integration test" as most of the changes are json/property files and the code that was added is just annotated classes without behaviour making unit testing really not possible.

@pmlopes I think that would be fine... Maybe just skip the test suite by default and then we can add a CI job which has everything setup to run these. WDYT ?

Sure, I'll work on it.

@pmlopes please rebase... We should now be able to correctly detect the copyright headers in the property files: https://github.com/netty/netty/pull/8967

@netty-bot test this please

@pmlopes let me know once you have the testing stuff added and I will see how to do the CI bit

@normanmaurer I've created the simplest white smoke test (which helped detecting a bug in the PR). The test suite is a hello world http server, that will fail to compile if the meta data is missing (the property files) or will fail to run (segfault) if the substitution classes are missing. Currently I added it as a sub module to the top top but I think that you need to help me fix as this should only run on a linux/mac with graalvm installed (not for everyone).

@olpaw could you have a look now that all the basic pieces are in place?

@pmlopes ok cool... I think what I would do is basically add an extra property which allows us to skip the test and only set it to true if we run it on the correct CI.
Something like:
https://github.com/netty/netty/blob/netty-4.1.34.Final/testsuite-autobahn/pom.xml#L67
https://github.com/netty/netty/blob/netty-4.1.34.Final/testsuite-autobahn/pom.xml#L85

This PR is now on hold until graal rc15 is out where the plugin will support skip configuration.
Depends: https://github.com/oracle/graal/issues/1113

@pmlopes just to be prepared can you let know what exactly should be installed to run the tests ?

@normanmaurer the tests are included in the top level pom as a submodule: testsuite-native-image
Once the rc15 plugin lands on central the skip directive will work, the variable name is skipNativeImageTestsuite to follow the other module style.
To test it then you really need a graalvm jdk (use graal 1.0.0-rc15 or later) and it's just the usuall stuff:
mvn clean verify

@pmlopes ok cool... will check and come back to you soon.

I've bumped the version of the plugin, however something went wrong with their release and there's one artifact missing on maven central: So we're again blocked by this: https://github.com/oracle/graal/issues/1148

@normanmaurer the missing bits from the maven plugin have landed on central, I belive this PR is finally ready. Let me know what is still missing!

@pmlopes ok cool... will check later today.

@netty-bot test this please

@normanmaurer the build failed in the tests for native image build because the host JDK isn't a graalvm jdk, the property skipNativeImageTestsuite needs to be added somewhere in order to disable it, or a special profile must be created for this i guess

@pmlopes can you update the PR to set it to false by default ? We will explicit set it to true on the CI that support it.

@pmlopes please add <skipNativeImageTestsuite>true</skipNativeImageTestsuite> to the parent pom.xml as default. We will add a profile to enable it on the CI that has graalvm installed

@normanmaurer done!

@netty-bot test this please

@trustin I've fixed all the indentation issues and white space. There are just 2 open questions, if I remove the copyright header on the properties files the checkstyle validation will fail. The copyright header in the testsuite is there just to keep it consistent with the remaning testsuites.
Please advise on how to proceed.

@johnou I've moved the System.exit outside the finally block as suggested!

@pmlopes great work!

@pmlopes please sign our ICLA and let me know once done + squash everything.
After this is done I can merge. Great work!

@normanmaurer done, squashed and signed the ICLA.

@pmlopes perfect... one last thing (sorry).
Can you just apply this diff to your patch and squash again:
diff --git a/pom.xml b/pom.xml
index 51b7f16dca..05f7e59c47 100644
--- a/pom.xml
+++ b/pom.xml
@@ -68,6 +68,19 @@
   </developers>

   <profiles>
+    <!-- Detect if we use GraalVM and if so enable the native image testsuite -->
+    <profile>
+      <id>graal</id>
+      <activation>
+        <file>
+            <!-- GraalVM Component Updater should exists when using GraalVM-->
+            <exists>${java.home}/bin/gu</exists>
+        </file>
+      </activation>
+      <properties>
+          <skipNativeImageTestsuite>false</skipNativeImageTestsuite>
+      </properties>
+    </profile>
     <!-- JDK13 -->
     <profile>
       <id>java13</id>
diff --git a/testsuite-native-image/pom.xml b/testsuite-native-image/pom.xml
index 5df8844c32..439f3b0209 100644
--- a/testsuite-native-image/pom.xml
+++ b/testsuite-native-image/pom.xml
@@ -21,7 +21,7 @@
   <parent>
     <groupId>io.netty</groupId>
     <artifactId>netty-parent</artifactId>
-    <version>4.1.35.Final-SNAPSHOT</version>
+    <version>4.1.36.Final-SNAPSHOT</version>
   </parent>

   <artifactId>netty-testsuite-native-image</artifactId>

This way the native testsuite will be run automatically if the CI uses graalvm to build :) Also I adjusted the version number as we released 4.1.35.Final in the meantime.

@normanmaurer wouldn't it make more sense to check for the existence of ${java.home}/bin/native-image to detect a GraalVM ?

Sure why not 👍

Am 18.04.2019 um 09:20 schrieb Paul Woegerer<EMAIL_ADDRESS>@normanmaurer wouldn't it make more sense to check for the existence of ${java.home}/bin/native-image to detect a GraalVM ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@normanmaurer @olpaw patch is applied and using native-image as check

@netty-bot test this please

@pmlopes thanks a lot again!


Add ability to parse and dump objects as the specified type

Change Summary
Adds the capability to parse and dump objects as a specified type.
This can be useful for the sake of dumping a model as though it were one of its superclasses in order to prevent inclusion of subfields, and works even with generic containers.
Related issue number
#811 (see that issue for more discussion/motivation)
Checklist
Although the tests currently pass with full coverage, I haven't thought about or added appropriate error messages in casing parsing/dumping fails, (and obviously haven't added any tests for those error messages).
Also, I'm aware that the current tests don't do a good job of stress-testing the capability; I'll add more once I get feedback about whether this might have a chance at getting merged.

[ ] Unit tests for the changes exist
[ ] Tests pass on CI and coverage remains at 100%
[ ] Documentation reflects the changes where applicable
[ ] changes/<pull request or issue id>-<github username>.rst file added describing change
(see changes/README.md for details)

I'm trying to get a beta for version 1 out the door asap, is this required for v1? Eg. does it have any breaking changes or just new functionality?

It’s not necessary for v1. Either way, I think it should be possible to add this functionality without any breaking changes.

Also yes I’ll do some profiling to make sure this isn’t causing perf regressions for non-consumers. I’ll try to think if there might be a way to do the casting separately from the dict-making; this would both simplify the code and ensure no perf implications for existing code.

@samuelcolvin I've recently gotten a lot of use out of the parse_as_type function when testing my apis, e.g.:
response = test_client.get(endpoint)
assert response.status_code == 200, response.json()
parsed_results = parse_as_type(response.json(), List[Result])

This same pattern is easy to use for any type of expected response, no matter what the shape of the expected response is.
(I just wanted to make it more concrete how the function is useful given some of your previously expressed concerns; I'm still planning to defer this PR until the more urgent v1.0 issues are resolved.)

@samuelcolvin I did a performance test (you can find it above if you ctrl+f for "with cython"). The changes I've added to this branch result in a ~15% speed up for typical dict serialization (i.e., without using include/exclude).
Removing the performance-improving changes, I noticed about a 2-3% performance decrease due to the checking of as_type. So I think that is an upper bound on how much slower things would go with include or exclude specified.
For the fastapi use case, I did a comparison of the current approach (parsing into an unrelated model and then dumping that) vs. the approach in this PR, and got a ~2.8x speedup. I think it would be nice if we could get that speed up in fastapi :)

I think this PR still needs two things:

Some more complex tests of the functionality to make sure it works as described
To make sure it handles pydantic dataclasses properly (presumably they should be supported?)

I'm going to close this PR now to clean up the outstanding pull requests, but I fully intend to get this functionality merged. Once #934 is closed I'll move the remaining changes from this PR into a new one that will hopefully be a little easier to reason about.


Event iterators stuck at the last event of a given type

Description
When iterating e.g. over the MC events the iterator seems to stuck at the last MC event low level block.
Reproduction
f = SimTelFile('path/to/test.simtel.gz')
n_total = 0
n_triggered = 0

for event_mc in f.iter_mc_events():
    n_total += 1

for event_array in f.iter_array_events():
    if event_array['type'] == 'calibration':
        continue
    if event_array['trigger_information']['n_triggered_telescopes'] > 0:
        n_triggered += 1

print(f'Total number of MC events: {n_total}')
print(f'Total number of triggered events: {n_triggered}')

yields smth like
Total number of MC events: 1000
Total number of triggered events: 1

while
f = SimTelFile('path/to/test.simtel.gz')
n_total = 0
n_triggered = 0

for event_array in f.iter_array_events():
    if event_array['type'] == 'calibration':
        continue
    if event_array['trigger_information']['n_triggered_telescopes'] > 0:
        n_triggered += 1

for event_mc in f.iter_mc_events():
    n_total += 1

print(f'Total number of MC events: {n_total}')
print(f'Total number of triggered events: {n_triggered}')

yields smth like
Total number of MC events: 0
Total number of triggered events: 1000

Environment
The test file is a dummy file for NSB study produced from dummy corsika events with 100 pedestal and 1000 MC events, all triggered. File was produced with corsika6.9_simtelarray_2018-11-07 SW release.
pyeventio is of the latest PyPi version
Possible fix
The function below (and alike) does not reset the iterator position before the loop.
https://github.com/cta-observatory/pyeventio/blob/c864d16dc5f537ff910517774fdb8fc91c9688a7/eventio/simtel/simtelfile.py#L203
Thus, without reloading the SimTelFile object it is not possible to iterate over it correctly more than one time.

This is impossible for many file types, e.g. zstandard compressed files. These are not backwards seekable, only forward. Gzip compressed files are a middle ground, where two implementations exist, one that is faster without backseeking and one where backseeking is possible but very slow.
So you will just need to open the input file again, if you start a new iteration.
If you are just interested in the total numbers of events that triggered and events that were simulated,
have a look into the histograms at the end of a file.
I agree that this is a bit surprising, I will look into if it is possible to improve this by raising an error or a warning if you attempt this.

Thanks for a reply. I provided the simplest possible example, just to show the behavior. Indeed, it was quite a bit surprising. Perhaps you can add a note or warning in the documentation?


Installed plugin, emacsIDEAs doesn't seem to be responding to any of its control commands

Hi, this looks like SUCH a great plugin and I really want to use it in my work, but I've tried again to install it (tried back in 2013 with similar results), and I can't tell that it does anything for me.
It doesn't appear like C-c has any effect - if I hit C-c a, IntelliJ just inserts an 'a', if I hit C-L [space], it just inserts a space. It appears that emacsIDEAs isn't responding at all to its initiation commands.
Am I missing any post-install instructions? I'm using a custom keymap that is a slight variation to the built-in Emacs keymap - do I need to use the built in keymap? Do you have any suggestions as how to proceed figuring out what the problem is?

hi @jmcmichael, Are you using in Windows?
if Yes,
firstly, please down the windows version:   https://raw.githubusercontent.com/whunmr/emacsIDEAs/master/emacsideas-windows.jar
secondly, by default Ctrl-c is mapping to COPY on windows, so there is a conflict. to fix this, remapping COPY to another shortcut key is needed.

hi @jmcmichael, any update?

@jmcmichael,  I will close this issue now. please reopen it if you still got problems when using this plugin.

Hey @whunmr , I am having the same issue. None of prefix keys work for me. I am on Ubuntu 16.04.


[Proof of concept] derive specs system

Relates to the RFC in issue #498. This allows you to do this:
#[specs_system(SysA)]
fn sys_a(mut pos: WriteStorage<Pos>, vel: ReadStorage<Vel>) {
    for (pos, vel) in (&mut pos, &vel).join() {
        pos.0 += vel.0;
    }
}

#[specs_system(SysPrint)]
fn sys_print(entities: Entities, pos: ReadStorage<Pos>, vel: ReadStorage<Vel>) {
    for (e, pos, vel) in (&entities, &pos, &vel).join() {
        println!("{:?}: Pos: {:?}   Vel: {:?}", e, pos, vel);
    }
}

// ...
let mut dispatcher = DispatcherBuilder::new()
    .with(SysA, "sys_a", &[])
    .with(SysPrint, "sys_print", &["sys_a"])
    .build();

and running this gives:
$ cargo run --example system_derive_with_components
    Finished dev [unoptimized + debuginfo] target(s) in 0.36s
     Running `target\debug\examples\system_derive_with_components.exe`
Entity(0, Generation(1)): Pos: Pos(2.0)   Vel: Vel(2.0)
Entity(1, Generation(1)): Pos: Pos(5.6)   Vel: Vel(4.0)
Entity(2, Generation(1)): Pos: Pos(6.9)   Vel: Vel(1.5)
Entity(0, Generation(1)): Pos: Pos(4.0)   Vel: Vel(2.0)
Entity(1, Generation(1)): Pos: Pos(9.6)   Vel: Vel(4.0)
Entity(2, Generation(1)): Pos: Pos(8.4)   Vel: Vel(1.5)

This change is

failed on stable, but I think it would work when 1.30 is out [1, 2, 3]. That means using this feature would bump the minimum rust version


Reorder passes as required for enforce-contract

Issue #, if available:
n/a
Description of changes:
Loop unwinding and contract replacement were previously performed after function contract enforcement. There was no dependence between these passes before. However, now they must be done before function contract enforcement:

Loop unwinding must be done before enforcing function contracts, since loop unwinding does not replicate writeset snapshots that might be introduced during contract enforcement step.
Function call replacement by contracts must be done before enforcing function contracts, since contract enforcement step inlines all function calls.

Note that since loop unwinding is now done much earlier, the loop "numbers" used in proof Makefiles might need to be changed.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The loop numbers need to be updated in proof Makefiles now.
Draft PRs on s2n-tls and aws-c-common:

https://github.com/aws/s2n-tls/pull/3096
https://github.com/awslabs/aws-c-common/pull/855

I guess we should discuss this change a bit more before merging.
Martin says (https://github.com/diffblue/cbmc/issues/6432#issuecomment-959405490) that the --unwind semantics on cbmc (which is what we currently use) is not the same as --unwind semantics on goto-instrument (which is what this PR proposes).

Per offline discussion on 11/10/2021 with @feliperodri and @tautschnig -- When we switch to unwinding with goto-instrument, we wouldn't need the +1 that we are currently doing because we pass --unwind to cbmc, but there's also no harm in unwinding "more" so we could just leave it that way in all our Makefiles.

The loop numbers need to be updated in proof Makefiles now. Draft PRs on s2n-tls and aws-c-common:
* [Bump aws-templates-for-cbmc-proofs aws/s2n-tls#3096](https://github.com/aws/s2n-tls/pull/3096)

* [Bump aws-template-for-cbmc-proofs aws-c-common#855](https://github.com/awslabs/aws-c-common/pull/855)

Is this the only blocker for this PR? @SaswatPadhi

Yes, and I have fixed the proofs for both these repos -- only changes to loop numbers was necessary. I can push the fixes in a bit, but similar loop-numbers changes will be necessary in all repos that use starter kit when we move the submodule pointer forward.

If there are other important PRs that need to go it first, then we could merge those first and move starter kit pointer forward. Then merge this and move the pointer forward along with several changes to loop numbers.

I've added a third commit 688d5d5e that restores loop unwinding to the invocation of cbmc and added a comment to the invocation of goto-instrument doing the loop unwinding explaining what is going on.


Flowser: Interact Screen + Blocto & FlowFan's collections integration + UI & Technical updates

Flowser: Interact Screen + Blocto & FlowFan's collections integration + UI & Technical updates
Grant category
Please select one:

Developer tools / services

1. Milestones & Tasks
1.1. Interact Screen
Problem: During (Flow) blockchain development, you often need to switch between multiple programs (your IDE, Flow CLI, Flowser,..), which can negatively impact your developing flow and productivity.
For example, you may edit the contract source code (in your IDE), redeploy this code (Flow CLI super commands will automatically handle this), test it out by executing some transaction/script (in Flow CLI), and review blockchain state (in Flowser).
This mental context switching is expensive, so ideally, you’d want to use as few tools as possible - your IDE for code writing, Flow CLI for managing the development flow, and Flowser for viewing and interacting with the blockchain.
This is also very similar to the traditional web2 development workflow (e.g., for client-side applications), where you use your IDE to edit code, a CLI tool (like [create-react-app,](https://create-react-app.dev/) [vite](https://vitejs.dev/),..) for managing development flow (rebuilding website source code,..) and your browser for reviewing the changes.
Solution: We want to build a brand-new screen for performing blockchain interactions (executing transactions or scripts). This could replace or enhance some Flow CLI commands like flow transactions send and flow scripts execute with an easier-to-use and more powerful GUI.
Main features:

Automatically detect the type of interaction (either script or transaction) and show appropriate info after execution.

For transactions, we plan to show (all) the “effects” of the transaction, e.g., events emitted, errors (if any), storage state change (in the future), and other helpful info.
For scripts, we plan to show the script output in a nice programmer-readable UI (e.g., JSON viewer) and other info if applicable (e.g., errors)

Automatically detect the transaction/script arguments and provide a smart UI for inputting values (e.g., if the argument is an account address, automatically provide a dropdown input with a list of accounts on the network)
Better Cadence code editor (e.g. using [Monaco editor & Cadence language server](https://github.com/onflow/cadence/tree/master/npm-packages/monaco-languageclient-cadence))
UI for viewing the non-linear history of interactions and state changes (similar to the output of git log --graph command)
Perform actions on past interactions (e.g., revert to the previous state, duplicate interaction,…). This is closely connected with the snapshot management feature we implemented in the previous grant. We also plan to improve the overall reliability of this feature in this grant.
Implement the possibility of adding templates for the most common transactions. This can be possible with community resources. This feature would be linked with milestone 2: Community to Community, Transaction Metadata.

Tasks:

Parse transaction/script source code to generate a list of required inputs with their respective data types
Build a smart account (Address) input, where the user can select an existing account from a dropdown-like UI (similar to how this is done in Flow Playground).
Pre-generate a list of accounts that can be used during the development. Provide a way for a developer to generate additional accounts if needed.

Optionally store these accounts settings in a separate flow.json configuration (e.g. flow.flowser.json)

UI Design:

Implement interact screen UI elements:

Past interactions,
State chart,
Interaction info,
Smart script/transaction inputs,
Transaction Status
Common transaction templates import

Smart History view design:
Design a UI for viewing the non-linear history of interactions.
Support all the technical features
(e.g., smart account inputs, generation of additional accounts…)
Action Status

In the case of Scripts, the data will be displayed in the same way we are displaying storage inspection
In the case of a Transaction, the result must be displayed

1.2 Community to Community
a. Transaction Metadata (Flowser & Blocto)
We will integrate [Blocto’s collection of audited Flow transactions](https://github.com/portto/flow-transactions) into Flowser. This will enable better support and documentation for some of the more standard/popular transactions.
With this integration, we will be able to define a list of common transaction templates. The data will then be used in the History view on the Interaction screen (see Milestone 1), as well as in the transaction table.
Tasks:

Implement a list of common transaction templates on the interact screen (using the [Cadence transaction templates](https://github.com/portto/flow-transactions/blob/main/transactions/Find/bid.cdc)).
Show a better summary of transaction logic in the transaction table (using the [transaction metadata](https://github.com/portto/flow-transactions/blob/main/transactions/Find/bid.json))
Optionally provide a way for users to express interest in adding support for other transactions not listed https://github.com/portto/flow-transactions repository

b. Token metadata (Flowser & FlowFans)
Integrate [FlowFan’s collection of Flow token metadata](https://github.com/FlowFans/flow-token-list) into Flowser.
Token metadata will allow us to recognize more standard/popular Flow tokens and show their metadata in Flowser UI (e.g., links to documentation, symbol, logo,…).
Tasks:

Show supported token icons where applicable (e.g., in token transfer info, event rows,…)
Show metadata on the contract details page.
Optionally submit a PR on https://github.com/FlowFans/flow-token-list that adds links to token documentation pages

1.3 UI Updates
a. Account address abstraction
Account addresses are not human-friendly, but we show them pretty much everywhere now. We want to provide a better abstraction on top of raw account addresses - account icons or names. Ideally, we’d want to use the same naming convention used in other Flow tools (e.g., flow dev super command).
Tasks:

We will update the design all over the tool (Accounts table, account details, transaction table, transaction details,…) and present the addresses more visually.
Autogenerate custom address avatars (or use the ones from fcl-dev-wallet) and show them next to account addresses, making it easier for users to identify accounts.
Treat account addresses as an implementation detail.

Pre-generate a list of accounts that can be used during the development. The addresses of these accounts could change on every project startup, so we wanna show names that will always stay the same.

b. Improve transaction transfers info
Flowser is a graphical user interface, and we would like to focus on presenting the data more visually in this grant. With this idea, we would like to improve the transaction token transfer info, enabling users to make more sense of what the transaction is doing.
Tasks:

Prepare a new design for displaying Transfers info, with the updates from the previous feature ([a. Account address abstraction](https://www.notion.so/a-Account-address-abstraction-5567b975f6b44a50b933019cd12430c9) ).

c. Transaction overview in table
Transactions do different things like:

transferring tokens
adding contracts to accounts
executing other application logic
…

If you look at the transactions table now, you are not able to see what each executed transaction did without examining the source code:

The idea is to display this information differently from other data, so you can quickly see the effect of a particular transaction.
Tasks:

If available, use community-maintained transaction metadata ([a. Transaction Metadata (Flowser & Blocto)](https://www.notion.so/a-Transaction-Metadata-Flowser-Blocto-aee77fbeaf2c431d82b4314c0784fb86)). This will enable us to show a human-readable description of the transaction, e.g., “Send 1 FLOW to Alice”.
Use transaction tags to indicate the type of transaction (e.g., NFT transfer)

d. Show uncollapsed view of transaction arguments
We show a collapsed view of transaction arguments (for complex data types like arrays or dictionaries):
Design today:

We should show a full data view, but there won’t be enough space to fit that data in a single line like we used to do (e.g., if the array has 5 elements). We will break that info into multiple lines when the data type is array or dictionary.
Example of how we could present the data:

e. Cleanup of the current UI

Less clutter on tables

We will eliminate unnecessary information, update the address view, and add a better overview of what the transaction did (in the Transaction Table).

Display non-clickable tabs differently and move "buttons" into tabs

Showing non-clickable tabs is confusing.
We will update the design of all details pages (account, blocks, and transactions) whew we will:

Redesign “buttons” into tabs
Present data with no additional details view (e.g., Collection in Blocs table) differently

f. Global search design
Global search will enable users to search for any kind of:

transaction
address
account
history item
transaction template
tag
etc

We will design a modal for a global search.
Global search will be implemented in the future, but we will prepare the design in the scope of this grant.
g. Tags
Tags are a way to attach labels to different objects on the Flow blockchain. We are planning to implement tags for accounts, transactions, and events.
Tasks:

Implement account tags:

service account - to indicate if the account is a service account defined in flow.json file

Implement transaction tags:

Fungible token transfer
NFT transfer
… others, if applicable

Event tags

Core event - to indicate if an event is a part of core Cadence events: https://developers.flow.com/cadence/language/core-events

1.4 Technical Improvements
a. Remove the need for manual transaction authorization
As of now, you need manually authorize every transaction that you want to execute using the fcl-dev-wallet modal. This is not ideal behavior for our upcoming interaction screen because it presents an unnecessary distraction.
Tasks:

Follow the [FCL documentation](https://github.com/onflow/fcl-js/blob/master/packages/fcl/src/wallet-provider-spec/authorization-function.md) and implement a custom authorization function

b. Improve snapshot management
The current implementation of snapshot management is not as reliable as we’d like. Because this feature will be used in the upcoming [interact screen feature](https://www.notion.so/Documentation-01d7fc2f7fab4c30b5d59c85d16ceb88), it should behave reliably.
That’s why we proposed some changes to the snapshot management API in Flow CLI, which have now been implemented in the PR below.
https://github.com/onflow/flow-emulator/pull/241
https://github.com/onflow/flow-emulator/issues/228
The next step is to integrate these API improvements to Flowser. We also want to create snapshots automatically on a per-block basis.
1.5 Continued support, Maintenance & PR
Resolve (or provide support) any GitHub issues: https://github.com/onflowser/flowser/issues
We will support all active users and resolve any GitHub issues: https://github.com/onflowser/flowser/issues, maintain the tool with regular updates and continue with communication on Twitter.
2. Milestones & Tasks

Milestone
Deliverables
Timeline
Risks
Flow Tokens Suggested

(4) Technical Improvements
• The need for manual transaction authorization is removed • Snapshots are created automatically on a per-block basis
2 weeks

6,000

(1) Interactive Screen Implementation
Interact Screen for performing blockchain interactions (executing transactions or scripts) with all functionalities is designed and developed.
6 weeks

36,000

(2) Community 2 community
• Blocto’s collection of audited Flow transactions integration into Flowser • FlowFan’s collection of Flow token metadata integration into Flowser.
3 weeks

7,000

(3) UI Updates
• Account address abstraction • Improved transaction transfers design • Display the human-readable description of the transaction • Uncollapsed view of transaction arguments is shown • Tables are updated and contain less clutter • “Buttons” on the detail page are redesigned into tabs • Non-clickable tabs on the details page are redesigned • Design for a global search is created • Tags are designed and implemented
3 weeks
-
20,000

(5) Continued support, Maintenance & PR
Provide support for all active users, maintain the tool with regular updates, and continue with communication on Twitter.
4 months*
-
36,000 (9,000 monthly)

*Milestone 5 will start on day one and will be ongoing work for 4 months. It will be done simultaneously with all other milestones.
Total suggested USD amount: $52,500
Team

Github
Name
Role
Bio
Email

@bartolomej
Bartolomej Kozorog
Full stack developer
Passionate developer and CS student. Currently building Flowser  tool and working at kazm.xyz - building a Web3 CRM platform
<EMAIL_ADDRESS>

@monikaxh
Monika Hriberšek
UX/UI Design + Graphic design
Proprietor @ Monikart; UX/UI Designer @ Flowser since Sep 2021; Designing: mobile apps, websites, social media content, NFTs. Additional experience: Product Manager @ Renault&Nissan Financing (~ 4y).
<EMAIL_ADDRESS>

thanks for the submission @monikaxh. @fotescodev will reach out to you to discuss this further

Awesome, thank you!

Hi @alxflw and @fotescodev! 👋
I just wanted to check if there are any updates. Is there any more info @bartolomej and I should provide?

Automated Snapshots is a great addition as well. Let's sync on Monday after we have reviewed this with @alxflw.

Automated Snapshots is a great addition as well. Let's sync on Monday after we have reviewed this with @alxflw.

Yeah, indeed! Maybe we didn't state that explicitly, but the automated snapshots feature is actually a prerequisite to the interact screen feature. That's because one essential idea behind the interact screen is the ability to revert to any previous interaction/transaction (read "block").
For this to work, we need a reliable mechanism to create snapshots for every new block. I believe we could do that at the (flowser) application layer, but I don't think will work reliably enough in all cases (e.g. if the block interval is very short we could miss some blocks).
So I believe we will need to work together on this and possibly other features in this grant if they require some work on the Flow tooling side.

@JeffreyDoyle I was wondering if this would work well with FLIX as well?

@fotescodev That's great news! We are starting our work right away. 🚀

We've successfully achieved our second milestone: Interact Screen. This marks a significant enhancement to Flowser, transforming it not just into a GUI, but also an integrated development environment (IDE) 🛠
Key Highlights from this Milestone:
Introduction of the interactive screen, empowering users to:

write Cadence interactions (transactions or scripts)
provide arguments to interactions
view results (error or success) of interactions
reuse (project or custom) Cadence templates (aka. snippets)
inspect and roll back to historic blockchain states
view execution logs (from log() calls in Cadence)

The main components on the Interactive screen are:

History: Browse and revert to historic blockchain states seamlessly.
Templates:

You can write Cadence interactions (transactions or scripts) and save them or use templates.
Flowser also reads scripts/transactions sourced from project files and presents them in a template section. You can easily edit them right on the interactive screen.

Editor: Create transactions and scripts, or edit them from the template list.

Arguments

You can quickly add and manage arguments

Execution result view

Access comprehensive execution details instantly, organized into separate tabs.
Added help banners with links to relevant learning resources throughout the app.

Watch the Interactive Screen in action:  Video Demo 📺

Reviewed the (1) Interactive Screen Implementation milestone. Really nice work!
I approve the milestone as being completed. 🎉
During the review and usage of the tool, I found some minor things that would be good to address before the grant is finished:

On the script execution if the script fails the error should be clearly written the same way as it is for transactions, but for a script, we now get the API error
When you open a template by double-clicking on it in the list on the left, and then opening another template, but then want to switch back to that first template by again double-clicking on it in the list it doesn't open it, it requires clicking on tabs. This is NIT but if it can be fixed it would be an improvement if not too much work
Not related to this milestone but something I want you to note: switching between different views (blocks, txs, events) is not clear what the view shows, and there's no title for those screens, I believe you might already have this in your plan, just wanted to make sure there's either a title somewhere or at least hover label when you click on the icon saying what the screen shows.
The new import schema is not working, related to issue you've already opened
The overview and error screens should have a slider or be made responsive

@sideninja

On the script execution if the script fails the error should be clearly written the same way as it is for transactions, but for a script, we now get the API error

I think this issue in FCL is blocking that: https://github.com/onflow/fcl-js/issues/1762
Agreed with other points you made, most of those are already a WIP!

Hello @sideninja @gregsantos @SeanRobb 👋
We've successfully reached a significant milestone with our latest updates to Flowser's user interface (UI).
UI updates (first pass)
UI updates
UI polish
Interaction polish
Let's dive into the exciting changes:
Enhanced UI: We put in the hard work to make Flowser's UI more intuitive and visually appealing. Notable improvements include the representation of addresses with icons and the repositioning of the main menu to the left side, simplifying navigation 🗺 We've also decluttered the interface, creating a cleaner and more user-friendly experience ✨
https://github.com/onflow/developer-grants/assets/80001381/699c6dd8-1bc9-4df6-b8d7-71143bfa23e5
Table and Details Page Redesign: We've revamped our tables and details pages, replacing buttons with tabs for easier data access and browsing. This refreshed design has also been extended to our Interactive screen.
https://github.com/onflow/developer-grants/assets/80001381/ca700f7f-59c4-47a3-b557-e216af574a0a
Global Search:  The design of global search was scheduled for this milestone, but the implementation was originally slated for the future. During the process, we recognized the importance of a global search feature and have decided to include it in upcoming milestones. 🔥

Tags: We've introduced tags such as #service, tailored for service accounts, and #default tag, which is used if the account was created automatically by the emulator.

Helpful Tooltips: To assist users, we've added useful tooltips throughout Flowser.

Improved Events Data display: We've enhanced the "events data" logic, moving away from a single cluttered table to a more organized structure with a dedicated events table and a detailed view.
https://github.com/onflow/developer-grants/assets/80001381/62b14854-11c6-4d82-b920-c781c768137e
We have introduced a temporary solution to showcase user-friendly names for commonly used transactions within Flow CLI. This solution will remain in place until we finalize the "Community to Community" milestone.
In our commitment to assist new developers on Flow, we have chosen to provide a range of helpful tips within the tool:

All of these updates (and more) can be found in Flowser version 3.0, which is now live 🚀
It combines the Interactive screen from our previous milestone with all the UI enhancements achieved in this release. Check it out here, and experience the future of Flowser!
Check out our Flowser demo 📺 & follow us on Twitter or jump on our Discord
Other:

Optimize app performance (first pass) by @bartolomej in https://github.com/onflowser/flowser/pull/172
Fix emulator error handling by @bartolomej in https://github.com/onflowser/flowser/pull/174
Update GRCP status entries by @bartolomej in https://github.com/onflowser/flowser/pull/175
Fix initial loading by @bartolomej in https://github.com/onflowser/flowser/pull/176
Remove dev wallet support by @bartolomej in https://github.com/onflowser/flowser/pull/177
Custom account avatars by @bartolomej in https://github.com/onflowser/flowser/pull/179
Support project templates and new import standard by @bartolomej in https://github.com/onflowser/flowser/pull/180
Improve project contract handling by @bartolomej in https://github.com/onflowser/flowser/pull/191
Update storage retrieval by @bartolomej in https://github.com/onflowser/flowser/pull/194

Reviewed the (3) UI improvements milestone. Awesome stuff and I approve the milestone as being completed. 🎉

Hello there @SeanRobb!
We've wrapped up two (last 🙀) milestones as part of the grant:

Milestone 2: Community to Community
Milestone 5: Maintenance

Community to Community
A key achievement was the integration of FLIX, enabling seamless browsing and utilization of templates. Our FLIX info UI displays verification status (with users empowered to propose new FLIX templates), existing audits, and inline argument documentation.

https://github.com/onflowser/flowser/pull/212
https://github.com/onflowser/flowser/pull/207
https://github.com/onflowser/flow-interaction-template-service/pull/2
https://github.com/onflowser/flow-interaction-template-service/pull/5
https://github.com/onflowser/flow-interaction-template-service/pull/4
https://github.com/onflowser/flow-interaction-template-service/pull/3

We also integrated with FlowFans token metadata collection - displaying token info and prompting the creation of new metadata.

https://github.com/onflowser/flowser/pull/203
https://github.com/onflowser/flowser/pull/206

Additionally, we are transitioning Blocto’s verified transactions collection to the FLIX standard and submitted various proposals to the official FLIX repo. Some of these are already experimentally implemented on our own FLIX fork, while others are still in draft.

https://github.com/blocto/flow-transactions/issues/59
https://github.com/onflow/flow-interaction-template-service/issues/35
https://github.com/onflow/flow-interaction-template-service/issues/34
https://github.com/onflow/flow-interaction-template-service/issues/29

Maintenance
Our ongoing maintenance work, initiated since day one, has also reached a completion.
This included various bug fixes, improvements, and overall software maintenance work. But some of the most notable changes include Linux support 🐧 for our desktop app and a large internal codebase restructure to support future extensions  🤙 (like the one hinted below).

https://github.com/onflowser/flowser/pull/208
https://github.com/onflowser/flowser/pull/197

In the realm of communication and marketing 🎯 we crafted a compelling 📺 [demo](https://www.youtube.com/watch?v=YClIKmCbj8k) for the interactive screen and enhanced our Twitter communication strategy 🐥 Over the past 91 days, our efforts have yielded an impressive 1.8K impressions per day 📈This marks a substantial leap from the pre-grant period (March 1st - May 31st), where we only garnered 8 impressions per day. Additionally, we witnessed a remarkable 1550% increase in the absolute number of replies and a notable 1.5 percentage point rise in overall engagement.
Next up
🔥 Exciting developments on the horizon for Q1:

Web version of Flowser featuring support for testnet and mainnet 🙀
Advanced global search 🚀
Native support for account linking
Further contributions to FLIX tooling, standardization, and adoption
FLIX web app (to be discussed)?
Work with the community on standardizing contract metadata ([context](https://x.com/onflowser/status/1724772820675117194?s=20))?

As we reflect on this journey, navigating through a bearish market 🐻 we're immensely grateful for the unwavering support 🫶

@monikaxh Approved 🎉

Closing due to be completed


Links to ontology and documentation from ld4l.org

I still have write access to the Drupal site so will take care of this myself.

Not required for release 1.0, can be done with public announcement (issue #18)

Out of scope for the repository


[Evaluation] add environment variable for API token refresh rate

Description
Fixed an issue where during long-running simulations, API token expires causing "Forbidden" error. Instead, users can now set an environment variable AZURE_TOKEN_REFRESH_INTERVAL to refresh the token more frequently to prevent expiration and ensure continuous operation of the simulation.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
API changes are not detected in this pull request.


How does this work? :-)

Hi! Do you have a write up of how this library works? I'd love to learn more about how it works and how it's different than the Mixbox approach.

Hi Ryan,
This is a good summary created by ChatGPT:

The Kubelka-Munk theory is a mathematical model, published in 1931, that describes the interaction of light with a homogeneous, particulate material. This theory is often used in color science, especially in the field of color measurement and color reproduction.
The theory is based on the assumption that the material under consideration consists of a large number of small, identical particles. These particles can either absorb or scatter light, and their behavior is characterized by two coefficients: the absorption coefficient (K) and the scattering coefficient (S). These coefficients are fundamental to the Kubelka-Munk model.
When it comes to translating sRGB (standard Red, Green, Blue) color data to spectral data for Kubelka-Munk analysis, it involves converting the RGB values to spectral reflectance values. The spectral reflectance is a measure of how much light of each wavelength is reflected by the material.
Here's a simplified explanation of the process:
1. Conversion to Spectral Data: Each RGB triplet represents a specific color in the sRGB color space. To convert this to spectral data, one can use a conversion algorithm or a color matching function. These functions provide a mapping between the sRGB values and the corresponding spectral reflectance values.
2. Kubelka-Munk Model: Once you have the spectral reflectance data, you can apply the Kubelka-Munk model. The model uses the absorption and scattering coefficients to calculate the reflectance and transmittance of the material as a function of wavelength. The Kubelka-Munk equations are complex and involve iterative calculations, but in essence, they express the reflectance and transmittance of a material in terms of its absorption and scattering properties.
3. Color Rendering: The resulting spectral data can be used to understand how the material will appear under different lighting conditions. By simulating the interaction of light with the material at various wavelengths, you can predict how it will be perceived in terms of color.

Mixbox also uses Kubelka-Munk, the main difference between spectral.js and Mixbox is that Mixbox uses spectral data from real pigments and spectral.js uses generated spectral data for red, green and blue (in the upcoming version, the current version uses white, cyan, magenta, yellow, red, green and blue).

Thanks for the fast response! I'd love to learn a little more about how you do the first bullet point. I'm familiar at a high level with the mixbox paper -- is your approach similar?
Another thing I was curious about is that in spectral_mix in spectral.wgsl it looks like you convert from sRGB -> linear RGB -> reflectance spectrum -> XYZ, and then use the XYZ data to figure out how to interpolate between the spectrums. Why is that necessary rather than using the interpolation value t directly? Also... is XYZ the CIE 1931 XYZ color space?

Oh wow, thanks! That's a lot for me to dig into.

the reason it's not linearly interpolating is because the luminance is needed for determining the correct concentrations, this ensures the color is perceptually evenly distributed between 0 and 1 where 0 is the first color and 1 is the second color.

Got it. I don't understand how you derived the concentration function, but this is enough for me to go off of for now. I'll let you know what other questions I have as I work through this!

Ah, nice! I have a couple of other performance questions, if that's ok!
In spectral_mix you compute the luminance of the spectrums like so...
float l1 = spectral_reflectance_to_xyz(R1)[1];
float l2 = spectral_reflectance_to_xyz(R2)[1];

Is there a reason that you compute XYZ from the spectrum, and not from the lrgb colors? I expect lrgb -> XYZ to be much faster than spectrum -> XYZ.
Another thing I'm curious about is that the RGB component functions looks a lot like logistic functions! Do you know if anyone has tried approximating the RGB component SPDs with logistic functions?

If you did this, and you computed xyz from lrgb above, then I think you could do away with the R1 and R2 vectors. You could compute the spectral components on the fly in this loop...
    float R[SPECTRAL_SIZE];

    for (int i = 0; i < SPECTRAL_SIZE; i++) {
      float r1 = compute_reflectance_using_logistic_approximations(lrgb1, i);
      float r2 = compute_reflectance_using_logistic_approximations(lrgb2, i);

      float KS = (1.0 - t) * (pow(1.0 - r1, 2.0) / (2.0 * r1)) + t * (pow(1.0 - r2, 2.0) / (2.0 * r2));
      float KM = 1.0 + KS - sqrt(pow(KS, 2.0) + 2.0 * KS);

      //Saunderson correction
      // let S = ((1.0 - K1) * (1.0 - K2) * KM) / (1.0 - K2 * KM);

      R[i] = KM;
    }

I'm not sure what kind of performance impact this would have, but it would use 38 * 4 * 2 fewer bytes per fragment. I'm guessing it'd be at least a little faster!

Is there a reason that you compute XYZ from the spectrum, and not from the lrgb colors? I expect lrgb -> XYZ to be faster than spectrum -> XYZ.

No particular reason for this, was just a design choise at that moment, I haven't fully optimized for speed.
But you make a good point, this shaves off some multiplications. I have changed this in my dev version.
const RGB_XYZ = [
    [0.4123908, 0.35758434, 0.18048079],
    [0.21263901, 0.71516868, 0.07219232],
    [0.01933082, 0.11919478, 0.95053215],
];

let luminance = dotproduct(RGB_XYZ[1], linear);

I don't fully understand your part about the logistics functions, wouldn't it be more computational costly if it needs a lot of iterration for calculating the best value on that wavelength?
But if you have a great idea you can implement it, I'm curious how it works.

Nice!!
I think my previous suggestion about logistic functions was more complicated than necessary. A simpler version is something like this...
Now that you compute XYZ from linear RGB, you access R1 and R2 only in the loop. Since they're not needed anywhere else, you don't need to pre-allocate them and store them in arrays. You may as well generate their values as you need them. So you could write a function that looks like this...
// Returns the reflectance value for a specific frequency; it's just a giant
// switch statement.
float spectral_linear_to_reflectance(vec3 lrgb, int frequency) {
  float r = lrgb.r;
  float g = lrgb.g;
  float b= lrgb.b;

  switch (frequency) {
    case 380: return r * 0.03147571 + g * 0.49108579 + b * 0.97901834;
    ... all the others ...
  }
}

... and call it from within the loop for each frequency when you need it.
Admittedly, I'm not sure how much faster this would make things. My intuition is that eliminating the two arrays would be meaningful since they're kind of big and allocated / cleared per fragment, but it's hard to be sure about this kind of thing without measurements.

When I find the time I will look into this.
I have to make a correction; I use the 1931 2deg CMF functions and not the 1964 10deg, I found the first give some more pleasing output.

Sure! No rush. I found another simpler way to think about this. You can declare your red, green and blue basis curves as a big constant array...
const vec3 rgbCurves[SPECTRAL_SIZE] = vec3[SPECTRAL_SIZE](
  vec3(...),
  vec3(...),
  vec3(...),
  ...
);

And then your loop becomes...
float R[SPECTRAL_SIZE];

for (int i = 0; i < SPECTRAL_SIZE; i++) {
  float r1 = dot(lrgb1, rgbCurves[i]);
  float r2 = dot(lrgb2, rgbCurves[i]);
  float KS = (1.0 - t) * (pow(1.0 - r1, 2.0) / (2.0 * r1)) + t * (pow(1.0 - r2, 2.0) / (2.0 * r2));
  float KM = 1.0 + KS - sqrt(pow(KS, 2.0) + 2.0 * KS);

  R[i] = KM;
}

Again... no pressure! But this feels even simpler so I felt like I should mention it.

Hi @ryankaplan,
The library is amazing. Thank you very much for open sourcing it.
I have a question about the Saunderson correction. In the source code the corresponding line is commented out:
https://github.com/rvanwijnen/spectral.js/blob/9e5f7b921473730df8f67c4a583e21e3183f5159/spectral.js#L70
Does it provide unsatisfying result? For example, did the result look too dark?

@eugene-khyst I think you meant to tag @rvanwijnen :)

Hi @rvanwijnen,
The library is amazing. Thank you very much for open sourcing it.
I have a question about the Saunderson correction. In the source code the corresponding line is commented out:
https://github.com/rvanwijnen/spectral.js/blob/9e5f7b921473730df8f67c4a583e21e3183f5159/spectral.js#L70
Does it provide unsatisfying result? For example, did the result look too dark?

Hi,
In my experience the Saunderson correction works as intended but I decided to disable for the release to keep things simple.
You can uncomment that line and use it if you like.
You can change the correction on this line:
https://github.com/rvanwijnen/spectral.js/blob/9e5f7b921473730df8f67c4a583e21e3183f5159/spectral.js#L242


fix: cycle headings on shortcut

fixes #45

TODO

[x] Tests!

This is so buggy. Toggling off the header is possible only after reaching level 6, then you can't toggle it back on again.
Compare with #110.

Toggling off the header is possible only after reaching level 6, then you can't toggle it back on again.

Not exactly right. The heading never got toggled off but instead got set to the non-existant h7. D'oh! Friday afternoon commits, amiright?
It's been fixed in 7d6d98d. Thanks @double-beep!

I still believe there should be a delay though. If a header is at level 1 and the user would like to toggle it off, then they'd need to press Ctrl + H 6 times, which might be annoying.


eve_mine with timestamp parameter is some times off by one second

evm_mine with timestamp parameter is some times off by one second. This is not helpful as deterministic behaviour of contracts is often desirable when hunting for bugs.
Expected Behavior
I would expect evm_mine with timestamp to deliver a block with exactly the given timestamp.
Current Behavior
I call evm_mine with a timestamp parameter, which usually is honoured but not always. This is an intermittent problem.  Below I provide two sample outputs of a test contract in Truffle, which differ only in the timestamps of block 14.
Here is the first output, with block 14 having a time stamp<PHONE_NUMBER>
$ truffle test
Compiling ./contracts/ConvertLib.sol...
Compiling ./contracts/MetaCoin.sol...
Compiling ./contracts/Migrations.sol...

  Contract: MetaCoin
block.number 5 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
1 'blockNumber' 6
    ✓ TEST 1: should deploy (42ms)
block.number 6 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
2 'blockNumber' 7
    ✓ TEST 2: should put 10000 MetaCoin in the first account (69ms)
block.number 7 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
3 'blockNumber' 8
    ✓ TEST 3: should fail because function does not exist on contract
block.number 8 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
4 'blockNumber' 9
    ✓ TEST 4: should call a function that depends on a linked library (85ms)
block.number 9 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
5 'blockNumber' 10
    ✓ TEST 5: should send coin (109ms)
block.number 11 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
6 'blockNumber' 12
    ✓ TEST 6: should not send coin (54ms)
block.number 12 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
7 'blockNumber' 13
    ✓ TEST 7: should send coin correctly (227ms)
block.number 14 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
8 'blockNumber' 15
0 'blockNumber' 0 'timeStamp'<PHONE_NUMBER>
1 'blockNumber' 1 'timeStamp'<PHONE_NUMBER>
2 'blockNumber' 2 'timeStamp'<PHONE_NUMBER>
3 'blockNumber' 3 'timeStamp'<PHONE_NUMBER>
4 'blockNumber' 4 'timeStamp'<PHONE_NUMBER>
5 'blockNumber' 5 'timeStamp'<PHONE_NUMBER>
6 'blockNumber' 6 'timeStamp'<PHONE_NUMBER>
7 'blockNumber' 7 'timeStamp'<PHONE_NUMBER>
8 'blockNumber' 8 'timeStamp'<PHONE_NUMBER>
9 'blockNumber' 9 'timeStamp'<PHONE_NUMBER>
10 'blockNumber' 10 'timeStamp'<PHONE_NUMBER>
11 'blockNumber' 11 'timeStamp'<PHONE_NUMBER>
12 'blockNumber' 12 'timeStamp'<PHONE_NUMBER>
13 'blockNumber' 13 'timeStamp'<PHONE_NUMBER>
14 'blockNumber' 14 'timeStamp'<PHONE_NUMBER>
15 'blockNumber' 15 'timeStamp'<PHONE_NUMBER>
    ✓ TEST 8: check all addresses (234ms)

  8 passing (904ms)

Here is the second output with block 14 having a time stamp<PHONE_NUMBER>
$ truffle test
Compiling ./contracts/ConvertLib.sol...
Compiling ./contracts/MetaCoin.sol...
Compiling ./contracts/Migrations.sol...

  Contract: MetaCoin
block.number 5 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
1 'blockNumber' 6
    ✓ TEST 1: should deploy (39ms)
block.number 6 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
2 'blockNumber' 7
    ✓ TEST 2: should put 10000 MetaCoin in the first account (67ms)
block.number 7 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
3 'blockNumber' 8
    ✓ TEST 3: should fail because function does not exist on contract
block.number 8 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
4 'blockNumber' 9
    ✓ TEST 4: should call a function that depends on a linked library (91ms)
block.number 9 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
5 'blockNumber' 10
    ✓ TEST 5: should send coin (119ms)
block.number 11 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
6 'blockNumber' 12
    ✓ TEST 6: should not send coin (57ms)
block.number 12 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
7 'blockNumber' 13
    ✓ TEST 7: should send coin correctly (228ms)
block.number 14 block.timestamp<PHONE_NUMBER> timestamp<PHONE_NUMBER>
8 'blockNumber' 15
0 'blockNumber' 0 'timeStamp'<PHONE_NUMBER>
1 'blockNumber' 1 'timeStamp'<PHONE_NUMBER>
2 'blockNumber' 2 'timeStamp'<PHONE_NUMBER>
3 'blockNumber' 3 'timeStamp'<PHONE_NUMBER>
4 'blockNumber' 4 'timeStamp'<PHONE_NUMBER>
5 'blockNumber' 5 'timeStamp'<PHONE_NUMBER>
6 'blockNumber' 6 'timeStamp'<PHONE_NUMBER>
7 'blockNumber' 7 'timeStamp'<PHONE_NUMBER>
8 'blockNumber' 8 'timeStamp'<PHONE_NUMBER>
9 'blockNumber' 9 'timeStamp'<PHONE_NUMBER>
10 'blockNumber' 10 'timeStamp'<PHONE_NUMBER>
11 'blockNumber' 11 'timeStamp'<PHONE_NUMBER>
12 'blockNumber' 12 'timeStamp'<PHONE_NUMBER>
13 'blockNumber' 13 'timeStamp'<PHONE_NUMBER>
14 'blockNumber' 14 'timeStamp'<PHONE_NUMBER>
15 'blockNumber' 15 'timeStamp'<PHONE_NUMBER>
    ✓ TEST 8: check all addresses (229ms)

  8 passing (914ms)

Possible Solution
I'm sorry, I have no idea.
Steps to Reproduce (for bugs)
Here is the truffle code needed to reproduce the issue:
MetaCoin.zip
$ unzip MetaCoin.zip
$ cd MetaCoin
$ truffle test
... keep trying until the behaviour changes
$ truffle test
Context
I am trying to debug smart contracts that use now. It would be most helpful if the contracts could be made to behave deterministically.
Your Environment
$ truffle version
Truffle v5.0.2 (core: 5.0.2)
Solidity v0.5.0 (solc-js)
Node v10.15.0
$ uname -a
Darwin 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64

After having spent an afternoon on this I think that I might have found what causes the problem. The test script controls the timestamp of some blocks but there are still blocks that are auto-mined. For example, block 14 is auto-mined, and apparently, it does not always have the same time stamp. This begs the question: Can I switch auto-mining off? I believe that auto-mining is needed while the contract is being deployed, so I'd like to switch it off once my test script gains control.

Thanks @pieterhartel for the detailed reproduction steps!
This apparent non-determinism is caused by ganache "instamining"; that is to say: it mines a new block immediately after a transaction is received.
evm_mine(timestamp) causes a block to be mined exactly at the timestamp given, and also updates the internal timeAdjustment (this basically lets us fast-forward or rewind time) so blocks mined in the future always happen after the last block mined. Block timestamps are still based on the real clock though, just with this timeAdjustment added in.
The amount of time between evm_mine and your next transaction is not going to be 0, and sometimes the time difference will span two different real seconds -- and this can happen even if the difference is a single millisecond. This is what causes the block timestamps vary in your tests.
To make your tests deterministic you should:

start ganache with the time option (in addition to a deterministic seed/mnemonic option). This will create a genesis block at the given timestamp (there is actually a bug here so this part might not always happen perfectly).
Send a miner_stop RPC call to prevent any more blocks from being insta-mined.
Send the transaction or transactions you want mined in the next block

Send an evm_mine RPC call with a timestamp to cause the transaction(s) you sent in step 3 to be mined at the specific timestamp.

Let me know if you have an questions. Thanks again!

Dear @davidmurdoch, Thank you for the explanation. I have implemented your suggestion and it seems that I have to execute step 4 twice. Why would that be?

Are you saying you have to send evm_mine twice in order to mine the transactions you sent in step 3?

Indeed but not on the MetaCoin example above, but on another contract. I am having some difficulty reproducing the behaviour with a manageable example; I need to spend some more time on this.
I do have another question though on the MetaCoin example. With the -t option I can set the time stamp of block 0, but how do I control the timestamp of block numbers 1 to 5?  To begin with I cannot even access web3 in a migration script.

@davidmurdoch I have tried to repeat the problem of the double evm_mine here:
Vitaluck.zip
In the file test/vitaluck.js there are two occurrences of the statement  await mine_time.mineBlockWithTimestamp(<PHONE_NUMBER> ) ;. If one is commented out the test will hang, trying to get a receipt which will never happen. If the statement is active the output is as shown below.
$ truffle test
Compiling ./contracts/Migrations.sol...
Compiling ./contracts/Vitaluck.sol...

  Contract: Vitaluck
    ✓ TEST: Vitaluck (60ms)
    ✓ TEST: Play(  ) (117ms)
0<PHONE_NUMBER> 0
1<PHONE_NUMBER> 1
2<PHONE_NUMBER> 1
3<PHONE_NUMBER> 1
4<PHONE_NUMBER> 1
5<PHONE_NUMBER> 0
6<PHONE_NUMBER> 0
7<PHONE_NUMBER> 0
8<PHONE_NUMBER> 0
9<PHONE_NUMBER> 0
10<PHONE_NUMBER> 1
    ✓ TEST: check all blocks (98ms)

  3 passing (311ms)

As for controlling the first timestamp of those initial blocks... could you open a new issue over on the Truffle repo?

RE Vitaluck.js: This is because when you call evm_mine the first time the JSON RPC call to deployed() either hasn't yet been received or just hasn't yet been processed by Ganache -- so there are no pending transactions for it to mine yet.
What you'll need to do is use .new() instead of .deployed(), as .new() returns a promiEvent:
const deployRequest = Vitaluck.new( );
await new Promise((resolve) => {deployRequest.on("transactionHash", resolve)});
await mine_time.mineBlockWithTimestamp(<PHONE_NUMBER> ) ;
deployedContract = await deployRequest ;

and similarly with the contract methods:
const txRequest = deployedContract.methods[ "Play()" ]( txOptions ) ;
await new Promise((resolve) => {txRequest.on("transactionHash", resolve)});
await mine_time.mineBlockWithTimestamp(<PHONE_NUMBER> ) ;
const txResult = await txRequest ;

@davidmurdoch Thanks very much for the suggested code fragments.
I have tried your suggestions out and it works well for contracts without constructor arguments. If there are constructor arguments I get something like this:
Uncaught Error: Invalid number of parameters for "undefined". Got 0 expected 2!
The constructor arguments are in the migration script, but that no longer works. For example if Vitaluck would have two arguments, the relevant part of the migration script would have looked like this:
	const txOptions = { from: accounts[5], value: "0", to: 0 }
	deployer.deploy( Vitaluck, **arg1, arg2**, txOptions ) ;

So my question is where do I put the constructor arguments? And where do the txOptions go?

The truffle docs for new should have the answer.

MyContract.new([arg1, arg2, ...], [tx params])
This function take whatever contructor parameters your contract requires and deploys a new instance of the contract to the network. There's an optional last argument which you can use to pass transaction parameters including the transaction from address, gas limit and gas price. This function returns a Promise that resolves into a new instance of the contract abstraction at the newly deployed address.

Let me know if that doesn't answer your question.

Dear @davidmurdoch ,
Thanks for you swift answer. Am I right in thinking that with using  .new() instead of .deploy() some of the functionality is shifting from the migration to the test script? The reason I am asking is because on this page https://truffleframework.com/docs/truffle/getting-started/running-migrations  the arguments are also mentioned.

deployed() in your test scripts assumes you're using migrations and they've already run.
It sounds like you could still use deploy (instead of new) in your migrations (and not in the tests themselves) in combination with miner_stop/miner_start and evm_mine.

Dear @davidmurdoch, thank you one again for the swift response. I believe that I found a solution by dispensing with the second migration script altogether!
Here is a fresh zip file Vitaluck.zip with a modified version of Vitaluck. I have added a constructor with an argument that is set in the test script as follows:
const txOptions = { from: accounts[5], value: "0", to: 0 } ;
const deployRequest = Vitaluck.new( 5000000, txOptions ) ;

The results show that (1) the constructor (in block 3) and the methods (in blocks 4 & 5) execute with now set to specific values; (2) the first method call succeeds and the second method call fails.
$ truffle test --show-events
Compiling ./contracts/Migrations.sol...
Compiling ./contracts/Vitaluck.sol...

  Contract: Vitaluck
    ✓ TEST: Vitaluck( 5000000 ) (1075ms)

    Events emitted during test:
    ---------------------------
    Configure(timestamp:<PHONE_NUMBER>, minBetValue: 5000000)
    ---------------------------
    ✓ TEST: Play( ) this should succeed (1055ms)

    Events emitted during test:
    ---------------------------
    NewPlay(timestamp:<PHONE_NUMBER>, player: 0x821aEa9a577a9b44299B9c15c88cf3087F3b5544, number: 0, won: false)
    ---------------------------
    1) TEST: Play( ) this should fail
    > No events were emitted
0<PHONE_NUMBER> 0
1<PHONE_NUMBER> 1
2<PHONE_NUMBER> 1
3<PHONE_NUMBER> 1
4<PHONE_NUMBER> 1
5<PHONE_NUMBER> 1
    ✓ TEST: check all blocks (82ms)
    > No events were emitted

  3 passing (3s)
  1 failing

  1) Contract: Vitaluck
       TEST: Play( ) this should fail:
     Error: Transaction: 0x34a0205add73c32d20cfffcd5230bad90430489ad884ad16e9cd1b6b5b4c22b2 exited with an error (status 0).
     Reason given: value less than minBetValue.

@davidmurdoch some of my transactions now timeout after 750 seconds.
Transaction was not mined within750 seconds, please make sure your transaction was properly sent. Be aware that it might still be mined!
I'm trying to reproduce it in a small test but that's not easy. Would it be possible to improve the code that you suggested to make such timeouts impossible, or at least a lot less likely?
const txRequest = deployedContract.methods[ "Play()" ]( txOptions ) ;
await new Promise((resolve) => {txRequest.on("transactionHash", resolve)});
await mine_time.mineBlockWithTimestamp(<PHONE_NUMBER> ) ;
const txResult = await txRequest ;


communities.json: update ffbs

shoragan asked what would be necessary to show up in census related projects, this is.
resolves #17

Deployed.

Thanks

Thanks @AiyionPrime!


Fix nested menus overflowing past screen bounds

[x] Depends on #4986
Fixes #3861

https://user-images.githubusercontent.com/20418176/148696343-f1198d58-0aaa-49be-910c-c227abacf608.mp4
PRing primarily for comment.
This implementation mirrors observed behaviour of most nested menus that I could find, namely that determining whether to flip a menu or not happens locally to the given menu level (i.e. even if the parent menu is right-aligned to its parent's left side, the child menu of that can be left-aligned again if there is enough space).
The contentious part of this may be that I'm using GetContainingInputManager() to perform this positioning. This is done because the menu's parent is not necessarily its clipping bounds. And it's not like the menu has to have a parenting ContextMenuContainer or other drawable to work correctly. So clipping to the input manager seemed like the closest thing to "clipping to window bounds".
The implementation is a little repetitive too, with explicit branches for both orientations, but I'm not sure how to make better without making it read even worse than what's already there.

I haven't gone through the logic changes in this PR yet, but on initial testing noticed the editor menu bar is no longer aligned correctly:

Believe the above should be fixed with the latest commit.
Note that both direction branches in the layout code have now become extremely similar; the differences are very subtle (note where Draw{Width,Height} are added, and where they aren't). This may be promising from the standpoint of reducing the amount of code, but I'm not sure if the result won't be too inscrutable. I don't even currently have the brainpower to figure out how I could unify the branches or what the actual difference is. I'll revisit with a fresher mind.

Looks to be working better now.


role: mailto_root: change mailto_root_from to mandatory

also, this change has to be documented in the CHANGELOG


BPF based masquerading picks wrong IP

Proposal
Is your feature request related to a problem?
Describe the solution you'd like
We've run into a setup where cilium is running on a node that has multiple IP addresses (primary and secondary).
For example:
eth0 <IP_ADDRESS>
eth0:1 <IP_ADDRESS>

If used in iptables masquerading mode <IP_ADDRESS> is used as masquerading IP.
If used in bpf masquerading mode <IP_ADDRESS> is used as masquerading IP.
AFAICS in the code the bpf IP discovery does a sort of IPs in order to make sure to have a stable IP (#7637 is referenced in the code comments for this) but this also means it uses the "lowest" IP regardless of which "order" they are set which is usually not what you want.
Using --devices in this scenario doesn't help either because from a netlink perspective eth0 and eth0:1 are one device.
I have a working local patch that would alter the sort in IP discovery to prefer primary IPs over secondary IPs in the sort order.
This would work for all setup that use the :n suffix on the interface name, because netlink provides this as label. Users that use multiple IP addresses on eth0 w/o any suffix would still stay on the current sorting mechanism.
WDYT?
Attached a PR as possible solution to this.

We are seeing a similar issue where BPF based masquerading starts failing if there are multiple IP addresses on primary interface. In our case, we have multiple ip's configured on eth0 using alias (eth0, eth0:15). IP address on eth0 is externally routable, but the ip-address on eth0:15 is not.
root@<IP_ADDRESS>:~# ip addr show eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 7200
    link/ether a0:42:3f:37:91:e2 brd ff:ff:ff:ff:ff:ff
    inet <IP_ADDRESS>/27 brd <IP_ADDRESS> scope global eth0
       valid_lft forever preferred_lft forever
    inet <IP_ADDRESS>/23 brd <IP_ADDRESS> scope global eth0:15
       valid_lft forever preferred_lft forever
root@<IP_ADDRESS>:~#

root@<IP_ADDRESS>:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<IP_ADDRESS>         <IP_ADDRESS>   <IP_ADDRESS>         UG    0      0        0 eth0
<IP_ADDRESS>    <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 eth0
<IP_ADDRESS>   <IP_ADDRESS>         <IP_ADDRESS> U     0      0        0 eth0
root@<IP_ADDRESS>:~#

When I am installing k8s with cilium on the host, cilium is picking up ip address on eth0:15 which is non-routable and my external traffic is failing.
From inside Pod:
/ # ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
^C
--- <IP_ADDRESS> ping statistics ---
36 packets transmitted, 0 packets received, 100% packet loss
/ # ^C

On the host:
root@<IP_ADDRESS>:~# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:24:09.005708 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 44221, seq 46, length 64
17:24:10.005835 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 44221, seq 47, length 64
17:24:11.005966 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP echo request, id 44221, seq 48, length 64

Since its picking the incorrect ip address (<IP_ADDRESS> instead of <IP_ADDRESS> on eth0), no response for the requests is coming back.
I tried using --devices flag to specify interface, but that didn't helped. If kubeProxyReplacement is disabled, or egressMasqueradeInterfaces flag is specified which makes BPF fall back to iptables-based masquerading, only then the traffic starts routing correctly.


Adding the ML School in The Netherlands 2022

More details about this specific school are here: https://bigml.com/events/machine-learning-school-in-the-netherlands-2022
We have been co-organizing ML schools with several education institutions since 2015 in different cities, the previous editions can be seen here: https://bigml.com/education#schools

Thank you for the contribution!