Smart Contract Verification research

Please describe the problem that your request should resolve.

Describe the solution you'd like

Is it already possible to achieve the same outcome in any other way? If so, how?

Additional context

I posted the research results in the aeScan confluence for an internal review


Adding a RedisTimeSeries example

Description
Adds a time series example and fixes a typo in the aggregation types enum and exports it so client code can use it.
Checklist

[y] Does npm test pass with this change (including linting)?
[y] Is the new or changed code fully tested?
[y] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

Codecov Report

Merging #1839 (5ceac88) into master (2ff7084) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1839   +/-   ##
=======================================
  Coverage   95.05%   95.05%
=======================================
  Files         353      353
  Lines        3314     3314
  Branches      407      407
=======================================
  Hits         3150     3150
  Misses         81       81
  Partials       83       83

Continue to review full report at Codecov.

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


PERL-890 command monitoring updates

Contains:

Specification test data updates
Adaption of new bulk_write test data format.
collectionOptions integration
Passing options field as option argument to methods.

TODO tests are now passing for me locally.

Coverage remained the same at 76.991% when pulling d99fad8e22feb8486b20379f70e3685fd3f11c3f on shadow-dot-cat:phaylon/PERL-890 into 9687f61af72838e9a75b855b94a0738cff1ae597 on mongodb:master.

Rebased and merged.  Thanks!


Incorrect API results

@nickypangers Hello, I noticed some of the data gotten from the API is incorrect. For instance:
https://rough-sun-2523.fly.dev/api/us/ca
returns the data
{
    "passport": "US",
    "destination": "CA",
    "dur": "",
    "status": "VR",
    "category": "visa required",
    "last_updated": "2024-08-08T00:43:15.429384",
    "error": {
        "status": false,
        "error": ""
    }
}

which is false as US citizens can enter Canada without requiring a Visa.
Where is the base data pulled from and can it be easily corrected?
Passport Index seems to contain the latest up-to-date data but for some reason the API calls to the endpoints on Passport Index return the same errorneous data (I am using postman).
I found this other website:

All Countries: https://api.henleypassportindex.com/api/v3/countries
Single Country: https://api.henleypassportindex.com/api/v3/visa-single/US

Both return JSON

Thanks for noticing. The other APIs you provided does not give the detailed visa durations like the one used. Im encountering the same errorneous data as well. I'll leave this open and investigate for now.

Okay great. Let me know how I can be of assistance so we find a solution in
the time.
On Sat, Aug 10, 2024, 1:13 PM Nixon Pang @.***> wrote:

Thanks for noticing. The other APIs you provided does not give the
detailed visa durations like the one used. Im encountering the same
erroneous data as well. I'll leave this open and investigate for now.
—
Reply to this email directly, view it on GitHub
https://github.com/nickypangers/passport-visa-api/issues/8#issuecomment-2281392104,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJSKWAEG5WRNC35FP2ME7FTZQX7YBAVCNFSM6AAAAABMFNUR42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBRGM4TEMJQGQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Im guessing i could set up a firebase database to store data of each country then can have the community to verify data. however that can take a while since I've been occupied with work at the moment. Re @MuluhGodson :  https://api.henleypassportindex.com/api/v3/visa-single/US this api provides only accurate visa status but does not provide visa required information such as days. I'm not sure if the api im using and the one provided are complimentary.

A Firebase database will be great. If the information can be verified by the community, we can indeed add more info, such as visa procedures for each visa sourced from the official embassy websites (since it varies from country to country).

I just deployed a new version which fetch data from a postgres database i created just now.
I've added id into the visa queries.
If there are any inaccuracies feel free to open an issue with the id and the correct data so I can update accordingly.


Removing submodule and dataScience

refactoring all dataScience -> gamechangerml
removed submodule and dataScience entirely from this repo.

refactoring all dataScience -> gamechangerml
removed submodule and dataScience entirely from this repo.

Can we do gamechanger_ml with underscore, for readability?

There's a sister PR here for gamechanger-ml repo: https://github.com/dod-advana/gamechanger-ml/pull/25
Additional changes:

Changed README.md to match
Fixed references to assets found in gamechangerml repo and generally removed things irrelevant to gamechanger-data repo
Removed gamechangerml as submodule entirely, and all references in configs/gitignore/dockerignore
Revised paasJobs/configure_repo.sh script to handle setting up and installing/initializing gamechangerml as a package in way that keep deployments simple (probably need to revisit this later for local installs - e.g. figuring out how to handle topic model dependencies with no dev/prod access)

Testing
Successfully deployed repo as per instructions in repo-level readme on DEV data eng box and used document parser to covert 10 pdfs to jsons.


Delete git-v3.sh

I’m not entirely sure I understand the point of this file being in this folder.
Tagging @PeterDauwe.

Oeps , forgot one. Fixed


Refactor to move messaging folder out of /pkg

factory.go imports from /internal so it should not be under /pkg as this breaks the intent of separating /internal from /pkg.
The messaging folder simply need to be moved up to the root level.

PR #12 addressed this issue.


Custom fonts entirely broken & can cause memory corruption

I've been trying to get custom fonts working using rlImGui-cs for about 4 hours now - something that would take 20 seconds using C++ and ImGui - and I just can't figure it out.
I have tried:

Just as in C++, getting the IoPtr and loading the font from a TTF file. This does nothing. The font does not get used.
Doing 1, but then calling ReloadFonts. This does nothing.
Doing 2, but then using PushFont. This causes a memory corruption error and crashes.
Doing 1 & 2 in the InstallFonts callback.

None of these work. Do you have an functioning example of loading a custom font?

There is a callback you can install in rlImGui to setup your own fonts. it's called by rlImGui before it loads the font atlas, and gives you a chance to install custom fonts in addition to the default font and font awesome.
                 ImFontPtr newFont = null;
                 rlImGui.SetupUserFonts = io => newFont = io.Fonts.AddFontFromFileTTF("resources/Kenney Future.ttf", 18);

                 rlImGui.Setup();

That will add a new font that you can push and pop with code like this.
                 ImGui.PushFont(newFont);
                 ImGui.TextUnformatted("New Font Text ");
                 ImGui.PopFont();

If you want to replace the default font, then you can do that by not using rlImGui.Setup, and instead using the sperate Begin/End Init functions and set your font before calling EndInitImGui(). This will set a font and prevent rlImGui from installing the default font and FontAwesome.
// do not call rlImGui.Setup(), call this instead.
            rlImGui.BeginInitImGui();
            ImGui.StyleColorsDark();
            ImGui.GetIO().Fonts.AddFontFromFileTTF("resources/Kenney Future.ttf", 18);
            rlImGui.EndInitImGui();

If you replace the default font with your own, you do not need to push and pop fonts.

Setup is the simple setup and does a lot of automatic stuff, both the C# and C++ have the split setup for custom stuff.


add utility to keep track of objects in memory

Scrapy has nice trackref module using weakref module, that allows you to track all items remaining in memory for too long.
Perhaps we could add something like this to Splash to figure out if/where it leaks memory?

FWIW, Py3.4+ has https://docs.python.org/3/library/tracemalloc.html for proactive memory allocation investigations.

@pawelmhm in Splash there is https://github.com/scrapinghub/splash/blob/7b90eefa0d007e57e667cf4b1e1cd16ce45ff549/splash/utils.py#L81; it is used in _debug endpoint to show all alive objects of certain type.

I don't know how tracemalloc is implemented, but I'm not sure all these tools help with checking how QT allocates memory; likely they only check what's allocated by Python itself.

The tracemalloc module is a debug tool to trace memory blocks allocated by Python.

yes, they only trace python allocations.

ok thanks @immerrr and @kmike so we already track memory allocations and there is no need to add something new here


[SliderIOS] Add minimumTrackTintColor and maximumTrackTintColor to SliderIOS

There are still many other props that can be added to further customize the SliderIOS component, but I had a specific need for these two so I just went ahead and added them.

Thanks for this - I need this functionality as well. In my app I additionally need thumbTintColor and am happy to add it in the same way (is it useful to somehow add it to this pull request?)...
The only question I would have is whether these values should be exposed via CSS (as they seem more style related)...
Also, is this likely to be merged into React Native? I can patch my local version but am just wondering what will happen in future updates...

@vitch please make a separate pull request, as this one has already been merged. Once accepted, it will become part of RN.
I'll let @vjeux field the question about whether it should be a style vs a prop, but my undertanding is that it should be a prop.

Style should only be used for base-level style that applies to View, Image, and Text.  We are actually going to take resizeMode out of style and make it a plain prop on image.
So no, these new attributes should not go in style and should just be normal props.
But yes, we'll probably merge stuff like this in soon :)

On Apr 23, 2015, at 10:21 AM, Kelvin Luck<EMAIL_ADDRESS>wrote:
Thanks for this - I need this functionality as well. In my app I additionally need thumbTintColor and am happy to add it in the same way (is it useful to somehow add it to this pull request?)...
The only question I would have is whether these values should be exposed via CSS (as they seem more style related)...
Also, is this likely to be merged into React Native? I can patch my local version but am just wondering what will happen in future updates...
—
Reply to this email directly or view it on GitHub.

Thanks for the quick responses :smile:
I'm just looking into setting the thumbTintColor but it seems there is a bit of a weird bug in iOS regarding this property. If I can get the workaround to work then I'll submit a PR...

The rule is that if there's an equivalent on the web in style, it should be a style with the same name and same behavior. Otherwise it should be a prop.

@vjeux - sounds very reasonable to me, I gathered that was what we were going for and said the same thing in another issue which I can't find at the moment :smile:


updated the tls templates to only run based on a boolean attribute

Added an attribute that makes pulling the tls certs from S3 optional.

Working on getting the Travis build to work, then I will re-PR


icons not centred

i tried everything but it doesn't work on my pc and idk why

I appear to have the same issue on version <IP_ADDRESS> from GitHub. Issue appears to be similar to #36 but my offset is set to 0 as expected. This was working fine yesterday and I've not installed any Windows update.
However, I was using version <IP_ADDRESS> and suddenly the icons stopped centring and the taskbarx.exe app kept restarting in a loop. I could change things like the taskbar style (opaque, transparent etc.) but the app would constantly restart and not centre the icons.
To overcome this I thought I'd upgrade to <IP_ADDRESS> and now the icons move and the app doesn't constantly restart but now the icons are too far to the right and seem to progress further to the right sometimes. Seems to happen if the icons on the system tray increase or decrease. I did have this issue on my work laptop ages ago but after a while it just seemed to fix itself so it's a very peculiar one.

