Installed NuGet throws System.IO.FileNotFoundException

Creating classlibrary and trying to install Markdig.

I can use usings in code, but I'm trying to start debugging and it throws it:

link to library.
https://github.com/xoofx/markdig
Here is my .csproj
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
    <RootNamespace>Kvyk.Telegraph.Markdown</RootNamespace>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Kvyk.Telegraph" Version="1.0.2" />
    <PackageReference Include="Markdig" Version="0.25.0" />
  </ItemGroup>

</Project>

https://stackoverflow.com/questions/68070423/installed-nuget-throws-system-io-filenotfoundexception

Just tried and it is working on my machine, it's working on the CI and it's working also for many users, with 2000+ download per day, we would get a substantial number of issues like that if Markdig was not working like you describe.
So you might have something wrong on your machine. Maybe try to setup a global.json which restrict to net5.0 SDK and/or remove any superfluous dotnet SDK installed. Try to install a new version of dotnet SDK 5.0. Cleanup maybe your NuGet cache folders...etc. Have you installed a preview version of VS like VS 2022? That could break things like that... but it could be anything, even a global env variable that is messing with msbuild. You can investigate yourself such issues by checking the log of msbuild...etc.

I've tryed to create new class library and install Markdig here. It works good.
Also I've downloaded my repo in new folder, tryed to add it, and have the same error.
Do you have any ideas about problem? I'm stacked with it. Probably you can download my repo https://github.com/MarkoKvyk/Telegraph/tree/development
(development branch), create classlibrary here and add Markdig to it and watch what's wrong

I found the problem. Problem in my Test project. For some reasones it doesnt work well and dont install packages. How to fix it I have no idea. If you had issue like that, please help me. Also you can check it in my repo https://github.com/MarkoKvyk/Telegraph/tree/development
(development branch)