Running Windows 10 Pro Version 21H2 OS Build 19044.1645
Dual monitor setup, both running at 1920x1080
Main monitor 60Hz
Second monitor 144Hz
All toolbars disabled
Not sure if that info is of any use but worth providing.

Having the same issue here on version <IP_ADDRESS> rm skin. Had no issues today and then all of sudden started randomly shifting to the right more and more sometimes and will no longer center correctly.


How to assign Array

I have array of workers. Now I want to put these worker in round-robin. How may I pass array in New so that when I do Next task should assign the next worker.
Please help.
Thanks in advance.

Hi @dineshsiprtc
From what I have understood, you want to use your slice (array) as the source of workers, pass it to the Round Robin, to be able to use workers in an round-robin manner.
All you need to do is unpack your array and pass it to the Variadic function..
This is how your code should look like:
workers := []*Worker{}  // for example, slice of workers having 3 workers

rr, _ := roundrobin.New(workers...) // unpack slice

rr.Next() // worker 1
rr.Next() // worker 2
rr.Next() // worker 3
rr.Next() // worker 1

I hope that answers your query?

Thanks For you response & its help me.
But I am getting issue. I tried in this way
func main() {
var redisClient *redis.Client = redis.NewClient(&redis.Options{
	Addr: "localhost:6379",
	DB:   0,
})
var queueKey string = "task_queue"
arr := []*Resource{&Resource{redisClient, queueKey + "1"},
	&Resource{redisClient, queueKey + "2"},
	&Resource{redisClient, queueKey + "3"}}

rr, _ := roundrobin.New(arr...)
// 	&Resource{redisClient, queueKey + "1"},
// 	&Resource{redisClient, queueKey + "2"},
// 	&Resource{redisClient, queueKey + "3"},
// )
for {
	resource := rr.Next()
	message, err := resource.RedisClient.RPop(context.Background(), queueKey).Result()
	if err == redis.Nil {
		// No message available, wait for a short time
		time.Sleep(time.Millisecond * 100)
		continue
	} else if err != nil {
		fmt.Println("Error consuming message:", err)
		break
	}
	fmt.Printf("Consumer %s processing message: %s\n", resource.QueueKey, message)
}

}

Issue: redundant type from array, slice, or map composite literal
One more thing I want to know, Can we use interface so that we may use multiple scheduling algo(i.e Round Robin, Hashing etc.). I want to implement 2-3 algorithms


I don't understand addEvent and can't find an example