I found the solution. In my test project were added dublicated references. I`ve created net test project for project I need to test an it works now.


Migrate action to official repository

Description
Changes

TODO

[ ] TODO

@dirrk would you mind taking a look at this and let me know what's missing? Note that I briefly modified some of the configuration but it's still heavily WIP at this point and I wanted to have your feedback from early on.


Make VinylDNS version more easily available

Is your feature request related to a problem? Please describe.
When attempting to file a bug report, it asks for the VinylDNS version.  As a user with only the UI, I couldn't locate this information.
Describe the solution you'd like
I'd like an about/info dialog box option in the dropdown menu with my API key operations.
Describe alternatives you've considered
A simple version number in the bottom left of the screen would also work, but a separate dialog lets vinyl supply any other information that might be useful when reporting a bug.

You can find the version at the bottom right corner of the portal

Ah, you're right.  I didn't see if because I didn't notice the scroll bar.  I don't know why there's so much blank space.


Adding support for TCP connections

This implements TCP connection support. It also makes the client reconnect automatically if the connection dies. When using TCP the client will block until a message is sent successfully.

This raises a bunch of questions and I'm honestly, as I said in #54, not really excited about adding TCP support.

How does this affect thread safety? StatsClient objects have always been as safe as the socket.socket().sendto method is for UDP. Now we have a persistent connection we're potentially sharing across threads.
This changes the promise of the library, which was "make a reasonable attempt then just power through". Adding time.sleep() is, in particular, not something I want to see, as it makes any client method take a potentially huge amount of time.
The while True construct takes a lot of unpacking to understand whether or not it can turn into an infinite loop for UDP sockets. I had to get to the man page for send(2) to verify that.

Thanks for your quick reply, I'm going to try to find a way that satisfies your three valid concerns:

I'll use an object internal dict() to keep the sockets, the keys will be the thread's TIDs
I will not loop or sleep in the Statsd client. I will rather call connect() in send() instead of init() if the socket is not already connected. If an open connection has died I'll try to reconnect only once on send(). If a connect fails due to connection refused or connection timed out the exception will be raised to be handled by the user, so if the user uses TCP he should wrap the send() in a try: except:.
To improve readability I'll split _send() into _send_udp() and _send_tcp().

What do you think about these ideas?

To clarify, the reason for adding TCP support here is to support our use-case of pulling messages containing events from an AMQP queue and forward them to statsd with delivery confirmation.  While UDP makes sense for initial collection, when using statsd like this as a component within a larger metric collection system we want the ability to tell whether the metric was received by statsd so that it can be retried if statsd is not available (using AMQP as a buffer).

I'll use an object internal dict() to keep the sockets, the keys will be the thread's TIDs

Before picking a solution, I want to make sure we're very clear on what the new guarantee is. Personally, I still want StatsClient objects to be thread-safe, and assume that Pipeline objects will continue to not be. What happens when a thread creates a Pipeline from a shared StatsClient?
A lot of this complexity is exactly why I am still not yet convinced this is a good idea. Early on there were attempts to do more complex threading management and the whole library got better when they were taken out. How big a win is TCP support vs the code cost?
(I think a threading.local() instance would beat an internal dict(), if we decide to go this route.)

I will not loop or sleep in the Statsd client. I will rather call connect() in send() instead of init() if the socket is not already connected. If an open connection has died I'll try to reconnect only once on send(). If a connect() fails due to connection refused or connection timed out the exception will be raised to be handled by the user, so if the user uses TCP he should wrap the send() in a try: except:.

That dramatically changes the contract of the library from "doesn't raise" to "might raise." That's huge.
It's subtle, but this was a very opinionated decision: that it's better for the application to work than for instrumentation to be 100% reliable. An argument can be made that it's the wrong decision, or that it should be left up to the developer, but an implicit switch based on the transport isn't the way to do it. (If anything, an __init__ kwarg like fail_silently=True would be the right way.) Developer A may not know that DevOps B decided to change the transport, and that they now need to try/except every call. Conversely, DevOps B probably didn't audit the code base to catch everything when the network transport requirements changed.

To clarify, the reason for adding TCP support here is to support our use-case of pulling messages containing events from an AMQP queue and forward them to statsd with delivery confirmation.  While UDP makes sense for initial collection, when using statsd like this as a component within a larger metric collection system we want the ability to tell whether the metric was received by statsd so that it can be retried if statsd is not available (using AMQP as a buffer).

I'm confused. The AMQP queue contains the data that you're sending to statsd?
The official StatsD server supports TCP transport, and that's the only reason I'm even a little open to adding it here, but that means that adding TCP is going to need to be in the most generic way possible, not to fit into any specific use case or changing the promises of this library. The TCP transport seems to exist mostly to get reliable metrics over unreliable networks, but that's just relying on TCP, not doing it at the application layer.

Absolutely, we're not talking about changing the library to do anything except add vanilla support for TCP.  We completely understand your concerns and agree 100% that support for TCP should not in any case involve changes to the way the library is used or add significant complexity.
The point of my original post was just to explain our use-case for TCP, where the code using the library needs to be able to confirm whether the metric was received by statsd.
Some more background might make things clearer.  We have various systems that produce metrics and send them to local collectors via UDP.  Those metrics are then passed to a rabbitmq exchange, from which they are consumed by our worker process which sends them to statsd (hopefully using pystatsd) for ingestion into graphite, as well as by other consumers.  If statsd isn't available we would like to have pystatsd let us know that the transmission failed so we can NACK the message back to rabbitmq and it can be retried, something we can't do via UDP.

I need to let this ferment a little. Writing out an answer I got to a point that scared me, introducing a colossal footgun.

No worries, looking forward to hearing your feedback.  We are assuming there are other potential users of pystatsd who could find applications for a TCP transport, which is why we'd like to contribute back if we can.  Should it not be a fit we can always write a custom statsd client for our needs and maintain it in-house.  In the meantime we'll go ahead with work on a patch that addresses the points you brought up earlier and we can see where things end up.

I've updated the patch to hopefully address all your concerns above.  To keep things clean it turned into a larger patch than originally intended, but I think this way it is still relatively easy to read and it is extendable because the connection handling for each protocol is isolated from the others.

The StatsClient is still thread safe because the tcp connection socket is kept in a threading.local object.
The Pipeline should also be fine and still work the same way
By default fail_silently is True so the behavior of the old version doesn't change unless the user passes fail_silently=False.
There are no loops or waits anymore. It only tries to reconnect once if a connection has once been established, but has died in the meantime. If this reconnect fails it will swallow the error by default or raise an exception if fail_silently=False. Basically this means that whenever send() gets called on an instance that has fail_silently off, it should be wrapped in a try-except to catch socket.errors.

I have not yet updated the tests or the docs yet, but if the patch itself looks acceptable I can go ahead and do that also.  Look forward to hearing your feedback.

OK, I think I've finally got a handle on the underlying issue I have here.
The thing that was bugging me was proto='tcp', fail_silently=True. It's dangerous, or requires that fail_silently doesn't do what it says on the tin.
The root of the problem is: UDP clients are stateless(/connectionless), and TCP clients would be stateful(/connection-mode). That manifests in a couple of big ways:

Errors. UDP clients just can't raise very many. It doesn't matter what fail_silently says: you will never get a exception from the vast majority of things that can go wrong. UDP clients don't even care if the target exists, let alone if they can connect to it.
Thread safety. Since the underlying connection is stateless, UDP clients are trivially thread-safe. The only thread-unsafe part of the Pipeline is storing the unsent data, the actual sending could be safely interleaved with another thread without a problem.

I started out with the position that changing the underlying transport shouldn't change the application semantics, but what I come around to is: that's nonsense. It literally doesn't make sense. But I still think that changing just the transport shouldn't. Changing one kwarg, especially for the default clients, shouldn't require re-working how an application uses the client.
So what I'm coming around to is: it should be possible, but harder. Supporting TCP does belong in this library, but not in the same object.
What do you think about a TCPStatsClient (or a better name) class? It can probably subclass the current StatsClient class—I think there are plenty of hooks already to support Pipelines, judging from the existing code here.
 This avoids having to hide stateful connections in threadlocals. Applications can still create threadlocal clients if they need to.
StatsClient swallows the basically zero errors it can produce, but TCPStatsClient does not, and makes the application decide what to do. That way we don't have to do any hidden retries, and we respect the spirit of the "reliable transport" idea.
TCPStatsClient can expose reconnect and close methods that don't make sense for StatsClient.
TCPStatsClient can have additional constructor kwargs that don't make sense or are unnecessary for StatsClient, like timeout, and debug (I've always maintained it's unnecessary for the UDP client: since you're already changing constructor args, just point it at localhost. But for a TCP client, skipping the connection and actual sending matters). It could even drop maxudpsize and just rely on sendall for Pipelines (eventually, it would require a little refactoring).
Opting for TCP is possible but a bigger choice. It makes more sense to have different application semantics when you're creating an entirely different kind of object.

I don't really imagine having TCPStatsClient instances in the statsd.defaults modules. Those are intended for super-common cases, but anything else—including TCP—is expected to create its own client.
Sorry I've been a little slow on this one. I had to write like 4 or 5 answers before I actually figured out what I was getting at.

Ok, we think your reasoning makes sense, so we gave it another try in a new branch.
I created a new pull request from it: #59


Update aws-core, http-client-spi, ... to 2.16.33

Updates

software.amazon.awssdk:aws-core
software.amazon.awssdk:http-client-spi
software.amazon.awssdk:netty-nio-client

from 2.16.20 to 2.16.33.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "software.amazon.awssdk" } ]

labels: library-update, semver-patch

Superseded by #303.


Run screenshots for phone, tab7 and tab10 simulators

I want to create screenshots on the 3 types accepted by google play but how can I start a simulator of each and take screenshots using fastlane. It only works on devices connected or simulators running.
Any way to configure emulators, run them and take screenshots

✅ fastlane environment ✅
Stack

Key
Value

OS
10.12.6

Ruby
2.1.10

Bundler?
false

Git
git version 2.14.3 (Apple Git-98)

Installation Source
~/.rvm/rubies/ruby-2.1.10/bin/fastlane

Host
Mac OS X 10.12.6 (16G29)

Ruby Lib Dir
~/.rvm/rubies/ruby-2.1.10/lib

OpenSSL Version
OpenSSL 1.0.2n  7 Dec 2017

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
9.2

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE

fastlane files:
No Fastfile found
No Appfile found
fastlane gems

Gem
Version
Update-Status

fastlane
2.80.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems

Gem
Version

executable-hooks
1.3.2

bundler-unload
1.0.2

rubygems-bundler
1.4.4

bundler
1.16.1

slack-notifier
2.3.2

atomos
0.1.2

CFPropertyList
2.3.6

claide
1.0.2

colored2
3.1.2

nanaimo
0.2.3

xcodeproj
1.5.6

rouge
2.0.7

xcpretty
0.2.8

terminal-notifier
1.8.0

unicode-display_width
1.3.0

terminal-table
1.8.0

plist
3.4.0

public_suffix
2.0.5

addressable
2.5.2

multipart-post
2.0.0

word_wrap
1.0.0

tty-screen
0.6.4

tty-cursor
0.5.0

tty-spinner
0.8.0

babosa
1.0.2

colored
1.2

highline
1.7.10

commander-fastlane
4.4.5

excon
0.60.0

faraday
0.14.0

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20170404

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

fastimage
2.1.1

mini_magick
4.5.1

multi_json
1.13.1

multi_xml
0.6.0

rubyzip
1.2.1

security
0.1.3

xcpretty-travis-formatter
1.0.0

dotenv
2.2.1

faraday_middleware
0.12.2

uber
0.1.0

declarative
0.0.10

declarative-option
0.1.0

representable
3.0.4

retriable
3.1.1

mime-types-data
3.2016.0521

mime-types
3.1

little-plugger
1.1.4

logging
2.2.2

jwt
2.1.0

memoist
0.16.0

os
0.9.6

signet
0.8.1

googleauth
0.6.2

httpclient
2.8.3

google-api-client
0.13.6

json
2.1.0

generated on: 2018-02-13

Check out our guide: https://docs.fastlane.tools/getting-started/android/screenshots/
I don't think we support multiple devices like we do in iOS but maybe @hjanuschka has some ideas.

@taquitos we stopped using emulators, because they suck, and running multiple is just a pain in the ass.
we decided to go with real-hw all attached to CI via usb at the same time.
and then something like:
devs = adb_devices
devs.each do |device|
    # using device to the various android commands as the serial parameter
end


Add Probably Ancient Evil by Lena Raine

Song Name
Probably Ancient Evil
Artist Name
Lena Raine
Source
Youtube
Youtube Link
g-PhpHZ76QA
Direct File Link
No response
Song ID
739991
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 105724358

reject
popular songs like "Sphere" are too inconvenient to be replaced by smth unrelated and are therefore usually rejected.
Note that you can still use the song yourself, but it won't be public

based for liking lena raine tho


MSSDK-1302-dynamic-trial-label

MSSDK-1302
Dynamic trial label on the checkout page
Changes

added generateTrialBadgeDescription() function to handle days and periods variants with dynamic translation
updated translations.json file with keys and values accordingly
changed label's min- and max-width values

Snapshots

Changes

i18next interpolation syntax refactored
functions renamed for potential optimization purposes
label's width set to fixed 80px

Snapshots


Distributed training failed

Hi,
I am trying to start a POC on distributed training, but get stuck at beginning:
trainer = DistributedTrainerReplicated(os.getenv('CUDA_VISIBLE_DEVICES'), server)
launch_train_with_config(config, trainer)
resulted in
AttributeError: 'TrainConfig' object has no attribute 'session_config'
Also tried to start training without using launch_train_with_config(...), but got
AttributeError: 'DistributedTrainerReplicated' object has no attribute '_callbacks'
Please help... I am using with tensorflow 1.4.0 docker image.

The first argument (gpus) needs to be a int or a list of int. Somehow it's missing from the documentation.
Please post full error when you report bugs.

Thanks.
We switched to v1 and that works. Will test v2 trainer later on.

Closing due to lack of activity. Feel free to reopen and include details if you still encounter error.

hi,@ppwwyyxx  I have the same question,could you give me any advice?
I read the docs http://tensorpack.readthedocs.io/en/latest/modules/train.html?highlight=DistributedTrainerReplicated#tensorpack.train.DistributedTrainerReplicated
and  I modified last lines of tensorpack/examples/ResNet/cifar10-resnet.py
166    config = TrainConfig(
167         model=Model(n=NUM_UNITS),
168         dataflow=dataset_train,
169         callbacks=  [
170             ModelSaver(),
171             InferenceRunner(dataset_test,
172                             [ScalarStats('cost'), ClassificationError('wrong_vector')]),
173              ScheduledHyperParamSetter('learning_rate',
174                                       [(1, 0.1), (82, 0.01), (123, 0.001), (300, 0.0002)]),
175        ],
176         max_epoch=164,
177         session_init=SaverRestore(args.load) if args.load else None,
178
179     )
180     config.session_config=None
181     print(config.data,config.model)
182     nr_gpu = max(get_nr_gpu(), 1)
183
184     hosts = ['gpu2', 'gpu3']
185     cluster_spec = tf.train.ClusterSpec({
186             'ps': [h + ':2222' for h in hosts],
187             'worker': [h + ':2223' for h in hosts]
188          })
189
190     server = tf.train.Server(
191                 cluster_spec, job_name=args.job, task_index=args.task,
192                     config = get_default_sess_config()  )
193
194     #DistributedTrainerReplicated(config, server).train()
195
196     #launch_train_with_config(config, SyncMultiGPUTrainerParameterServer(nr_gpu))
197     #launch_train_with_config(config, SyncMultiGPUTrainer(nr_gpu))
198     launch_train_with_config(config, DistributedTrainerReplicated(nr_gpu, server))

and I launch it like this:
(tf-py27) [chongyang@gpu2 ResNet]$ python cifar10-resnet.py --job worker --task 0
and part of the error message
[1206 14:16:28 @training.py:90] Building graph for training tower 1 on device /job:worker/task:0/gpu:1...
2017-12-06 14:16:28.115375: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1120] Creating TensorFlow device (/device:GPU:0) -> (device: 0, name: Tesla P100-PCIE-16GB, pci bus id: 0000:06:00.0, compute capability: 6.0)
2017-12-06 14:16:28.115407: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1120] Creating TensorFlow device (/device:GPU:1) -> (device: 1, name: Tesla P100-PCIE-16GB, pci bus id: 0000:84:00.0, compute capability: 6.0)
[1206 14:16:47 @trainers.py:193] WRN For efficiency, local MODEL_VARIABLES are only synced to PS once every epoch. Be careful if you save the model more frequently than this.
Traceback (most recent call last):
  File "cifar10-resnet.py", line 198, in <module>
    launch_train_with_config(config, DistributedTrainerReplicated(nr_gpu, server))
  File "/home/chongyang/.local/lib/python2.7/site-packages/tensorpack/train/interface.py", line 88, in launch_train_with_config
    model._build_graph_get_cost, model.get_optimizer)
  File "/home/chongyang/.local/lib/python2.7/site-packages/tensorpack/utils/argtools.py", line 171, in wrapper
    return func(*args, **kwargs)
  File "/home/chongyang/.local/lib/python2.7/site-packages/tensorpack/train/tower.py", line 148, in setup_graph
    self.register_callback(input_callbacks + train_callbacks)
  File "/home/chongyang/.local/lib/python2.7/site-packages/tensorpack/train/base.py", line 146, in _register_callback
    self._register_callback(x)
  File "/home/chongyang/.local/lib/python2.7/site-packages/tensorpack/train/base.py", line 149, in _register_callback
    assert not isinstance(self._callbacks, Callbacks), \
AttributeError: 'DistributedTrainerReplicated' object has no attribute '_callbacks'

There are some bugs in distributed trainer. Should be fixed now.


can not preview GLB file generated by StableFast3D

Attached pls. Check for me.
By the newest version of ComfyUI v0.2.2 Release

Thanks for you care.

after update to the newest version of 3D-PACK,preview function run smoothly.
Thanks for you effort. Great Job!
This issue can be closed.


What is the best way of adding content/text to index.html?

Hi, I am starting to use your theme, it is amazing. But I have a question, how should I add text to index.html?
So far I have added a header image, but I don't know what's the recommended way to add some text. It is a personal website, so I just wanted to write a few paragraphs about me and perhaps add some images. I don't know if I should just type it after the front matter.

Depends on what layout you’re using. Most support adding body content after the front matter.
I’d suggest experimenting or looking at the example sites under /docs or /test to emulate a look you like.

Thank you for your answer. I think I am more confused now, /docs doesn't have an index.html file, and /test has one, but then the content under the front matter is plain html, not markdown.

The docs home page is under docs/pages/home.md and is using a custom permalink to set it as the index page. You don't have to do it this way.
If you go the index.html route I don't think you can add Markdown to the body since it's a HTML file... you'll need to provide HTML. This is a limitation to having a paginated home page as that's how Jekyll's plugin works.
index.html:
---
layout: home
---

Your content here to appear above recent post list

If you want something more static like what I did with the doc site then there are several layouts at your disposal... like layout: splash.
Your best bet is to look through the examples I've provided and then dig into the source files to see how they're done.

Thank you very much for your answer. I have a question related (maybe very nooby question because I am new to jekyll), would it be possible in the index.html to include a markdown file with markdown text?

If you change it to index.md, then Jekyll will process it as Markdown.
Problem with that you won't get paginated posts on the homepage because Jekyll's pagination plugin requires it to be a index.html file.
https://jekyllrb.com/docs/pagination/

Using the html, can I use liquid to include a md file? or would that failt to produce markdown too?
Sorry for all the questions. If the answer is no, I guess I will stick with HTML

Try it out and see what happens. I'm not sure.

If Liquid works and you can include a file I don't think it will process the Markdown. It will still treat it as HTML text since that's the file extension of the file with the include.

Liquid does work, but using include_relative the markdown does not work :(
I will need to use plain html
thanks for your help


update parameter type of OptionalBoolean

PR Checklist
Please check if your PR fulfills the following requirements:

[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

The parameter type of OptionalBoolean is any for now, but expect that there is no use case that object will be passed to OptionalBoolean. So I added specific union type rather than use of any.
Issue Number: N/A
What is the new behavior?
OptionalBoolean input parameter will have specific type constraint.
Does this PR introduce a breaking change?

[x] Yes
[ ] No

Other information

I think the value should be any or unknown.

I see... It is supposed to be extended version of Boolean()


[New chain]: Blast Mainnet 1.3.0

ChainId
81457
Chainlist
https://chainlist.org/chain/81457
Contract deployed

[X] I confirm that the contracts are deployed

Version of contracts deployed
v1.3.0
Relevant information
https://github.com/ethereum-lists/chains/blob/master/_data/chains/eip155-81457.json

It has been solved in #418


Updates to run Serv in CFU Playground

This PR adds basic, necessary changes to build & run the baseline Serv implementation (i.e. no MDU, no CFU) in CFU Playground. This is the first addition/use of another CPU in the Playground :)
Here is a test to give Serv a spin. Add the following to the end of the Makefile in proj/proj_template:
DEFINES += INCLUDE_EMBENCH_PRIMECOUNT
export SERV=1
DEFINES += USE_LITEX_TIMER

Then run:
make prog EXTRA_LITEX_ARGS="--cpu-type=serv --cpu-variant=standard"
make load EXTRA_LITEX_ARGS="--cpu-type=serv --cpu-variant=standard"

Try to run the primecount workload from the Embench benchmark suite and see the following output running on Arty:
CFU Playground
==============
 2: Functional CFU Tests
 3: Project menu
 4: Performance Counter Tests
 6: Benchmarks
 7: Util Tests
 8: Embench IoT
main> 8

Running Embench IoT

Embench IoT
===========
 1: primecount
 x: eXit to previous menu
benchmarks> 1

Running primecount
OK  Benchmark result verified
Spent 337298843 cycles
---

You can also run TFLM Unit/Golden tests and they should all pass. Note that because Serv does not implement mcycle the built in Litex Timer must be used by the user for profiling cycle counts. Functionality to call this timer has been added in the PR, and its use is demonstrated in the Embench workloads.
This replaces #757.

@tcal-x most of the tests were failing in #757 because of a Renode issue that was fixed with a commit. I merged that commit and the rest of main into this branch now. I think some tests are failing now because of the env issue you mentioned.

@tcal-x fixed UART_SPEED and all tests passing btw 👍


Add tab completion

It seem pretty obvious but it was not listed.
Note that unlike jlp, tab in classic notebook;

complete to longest common subsequence (not counting leading % because of magics).

Yes, I think adding the completer extension from lab should to the trick.
Should be similar to https://github.com/jtpio/jupyterlab-classic/issues/8.


Research options for Continuous Improvement

Read https://angular.io/guide/testing and decide how we will implement testing in the portfolio.

After reading, I plan to use Angular's default testing framework and also the built-in test runner karma.
I plan to use Github Actions to handle CI as well.


Getting Gates and Transistor count

I am new to Yosys and synthesis but what I want to achieve is to get the number of gates and transistors after the design unit has undergone synthesis. How do I achieve that?

A couple of steps:

Read your files into yosys, using read -sv filename.sv.  VHDL files may be read similarly when using the SymbioticEDA Suite.

Synthesize your design.  For generic architectures, such as general ASIC gate counts, synth -top topmodulename is usually sufficient.

You'll then want to map to gates, using abc -g GATES.  If you want some kind of special mapping, such as mapping to NAND and NOT gates plus FFs, then you can use abc -g CMOS2.  See the help for abc within yosys for more information.

Finally, run the stat command to get the numbers of the various items used.

That should get you a number of gates.  You'll need to do the gate to transistor mapping yourself.
Feel free to check out this article on ZipCPU.com for an example.
Dan

@ZipCPU Thanks. So Gates to transistor mapping is not supported. Any direction on how to achieve that.

Depends ... how are the gates being implemented by your foundry?  Seems like you'd kind of need to know that before you could go all the way to transistors.

@ZipCPU Okay. I will use the number of gates for now. What I want to achieve is, if I have multiple implementation of say an adder how do I select one the uses few number of gates or transistors.

Yosys maps to gates (via ABC) described in the Liberty format. The Liberty format has a attribute "area" which I think is used by ABC to make area-delay mapping decisions -- I presume this is the attribute used to capture transistor counts, so I suggest looking down that road?
You could look at the Yosys gate counts and multiply them by this area value, and/or you can get similar information from ABC, using ABC commands like print_stats...

@eddiehung Will do. Thanks

The Yosys stat command can also read a liberty file. If called with a liberty file it will output area numbers for the design.


[DO NOT MERGE] 4.0.x new

Just creating this PR to force tests to be run

Do not delete 4.0.x-new branch.


Feature: Add ability to measure the amount of time spent in a label

The label would be configurable via the .env file or the GitHub actions env.
Currently brainstorming how to figure out what to do when an issue still has that label on it. ie. '5 days and counting' or '5 days and still labelled'

For the case where the label is still active on the issue/pr/discussion, let's go with the text "X time since label has been applied"


DelegateClass not found

Hi guys,
Looks like there is a require 'delegate' missing, so that the standard library DelegateClass is not found when running a sample.
Any idea how the tests pass? anything I'm missing?
Thanks

Hey @jondot, thanks for opening this issue!
You are absolutely right, we should require "delegate" whenever DelegateClass is used. It is obviously loaded by one of gcloud's dependencies, but gcloud's usage and dependency should be explicit.
I am unable to reproduce this, however. When I run $bundle exec rake test (or $rake test within a gemset) everything passes for me. Can you post what command you are running and the output it gives?

Yep. I think the way to reproduce is to run without running bundler. So I'm guessing you're right - in this case some of gcloud-ruby's deps do that.

We will definitely fix this, but it would be helpful if you could share your output. Either way, thanks again for opening the issue!


Bump current mypy version to 0.800

Mypy prior to 0.800 didn't support Python 3.9, so I was getting test
failures locally. Bumped the version in current_mypy_version.txt to
fix that. New mypy was also unhappy about test/types being a
top-level module (since it shadows the stdlib types module); dealt
with that by adding an __init__ to test.

Ach I only just saw https://github.com/dshahbaz/bazel-mypy-integration/wiki#2-confusion-around-py_library-targets-with-imports. So I guess it's between a rock and a hard place.

Ach I only just saw ...

I hadn't seen that wiki before. Looks pretty useful.

If we were going to update the version, the README reference to a mypy version should also be updated 👍

the README reference to a mypy version should also be updated

Done in https://github.com/thundergolfer/bazel-mypy-integration/pull/37/commits/87089096631fafa46f221ed4cca90218906496f9.
Feel free to reject-I can work around the 3.9 issue.

Is the "the 3.9 issue" what's detailed in https://github.com/dshahbaz/bazel-mypy-integration/wiki#2-confusion-around-py_library-targets-with-imports ?

Is the "the 3.9 issue"

Yeah, you need 0.800 to support 3.9 (ref https://mypy-lang.blogspot.com/2021/01/mypy-0800-released.html), but then that issue kicks in.

Since #98 it's up to users to bring the version of mypy, so this is no longer a job of this ruleset.


Update vagrant environment

This is (yet) another update (I will close #29), in which the VM for developers of windows and mac is updated with several features:

add updated OS to reflect what we'll have on fraktis
add updated bootstrap method
add utility containers for orchestration and CI

README was updated accordingly

Looks really good.
What is portainer?

You can test it yourself too ;) and you can get a hang of what is portainer (I just briefly showed you at agora, it's basically an orchestrator but simpler than rancher)
git clone --recursive -b update-vagrant https://github.com/linuxbandit/oms-docker
cd oms-docker
vagrant up
note that for that you must edit your /etc/hosts because traefik serves it through "portainer.*" e.g. http://portainer.appserver/ only (I mean, also with http://portainer.localhost:8888/ but you should edit the hosts anyway so why not using appserver :p )

will merge tomorrow after andrea tries it


Columns with period in the name do not work correctly

Describe the bug
Sequelize models may have periods in the names of their columns.  These models do not work correctly in adminbro.
Installed libraries and their versions
"admin-bro": "^2.4.3",
"admin-bro-expressjs": "^2.1.0",
"admin-bro-sequelizejs": "^0.5.1",

To Reproduce
Steps to reproduce the behavior:

create a model with a column that has a period in its name
create a resource with this model
try to create or update this model in adminbro
creating fails (column is null) and updating has no effect on this columns with periods

Expected behavior
Creating and updating these columns should work
AdminBroOptions with schema
Paste your AdminBro config with database schema if it could be related to the issue
const TestModel = sequelize.define('TestModel', {
  name: {
    type: Sequelize.STRING,
    allowNull: false,
  },
  'something.with.dots': {
    type: Sequelize.STRING,
    allowNull: false,
  },
}, {});

we use dot notation to flat / unflat the objects (this package https://www.npmjs.com/package/flat is used) That is why this is not possible. Implementing this will be super problematic so I am closing this issue

I'm confused why this is closed.  Is this intended behaviour? Is there a workaround for tables with these columns?

sorry for being not clear. Closed that because I think that in current architecture it is not possible :(. But you are right - let's keep this open - maybe someone will find a solution.


Merge master to live

Merge master to live

Docs Build status updates of commit 1d71570:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Odata-docs/TOC.yml
:white_check_mark:Succeeded
View

Odata-docs/changelog/odataconnectedservice.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Space worms

About the PR

Simple new kudzu type.

Slippery
Easy to remove
Poison contact damage
Food?
can randomly spawned via event
die easily from high temperatures, but are immune to pressure and space

Why / Balance
more event variety
accidentally found a texture of these worms in the game files and thought "why not add them?"
Technical details

minor changes in Kudzu rule
Media
https://github.com/space-wizards/space-station-14/assets/96445749/4fc15b4d-de74-4a51-85de-ef65e620dd2b

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl:

add: Space worms can could infect the station

looks boring and uninteresting, I don't like it

this is just tendons that do poison instead of brute + slip you

I don't think we need another kudzu/meatzu

i dont really see a noticeable enough difference to have this event alongside kudzu and tendons. I like the sprites but it's probably better served as its own cool biohazard or antag or w/e

looks boring and uninteresting, I don't like it
Did you just downvote your own PR? Is this a social experiment?

looks boring and uninteresting, I don't like it

Did you just downvote your own PR? Is this a social experiment?

This is self cringe


Chained .with() calls that include nested relationships fail

Given the following query:
Vue.$store.getters['entities/workspaces/query']()
            .with('queries.pane.query').with('queries.pane.explore.obj').with('queries.pane.profile')
            .where('active', true)
            .limit(1).get()[0];

Only the last with() call ('queries.pane.profile') has an effect on the item returned from the store.    I've swapped around the with() invocation order and can confirm that only the last relationship is applied.

Just in time, I've wrote this #94 too but you have to nest the queries.
Vue.$store.getters['entities/workspaces/query']()
  .with('queries', (query) => {
    query.with('pane', (query) => {
      query.with('query').with('explore.obj').with('profile')
    })
  })
  .where('active', true)
  .first()

I had many people having trouble with this syntax so I'll create another issue to resolve this one too!

Yea, we crossed paths there... apologies.  Thanks for looking into the fix.  The ability to chain nested relationships would be helpful.  I'll use this method for now.   Thanks!

I see the dilemma.   Could you only resolve the "has" type (hasMany, hasOne) relationships and ignore the "belongsTo" ones?   This way, you would only be resolving the children/grandchildren/great-grandchildren/etc of the parent query.
Not sure how to make that clear in the API though.
Maybe I need to better understand how belongsTo() and with() relate.  I hadn't thought of that child-parent relationship.

I wouldn't think adding method that fetch only "has" type method. Because how about when you want to fetch non circular relation with belongsTo? For example when you have something like User hadMany Post, Post belongsTo Project. Wouldn't you want Post to retrieve Project as well?

Maybe I need to better understand how belongsTo() and with() relate. I hadn't thought of that child-parent relationship.

Well I think your data schema is quite complex. Which I'm very happy because you're using Vuex ORM in such complex project! One thing what I would do is just add helper getters that create complex query and use that when ever you need predefined query scopes.
const getters = {
  withQueryPanes ({ getters }) {
    return getters.query().with('queries', (query) => {
      query.with('pane', (query) => {
        query.withAll().with('explore.obj')
      })
    })
  }
}

// Then use it to fetch predefined with call.
store.getters['entities/workspaces/withQueryPanes']().where('active', true).first()

One thing what I would do is just add helper getters that create complex query and use that when ever you need predefined query scopes.

@kiaking Very slick.  I like it.  Thanks.

I wouldn't think adding method that fetch only "has" type method. Because how about when you want to fetch non circular relation with belongsTo?  For example when you have something like User hasMany Post, Post belongsTo Project. Wouldn't you want Post to retrieve Project as well?

Yes, I agree, you would want it to retrieve Project as well.
Hmm, well my only - likely throwaway - idea would be to then allow for resolution of all relationships up until you get to the same entity type you are querying from and stop there (including any siblings of my same type... ugh, that's where it could get really hairy).
Considering all the relationship types your library supports, that sounds quite challenging to implement.   Might not be worth it.
Thanks again for your time!

Yes, it does become quite complicated. I think we should introduce some easy way for the user to define their query scopes. Something like Laravel has.

I like the query scopes idea!
For now, I implemented a withAllRecursive method that fetches all relations to a certain depth (default 3).
See: https://github.com/vuex-orm/vuex-orm/pull/106

See my comment here for the multiple with calls: https://github.com/vuex-orm/vuex-orm/issues/104#issuecomment-369725969


FIX: fix save fiducials in mne coreg with scaled MRI (#5491)

Reference issue
Fixes #5491
What does this implement/fix?
The dialog box asking to save the fiducials file didn't open when trying to save a -trans file with a scaled MRI, which caused the saving procedure to fail. This fixes the problem.

I let @larsoner judge if it's correct or not :)

Thanks for correcting my begginer's mistakes :)
I updated the code and I see now that Travis showed an error:
"No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
(...)
The build has been terminated"
I suppose I should run the test again but as far as I've read it's only possible for users with write access. Can you do it? Or should I close the PR and open a new one?

Restarted

Thanks @ezemikulan


Live++ crash reports can fill up your storage over time

Hi,
Live++ crash dumps keep filling up our PCs. From the look of things we generate a few of them each day when using our application, and each of them can get quite large (up to a few GBs). I'm guessing this is abnormal behavior, but both our application & the Live++ Broker keeps working fine, so I'm not exactly sure what is crashing and generating the dump files.
It's probably not a bad idea to figure out what's causing these crash dumps in the first place, but considering the size of the dumps and the potential rate they are produced in, I think it'd be good for Live++ to track these and delete old ones. This would ensure Live++ does not completely full up the PC storage, like it has done in my case here (and many times before & for other's too).

We're on a somewhat old version (2.4.1) but we can't find anything relevant in the change logs. Let us know if you think upgrading would resolve this.
Thanks!
Kind regards,
Simon Moos

Thank you very much for reporting this Simon.
This is definitely very abnormal behaviour, and it seems like the Live++ Broker produces crash dumps at a rate of one every minute (!), yet keeps on running as you mentioned.
I'd suggest upgrading to the latest 2.7.2 and see if this goes away.
But in any case, can you make one of these crash dumps available to us? It's very, very odd that the Broker would produce a crash dump but keep on running as if nothing happened and I'd absolutely like to investigate this.

Hi! I'm happy to send a crash dump to you, but would rather do it in a confidential way (just in case there's any info about our exe/symbols inside). Please just let me know where to send.
Will also update to the latest now.
Thanks!

This was caused by portable USB drives spontaneously disconnecting every now and then, causing an EXCEPTION_IN_PAGE_ERROR error that was caught by the exception handler in the Broker.
In the next update, these exceptions will no longer cause a dump to be written, but will output a warning to the user instead.


Add support for tag entries

In AL1, tags can have their own entries with descriptions. It would be useful to add this feature to Frisktol, especially with the references feature allowing an #affix tag to reference the entries for all the specific types of affixes.

Implemented.


feat: add platformatic deploy command [Don't merge]

[ ] add documentation
[ ] release a minor or major version of deploy-client
[ ] update dashboard UI

Good work!


Insteon Micro Open/Close Device Not Added / Scenes won't trigger without Buttons

So far all the devices I have added to my ISY994i automatically show up in my Homebridge. However, I just added 4 "Insteon Micro Open/Close Modules" to my ISY994i and they will not show up in Homebridge.
The only way to get them into Homebridge, currently, is to add a scene, add the device to the scene, and then add that scene in the config.json.
I wouldn't even mind this workaround but there seems to be a further complication with this: if I do not also add a "Keypad" button to the scene the device status will be updated in HomeKit when triggered on the ISY but the commands triggered in HomeKit will not be sent back to the ISY.
If I add a physical Keypad button to the scene the communication works both ways.
Here is my example set up:
Three of my shutters are in the master bedroom. I have one scene that will close/open all three. That scene also has a button assigned so that I can open/close them from my Insteon Keypad. This scene works great. Then I have a scene for just the two window shutters and one more scene for just the door shutter. Neither of those two scenes have a button assigned since I only want to control them with HomeKit. However, these do not execute.
So I am finding two bugs at the moment:

Open/Close Module Devices do not get added into Homebridge
Scenes without a button can't be executed from HomeKit

Would love to get those issues resolved if possible. Let me know if I can do anything to help!
Thanks,
Philipp

This is just a device type that isn't yet mapped in the base ISY library. See here
You can modify that file and add it to your own installation. You can also open an issue over at the ISY page to have that device type permanently added.

Ah I see. Now when you say "ISY library" do you mean the ISY Homebridge plugin one or are you actually talking about the Universal Devices ISY library? Because the ISY994 actually recognizes the device. I can control it from my ISY. It just doesn't show up in Homebridge.
And when you say "open an issue" over at the ISY page, didn't I already do that here? Or are you talking about the Universal Devices website?
Thanks!

You have to add your devices to the JSON file.  The max limit is 100.
Jeff
Sent from my iPhone

On Feb 3, 2017, at 8:04 PM, VeniceNerd<EMAIL_ADDRESS>wrote:
Ah I see. Now when you say "ISY library" do you mean the ISY Homebridge plugin one or are you actually talking about the Universal Devices ISY library? Because the ISY994 actually recognizes the device. I can control it from my ISY. It just doesn't show up in Homebridge.
And when you say "open an issue" over at the ISY page, didn't I already do that here? Or are you talking about the Universal Devices website?
Thanks!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@fahrvergnuugen looked into this a bit more. Couple of questions:

where on my mac will I find that isydevicetypes.json? Tried a spotlight search but couldn't find it.

where do I find this string "type": "<IP_ADDRESS>" for the device I want to add? I know where to get the name and other parameters but not sure what that number stands for or where I'd get it.

what HomeKit "deviceType" s does the ISY-JS support? I'd love to add the open/close module as some sort of "blinds" device but not sure if the ISY-JS supports those. Otherwise I'd probably add it as an "outlet".

@VeniceNerd

Spotlight wont search everywhere on your mac, it ignores stuff outside of "user space". NPM installs packages in /usr/local/lib/node_modules on my machine, so have a look there. You should find homebridge-isy-js there, and inside that folder you will find node_modules/isy-js/. So on my machine, the isydevicetypes.json file's full path is: /usr/local/lib/node_modules/homebridge-isy-js/node_modules/isy-js/isydevicetypes.json
The type comes from the physical insteon device. You can get these types from the ISY directly. The easiest way is to open http://YOURISY'sIP/rest/nodes. This will spit out an XML file with every device thats linked to the ISY, it's device type, address, etc.
This last one is a little more difficult to explain. The ISY doesn't support homekit at all - that's what homebridge-isy-js is for. This file is a mapping between ISY insteon types and homekit devicetypes. Homekit has a fixed set of devices in it's API and rodtoll has written the code to wire them together. So I suppose the real question is - what kinds of device types does homebridge-isy-js support? I think the answer is:

Fans
Outlets
Locks
Lights (both dimmable and not)
Contact Sensors
Motion Sensors
Garage Doors
Elk Alarm Panel

@fahrvergnuugen
Oh that's very helpful! Found the json and was also able to spit out the XML file. Here is the readout for one of the devices:
<node flag="128">
<address>3B 48 B3 1</address>
<name>Window Shutter Right</name>
<parent type="3">27213</parent>
<type><IP_ADDRESS></type>
<enabled>true</enabled>
<deviceClass>0</deviceClass>
<wattage>0</wattage>
<dcPeriod>0</dcPeriod>
<startDelay>0</startDelay>
<endDelay>0</endDelay>
<pnode>3B 48 B3 1</pnode>
<ELK_ID>K07</ELK_ID>
<property id="ST" value="255" formatted="On" uom="on/off"/>
</node>

And here is how it shows up on my ISY:

From those I'd guess I'd need to make the following entry to the isydevicetypes.json:
{ "type": "<IP_ADDRESS>", "address": "", "name": "(2444-22) Micro Module Open/Close v.48", "deviceType": "Outlet", "connectionType": "Insteon Wired", "batteryOperated": false }
Is that correct? Not sure if I'd need to add anything in the "address" part, though? I see some entries have a "1" there?

Some insteon devices have more than one circuit in them (like the i/o link and fan controllers) and therefore it publishes more than one device address. The Address field in isydevicetypes.json file is there to filter them and set those up as separate homekit device types if necessary.
In your case you should just leave it blank.
The "Name" should be the type of insteon device it is, e.g. (2444-222) Insteon Micro Open/Close Module, not the user defined name you gave it in your ISY.

It worked! I'll also report the correct string over at the other forum for inclusion. :)


Python 2 print statement in test_primes.py

When installing smop, I am getting the following error (presumably simply an old py2 print statement):
byte-compiling build\bdist.win-amd64\egg\smop\test_primes.py to test_primes.cpython-38.pyc
  File "build\bdist.win-amd64\egg\smop\test_primes.py", line 2
    print liboctave.primes(10000)
          ^
SyntaxError: invalid syntax

byte-compiling build\bdist.win-amd64\egg\smop\test_solver.py to test_solver.cpython-38.pyc

@victorlei I believe vast majority of people already moved to Python3. I suggest to fix this, others similar change Makefile accordingly.


HystrixRequestContext in case of async requests

Hi,
In case when HystrixObservableCommand is used to wrap a non-blocking observable, and the non-blocking request is done on ExecutorService, (the subscription is also done on the executor service)  will the HystrixRequestContext have to be explicitly copied to the newly created threads for the HystrixObservableCollapser to work ??
The HystrixObservableCollapser is used in Rx composition (flatMap).

Hi Amit,
I have a similar question and found your post.
From what I understand, the request context is not automatically copied or inherited by child threads. If you're scheduling with RxJava (e.g. hystrixObservableCommand.toObservable().subscribeOn(Schedulers.computation()).subscribe()) then you can do the following:

Implement a  RxJavaSchedulersHook
Overwrite onSchedule() and wrap the action with your own action
In our action, make use of HystrixRequestContext.setContextOnCurrentThread before delegating to the original action

Now, the problem that I've encountered is that this does not copy anything, it simply references the parent request context. And now comes my question:
We initialize the hystrix request context with a servlet filter as mentioned in the wiki. Using the above method works fine, if all child threads complete before the we call HystrixRequestContext.shutdown(). However, if we just asynchronously subscribe to an observable and walkaway, then the filter will shutdown the context and the aynchronous action will fail because the context no longer exist.
Anyone from the Netflix team can advise on how to use the context with asynchronous actions? Is there a way to copy the context? Or is there a way to "remember" that there are still actions using the context and only close it when all actions completed?

Hi ruhkopf,
I believe I am also facing similar issue, not sure though. You can the details of the issue I am facing here. https://groups.google.com/d/msg/hystrixoss/-bJmnhgmJwU/ZX2-8EPrBQAJ
Just to understand your case, how are you making sure that the servlet filter calls shutdown after all the async threads are done with processing ? In my case, I am blocking the server request thread by calling observable.toBlocking()

how are you making sure that the servlet filter calls shutdown after all the async threads are done with processing
That is the question I was hoping to get an answer for. :-) I'm currently playing around with a map that remembers every async thread per request context and only really shuts down the context if there are no more threads running. It looks like it might work, but it adds overhead.

In my case, I am blocking the server request thread by calling observable.toBlocking()
Yes, blocking at the end of the request works. However, what if we don't want to do this? In my case I have a task that takes some time. I don't want to block the request until it's finished...

@amitcse / @ruhkopf Sorry for the delay in answering.  I still need to work up an example for HystrixObservableCollapser, but here's what happens for HystrixCollapser.  Note that you must not be using a globally-scoped collapser if you want a HystrixRequestContext.
Each invocation of a HystrixCollapser puts the arg in a batch (com.netflix.hystrix.RequestCollapser.CollapsedTask).  The first item in a batch copies the HystrixRequestContext onto the contained Callable.
Once the timer ticks, it executes this task, which then has the proper HystrixRequestContext.
This should work in the same way for HystrixObservableCollapser - I will write a unit test to confirm (or find a bug).

Also, for the question of how to fit the async model into a blocking model (like Servlets), the general solution is to represent the entire "work" of the request as an Observable<Response> by using RxJava to compose all of the individual work you need to complete.
Then, as you put that work on non-Tomcat threadpools, you can block the Tomcat thread via responseObservable.toBlocking().single(), or something equivalent.
Here's one of @benjchristensen's presentations that goes into more detail on this topic:
https://speakerdeck.com/benjchristensen/applying-reactive-programming-with-rxjava-at-goto-chicago-2015

@amitcse I've created a simple unit test that demonstrates the ObservableCollapser. It also shows that a RxJavaPlugin is necessary when scheduling asynchronously. I hope it's useful. Everything seems to work well: https://github.com/ruhkopf/ExampleAsyncHystrixObservableCollapserExample
@mattrjacobs Thanks for providing some details around the request collapser and the link to Ben's presentation. It's a great intro!
About blocking: That's what we're pretty much doing right now. Our service layer is based on Observables and then we block in our REST layer. This works fine.
However, I now have the use case were a (synchronous) web service call should subscribe to an Observable asynchronously and then walk away (i.e. not block and wait for the result). I'm not sure how/if I could still leverage the benefits of the request context (e.g. request collapsing). I'm going to add another unit test soon, that demonstrates this.

@ruhkopf Thanks for the test. I also did something similar, wherein copy the HystrixRequestContext to the new thread from my executor service, on which the async request happens. I am not seeing any arbitrary exceptions about RequestContext right now.
@mattrjacobs This HystrixRequestContext for async requests seems to be solved by copying the HystrixRequestContext on the new thread/scheduler, but I am facing an issue with the semaphores wherein semaphores are not being released in case of exceptions properly. I will create a new thread for that. Need your help there.

I was able to recreate the situation you described by adding logging to an existing unit test: https://github.com/mattrjacobs/Hystrix/commit/c6ffedbf12d4f8903605af6f82f0181d28fb195a
The output of HystrixObservableCollapserTest.testTwoRequestsWhichShouldEachEmitTwice is:
Thread which calls observe() on collapser instances is [main] and has ReqCtx : com.netflix.hystrix.strategy.concurrency.HystrixRequestContext@5f70bea5
add listener: com.netflix.hystrix.collapser.RequestCollapser$CollapsedTask@44d3db51
ExecutionCount 0 => Time: 10 Delay: 10
Executing task ...
Thread creating batch command is [main] and has ReqCtx : com.netflix.hystrix.strategy.concurrency.HystrixRequestContext@5f70bea5
executionCount: 1
Thread constructing batch HystrixObservableCommand is [hystrix-OWNER_ONE-1] and has ReqCtx : com.netflix.hystrix.strategy.concurrency.HystrixRequestContext@5f70bea5
Thread executing batch HystrixObservableCommand is [RxComputationThreadPool-1] and has ReqCtx : null
tasks: [com.netflix.hystrix.HystrixCollapserTest$TestCollapserTimer$ATask@13b06041]
**** clear TimerListener: tasks.size => 1
Which matches your description exactly.  I need to think about how best to handle this.  The workaround described by @ruhkopf absolutely works, but I'd like to see if Hystrix can handle this case better.  Will update this thread as I make progress on that.

Thanks for looking into this @mattrjacobs. It would be great to find a better way to handle this, because unfortunately the workaround does not work for all scenarios: Since I pass the request context from the calling thread to the scheduled thread, it breaks if the scheduled action runs after the caller has already completed.  (In my specified case the caller is a http servelet request and the Hystrix servlet filter then closes the Hystrix Context at the end).
I've added another test that demonstrates this. Please see the test demonstrateSyncRequestThatSchedulesAnAsyncTask in IssueWithBackgroundTasks.
The observable that runs in the background fails with:
java.lang.IllegalStateException: HystrixRequestContext.initializeContext() must be called at the beginning of each request before RequestVariable functionality can be used.
	at com.netflix.hystrix.strategy.concurrency.HystrixRequestVariableDefault.get(HystrixRequestVariableDefault.java:76)
	at com.netflix.hystrix.strategy.concurrency.HystrixRequestVariableHolder.get(HystrixRequestVariableHolder.java:68)
	at com.netflix.hystrix.collapser.RequestCollapserFactory.getCollapserForUserRequest(RequestCollapserFactory.java:133)
	at com.netflix.hystrix.collapser.RequestCollapserFactory.getRequestCollapser(RequestCollapserFactory.java:88)
	at com.netflix.hystrix.HystrixObservableCollapser.toObservable(HystrixObservableCollapser.java:422)
	at com.netflix.hystrix.HystrixObservableCollapser.toObservable(HystrixObservableCollapser.java:398)
	at name.ruhkopf.rx.hystrix.example.IssueWithBackgroundTasks.lambda$1(IssueWithBackgroundTasks.java:56)
	at name.ruhkopf.rx.hystrix.example.IssueWithBackgroundTasks$$Lambda$1/1844169442.call(Unknown Source)

I understand why it happens. Because we don't block and wait for the background task to finish, the parent completes first and removes the context. Then the background task runs and can't find the context (it was already removed). It all makes sense, but I don't know how to solve it. If only there was a way to identify actions that should run in the background vs. actions that must complete in one request. Then it would be easy to just create a new request context for the background actions and inherit the current one for foreground actions. Do you know what I mean?

A quick note (don't have a full solution yet):  A class already exists (com.netflix.hystrix.strategy.concurrency.HystrixContextScheduler), which allows you to pass a HystrixRequestContext through a scheduling event.  This is how Hystrix manages executing work in Hystrix thread pools with the appropriate context.  This is likely a good alternative to affecting all Rx scheduling in your application.

My comment above (https://github.com/Netflix/Hystrix/issues/895#issuecomment-141447734) was based on a unrealistic unit test.
I changed the unit test in #902 in the following ways:

Run it on a real HystrixTimer (Which uses a HystrixTimer thread for command execution)
Configure the batch command to be Semaphore-isolated
Don't use subscribeOn(Schedulers.computation()) at the end of the construct() method.

When those are put together, the execution of the batch command is semaphore-isolated, and so runs on the calling thread.  The HystrixTimer thread executes the command, so the batch command runs there.  No thread-hopping is needed in user-specified code, and Hystrix manages all of the passing around of HystrixRequestContext, such that it exists everywhere.
I'll now play around with the tests provided by @ruhkopf to understand those

@ruhkopf Take a look at https://github.com/mattrjacobs/ExampleAsyncHystrixObservableCollapserExample/commit/3032249a88580304ef7bf2377fcf043e1ee2baaa.
Here, the unit test is passing without the use of RxJavaPlugins.
If you use that code as-is, then the HystrixObservableCommand is executed on the HystrixTimer thread.  Without thread-hopping, the subscribe  in collapser.observe().subscribe() executes in the main thread.  This is generally fine, as the OnSubscribe here is just putting arguments into a batch.
Please let me know if this helps, or if there are any other cases I haven't considered.  Having your repo to code against is very helpful, so feel free to illustrate with examples.  Also, once you're satisfied with how things look, would you consider submitting some of those examples to hystrix-examples?  It's been on my TODO list for awhile to get HystrixObservableCollapser examples there.

@ruhkopf Here's a different solution to the lack of context.
https://github.com/mattrjacobs/ExampleAsyncHystrixObservableCollapserExample/commit/e1fad9dd49fc3c3ff6e71812b947802717c85816
In this case, it uses a HystrixContextScheduler, and applies it via `collapser.observe().subscribeOn(HystrixContextScheduler).subscribe().

@mattrjacobs I like the idea of executing the HystrixObservableCommand on the HystrixTimer thread. It gets me into thinking that maybe I don't need to call Jersey Reactive Client with a custom ExecutorService, and maybe simple Jersey client will be enough. I will look into it.
One question: Is the default isolation strategy for `HystrixObservableCommand' SEMAPHORE ? According to [Ben's comment] (https://github.com/Netflix/Hystrix/issues/805#issuecomment-109371037), thread isolation is not even necessary here, so is semaphore isolation the default strategy ?

@amitcse Yes, the defaults are for batch commands (either HystrixCommand or HystrixObservableCommand) to be executed from the HystrixTimer thread.
HystrixObservableCommand does default to SEMAPHORE-isolation.  See https://github.com/Netflix/Hystrix/blob/master/hystrix-core/src/main/java/com/netflix/hystrix/HystrixObservableCommand.java#L194.
Part of my confusion was that both of these were being overridden in the unit test I added logging to.

Thanks for your help @mattrjacobs The example that shows how to use the HystrixContextScheduler is very useful. With this, the RX plugin is no longer necessary.
I still have an issue when scheduling a background task. It's more like an architecture issue/question. Could you please have a look at the other test class (IssueWithBackgoundTasks)? I'm interested to hear your thoughts. I guess the background task should rather use the global context instead of a request context...
I'd be happy to add the examples. Just let me know how (fork and pull request?)

@ruhkopf Will look at that example on Monday and give you feedback.
For contributing, fork and pull request is exactly right

Thanks, what branch should I base my changes on?

1.4.x.  I'll forward-port to master
On Mon, Sep 21, 2015 at 3:29 PM, Patrick Ruhkopf<EMAIL_ADDRESS>wrote:

Thanks, what branch should I base my changes on?
—
Reply to this email directly or view it on GitHub
https://github.com/Netflix/Hystrix/issues/895#issuecomment-142127484.

Done: https://github.com/Netflix/Hystrix/pull/905
Any thoughts yet on my other question? Let me add some more background information. Here's what I currently have:

an API (let's say a product service) that exposes Observables
an implementation of the API based on HystrixObservableCollapser / HystrixObservableCommand

these commands by default operate on the request context (for collapsing and the request log)

the Hystrix servlet filter that initializes and shuts down the context

All is fine when the work is completed inside one request (i.e. block at the end). However, now let's say we add auditing, for example, when someone accesses a product, we also want to store this request in the database. This should happen in the background, i.e. we don't want to wait until this action completes. Instead we return the product immediately and asynchronously subscribe to the auditing service. Without modifying any code, we then run into an issue, because the Hystrix servlet shuts down the context and then the asynchronous command to the auditing service fails (Hystrix context not initialized). This can be seen in IssueWithBackgroundTasks.demonstrateSyncRequestThatSchedulesAnAsyncTask.
One solution would be to change the collapser mode to global instead of request (and disable request log) for this command instance. However, from a design perspective this is not great, because it's invasive. My service layer at the moment does not expose any commands, only observables. That makes it impossible to change any settings of one command instance, without modifying the signature of the API. I am wondering if there is a way to a) make Hystrix request log/collapser smarter to detect this (I'm not sure how) or use a specific scheduler that would provide the request context for this case...

My first thought is that converting the background task from collapser -> command should work.  Collapsing requires a HystrixRequestContext, but a HystrixCommand/HystrixObservableCommand does not.  Since you're explicitly trying to do work outside of a request scope, semantically having no request scope makes sense.
Let me see if I can get a working code example that follows this approach.

Here's a working example where I replaced the background task with a HystrixObservableCommand instead of a HystrixObservableCollapser.  https://github.com/mattrjacobs/ExampleAsyncHystrixObservableCollapserExample/commit/76040a71e4a64c12fedbfb06646909caf27d9d69.  This works because the HystrixObservableCommand does not require a HystrixRequestContext.
A different approach would be to continue to use the HystrixObservableCollapser, but make it GLOBAL-scoped (as you mentioned above).
Putting it differently, you can't use a REQUEST-scoped HystrixObservableCollapser outside of a request scope, so you have to change that code somehow.

Ok, thanks for getting back. I was afraid this would be the answer. ;-)
Unfortunately this means I will have to change my API. Currently, I only expose Observable. In fact, the caller is not even aware that Hystrix is used in the implementation. But in order to change the command settings (GLOBAL) or to use an entire differently command (HystrixObservableCommand instead of HystrixObservableCollapser), I need to either expose those, or perhaps add a flag boolean useRequestScope or similar to the method signature. (To be clear: I don't want to change the command default settings; 99% of the cases we don't use it in the background.)
I noticed another thing, too: I was surprised to see my real world code fail, even when not using the collapser. I compared it with your example (thanks, btw, for providing it) and could not find a difference. Then I started debugging and saw the following code in AbstractCommand:
if (concurrencyStrategy instanceof HystrixConcurrencyStrategyDefault) {
 // if we're using the default we support only optionally using a request context
 if (HystrixRequestContext.isCurrentThreadInitialized()) {
   currentRequestLog = HystrixRequestLog.getCurrentRequest(concurrencyStrategy);
 } else {
   currentRequestLog = null;
 }
} else {
 // if it's a custom strategy it must ensure the context is initialized
 if (HystrixRequestLog.getCurrentRequest(concurrencyStrategy) != null) {
   currentRequestLog = HystrixRequestLog.getCurrentRequest(concurrencyStrategy);
 } else {
   currentRequestLog = null;
 }
}

I am using a custom HystrixConcurrencyStrategy. (My project has it's own version of a context, that we need to propagate). So the command fails, because it always tries to use the request log. In the source code it says:

// if it's a custom strategy it must ensure the context is initialized

I'm confused by this comment. Why must it be ensured? Why not optionally? Unforuntately this breaks my code. Do you think this is something that could be changed?

Or maybe at least allow to extend from HystrixConcurrencyStrategyDefault?

I'm confused by this comment. Why must it be ensured? Why not optionally? Unforuntately this breaks my code. Do you think this is something that could be changed?

@ruhkopf Refer to this [comment] (https://github.com/Netflix/Hystrix/issues/92#issuecomment-122329695) from Ben. Also, you can modify your custom strategy as suggested by pbetkier on the same thread.

Thanks @amitcse, that works.

Thanks @amitcse for that pointer.  That's exactly right.
@ruhkopf -  I will add this to the plugin docs, so that others don't get bitten by this.
Regarding IssueWithBackgroundTasks, since HystrixObservableCommand<T> and HystrixObservableCollapser<T> are both capable of returning Observable<T>, is there any way to create an interface with just Observables in the signatures, and then have concrete implementations use commands/collapsers underneath.  Just a thought - I'm sure your real usecase is much more complex than the IssueWithBackgroundTasks example.

FYI, I actually needed to implement initialValue and `shutdown', too. Here's the snippet:
@Override
	public <T> HystrixRequestVariable<T> getRequestVariable(final HystrixRequestVariableLifecycle<T> rv)
	{
		return new HystrixRequestVariableDefault<T>()
		{
			@Override
			public T initialValue()
			{
				return rv.initialValue();
			}

			@Override
			public void shutdown(final T value)
			{
				rv.shutdown(value);
			}

			@Override
			public T get()
			{
				if (!HystrixRequestContext.isCurrentThreadInitialized())
				{
					return null;
				}
				return super.get();
			}
		};
	}