Seeing there is removeEvent which takes an element, I don't understand why addEvent does not take an element. Furthermore, I can't seem to get addEvent to working. The following example code shows an FFI defined inline that works and the DOM import not working:
{-# LANGUAGE EmptyDataDecls, OverloadedStrings #-}
module Sudokucalc where

import FFI
import DOM (addEvent, getElementById)

data Event

addWindowEvent :: String -> (Event -> Fay ()) -> Fay ()
addWindowEvent = ffi "window.addEventListener(%1, %2)"

showEvent :: String -> Event -> Fay()
showEvent prefix event = putStrLn (prefix ++ show event)

setup :: Event -> Fay()
setup event = do
  putStrLn "The document has loaded"
  addEvent "click" (putStrLn "Using addEvent")
  addWindowEvent "click" (showEvent "Using addWindowEvent ")

main :: Fay ()
main = do
  addWindowEvent "load" setup

Expected behaviour: on clicking anywhere in the window both "Using addEvent" and "Using addWindowEvent" show up in the console.
Current behaviour: only "Using addWindowEvent" shows up.

Seeing there is removeEvent which takes an element, I don't understand why addEvent does not take an element.

A mistake, probably.
I don't have a working fay installation at the moment so I can't debug this now, but I'd recommend trying the fay-jquery bindings, it's more mature.

The code is definitely bitrotten. However it should be easy to fix it and make it do what you want. I opened a PR for addRequest here - https://github.com/faylang/fay-dom/pull/6/files.

Thank you, that explains it all. Closing the issue.


Use static NetworkWriter instances in NetworkIdentity

Attempt at a fix motivated by me getting a ton of allocations even when a networked object is not doing any work:

Overall, the NetworkWriter pattern has rather disappointing performance implications. This especially hurts in network-heavy VR games where dropping frames due to garbage collection is quite noticable. One option would be to use resettable NetworkWriters like this all over the place, but it's kind of cumbersome (and probably hard to fix in the case of Commands/ClientRPCs).

Thanks for the pull request. We want to avoid premature optimization for now, since this is what made the original HLAPI so complex and error prone.
I am closing this for now, not because we don't think there is value in it, but because we want to get everything else perfect first. If we still have performance/GC issues at the end, then we can still do these types of optimizations.
Thanks


SSL corruption for loading frontend

This error is strange. When using your latest deployment without SSL it works like a charm with latest features and fast performance. This is what it looks like

However, when applying SSL to the project it appears to go back to a previous version somehow and bugs out. The tool is very slow, doesn't scroll properly and nodes freeze on screen when trying to zoom in and out. You can't move around with the mouse and no arrows appear connecting the nodes.

Are there issues with SSL for this project? Do I need to apply something special or enable something to make this work? I have valid certificates and eiffelvis is hosted at https if im using SSL. I also changed the nginx conf file a bit to properly work with SSL. This has worked previously in #102 but failed when we upgraded to the latest version #141

Just to make sure, have you tried this on a browser with the cache flushed, ideally in anonymous browsing?
The issue sounds like a client-side caching behavior.

In incognito mode the new layout appears as the first image. But no nodes are showing. Same with a different browser i've never tested this before. However it gives an error in console:
Uncaught (in promise) DOMException: The operation is insecure. [bundle.js:2]

Did you build the frontend with EIFFELVIS_SSL = true in the .env ? (default in Dockerfile is false)

I guess you didn't because our documentation does not mention the need to do that when doing non-manual deployment.
I will update the documentation to clarify.

I did a hard refresh in the browser and the new layout appeared with SSL enabled. And yes, I did build with EIFFELVIS_SSL = true. Do I also need to change anything in the Dockerfile?
Now this appears, not sure if this is due to a problem on my side or something is not compatible.
`Mixed Content: The page at 'https://eiffelvisURL' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://eiffelvisURL/ws'. This request has been blocked; this endpoint must be available over WSS.
Uncaught (in promise) DOMException: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS.`

Just to clarify, you changed EIFFELVIS_SSL in the Dockerfile, not in the .env, correct?

I changed it in both of them. first i .env file and then in Dockerfile, now both are True


"Setting up TensorFlow for Development" no longer works with recent TF versions

Environment info
Operating System: OS X 10.11, Ubuntu 15.10
Source build, commit hash: e39d8feebb9666a331345cd8d960f5ade4652bba
Steps to reproduce
I have TF as a submodule and build it local to the project. I use more or less the exact same commands in the development setup. The only minor change is that I don't run python setup.py develop (under OS X, this breaks my Anaconda python installation completely via screwing with the site-packages). So the steps are (in Makefile syntax):
git submodule update --init --recursive
cd $(TF_DIR) && ./configure
cd $(TF_DIR) && bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
cd $(TF_INSTALL_DIR) && ln -s $(addprefix ../../,$(wildcard $(TF_DIR)/bazel-bin/tensorflow/tools/pip_package/build_pip_package.runfiles/*)) .
$(TF_INSTALL_DIR) && ln -s $(addprefix ../../,$(wildcard $(TF_DIR)/tensorflow/tools/pip_package/*)) .

The prefix commands are for making globs work in Make. I have confirmed they expand to the same symlink commands.
Issue
Importing tensorflow no longer works using development guidelines. Specifically, assuming tensorflow is cloned into $TF_DIR, symlinked into $TF_INSTALL_DIR, and built by bazel in $BAZEL_TMP, this no longer works: (output sanitized manually)
$ PYTHONPATH=$TF_INSTALL_DIR python
Python 2.7.10 (default, Oct 14 2015, 16:09:02)
[GCC 5.2.1 20151010] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "$TF_INSTALL_DIR/tensorflow/__init__.py", line 23, in <module>
    from tensorflow.python import *
  File "$TF_INSTALL_DIR/tensorflow/python/__init__.py", line 49, in <module>
    from tensorflow.core.framework.graph_pb2 import *
  File "$TF_INSTALL_DIR/tensorflow/core/framework/graph_pb2.py", line 6, in <module>
    from google.protobuf import descriptor as _descriptor
  File "$BAZEL_TMP/tensorflow/bazel-out/local_linux-opt/bin/tensorflow/tools/pip_package/build_pip_package.runfiles/google/protobuf/descriptor.py", line 46, in <module>
    from google.protobuf.pyext import _message
  File "$BAZEL_TMP/tensorflow/bazel-out/local_linux-opt/bin/tensorflow/tools/pip_package/build_pip_package.runfiles/google/protobuf/pyext/__init__.py", line 2, in <module>
    __import__('pkg_resources').declare_namespace(__name__)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2226, in declare_namespace
    _handle_ns(packageName, path_item)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2195, in _handle_ns
    path.sort(key=sort_key)
  File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2193, in sort_key
    return sys_path.index(_normalize_cached(os.sep.join(parts)))
ValueError: '$BAZEL_TMP/tensorflow/bazel-out/local_linux-opt/bin/tensorflow/tools/pip_package/build_pip_package.runfiles' is not in list

Linux output shown, but OS X also fails with a similar exception.
What have you tried?
I believe the issue comes down to the same one as #1535. I am creating this issue separately so that if it turns out to be a different problem, it isn't muddled. If it's the same, we can close it.
The exception is a result of namespace package resolution in google.protobuf trying to find $BAZEL_TMP/tensorflow/bazel-out/local_linux-opt/bin/tensorflow/tools/pip_package/build_pip_package.runfiles/google/protobuf/pyext. It is trying to find it in a list of system paths which includes $TF_INSTALL_DIR. Recall that due to the development setup rules, the files in $TF_INSTALL_DIR are symlinks to files in $BAZEL_TMP. Specifically, $TF_INSTALL_DIR/google/protobuf is the same directory as $BAZEL_TMP/google/protobuf. (I have verified this with pwd -P.
What seems to be going on is that Python is attempting to unify the protobuf namespace package, but its filename ($BAZEL_TMP/google/protobuf/pyext) does not match the sys.path entry ($TF_INSTALL_DIR).
Note: This only appears to be a problem when trying to use the development install rules, and it only appears to be a problem when there's another tensorflow or protobuf installed in the system somewhere else. At least on OS X; the other version of tensorflow on my Linux machine is in use by other users, so I can't uninstall it safely. I have not attempted to create a clean virtual environment just for my development directory (for one, because virtual environments are a pain in the neck; and two, that's part of the whole point of having a local build of tensorflow).
Workaround: Replacing the symlinks with a recursive copy (from $BAZEL_TMP to $TF_INSTALL_DIR) is apparently sufficient to convince Python that it's unified the namespace packages correctly, and it chooses the $TF_INSTALL_DIR specified in $PYTHONPATH.
So I don't know what the appropriate solution here is, but the problem seems to be the result of a convergence of semi-hacky solutions, any one of which alone might not be an issue, but work together to cause problems:

There's no clean way to extract the necessary files from a built tensorflow without going through pip install. Perhaps there's a method using pip I'm not aware of (maybe something with --target?).
Python namespace packages have poor path resolution semantics. It looks like this ship has sailed.
The symlink approach is kind of coarse and tricky to script around.

Hi @rdadolf , I met this problem just now by coincidence. I tried rebuild the project but the problem was   not solved. Then I tried pip uninstall tensorflow and python setup.py develop. It was fixed.

Yep, this is one workaround. I mentioned that this did alleviate the issue in the "Note:" piece above, and I think a similar approach was mentioned in the other issue I referenced. I should have probably placed it more prominently.
This doesn't help a whole lot with shared systems, however. I have other folks who work on an older, stable install of TF on the same system (and sometimes I'm one of them), so uninstalling isn't a solution in my case. I believe virtualenv's have been tried, and they may work here, but one of the whole ideas behind a local install was to avoid that route.
I'm glad that this solved your problem, though.
To devs: if it looks like this problem is too much of a pain for not enough benefit, another stopgap would be to update the development setup docs to point out that you either need to have protobuf version compatibility and/or uninstall other versions of tensorflow to do this. Might save some folks in @wangg12's situation some headache.

@rdadolf I'm also using a shared system. But for python, I installed an anaconda just for me. So there won't be any problem to influence others' environment.

For those that land on this ticket from Google searches, you might also want to check out https://github.com/tensorflow/tensorflow/issues/2591 which outlines a typo in the master docs.

Just a followup on @orionr's mention: the typo in #2591 is a recent addition: prior to around May 24 2016, the line in the setup documentation didn't have this issue, since the org_tensorflow part didn't exist. (This is the relevant diff.) So the original issue in this thread is not a symptom.
Thank you for mentioning it, though. They are similar issues, and it's tricky to find all of the relevant issue/commit threads in github. This helped me eliminate another recent problem regarding bazel versioning.

Given the recent flux, I thought I'd update this issue based on a more recent version (79174af).
First, I've updated to bazel 2.3 to avoid this problem, so the relevant commands now use the org_tensorflow syntax (with the typo fix).
The changes to protobuf have not solved these issues, they've just broken them in different ways.
Change in behavior regarding manual import
It looks like the change has broken the way I was importing TensorFlow in the original issue. I.e, running through the TensorFlow development setup instructions without the setup.py step and just importing from the directory no longer works. The specific commands are (not in Makefile syntax this time, to make things easier to read):
cd $TF_DIR && ./configure
cd $TF_DIR && bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
rm -r $TF_INSTALL_DIR
mkdir $TF_INSTALL_DIR
cd $TF_INSTALL_DIR && cp -r $TF_DIR/bazel-bin/tensorflow/tools/pip_package/build_pip_package.runfiles/org_tensorflow/* .
cd $TF_INSTALL_DIR && cp -r $TF_DIR/tensorflow/tools/pip_package/* .

Example 1: In a clean environment, protobuf is not found.
PYTHONPATH=$TF_INSTALL_DIR python
>>> import tensorflow as tf
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "$TF_INSTALL_DIR/tensorflow/__init__.py", line 23, in <module>
    from tensorflow.python import *
  File "$TF_INSTALL_DIR/tensorflow/python/__init__.py", line 58, in <module>
    raise ImportError(msg)
ImportError: Traceback (most recent call last):
  File "$TF_INSTALL_DIR/tensorflow/python/__init__.py", line 52, in <module>
    from tensorflow.core.framework.graph_pb2 import *
  File "$TF_INSTALL_DIR/tensorflow/core/framework/graph_pb2.py", line 6, in <module>
    from google.protobuf import descriptor as _descriptor
ImportError: No module named google.protobuf

Error importing tensorflow.  Unless you are using bazel,
you should not try to import tensorflow from its source directory;
please exit the tensorflow source tree, and relaunch your python interpreter
from there.

Example 2: In a mixed environment (i.e., one with a system-installed version of tensorflow and a custom verstion. In this case, they are the same version of protobuf, so we don't get an error as in the original issue):
PYTHONPATH=$TF_INSTALL_DIR python
>>> import tensorflow as tf
>>> tf.__file__
$TF_INSTALL_DIR/tensorflow/__init__.pyc
>>> import google.protobuf
>>> google.protobuf.__file__
$SYSTEM_SITE_PACKAGES/google/protobuf/__init__.pyc

It looks like the changes have made importing directly impossible. That's unfortunate, but I understand that it wasn't a supported behavior in the first place. So I bit the bullet and tried to make things work as in the first bullet point I mentioned in the original file (working through setup.py or pip).
Installing via "Setting up TensorFlow for Development"
Same commands as before, but this time using the setup.py as written (and a separate build directory):
cd $TF_DIR && ./configure
cd $TF_DIR && bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
rm -r $TF_BUILD_DIR
mkdir $TF_BUILD_DIR
cd $TF_BUILD_DIR && ln -s $TF_DIR/bazel-bin/tensorflow/tools/pip_package/build_pip_package.runfiles/org_tensorflow/* .
cd $TF_BUILD_DIR && ln -s $TF_DIR/tensorflow/tools/pip_package/* .
python $TF_BUILD_DIR/setup.py develop

Note: this is not safe. This can overwrite files in your site-packages directory, including replacing existing easy_install and wheel scripts and modifying your existing sys.path through .pth files. If there's a flaw here (or, say a mismatch between the version of setuptools that TensorFlow just installed and your other tools like, say pip or conda) and you're not using some type of sandboxing (virtualenv, VM, etc.), python is basically broken until you manually remove the offending files TensorFlow installs (and you won't be able to use the --uninstall option because of the same underlying issue). Also, if you already had a working version of tensorflow, it's now gone, as they conflict and setup.py will remove the other. So as before, I hope you were working in a sandbox.
So this sort of works, but it doesn't solve my original problem of having any sort of control over where the library was installed. So there are a couple of possible solutions:
Flags to setup.py
setup.py develop takes an --install-dir flag. Long story short, it doesn't work. 1) it requires pre-modifying your environment, 2) it doesn't actually obey the flag---it still modifies files in your default site-packages, and 3) it doesn't actually work: python doesn't find the library, even when the directory is specified in PYTHONPATH.
Counter-intuitively, setup.py install has different options, including a --prefix flag, which doesn't do quite the same thing. Except it turns out that this the same problems.
Ultimately, both of these use .pth files as an underlying mechanism. Because python only reads .pth files from four specific directories, these methods are unworkable.
Flags to pip
So the remaining option is to forget the "development" options altogether and attempt to use the pip package. Recent versions of pip take a --prefix option, which is supposed to support this. So the commands are:
cd $TF_DIR && ./configure
cd $TF_DIR && bazel build -c opt //tensorflow/tools/pip_package:build_pip_package
$TF_DIR/bazel-bin/tensorflow/tools/pip_package/build_pip_package $TF_BUILD_DIR
pip install $TF_BUILD_DIR/tensorflow-0.8.0-py2-none-any.whl --prefix=$TF_INSTALL_DIR

and we get this output:
Thu Jun 2 16:27:58 EDT 2016 : === Using tmpdir: /var/folders/mw/kf4sryxx1xvgh2kyg9_yxvsw0000gn/T/tmp.XXXXXXXXXX.PYkoZMt7
/var/folders/mw/kf4sryxx1xvgh2kyg9_yxvsw0000gn/T/tmp.XXXXXXXXXX.PYkoZMt7 ~/scratch/tensorflow
Thu Jun 2 16:27:58 EDT 2016 : === Building wheel
~/scratch/tensorflow
Thu Jun 2 16:28:10 EDT 2016 : === Output wheel file is in: $TF_BUILD_DIR
Processing $TF_BUILD_DIR/tensorflow-0.8.0-py2-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): six>=1.10.0 in $SYSTEM_SITE_PACKAGES (from tensorflow==0.8.0)
Collecting protobuf==3.0.0b2 (from tensorflow==0.8.0)
  Using cached protobuf-3.0.0b2-py2.py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): numpy>=1.10.1 in $SYSTEM_SITE_PACKAGES (from tensorflow==0.8.0)
Requirement already satisfied (use --upgrade to upgrade): wheel in $SYSTEM_SITE_PACKAGES (from tensorflow==0.8.0)
Requirement already satisfied (use --upgrade to upgrade): setuptools in $SYSTEM_SITE_PACKAGES/setuptools-21.2.1-py2.7.egg (from protobuf==3.0.0b2->tensorflow==0.8.0)
Installing collected packages: protobuf, tensorflow
Successfully installed protobuf tensorflow

And we try importing...
PYTHONPATH=$TF_INSTALL_DIR/lib/python2.7/site-packages python
>>> import tensorflow
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "$TF_INSTALL_DIR/lib/python2.7/site-packages/tensorflow/__init__.py", line 23, in <module>
    from tensorflow.python import *
  File "$TF_INSTALL_DIR/lib/python2.7/site-packages/tensorflow/python/__init__.py", line 58, in <module>
    raise ImportError(msg)
ImportError: Traceback (most recent call last):
  File "$TF_INSTALL_DIR/lib/python2.7/site-packages/tensorflow/python/__init__.py", line 52, in <module>
    from tensorflow.core.framework.graph_pb2 import *
  File "$TF_INSTALL_DIR/lib/python2.7/site-packages/tensorflow/core/framework/graph_pb2.py", line 6, in <module>
    from google.protobuf import descriptor as _descriptor
ImportError: No module named google.protobuf

Error importing tensorflow.  Unless you are using bazel,
you should not try to import tensorflow from its source directory;
please exit the tensorflow source tree, and relaunch your python interpreter
from there.

Which brings us back to a similar problem. It seems nigh-on impossible to get tensorflow to import protobuf using the new system unless it's installed in the default user or system directory. I believe this boils down to the same namespace packaging issue, but that's just a conjecture at this point.
TL;DR
The new protobuf mechanism doesn't actually solve this problem. Installing tensorflow in a non-standard location seems to cause protobuf imports to fail regardless of how or where.

@rdadolf - thanks for updating to the latest, which eliminates the issue I was commenting on. This might be silly, but have you considered adjusting your PYTHONPATH variable? With that you might be able to get it to find your tensorflow package as well as protobuf. Basically something like this, if import google.protobuf succeeded when you ran python without the path:
PYTHONPATH=$TF_INSTALL_DIR/lib/python2.7/site-packages:$PYTHONPATH python
>>> import tensorflow
...

And, of course, using virtualenv might help (it works great for me), but it looks like you specifically don't want to go that route. Good luck!

Yep. That's the ultimate goal here: place tensorflow in directory X, and point PYTHONPATH to it, and write import tensorflow, where X is a directory of my choosing. Each one of these examples actually sets PYTHONPATH to TF_INSTALL_DIR before running, just like you mention. It certainly seemed like it should be that easy. Unfortunately, it seems that either due some combination of the packaging tools and the way the TensorFlow and/or protobuf packages are written, it's not.
I do understand the virtualenv perspective. Without getting into too much of a holy war, virtualenv takes a very different approach to solving the problem, one that is pretty narrow in scope. Part of my hope was that I would only have to have one solution for dealing with versioning, environment, and consistency. virtualenv can only handle a small piece of the python-only part of that. For instance, there's a collection of training data and preprocessing which needs similar solutions: externally managed, place it in directory X, point Y to it, etc. Virtualenv isn't much help there. Same with some low-level instrumentation code which we use. And this is compounded by running on a variety of machines and platforms. So while I'll admit I'm a little biased because I don't much like virtualenv's approach to the world, I'd also really like to avoid adding more complexity in a lot of places just because of idiosyncrasies in the way tensorflow's package is written. (Especially since it was working two weeks ago!)

Only thing I would suggest is to concatenate to the existing PYTHONPATH rather than overriding it. Take one more look at my previous comment and the :$PYTHONPATH inserted in the middle. If that doesn't work I guess we'll need to hear from the real maintainers.

On Jun 2, 2016, at 3:18 PM, Bob Adolf<EMAIL_ADDRESS>wrote:
Yep. That's the ultimate goal here: place tensorflow in directory X, and point PYTHONPATH to it, and write import tensorflow, where X is a directory of my choosing. Each one of these examples actually sets PYTHONPATH to TF_INSTALL_DIR before running, just like you mention. It certainly seemed like it should be that easy. Unfortunately, it seems that either due some combination of the packaging tools and the way the TensorFlow and/or protobuf packages are written, it's not.
I do understand the virtualenv perspective. Without getting into too much of a holy war, virtualenv takes a very different approach to solving the problem, one that is pretty narrow in scope. Part of my hope was that I would only have to have one solution for dealing with versioning, environment, and consistency. virtualenv can only handle a small piece of the python-only part of that. For instance, there's a collection of training data and preprocessing which needs similar solutions: externally managed, place it in directory X, point Y to it, etc. Virtualenv isn't much help there. Same with some low-level instrumentation code which we use. And this is compounded by running on a variety of machines and platforms. So while I'll admit I'm a little biased because I don't much like virtualenv's approach to the world, I'd also really like to avoid adding more complexity in a lot of places just because of idiosyncrasies in the way tensorflow's package is written. (Especially since it wa s working two weeks ago!)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

This would be nice to figure out with "just use PYTHONPATH" way.  This way one could start ipython notebook to play around with their tensorflow changes in Jupyter, but current way is limiting you to simple_console.py

These set of commands work for me :
mkdir tensorflow
export TF_INSTALL_DIR=/tmp/tensorflow
pip install --prefix=$TF_INSTALL_DIR https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.9.0rc0-cp27-none-linux_x86_64.whl
Collecting tensorflow==0.9.0rc0 from https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.9.0rc0-cp27-none-linux_x86_64.whl
Using cached https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.9.0rc0-cp27-none-linux_x86_64.whl
Requirement already satisfied (use --upgrade to upgrade): six>=1.10.0 in /usr/local/lib/python2.7/dist-packages (from tensorflow==0.9.0rc0)
Requirement already satisfied (use --upgrade to upgrade): protobuf==3.0.0b2 in /usr/local/lib/python2.7/dist-packages (from tensorflow==0.9.0rc0)
Requirement already satisfied (use --upgrade to upgrade): wheel in /usr/lib/python2.7/dist-packages (from tensorflow==0.9.0rc0)
Requirement already satisfied (use --upgrade to upgrade): numpy>=1.8.2 in /usr/lib/python2.7/dist-packages (from tensorflow==0.9.0rc0)
Requirement already satisfied (use --upgrade to upgrade): setuptools in /usr/local/lib/python2.7/dist-packages (from protobuf==3.0.0b2->tensorflow==0.9.0rc0)
Installing collected packages: tensorflow
Successfully installed tensorflow

PYTHONPATH=$TF_INSTALL_DIR/lib/python2.7/site-packages:$PYTHONPATH python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tensorflow as tf
tf>>> tf.__file__
'/tmp/tensorflow/lib/python2.7/site-packages/tensorflow/__init__.pyc'

mkdir /tmp/tensorflow
export TF_INSTALL_DIR=/tmp/tensorflow

I am on a Ubuntu 14.04, though. Can you give this a shot? Having said that, virtualenv is our tested installation methodology. We need lot more people asking for this way on installation before we can start thinking about supporting and testing this. Feel free to keep this open in case you really want to see this supported, otherwise please close the issue.

@rdadolf Closing this one out due to inactivity. I don't see anything fundamentally broken about using pip with --prefix and using $PYTHONPATH later, at least in the platforms I tried. Please feel free to reopen if you think this is still an issue worth solving.


Fix spelling in package description

Wicktionary marks "powerfull" as an "archaic form of powerful", so I suppose it could be fixed?

They say archaic, I say classic.

Thanks


Make compatible with addons.js register

Compared to other addons, this addon is required to be added in the config.js as there is no register function. It would be nice it could be applied as every other addon.
Current setup
config.js:
import '@storybook/addon-console';

Expected setup
addons.js:
import '@storybook/addon-console/register';

Hey @renestalder

Hey @renestalder
there are different ways how people can extend Storybook functionality
usually addons add something to addons.js when they injects some UI into Storybook interface. But this addon don't have own panel it uses panel of another addon for displaying outputs.
Another addon is @storybook/addon-actions which is specified as a Peer Dependency - didn't you notice a warning about missing peer dependency?
This way allows to focus only on the one thing and don't bloat addons panel
So sorry for not clear readme, I expected that users usually have addon-actions, but actually I shouldn't rely on that :smile:

After Storybook v5 got rich UI options it possibly worth to add something to notify users on the manager-side

@UsulPro Thanks for clarification.


Failed to get maven-metadata.xml file

I'm attempting to execute the following command:
prospero.sh install -vv --channels=dev.resteasy.channels:resteasy-6.2,org.wildfly:wildfly --dir=wildfly --fpl=org.wildfly:wildfly-galleon-pack --use-default-local-cache

However, the dev.resteasy.channels:resteasy-6.2/maven-metadata.xml cannot be found by the dependency resolution. The file does exist though, https://repo1.maven.org/maven2/dev/resteasy/channels/resteasy-6.2/maven-metadata.xml. Below is the error I'm seeing:
org.wildfly.channel.ArtifactTransferException: dev.resteasy.channels:resteasy-6.2/maven-metadata.xml failed to transfer from https://repo1.maven.org/maven2 during a previous attempt. This failure was cached in the local repository and resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer metadata dev.resteasy.channels:resteasy-6.2/maven-metadata.xml from/to central (https://repo1.maven.org/maven2): Cannot access https://repo1.maven.org/maven2 with type  using the available connector factories: BasicRepositoryConnectorFactory
	at org.jboss.prospero//org.wildfly.channel.maven.RetryHandler$RetryCounter.addRetry(RetryHandler.java:144)
	at org.jboss.prospero//org.wildfly.channel.maven.RetryHandler.attemptResolveMetadata(RetryHandler.java:109)
	at org.jboss.prospero//org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.getAllVersions(VersionResolverFactory.java:153)
	at org.jboss.prospero//org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.resolveChannelMetadata(VersionResolverFactory.java:238)
	at org.jboss.prospero//org.wildfly.channel.maven.VersionResolverFactory.resolveChannels(VersionResolverFactory.java:340)
	at org.jboss.prospero//org.wildfly.prospero.api.ProvisioningDefinition.resolveChannels(ProvisioningDefinition.java:177)
	at org.jboss.prospero//org.wildfly.prospero.cli.commands.AbstractInstallCommand.resolveChannels(AbstractInstallCommand.java:93)
	at org.jboss.prospero//org.wildfly.prospero.cli.commands.InstallCommand.call(InstallCommand.java:149)
	at org.jboss.prospero//org.wildfly.prospero.cli.commands.InstallCommand.call(InstallCommand.java:50)
	at org.jboss.prospero//picocli.CommandLine.executeUserObject(CommandLine.java:2041)
	at org.jboss.prospero//picocli.CommandLine.access$1500(CommandLine.java:148)
	at org.jboss.prospero//picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
	at org.jboss.prospero//picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
	at org.jboss.prospero//picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
	at org.jboss.prospero//picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
	at org.jboss.prospero//picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
	at org.jboss.prospero//picocli.CommandLine.execute(CommandLine.java:2170)
	at org.jboss.prospero//org.wildfly.prospero.cli.CliMain.execute(CliMain.java:132)
	at org.jboss.prospero//org.wildfly.prospero.cli.CliMain.main(CliMain.java:60)
	at org.jboss.modules.Module.run(Module.java:352)
	at org.jboss.modules.Module.run(Module.java:320)
	at org.jboss.modules.Main.main(Main.java:607)
Caused by: org.eclipse.aether.transfer.MetadataTransferException: dev.resteasy.channels:resteasy-6.2/maven-metadata.xml failed to transfer from https://repo1.maven.org/maven2 during a previous attempt. This failure was cached in the local repository and resolution will not be reattempted until the update interval of central has elapsed or updates are forced. Original error: Could not transfer metadata dev.resteasy.channels:resteasy-6.2/maven-metadata.xml from/to central (https://repo1.maven.org/maven2): Cannot access https://repo1.maven.org/maven2 with type  using the available connector factories: BasicRepositoryConnectorFactory
	at org.jboss.prospero//org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.newException(DefaultUpdateCheckManager.java:331)
	at org.jboss.prospero//org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata(DefaultUpdateCheckManager.java:293)
	at org.jboss.prospero//org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:303)
	at org.jboss.prospero//org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:180)
	at org.jboss.prospero//org.apache.maven.repository.internal.DefaultVersionRangeResolver.getVersions(DefaultVersionRangeResolver.java:198)
	at org.jboss.prospero//org.apache.maven.repository.internal.DefaultVersionRangeResolver.resolveVersionRange(DefaultVersionRangeResolver.java:148)
	at org.jboss.prospero//org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveVersionRange(DefaultRepositorySystem.java:260)
	at org.jboss.prospero//org.wildfly.channel.maven.VersionResolverFactory$MavenResolverImpl.lambda$getAllVersions$0(VersionResolverFactory.java:155)
	at org.jboss.prospero//org.wildfly.channel.maven.RetryHandler.attemptResolveMetadata(RetryHandler.java:96)
	... 20 more

The ~/.m2/repository/dev/resteasy/channels/resteasy-6.2/resolver-status.properties contains the following:
#NOTE: This is a Maven Resolver internal implementation file, its format can be changed without prior notice.
#Fri Jun 21 10:15:38 PDT 2024
maven-metadata-central.xml.error=Could not transfer metadata dev.resteasy.channels\:resteasy-6.2/maven-metadata.xml from/to central (https\://repo1.maven.org/maven2)\: Cannot access https\://repo1.maven.org/maven2 with type  using the available connector factories\: BasicRepositoryConnectorFactory
maven-metadata-central.xml/@-central-https\://repo1.maven.org/maven2/.lastUpdated=1718990095779

I'm not too sure what the issue could be.

@jamezp thanks for the report, there's two issues here: 1) a bug fixed in #703, and 2) there are no channels published at the GAVs you're using, only manifests (channel artifact would have a channel classifier).
I think what you're trying to achieve is:
echo '---
schemaVersion: "2.0.0"
name: "wildfly"
repositories:
  - id: "central"
    url: "https://repo1.maven.org/maven2/"
  - id: "jboss-public"
    url: "https://repository.jboss.org/nexus/content/groups/public/"
  - id: "mrrc"
    url: "https://maven.repository.redhat.com/ga/"
manifest:
  maven:
    groupId: "org.wildfly.channels"
    artifactId: "wildfly"
---
schemaVersion: "2.0.0"
name: "resteasy"
repositories:
  - id: "central"
    url: "https://repo1.maven.org/maven2/"
manifest:
  maven:
    groupId: "dev.resteasy.channels"
    artifactId: "resteasy-6.2"' > resteasy-channel.yaml

prospero.sh install --channels resteasy-channel.yaml --dir test-wfly --fpl org.wildfly:wildfly-galleon-pack

Unfortunately since this requires two channels, it's not possible to execute it as a oneliner with --manifest and --repositories

Thank you @spyrkob. I was wondering if it was a missing channel issue. Would it make sense for manifests which just want to override the version of provisioned dependencies to also create a channel? I don't think there is much effort in doing this, but I want to make sure it also won't make a mess of things.
IoW, in this specific case should RESTEasy also create a channel that gets published?

Would it make sense for manifests which just want to override the version of provisioned dependencies to also create a channel?

Yes, each channel is tied to a single manifest so an overwrite manifest has to come with it's own channel. Note it's possible to define a dependency on another channel (see requires field in manifest definition). Using this the WildFly channel would be created based on repositories defined in the RESTEasy channel and the required manifest.

IoW, in this specific case should RESTEasy also create a channel that gets published?

I'd say if you feel like this would make it easier to consume the manifest, than sure. So far we haven't been publishing channel definitions for any other projects, but we're really only starting with them in WildFly :)


acme: add missing setrlimit call for lego

$ sudo journalctl _AUDIT_TYPE_NAME=SECCOMP -f
Oct 25 09:25:07 ***** audit[619521]: SECCOMP auid=4294967295 uid=996 gid=60 ses=4294967295 subj=kernel pid=619521 comm="lego" exe="/nix/store/pbpkp3yqj5raw05624xscsl5ix1xl73p-lego-4.9.0/bin/lego" sig=31 arch=c000003e syscall=160 compat=0 ip=0x4043ee code=0x80000000

Otherwise it crashes at startup.
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This might be a duplicate of #197513 , which was fixed in #197544 yesterday. Could you try with that patch please? It looks like the same error.

You are right. I think https://github.com/NixOS/nixpkgs/pull/197544/commits/f2831a98b7fc3401c85033b834228725dbcb1511
should also fixes it. I did not had this commit on the machine, where I saw the error.


Add Cypress as a provider for browser mode

Clear and concise description of the problem
Currently, we have a codebase that's utilizing Cypress for e2e.
We also bundle our application with vite, as well as having many unit tests written with jest and we're considering migrating them to vitest and a bunch storybook stories.
Instead of having many tools, one for each purpose, we'd like to have them integrate with each other (just like the new storybook integration). Ideally we'd have Cypress, Storybook, vitest and vite all talk to each other.
Suggested solution
Add a new browser mode provider for Cypress
Alternative
Allow for the creation of custom provider and let the community develop the Cypress integration, as well as extracting playwright and webdriverio to their own custom provider.
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Cypress is a test runner, not a browser provider. They do not expose any APIs to just open a browser, like playwright and webdriverio do, so this request is not possible to achieve.

Allow for the creation of custom provider

It is already possible to create custom providers - the browser.provider field also accepts a file path, but beware that all Vitest API (and especially browser API) are experimental and can change at any time.


Allow to jsonPatch containers

Hi,
Currently, can't patch container objects
my_container = my_deployment.add_container(kplus.ContainerProps(...))
kubeContainer = cdk8s.ApiObject.of(my_container)

Gets
Expected type 'IConstruct', got 'Container' instead

The current solution is to patch the deployment instead but:

This is easy when I have a single container. but patching a container in a list is a lot harder
This means that I can’t reuse the patched container.

Thank you

Effort large because I still don't really know how to implement this, but its a nice feature to have.


mat-list-option tabindex is -1 in mat-selection-list

Reproduction
Steps to reproduce:

https://stackblitz.com/angular/dlookbyxlng?file=src%2Fapp%2Flist-selection-example.html
try navigating the selection list using tab

Expected Behavior
users should be able to navigate each list option using tab
Actual Behavior
only the first option is reachable using tab
setting tabindex="0" is changed back to tabindex="-1"
Environment

Angular: 9
CDK/Material: 9.1.0
Browser(s): all
Operating System (e.g. Windows, macOS, Ubuntu):

same with mat-radio-button in mat-radio-group

MatSelectionList is implemented as an ARIA listbox, and thus follows the ARIA Listbox Design Pattern. The keyboard interaction specified in the design pattern is that arrow keys should move between list options, not tab. If MatSelectionList navigated between list options with tab, it would fail to follow the listbox keyboard interaction, and subsequently be a confusing widget for keyboard and screen reader users.
Essentially the same story for MatRadioGroup, take a look at the ARIA Radio Group Design Pattern.

Closing since it's working as expected.


Create labels only style

Needed for #31. Create a style definition that renders only the wanted labels.

Labels only style created and merged.


No Camera Access in Demo File

If I open the downloaded demo file, it does not access the camera. It displays the placeholder in the canvas.

I don't think the demo is supposed to work outside a web server. You can't just open the file from disk. Use a local web server for testing.
You can view the demo online at https://amw.github.io/jpeg_camera/demo/ . These are exactly the same files that you download from the repo.

Thanks alot for your quick response. Actually I am new coder, so sorry for asking this type of question.


More expandable bg color modifiers - [Copied from FlapJack backlog]

We need white and gray padded bg modifiers so we can do white single expandables or gray stacked expandable groups which makes this pattern way more versatile across different background types.

Is this theoretical or do we have a location where this background variation is necessary? cc @nataliafitzgerald

😂 Like I can remember why we had this in the flapjack backlog over two years ago

@jimmynotjim @anselmbradford
The only expandables I've seen on the website are the white background groups of expandables. That's not to say that we aren't using an individual white (or gray) or a group of gray, I just haven't seen it on our site. Is there a way for us to do a search and find everywhere a pattern is used on our site?
I do see that we accounted for all these types in our DM: https://cfpb.github.io/design-manual/page-components/expandables.html

Individual white
Individual  gray
Group white
Group gray

The filterable list controls on the blog and newsroom are single gray expandables and well being results page uses a single white expandable https://www.consumerfinance.gov/consumer-tools/financial-well-being/results/

This was fixed in #787


Use Vite4 or Vite5 manifests, not both

Description 📖
This fixes an issue where upgrading to Vite5 was merging old Vite4 and Vite5 manifests together, creating JS errors.
Background 📜
This was happening because vite_ruby was merging vite4 and vite5 manifests together.
The Fix 🔨
Check for Vite5 manifests. If present, use those, otherwise fall back to Vite4 manifests.
Amends #420

I'm going through the same problem.

I just upgraded to Vite 5 and am dealing with this now as well.

Hey @ElMassimo , is there anything that needs to be done here before this can be merged?

@ElMassimo we're eager to see this merged. Is there anything we can do to help?

@ElMassimo Could this please be merged and included in the next release?

Is there anything we can do to help with getting this released?

HI @ElMassimo! I'm also offering my help to get this released as soon as possible.

This should have shipped along 3.5.0, when we started enforcing:
  "vite": "~>5.0.0"

That means 3.5.0 would fail early if used with vite 4, prompting users to run bin/vite upgrade, which would install vite 5.
Any deployment that switches from vite 4 to vite 5 would modify package.json, so the last build would be stale, making it safe to assume the manifests will always be in the new location.


Stop defaulting within the template blocks

The type of the StackSpec.workspaceTemplate field should be an "apply" variant, similar to k8s.io/client-go/applyconfigurations; it should not set any default values.  Otherwise it makes for noise in the higher-level APIs.
For example, when we apply a given stack:
kind: Stack
spec:
  workspaceTemplate:
    spec:
      image: pulumi/pulumi:3.134.1-nonroot

We get:
kind: Stack
spec:
  workspaceTemplate:
    metadata: {}
    spec:
      image: pulumi/pulumi:3.134.1-nonroot
      resources: {}
      securityProfile: restricted
      serviceAccountName: default

Added to epic https://github.com/pulumi/pulumi-kubernetes-operator/issues/586

I think this is more to do with the WorkspaceSpec embedded in the Stack. We probably want an annotation to disable defaults on it (if there is such a thing) or create a separate Partial/Embedded type without defaults.
https://github.com/pulumi/pulumi-kubernetes-operator/blob/58b053960356ce484dee24a47f5aaed475ba9f7d/operator/config/crd/bases/pulumi.com_stacks.yaml#L9340-L9344

@blampe there's a code generator for just this purpose (applyconfigurations), to generate an EmbeddedWorkspaceSpec.
The same issue is present with PodTemplate in the WorkspaceSpec. IIRC there was a problem with DeepCopy being missing on the generated code, need to revisit it.


Underscores in numerals

This is a pretty straightforward feature request for _ characters in numbers in ron, similar to how they are allowed in Rust. I'm really just looking to make my files with big numbers slightly more readable.
To clarify, I want to be able to write this:
foo: 123_456_789.0

Currently, ron gives a Parser(ExpectedArrayEnd, Position { ... }) error at the underscore.

I'm just seeing that your example uses a floating point number. In my PR I
only implemented it for integers.
On Sun, Oct 14, 2018, 04:58 bors[bot]<EMAIL_ADDRESS>wrote:

Closed #134 https://github.com/ron-rs/ron/issues/134 via #135
https://github.com/ron-rs/ron/pull/135.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ron-rs/ron/issues/134#event-1902421540, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AWFFuThm_E93KKFqkT1ncpiG8ZKOKb4eks5ukqhDgaJpZM4XaOJF
.


Filters from v1 not working with v3

I used to have a query like this which used to work in v1, but this is no longer working with v3, and this is not mentioned as a breaking change in the migration guide.
const records = await conn.sobject("Opportunity")
    .where({
        Amount: { $gte: 45000, $lte: 75000 },
        OwnerId: ['0055h00000AKFzTAAX']
    })
    .execute();

This produces an invalid query string, where the Amount <= 75000 condition is missing.
SELECT Id, LastModifiedDate, CreatedDate, Name, AccountId, OwnerId, Amount, StageName, Probability, ExpectedRevenue, NextStep FROM Opportunity WHERE OwnerId IN ('0055h00000AKFzTAAX') AND Amount >= 45000

I tried to debug the issue myself, but I couldn't seem to install the dependencies using npm i :(

The issue is that when passed as object, it only takes the the first key, not all of them.
https://github.com/jsforce/jsforce/blob/38b60d64414929078a3f371c126e63aa383f0744/src/soql-builder.ts#L108

The issue is that when passed as object, it only takes the the first key, not all of them.

@stomita do you remember if this change was on purpose? I think @pavitra-infocusp is right but trying to refactor the query builder to match this breaks some tests:
https://github.com/jsforce/jsforce/blob/c04515846e91f84affa4eb87a7b2adb1f58bf04d/lib/soql-builder.js#L132-L136
in the meantime, you can pass multiple conditionals as an array:
https://jsforce.github.io/document/#conditionals
const soql = await conn.sobject('Opportunity')
  .find({
    $and: [
      { Amount: { $gte: 45000 } },
      { Amount: { $lte: 75000 } }
    ],
    'OwnerId': ['0055h00000AKFzTAAX'],
  }, ['AccountId'])
  .toSOQL()
console.log(soql)

// SELECT AccountId FROM Opportunity WHERE (Amount >= 45000 AND Amount <= 75000) AND OwnerId IN ('0055h00000AKFzTAAX')


Class Initialize inheritance

Description
Allow a ClassInitialize in a base class of a TestClass so that in addition to initializing static variables in the test class, I can initialize static variables in the test base class.
UV item: https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2311366-support-classinitialize-in-base-class

I believe this works if the test class and base class are in the same assemblies.  I'm curious if issue #22 fixed this behavior.

This works for TestInitialize today. ClassInitialize however is not inherited from base classes. We only execute the ClassInitialize of that specific class. The fix for this should just be plugging in similar functionality for Class Initialize/Cleanup as we have for Test Initialize/Cleanup here. FWIW, this should be the default workflow. However, since this would be a change in behavior from v1 mstest, we would also want to add a setting to turn this off as appropriate.

That sounds great!  Though it would be fairly easy to work-around for now, since your test class [ClassInitialize] static method could just manually call your base class [ClassInitialize] static method.  Using a static constructor would also be a work around.  Would love to see this "bug" fixed though!  I've been working on a lot of unit tests lately that could really use this pattern.

Hello
Its also happened for "AssemblyInitialize" attribute and mentioned problem not happened for all Unit testing frameworks (nUnit, xUnit, MbUnit....)
I will be very grateful if it will be fixed soon.
Thanks.

I'm very much pro this idea!
However, there are some details that must be flushed out first:
First, there's the backward compatibility issue that @AbhitejJohn mentioned. But in addition, I can think of at least 2 possible outcomes  of inheriting ClassInitialize:

ClassInitialize will be called only once before any derived class
ClassInitialize will be called before each of the derived classes.
I believe that each of these outcomes may be desired in different situations.

Therefore I suggest to add an optional enum parameter to the ClassInitializeAttribute with the following possible values:

[ClassInitialize] or [ClassInitialize(InheritanceBehavior=ClassInitializeInheritance.None)] - ClassInitialize is called only for tests defined in the same class, as in V1.
[ClassInitialize(InheritanceBehavior=ClassInitializeInheritance.OnceBeforeAnyDerivedClasses)] - ClassInitialize will be called only once before any derived class
[ClassInitialize(InheritanceBehavior=ClassInitializeInheritance.BeforeEachDerivedClass)] - ClassInitialize will be called before each derived class.

Please let me know what you think.

Thanks for detailing that out @arnonax . That does sound interesting although I was hoping to just stick with [ClassInitialize(InheritanceBehavior=ClassInitializeInheritance.BeforeEachDerivedClass)] that is inline with C# behavior and [ClassInitialize] or [ClassInitialize(InheritanceBehavior=ClassInitializeInheritance.None)] for compat. This does sound like a viable alternative to a runsettings switch that is more explicit in code.
/cc: @pvlakshm and @harshjain2 to get their thoughts.

Could this work for [ClassCleanup] too?

Of course. ClassCleanup should be symmetrical to ClassIntialize.
However, please also see my thoughts about a better cleanup mechanism, as I descried in a comment from Sep 8 on Issue 250

Any news?

Not sure if there's anyone working on this issue, but I've assumed that no one is working on it and grab this one.
I've started to implement this new enhancement, and so far so good. Added the parameter to the ClassInitialize attribute, created some unit tests, and it seems to be working fine with "ClassInitializeInheritance.None" and "ClassInitializeInheritance.BeforeEach".
@AbhitejJohn if we will just stick with those two options, according to your comment, I think that by tomorrow I'd be creating the PR for your reviews. Otherwise, I'll keep working on the "ClassInitializeInheritance.OnceBeforeAnyDerivedClasses" as well, to get the three option for the ClassInitialize attr.
let me know your thoughts.

This is great news!!!!

Any update?  Also does ClassInitialize and ClassCleanup work with Async i.e. Task results?  Thanks.

@parrainc : That sounds fantastic, I'm super late to this though but I think we could definitely start with just that two. I've moved on to other things but @jayaranigarg and @singhsarab could help if you still need any.
@AceHack : From here ClassInitialize and ClassCleanup should be async Task friendly too.

@AbhitejJohn cool, It's been a while since I opened the testfx project on my computer, so I have to get my fork up-to-date. After that, will be submitting the PR so @jayaranigarg and @singhsarab can take a look when available.

Consume this change using following nuget packet versions:
https://dotnet.myget.org/feed/mstestv2/package/nuget/MSTest.TestAdapter/2.0.0-build-20190708-01
https://dotnet.myget.org/feed/mstestv2/package/nuget/MSTest.TestFramework/2.0.0-build-20190708-01

This issue is still occuring for me, which is very weird because yesterday it seemed just fine.
`namespace Tests
{
[TestClass]
public abstract class BaseTest
{
protected static TestContext mContext;
    [AssemblyInitialize]
    public static void Assembly(TestContext pContext)
    {
        Core.Construct<FrameworkConstruction>()
            .AddProperties(pContext.Properties)
            .AddConsoleLogger().AddDebugLogger().AddFileLogger()
            .Build();

        Core.Log.Information("AssemblyInitialize: " + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
    }

    [AssemblyCleanup]
    public static void AssemblyCleanup()
    {
        Core.Log.Information("AssemblyCleanup: " + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
    }

    [ClassInitialize]
    public static void ClassInitialize(TestContext pContext)
    {
        mContext = pContext;
        Core.Log.Debug("ClassInitialize: " + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
    }

    [ClassCleanup]
    public static void ClassCleanup()
    {
        Core.Log.Debug("ClassCleanUp: " + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
    }
}

}
`
Above you can see my base test. below you can see my unit tests
namespace Tests {     [TestClass]     public class UnitTest1 : BaseTest     {         [TestMethod]         public void TestMethod1()         {             Core.Log.Debug("TestMethod: " + System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());         }     } }
The assembly is being called, the test method is being called.
INFORMATION: [2019-08-09 08:57:23] AssemblyInitialize: 12 [BaseTest.cs > Assembly() > Line 21]
INFORMATION: [2019-08-09 08:57:23] TestMethod: 12 [UnitTest1.cs > TestMethod1() > Line 15]
INFORMATION: [2019-08-09 08:57:23] AssemblyCleanup: 4 [BaseTest.cs > AssemblyCleanup() > Line 27]
ClassInitialize and Cleanup are not being called

@KitoCoding : For compat reasons this is an opt in at the moment. You'd need to add [ClassInitialize(InheritanceBehavior.BeforeEachDerivedClass)] and [ClassCleanup(InheritanceBehavior.BeforeEachDerivedClass)] to your base class if you want them to be invoked.
@jayaranigarg : Do we also plan to add a runsettings configuration to tune this globally?

@AbhiteJohn
I don't see this feature you speak of. Am i missing a namespace I am not familiar with?

@KitoCoding : you'd need the packages from the daily feed Jaya posted earlier. It doesn't look like this is part of the public nuget feed just yet.

@AbhiteJohn, this Nuget package is missing.
Install-Package MSTest.TestFramework -Version 2.0.0 -Source https://dotnet.myget.org/F/mstestv2/api/v3/index.json
I have tried with the different builds, but it is not able to find any.

@KitoCoding I was able to get the changes from version 2.0.0 in the daily feed. And your example code worked with no issues.

This seems to be broken now. I tried a very simple example:
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace SomeTests
{
    [TestClass()]
    public class TestCase
    {
        [Microsoft.VisualStudio.TestTools.UnitTesting.ClassInitialize(Microsoft.VisualStudio.TestTools.UnitTesting.InheritanceBehavior.BeforeEachDerivedClass)]
        public static void InitMe(Microsoft.VisualStudio.TestTools.UnitTesting.TestContext context)
        {

        }

        [TestMethod]
        public void TestFromBase()
        {

        }
    }

    [TestClass()]
    public class DerivedTestCase : TestCase
    {
        [TestMethod]
        public void TestFromDerived()
        {

        }
    }
}

The project file looks like:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="MSTest.TestFramework" Version="2.0.0-build-20190708-01" />
    <PackageReference Include="MSTest.TestAdapter" Version="2.0.0-build-20190708-01" />
  </ItemGroup>

</Project>

The constructor overload is working, the project builds, Test Explorer detects all of the tests, but when I try to run them, I get:
[8/23/2019 8:02:23.253 PM Error] System.InvalidOperationException: The following TestContainer was not found 'C:\Users\shad\source\repos\ConsoleApp6\SomeTests\bin\Debug\netcoreapp2.0\SomeTests.dll'
   at Microsoft.VisualStudio.TestWindow.Client.TestContainer.TestContainerProvider.<GetTestContainerAsync>d__47.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.TestContainerConfigurationQueryByTestsBase.<QueryTestContainerConfigurationsAsync>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.TestContainerConfigurationQuery.<GetTestContainerConfigurationsAsync>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.TestRunConfiguration.<UpdateAsync>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.RunOperation.<RunTestsAsync>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Controller.Operation.<<Execute>b__37_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.TestWindow.Extensibility.ILoggerExtensions.<CallWithCatchAsync>d__10`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)

I verified the file in the error message definitely exists. I tried updating Windows 10 and Visual Studio 2019 to the latest patches. I tried deleting the bin and obj folders and built again. I also tried running in Visual Studio 2017, but get the same error message.
I also tried using version 2.0.0, and tried swapping out the test adapter with 2.0.0-beta4 from NuGet. No dice.

Not sure if this was a design choice or a bug, but for this simple scenario, InitMe is called twice. I would expect only one call here because there is technically only one executable test class.
Two calls is better than none, but it does complicate things if we have to track these extra calls in order to prevent test data from cleaning up before all of the tests are done.
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace SomeTests
{
    [TestClass()]
    public abstract class TestCase
    {
        [ClassInitialize(InheritanceBehavior.BeforeEachDerivedClass)]
        public static void InitMe(TestContext context)
        {

        }

        [TestMethod]
        public void TestFromBase()
        {

        }
    }

    [TestClass()]
    public class DerivedTestCase : TestCase
    {
        [TestMethod]
        public void TestFromDerived()
        {

        }
    }
}

I found another issue: When the derived type is in another assembly that is referenced in the same project, the FullyQualifiedTestClassName doesn't include the name of the other assembly. So, when calling Type.GetType(context.FullyQualifiedTestClassName), it resolves to null.
Since I am developing a test case framework for an application for 3rd parties to inherit, I have no way of knowing what the assembly name might be, and it wouldn't be very efficient for me to have to load all referenced assemblies to find it.
Also, since my goal is to look for one of my custom attributes on the 3rd party test class, it seems like it might be a good idea to add the TestClassType as a property so I don't have to gamble with the string actually resolving to something.

@NightOwl888 Thanks for the alert to ClassInitialize running multiple times - saved me some time trouble-shooting.
For now I'm keeping track of the current test class on the TestContext which seems sufficient for my needs.
[ClassInitialize(InheritanceBehavior.BeforeEachDerivedClass)]
public static void ClassInitialize(TestContext testContext)
{
    try
    {
        // Due to an apparent bug ClassInitialize is called twice (or perhaps multiple times).
        // See https://github.com/Microsoft/testfx/issues/143
        if (testContext.FullyQualifiedTestClassName == _currentTestClass)
        {
            return;
        }
        _currentTestClass = testContext.FullyQualifiedTestClassName;
        ...

It should also be noted that the class initialization attribute is not being run on the same thread as the test attributes. The test attributes when a worker is running off of the level of test methods should run on separate threads as the class initialization attributes however when a worker is running on a class level then they should all run on the same thread.
On Sep. 10, 2019 12:22 p.m., Mike Branscomb<EMAIL_ADDRESS>wrote:
@NightOwl888https://github.com/NightOwl888 Thanks for the alert to ClassInitialize running multiple times - saved me some time trouble-shooting.
For now I'm keeping track of the current test class on the TestContext which seems sufficient for my needs.
[ClassInitialize(InheritanceBehavior.BeforeEachDerivedClass)]
public static void ClassInitialize(TestContext testContext)
{
try
{
// Due to an apparent bug ClassInitialize is called twice (or perhaps multiple times).
// See https://github.com/Microsoft/testfx/issues/143
if (testContext.FullyQualifiedTestClassName == _currentTestClass)
{
return;
}
_currentTestClass = testContext.FullyQualifiedTestClassName;
...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/testfx/issues/143?email_source=notifications&email_token=ABRAMNY4EYYGCTXU26LSG43QI7CTNA5CNFSM4DG2YQCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6LV7AQ#issuecomment-530014082, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABRAMN5EL7NOYYMLGUEVYYDQI7CTNANCNFSM4DG2YQCA.

@KitoCoding
Thanks. That is a huge problem for me because my test fixture sets the culture during initialization of the class, which obviously needs to be on the same thread as the test in order to function.

@KitoCoding
Thanks. That is a huge problem for me because my test fixture sets the culture during initialization of the class, which obviously needs to be on the same thread as the test in order to function.

I have brought this attention to the team, unfortunately they see this as a low priority. To me this breaks the feature of parallel testing on a classLevel. I have a threadManager that handles all of my objects on a per worker base. Since they offer no way of handling unique IDs per worker, I have to rely on ManagedThreadIds. But since the Init Class attribute and clean up runs on separate threads, I can't clean up worker nodes on a class level.

Has anyone found a workaround for [ClassCleanup] not called at all?
This is a great feature, but useless as it is implemented for now.
I also guess that ClassCleanup should be called AFTER every derived class cleanup to keep the symetry.

Class cleanup as of the latest stable build will not run if the class clean up is not inside the class you are calling from. This means you can't put it in your base test. A simple workaround would be to create a function call that will trigger the initialize or cleanup method. But regarding your other issue 4test class clean up not being triggered after all of the tests have been executed. this is a known issue but the Microsoft team has already announced that this is not a priority to them. I suggest not relying on worker nodes to run on a class level rather to have the one on a method level. I 100% agree that this is silly and should be addressed but they have made it clear that their priorities are not to fix this

Added PR to fix issue where base class cleanup isn't called.

Are there any plans to fix the ClassInitialize method being called multiple times for the same class?
From my (very) simple tests, like other have already mentioned, it looks like the ClassInitialize method is called once for each test. I used the following dependencies:
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.5.0" />
<PackageReference Include="MSTest.TestAdapter" Version="2.1.0" />
<PackageReference Include="MSTest.TestFramework" Version="2.1.0" />

TestBase.cs
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace TestFxIssue143
{
    [TestClass]
    public class TestBase
    {
        public TestContext TestContext { get; set; }

        [ClassInitialize(InheritanceBehavior.BeforeEachDerivedClass)]
        public static void ClassInitialize(TestContext context)
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] ClassInitialize: {context.FullyQualifiedTestClassName}/{context.TestName}");
        }

        [ClassCleanup(InheritanceBehavior.BeforeEachDerivedClass)]
        public static void ClassCleanup()
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] ClassCleanup");
        }

        [TestInitialize()]
        public void TestInitialize()
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] TestIntialize: {this.TestContext.FullyQualifiedTestClassName}/{this.TestContext.TestName}");
        }

        [TestCleanup()]
        public void TestCleanup()
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] TestCleanup: {this.TestContext.FullyQualifiedTestClassName}/{this.TestContext.TestName}");
        }
    }
}

UnitTest1.cs
using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace TestFxIssue143
{
    [TestClass]
    public class UnitTest1 : TestBase
    {
        [TestMethod]
        public void TestMethod1()
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] TestMethod: {this.TestContext.FullyQualifiedTestClassName}/{this.TestContext.TestName}");
        }

        [TestMethod]
        public void TestMethod2()
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] TestMethod: {this.TestContext.FullyQualifiedTestClassName}/{this.TestContext.TestName}");
        }

        [TestMethod]
        public void TestMethod3()
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] TestMethod: {this.TestContext.FullyQualifiedTestClassName}/{this.TestContext.TestName}");
        }
    }
}

And the output is:
TestMethod1
[16:43:26.249] ClassInitialize: TestFxIssue143.UnitTest1/TestMethod1
[16:43:26.261] TestIntialize: TestFxIssue143.UnitTest1/TestMethod1
[16:43:26.261] TestMethod: TestFxIssue143.UnitTest1/TestMethod1
[16:43:26.262] TestCleanup: TestFxIssue143.UnitTest1/TestMethod1

TestMethod2:
[16:43:26.272] ClassInitialize: TestFxIssue143.UnitTest1/TestMethod2
[16:43:26.272] TestIntialize: TestFxIssue143.UnitTest1/TestMethod2
[16:43:26.273] TestMethod: TestFxIssue143.UnitTest1/TestMethod2
[16:43:26.273] TestCleanup: TestFxIssue143.UnitTest1/TestMethod2

TestMethod3:
[16:43:26.273] ClassInitialize: TestFxIssue143.UnitTest1/TestMethod3
[16:43:26.273] TestIntialize: TestFxIssue143.UnitTest1/TestMethod3
[16:43:26.273] TestMethod: TestFxIssue143.UnitTest1/TestMethod3
[16:43:26.273] TestCleanup: TestFxIssue143.UnitTest1/TestMethod3

I noticed the ClassCleanup is not written in the output but it did get called only once which is the expected behavior, but the ClassInitialize is called 3 times and I would have expected only 1 time since there's only 1 class.

@maboivin there are not plans to fix this at the moment, for the next version we are focusing on stabilization, performance and low-hanging fruit, which this unfortunately is not, but this issue has multiple upvotes and we go from the most upvoted / most commented when looking at issues, so hopefully soon.

@nohwnd consider #705 to fix the duplicate class init bug. @maboivin FYI.

Good news. Thanks. I will take a look when the next release is available.

I have the following in my base class:
        [ClassCleanup(InheritanceBehavior.BeforeEachDerivedClass)]
        public static void ClassCleanup()
        {
            Console.WriteLine($"[{DateTime.Now.ToString("HH:mm:ss.fff")}] ClassCleanup");
        }

And it's not being executed for the classes inherting from the base class. Shouldn't it work?

@poserdonut yes that should work. Are you using the latest version that has these changes? How did you confirm it didn't get executed? Did you try in a debugger? Note that your text in your call to WriteLine won't end up getting logged anywhere.

Latest version (not preview) and we were using debug. Had to switch to testcleanup instead.

Latest version (not preview) and we were using debug. Had to switch to testcleanup instead.

Same here :(

@poserdonut yes that should work. Are you using the latest version that has these changes? How did you confirm it didn't get executed? Did you try in a debugger? Note that your text in your call to WriteLine won't end up getting logged anywhere.

Any luck so far? This is really not working as it should

any update ?

I am confused as there seems to be two different "things" (one feature request and one bug) being discussed here.
As far as I can see, the inheritance of the class initialize is implemented and is working properly (we recently added a bunch of integration tests for this: https://github.com/microsoft/testfx/blob/2d2ab810a78fa98855a9e56cb5a18d7f963c45f2/test/IntegrationTests/MSTest.VstestConsoleWrapper.IntegrationTests/SuiteLifeCycleTests.cs).
@enisak Could you please let us know which version of MSTest you are using? Also, would you mind providing a small repro of what's not working so we can investigate (cc @engyebrahim)?

The feature request was completed. There were some bugs with it that I fixed but AFIK there aren't any other issues. The feature is working fine for my team. Maybe this should get closed out an bugs be opened if anyone has specific issues.

Agreed, let me do that now.


Question for AVR-DA

Can the programmer also used with DxCore (AVR-DA and AVR-DB) and MegaCoreX (AtMega4809...)?

Good question. I've used the Nano Every with MegaCoreX  and got to the point of everything working except the serial. I needed to do more investigation with the built-in SAMD programmer chip and UPDI line.
Should be no issues adding full HV programming support to the 4809 on its own ... I'll do this first prior to adding support for the AVR-DA/DB with DxCore as the code would be quite similar. So to answer your question ... not yet, but coming soon!

Thank's for the fast response, hope AVR-DA support will follow, I  ordered some of 28-pin DIP one direct from microchip, also 2 of your programmers from Tindie. Meanwhile I can use the code from SpenceKonde which should also work with the Nano, but with no HV.

Added HV support for ATmega4809 Family
This includes the ATmega4809, ATmega4808, ATmega3209, ATmega3208, ATmega1609, ATmega1608, ATmega809 and ATmega808 devices. Pinout diagrams and new information added to the GitHub Wiki.
Also added HV support for the AVR DA, but getting compile errors due to missing pin definitions ... left an issue at the DxCore repository.

New update with ATtiny and ATmega HV Programmer fixes, updated documentation with working 40-pin ATmega4809 on breadboard.

I'll be watching for this upstream.

Taking another look at this...
Should be able to add HV programming support for AVR-DA parts with 128K flash memory
(AVR128DA32, AVR128DA48 and AVR128DA64).

Done!
Repo updated.
For pinout descriptions, just refer to the 28/48/64 pin images for the DIY ATmega4809 HV UPDI Programmer.


Implemented list endpoints request.

This works similar to HNSListNetworkRequest, but returns a list of HNSEndpoint.

Hi @m-kostrzewa, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, MSBOT;

I think this has been implemented in other PR: https://github.com/Microsoft/hcsshim/blob/master/hnsendpoint.go#L65-L74
closing


Check for missing migrations in Travis CI

Explanation how it works: if you run makemigrations with -e flag, 1 is returned when there are no changes and 0 when there are missing migrations.
Unfortunately, I couldn't test if this PR works. This PR works. This PR have no missing migrations and passed. #884 has missing migrations and failed.

I like the change. +1.
Here are few suggestions from my end:

Bundle a model change along with the PR without the corresponding migrations. See if it fails.
How about we make the check for missing migrations as a different check. So that when check migration test fails and the tests pass, we see something like "1/2 tests passed". I wish to add another check solely concerned with running the tests within the pydata app.

@narayanaditya95

Bundle a model change along with the PR without the corresponding migrations. See if it fails.

Tested in #884.

How about we make the check for missing migrations as a different check. So that when check migration test fails and the tests pass, we see something like "1/2 tests passed". I wish to add another check solely concerned with running the tests within the pydata app.

I don't know how to configure Travis to do this, feel free to guide me or send PR.

@chrismedrela
The matrix field within the .travis.yml allows us to export env variables. Each entry within the matrix field corresponding to another check.
The script field can then use the env variable to run different test suites.
See a working example at https://github.com/divio/django-cms/blob/release/3.3.x/.travis.yml.

P.S. Although it configures a list of jobs in Travis, Travis still appears as a single check in GitHub.

So why do you want to use matrix field?

So why do you want to use matrix field?

Well, after I realized we anyway have to open the Travis UI to check for failing job, I'm -1 for the suggestion.

Gentlemen, as you can clearly see by the #885 and discussion in #883 (here), we have still plenty of room for improvement over our tests / upon-PR services.
If you have some ideas I'm open for suggestions. For example we could somehow show the coverage for AMY (the tool running tests already supports coverage package), we may add "build: passing", "coverage: XY%" icons to the readme, etc. Feel free to propose any ideas that you have.
@chrismedrela I'm going to merge in v1.7 after you swap the lines.

@pbanaszkiewicz, done.


New ooi design

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!! DO NOT MERGE !!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 MERGING AT THIS POINT WILL BREAK THINGS.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!! DO NOT MERGE !!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

LOL!

This may as well be a giant red button! lol


xSQLAOGroupEnsure: For named instances, replicas require full instance name

With the code in xSQLAOGroupEnsure's SET method, I noticed that the creation of Availability Groups (AGs) fail when dealing with named SQL Server instances.
The problem is the value supplied to the replica object's constructor. Currently, it's the cluster node's name. It should probably be the full instance name, in the format of: nodename\instancename.
In pseudo-code, the logic would look like this:
if $SQLInstanceName == to 'MSSQLSERVER'
then $replicaName = $SQLInstanceName
else
$replicaName = "$node\$SQLInstanceName"

We would then supply $replicaName to the replica's constructor. I made this patch in my setup using named instances, and the AG was then able to form afterwards.
I'm refraining from submitting a PR since I'm waiting on my company to clarify their stance on non-trivial open source contributions. But I still wanted to raise this issue in case anyone else is running into the same problem.

@johlju , please assign this to me.

@randomnote1 Can not set you as assignee unless you are the author of the issue (or a maintainer) :/ But I did set the label 'In progress' so we can see someone is working on it.

@randomnote1 So consider yourself assigned 😉


Public CI metaissue

This issue tracks various refinements we want to do to our CI infrastructure post-open source.

[x] https://github.com/dfinity/motoko/issues/2544 Pick a public CI system (Github actions + cachix for now)
[x] https://github.com/dfinity/motoko/pull/1224 Set it up
[x] https://github.com/dfinity/motoko/issues/2566 Automatically create releases and publish build artifacts there
[x] https://github.com/dfinity/motoko/issues/2567 Allow public access to drun, so that all tests can be run on CI
This blocks most of the following items:
[ ] https://github.com/dfinity/motoko/issues/2568 Publish reports (profiling, documentation preview) from GitHub Action runs
[ ] Report performance changes in comment to PR (maybe using this Github Action)
[ ] Stop using the internal CI system.

"CI: Publish reports" this is not something we do today, right?
I'm thinking what's left to do before stopping using Hydra. I think once we port posting perf and size changes to GH CI we should be able ditch it?

"CI: Publish reports" this is not something we do today, right?

Yes, we have direct links to the latest flame graph, documentation, etc. for each PR. Would be a shame to lose that, but maybe ok temporarily until we have a good idea. I should research what kind of services are there out there.
Besides that it's just the perf changes comments, which I can look into this week maybe

Yes, we have direct links to the latest flame graph, documentation, etc. for each PR.

Interesting, I didn't know that. Where can I see these reports?

You didn't know? Anyways, see https://github.com/dfinity/motoko/pull/2562 for some of the links, which we removed to keep up appearances.

Flame graphs at https://hydra.dfinity.systems/job/dfinity-ci-build/motoko/tests.profiling-graphs/latest/download/1/index.html I assume (I can't check, of course). One can construct similar urls for each PR. I hope to preserve that feature, or improve it (easier discoverability in particular of course). But needs not block turning off hydra.

Maybe we can sign up to coveralls.io (free for open repos) and upload coverage data there. Supports OCaml (https://github.com/aantron/bisect_ppx#Coveralls). We used to have coverage reports, but they have somewhat bitrotted.