Re use case: My API has a function like Observable<Response> deleteItem(String id). We are able to batch multiple delete requests. Most consumers of the API call and block, so we can make use of the request context. Other consumers might not want to block. At the moment the API implementation does not know how it's used. It therefore can't make the decision of whether to use the Collapser or not. I could change this to Observable<Response> deleteItem(String id, boolean enableRequestCtx) to make it explicit, but was hoping to be able to avoid this.

Given the work done in #951, I think this is better-handled now.  OK to close this, @ruhkopf ?

Yep, I would say so. Thanks again for your help.

Great, thanks for following up.  Closing


Panics when searching for multi-byte characters

When searching for strings containing double width characters, the program panics at this call to String::drain, since the endpoint is not on a char boundary. I haven't figured out how to fix it.
Steps to reproduce
Search 甲州 in the pager with the following code.
Dummy text in Japanese: text.txt
main.rs
use std::fmt::Write;

const STR: &str = include_str!("./text.txt");

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let mut pager = minus::Pager::new();
    write!(pager.lines, "{}", STR)?;
    minus::page_all(pager)?;
    Ok(())
}

Cargo.toml
# ...
minus = { version = "3.3", features = ["search", "static_output"] }

Panic backtrace
thread 'main' panicked at 'assertion failed: self.is_char_boundary(end)', /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/string.rs:1572:9
stack backtrace:
0: rust_begin_unwind
    at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
    at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:92:14
2: core::panicking::panic
    at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:50:5
3: alloc::string::String::drain
    at /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/string.rs:1572:9
4: minus::search::find
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/minus-3.3.3/src/search.rs:194:9
5: minus::search::highlight_search
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/minus-3.3.3/src/search.rs:166:13
6: minus::init::static_paging
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/minus-3.3.3/src/init.rs:78:32
7: minus::static_pager::page_all
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/minus-3.3.3/src/static_pager.rs:86:13
8: indicatif_test::main::{{closure}}
    at ./src/main.rs:10:5
9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
    at /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/mod.rs:80:19
10: tokio::park::thread::CachedParkThread::block_on::{{closure}}
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/park/thread.rs:263:54
11: tokio::coop::with_budget::{{closure}}
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/coop.rs:106:9
12: std::thread::local::LocalKey<T>::try_with
    at /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:272:16
13: std::thread::local::LocalKey<T>::with
    at /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:248:9
14: tokio::coop::with_budget
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/coop.rs:99:5
15: tokio::coop::budget
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/coop.rs:76:5
16: tokio::park::thread::CachedParkThread::block_on
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/park/thread.rs:263:31
17: tokio::runtime::enter::Enter::block_on
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/runtime/enter.rs:151:13
18: tokio::runtime::thread_pool::ThreadPool::block_on
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/runtime/thread_pool/mod.rs:71:9
19: tokio::runtime::Runtime::block_on
    at /home/akitaki/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.6.0/src/runtime/mod.rs:452:43
20: indicatif_test::main
    at ./src/main.rs:11:5
21: core::ops::function::FnOnce::call_once
    at /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Thanks for putting up the issue. A new version of minus is in the works, if you want to fix it, you should probably do it in the 4.0 branch, which will be the next major release of minus

After some investigation,

It seems like the panic is caused by the mixed usage of byte indices and unicode character indices, which are not always the same.  Any multibyte character (for example à) can trigger the bug, so it also happens on languages with accented letters like Spanish.
On the master branch,

The panic can be solved by replacing let truncate = x + query.char_indices().count(); with let truncate = x + query.len();, because String::drain requires a byte range, not a character index range.
After fixing the panic, the cursor positioning is wrong.  I'm not familiar enough (yet) with the codebase enough to fix this.

On the 4.0 branch, it's further complicated.  The panic occurs before the pager is shown, due to a call to split_at() with confused index.  This is trickier to solve than the master branch.

Panic backtrace on branch 4.0
thread 'main' panicked at 'byte index 86 is not a char boundary; it is inside '張' (bytes 84..87) of `織田信長は、織田弾正忠家の当主・織田信秀の子に生まれ、尾張（愛`', /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/str/mod.rs:565:13
stack backtrace:
0: rust_begin_unwind
    at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
1: core::panicking::panic_fmt
    at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:92:14
2: core::str::slice_error_fail
3: core::str::<impl str>::split_at
    at /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/str/mod.rs:565:13
4: minus::line::Line::break_line
    at /home/akitaki/code/minus/src/line.rs:129:36
5: minus::line::Line::new
    at /home/akitaki/code/minus/src/line.rs:112:26
6: minus::line::Line::from_str
    at /home/akitaki/code/minus/src/line.rs:148:24
7: minus::Pager::prepare
    at /home/akitaki/code/minus/src/lib.rs:322:45
8: minus::static_pager::page_all
    at /home/akitaki/code/minus/src/static_pager.rs:62:5
9: indicatif_test::main
    at ./src/main.rs:6:5
10: core::ops::function::FnOnce::call_once
    at /home/akitaki/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I have fixed this in 4.0 branch. Closing this issue.


Update documentation and demos for file system format option

Documentation and demos need updating post https://github.com/vmware/docker-volume-vsphere/pull/597 merge

@kerneltime
There is more documents needing an update other than the README.md?

Yup. https://vmware.github.io/docker-volume-vsphere/ content needs updating which gets generated from https://github.com/vmware/docker-volume-vsphere/tree/master/docs. We will be cutting a release on the 28th, if it is not done by then I will do it as part of the release.

I will look into it.
Should #35 also be closed after #597 merge? Found it in the README.md and remember @msterin commenting something about a similar issue.

@brunotm - unfortunately  #35 is still valid. #597 makes it low(er) priority - before your fix create of a large volume blocked ALL plugins on the given ESX host for the time it took to format the volume. Now, it only blocks an individual Docker engine plugin, but other Docker VMs are fine.
Still, everything is serialized per Docker engine, and other ops are serialized globally.

Fixed in #605


minishift: 1.34.2 -> 1.34.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/minishift/minishift/releases.
meta.description for minishift is: "Run OpenShift locally"
meta.homepage for minishift is: "https://github.com/minishift/minishift"
meta.changelog for minishift is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.34.3 with grep in /nix/store/bn3c889dyfg3fvqjq4gk74qh1ipvadnl-minishift-1.34.3

directory tree listing: https://gist.github.com/81fffb10a7e0b4aef6fe266dfe9e54ce

du listing: https://gist.github.com/4b11ec2b7e9e0bebd797570f8b7523ed

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

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
minishift

Instructions to test this update (click to expand)

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

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

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

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.


Optimize rich-list endpoint list by storing only the most recent version (Nova) [none]

Description

Priority: none

The rich-list stores everything but we only just use the most recent version. We could optimize and improve chronicle by just keeping the most recent version
Motivation
Cleanup
Requirements

Open questions (optional)

Are you planning to do it yourself in a pull request?
No.

Implemented!


Add classes from apache-log4j-extras especially rolling.RollingFileAppender

org.apache.log4j.rolling.RollingFileAppender is well known as a better alternative to org.apache.log4j.RollingFileAppender
yet the only way to obtain it is via log4j:apache-log4j-extras:1.2.17 - which also includes all of log4j:1.2.17
could reload4j include classes from extras jar as well?
P.S. Ceki, massive thanks for your all your work over the years

Also from same package if you could add org.apache.log4j.rolling.TimeBasedRollingPolicy?


NASA NeoWs (Independent Publisher)

When submitting a connector, please make sure that you follow the requirements below, otherwise your PR might be rejected. We want to make you have a well-built connector, a smooth certification experience, and your users are happy :)
If this is your first time submitting to GitHub and you need some help, please sign up for this session.

[x] I attest that the connector doesn't exist on the Power Platform today. I've verified by checking the pull requests in GitHub and by searching for the connector on the platform or in the documentation.
[x] I attest that the connector works and I verified by deploying and testing all the operations.
[x] I attest that I have added detailed descriptions for all operations and parameters in the swagger file.
[x] I attest that I have added response schemas to my actions, unless the response schema is dynamic.
[x] I validated the swagger file, apiDefinition.swagger.json, by running paconn validate command.
[ ] If this is a certified connector, I confirm that apiProperties.json has a valid brand color and doesn't use an invalid brand color, #007ee5 or #ffffff. If this is an independent publisher connector, I confirm that I am not submitting a connector icon.

If you are an Independent Publisher, you must also attest to the following to ensure a smooth publishing process:

[x] I have named this PR after the pattern of "Connector Name (Independent Publisher)" ex: HubSpot Marketing (Independent Publisher)
[x] Within this PR markdown file, I have pasted screenshots that show: 3 unique operations (actions/triggers) working within a Flow. This can be in one flow or part of multiple flows. For each one of those flows, I have pasted in screenshots of the Flow succeeding.
[x] Within this PR markdown file, I have pasted in a screenshot from the Test operations section within the Custom Connector UI.
[ ] If the connector uses OAuth, I have provided detailed steps on how to create an app in the readme.md.

Hi @fordosa90, I think I've already submitted this service as a connector:
https://learn.microsoft.com/en-us/connectors/nearearthobjectwebip/

@troystaylor  You are quick, I guess you have some alert set up for all of your connectors versus pull requests?
Indeed, it looks like the same service, apologies, bad luck for me.. Will cancel my PR.
When I did the search and check on existing connectors, I was looking by service names and endpoints and somehow missed yours - could be grouped better with the other NASA one?

Closing PR, connector exists based on other source

@fordosa90 I follow all PRs submitted to this repo, mostly so I have awareness of the other Independent Publishers submitting and I'll try to help if I can.


Integration Detail Page Layout

Integration detail page layout
Details tab

[ ] implementation
[ ] write storybooks
[ ] write tests

Activity tab

[ ] implementation
[ ] write storybooks
[ ] write tests

Metrics tab

[ ] implementation
[ ] write storybooks
[ ] write tests

Should also probably add the route, unless @riccardo-forina has done this
integration details route (/integrations/:integrationId/details)

[ ] page component
[ ] set up the i18n labels
[ ] write tests

Yep it makes sense!


completed alias for macos setup. also, extracting docfx should be don…

…e to /Users/hector/bin/docfx, was ambiguous and first tried to extract it into mono's bin

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


defer() implementation

I noticed this recently - https://github.com/google/nsjail/blob/db4a90d22542d3642b4a34fe6c2a9358c3414c69/common.h and thought it may be of interest to you, in the off chance you were ever wondering how to support a defer() type implementation in libmill.

No need to do this in libmill. Users are free to use the cleanup attribute themselves if they feel like it.

Fair enough - thought it might have been a nice abstraction you may have been interested in adding.
Thanks for your work on libmill - I enjoy using it :)


IOS version of SWIFT, how to set the background of the animation view to a transparent？

IOS version of SWIFT, how to set the background of the animation view to a transparent？

I set the background color to transparent in the arBoard,
And then set the background color of RiveView to clearColor when using it in swift project.


work on the touch screen

Hello! I really like your project, but noticed a few inconveniences when working on a touch screen (android, google chrome browser):

buggy double tap to edit the contents of the node text;
pinch-to-zoom buggy, no double-tap-to-zoom;
it is difficult to call the context menu if there are many selected elements (it would be nice to have a statically located button to call it);
there is no way to block each selected element from accidental changes separately (or is it somehow possible?);
most pop-up windows do not have a button to close them, and a tap outside the window cancels all element selections.
Thank you for the attention!

Please only one subject per thread, we cannot track multiple reports in a single issue.

ok


Missing parenthesis in the samples of openrowset-transact-sql.md

[x] Missing parenthesis in the sampletestcred example
[x] Fix poor indentation with respect to the style of the beginning of the document.

You should SQLFluff all the SQL examples for better readability.
In my opinion, as a newcomer, it was hard to understand proper use of OPENROWSET, the examples could be better organized or provide more explanations.

@MikeRayMSFT
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@mycaule Thank you for your contribution. We manage over 16,000 articles in this repository, so it is not possible to clean up the formatting for code blocks unless we dedicate time to that task.
A refreshed version of this article will publish in the next few days, that also updates other sections.

Why did you not merge, there was a syntax error in the samples ?

We did merge, using an internal PR based on this one. As I stated previously:

A refreshed version of this article will publish in the next few days, that also updates other sections.

If you check the updated article, you will see your changes were included.


Supporting concurrent in-place copies during stream allocation.

This will allow us to schedule copies (and other ops) together when operating on the same resources either when directed by the user at higher levels of the stack ("trust me this is safe") or by partitioning that can ensure the ops are mutually exclusive (non-overlapping ranges derived from analysis). This will be useful for collectives as we can group multiple collectives together operating on the same send and recv resources.
Progress on #7729.
Progress on #9580.

Test failure was a tf network flake - merging.


[RFC]: improve README examples of stats/base/dists/logistic namespace

Description
This RFC proposes to improve the README examples of the stats/base/dists/logistic namespace package. Currently, namespace package READMEs only include minimal examples which are not particularly informative and do not showcase namespace functionality.
Historically, namespace examples were not given much effort due to the rapidly changing nature of the project; however, now that development and organization has settled, it would be good to revisit these packages and add proper examples to better communicate to users how to use namespace contents.
For those wanting to contribute to this issue, you can use the following steps:

Browse through the contents of the stats/base/dists/logistic namespace and identify interesting functions and packages to showcase.
Update the example code block in the "Examples" section of the README for the stats/base/dists/logistic namespace and open a PR.
When updating the README, examples should follow existing project conventions (e.g., ES5).
Examples may require functionality from other packages to help make examples more interesting.

Related Issues
None.
Questions
No.
Other
No.
Checklist

[X] I have read and understood the Code of Conduct.
[X] Searched for existing issues and pull requests.
[X] The issue name begins with RFC:.

Hi @Planeshifter I would like to work on this issue. It would be great if you could assign me to this issue. Thanks.

@Planeshifter can you assign this issue to me?

@AbhinavKRN This was closed, as, generally, we have received exceedingly low-quality PRs adding such examples. Individuals who have been submitting PRs for these issues have heavily relied on LLMs generating poor content, and the PRs have been a significant source of noise and headache for maintainers. As such, we closed all of them to help stop the deluge of low-quality PRs.


stop() built-in/op/kernel

DaphneDSL should offer a stop() built-in function which stops the execution of the script (similar to the one in Apache SystemDS). This would be very helpful, e.g., since it would allow UDFs to react to invalid arguments. In such cases, the program should not simply continue (and printing a warning could easily be overlooked), the program should stop.
Example:
def foo(x:si64) {
    if(x < 0)
        stop("x must not be less than zero");
    return 1 + sqrt(x);
}

We need:

A stop() built-in function in DaphneDSL, which should take an optional message string that is displayed along with an error message. If no argument is provided at DSL level, an empty string could be used under the covers.
A StopOp DaphneIR operation, with mandatory message operand.
A stop kernel; the most straightforward way to ensure that an error message is printed and the program execution terminates in a controlled way would be to simply throw a std::runtime_error in the kernel. This exception would be caught by DAPHNE's (WIP) error handling infrastructure as any other error.
Ideally support for stop in DaphneLib (Python API), maybe as a function on the DaphneContext.
Unit test cases checking for an exception (CHECK_THROWS in catch2) and script-level test cases checking for unsuccessful program termination.

Hints:

Please search for #658 in the code base (especially in the scripts/ directory), since multiple places where stop() should be used instead of a print() are marked that way.
As a possible extension (and that could be done later), the DAPHNE compiler could detect occurrences of stop() that happen unconditionally (e.g., because the check surrounding it has been resolved at compile-time through constant propagation). In such cases, we do not even need to start the script execution, but could immediately abort with the given error message at compile-time.

I'd like to work on this issue.

Great, thanks. Go ahead!

I've just pushed the first version of the stop() function to my fork: Fork: dev-issue-658.
The functionality is as follows:
Custom Input
File:
stop("Custom error");

Output:
[error]: Execution error: The kernel-function _stop__char failed during runtime with the following message [ System stopped: Custom Error ]
    | Source file -> "/daphne/test.daph":1:0
    |
  1 | stop("Custom Error");
    | ^~~

No Input
File:
stop();

[error]: Execution error: The kernel-function _stop__char failed during runtime with the following message [ System stopped: Unspecified error occurred. ]
    | Source file -> "/daphne/test.daph":1:0
    |
  1 | stop();
    | ^~~

When throwing the std::runtime_error, the function does show the failing lines inside the .daph file, but also mentions _stop__char. Should only the second part of the message be printed, and if so, do you have any suggestions on how to implement this?
Apart from that, if there aren't any major concerns in how I've implemented this functionality, I'll continue working on the Python API implementation as well as the unit/script tests.

Thanks for the update. The error message looks fine as it is for now. The overall format is generated by our error handling facilities. That includes the kernel name (_stop__char), because it's useful information for users and developers. Furthermore, that way, the error message is consistent with other errors. So having the message from the stop() function inside the general error message is totally fine.
Regarding the Python API: Thinking about it again now, adding the stop() function there will most likely not work out at the moment. This is because stop() doesn't have any results (values it returns). Therefore, it will not be included in the generated DaphneDSL script. That is a general limitation of DaphneLib at the moment (see #712), which we will fix later. Thus, you can skip the DaphneLib part for this issue.
The code in your fork looks very good already. The main thing that's still missing are indeed the test cases.

The  stop() function now works like requested and also includes the unit/script-level tests. The script-level tests are located in ControlFlowTest.cpp, as this seemed like the most logical place.
When running ./test.sh -nb -d yes, I encountered errors in DistributedTest and MatrixLiteralTest. These errors should be unrelated to my recent commit because I didn't change any files related to these tests. If there is a correlation though, please let know.
If there are any issues with my implementation, please let me know.

Thanks for the update. At a quick glance, the tests in your fork look good. It would be great if you could employ the stop() built-in function in the DaphneDSL scripts as mentioned in the hints above. Other than that, feel free to create a pull request :) .
Regarding the errors: the DistributedTest also sometimes fails on my system (for unknown reasons), but regarding the MatrixLiteralTest, I'm not aware of any problems. But thanks for letting us know; sometimes there are non-deterministic errors that do not occur in all environments. I agree that your changes are unrelated, though.