Make ODE integrator fail if precision is not reachable

The current ODE integrator uses the dense_output scheme of odeint. This schemes may run into an infinite loop if the requested parameters to solve an ODE for make the ODE system too stiff, i.e. the integrator will end up in a never ending loop.
Now, odeint also offers the controlled_stepper interface which does trigger a thrown execption whenever too many attempts are needed in the seek for a small enough step-size. This is behavior makes the integrator robust against extreme parameter values tried out mostly in early phases of sampling.
This should solve issue #52 to some degree, i.e. the integrator is still a RK45 (non-stiff), but will be robust against extreme parameter draws and gracefully fail intstead of locking up Stan.

This is a good idea.  Daniel and I never figured out how to get the lower-level interfaces working.  The code's modular enough that it should be doable.  I'm assigning to Daniel for 3.0, but it'd be nice to get this in sooner rather than later if the new integrators aren't coming on line soon.

Yes, it would be great to have this possibly in a 2.8.1 or 2.9.0 whatever your plans are. It makes a huge difference for users, really. No more freezing of Stan due to the ODE integrator locking up. This patch is critical for anyone wanting to do ODE integration in Stan. The need for a new integrator is much relaxed now that the RK45 is robust. I am curious to try this with Michaels just filed coupled ode system patch.
I just filed a pull request, hope this is good to go in.

We'll review it and either fix it or get it in ASAP.
We probably won't release a 2.9.0 for another couple months,
at which point we should have a bunch new features.
Of course, this fix is probably going to be incompatible
with Michael's fix, since it's all in the same code.
Should we just go with this one?  Or what?  Michael's also asked
me to look at his patch.

Bob

On Sep 28, 2015, at 3:52 PM, wds15<EMAIL_ADDRESS>wrote:
Yes, it would be great to have this possibly in a 2.8.1 or 2.9.0 whatever your plans are. It makes a huge difference for users, really. No more freezing of Stan due to the ODE integrator locking up. This patch is critical for anyone wanting to do ODE integration in Stan. The need for a new integrator is much relaxed now that the RK45 is robust. I am curious to try this with Michaels just filed coupled ode system patch.
I just filed a pull request, hope this is good to go in.
—
Reply to this email directly or view it on GitHub.

Hi!
This patch is compatible with michael one at least i did not get any merge conflicts and to my understanding michael edited the coupled system while i changed the integrate ode function. Have a look at the odeint doc for the difference in a dense output and a controlled error stepper. To my understanding the dense output uses interpolation and gives you back an object which you can query at any time point while the controlled error stepper only controls the precision and nothing more. As we need the solution at fixed time points there not much of a difference, i think.
And yes, getting this thing earlier rather than later will make all stan ode users very happy. For me  this patch is making the integrator simply robust which is a critical property - viewed differently stan has been affected by a bug in the dense output scheme all along, which is now being circumvented. But please take a careful review of it, this must be correct by all means.

Great that there's no conflict.  Of course, we have to figure
out what's wrong with Michael's merge.  I know we need this patch.
We've known that all along, but never figured out how to do it.
In any case, we probably won't do another official release for a
couple of months.

Bob

On Sep 29, 2015, at 3:39 PM, wds15<EMAIL_ADDRESS>wrote:
Hi!
This patch is compatible with michael one at least i did not get any merge conflicts and to my understanding michael edited the coupled system while i changed the integrate ode function. Have a look at the odeint doc for the difference in a dense output and a controlled error stepper. To my understanding the dense output uses interpolation and gives you back an object which you can query at any time point while the controlled error stepper only controls the precision and nothing more. As we need the solution at fixed time points there not much of a difference, i think.
And yes, getting this thing earlier rather than later will make all stan ode users very happy. For me this patch is making the integrator simply robust which is a critical property - viewed differently stan has been affected by a bug in the dense output scheme all along, which is now being circumvented. But please take a careful review of it, this must be correct by all means.
—
Reply to this email directly or view it on GitHub.

The earlier users get this the less frustrated ode users you get on stan-users.
I did find this out by chance when browsing for reasons i forgot through the odeint controlled stepper sources where i saw a maxtries variable - this caught my attention and i am glad it works.
Not sure whats wrong with michaels patch, but if we can really reduce ad by a factor of n, then that's great. Right now things are a lot slower with the new coupled system, for unkown reasons.

See here:
https://github.com/headmyshoulder/odeint-v2/issues/173
in short: odeint does not have a way to throw an exception when there is too much work. It only has a concept to throw an exception if it cannot find a step-size within 1000 subsequent tries. Hence, to get close to the desired behavior of a robust integrator which throws an exception when the system gets stiff is to adaptively integrate between time-points. The down-side is that now the dt step size is re-adjusted many times, on the up-side Stan does not hang any more on many problems.
... with this patch the coupled_ode_observer.hpp could be removed...

The current active pull request for this should be closed (and the branch can be removed). The respective branch with a -2 as postfix implements what should be done (as discussed with the author of odeint). It currently only lacks the feature to set the maximal number of steps allowed depending on the time-span being integrated and a fixed density of allowed number of steps per dt (as suggested on the mailing-list).
Sorry for those iterations, but this is the result of a long discussion with the odeint author who is by now expanding odeint accordingly.

With boost 1.60 this fix is now trivial to do as the max_step_checker concept was introduced in the new odeint library. I am initiating a new pull request for this.


[gql_build] ensure all serializer return types (all types?) are available in generated file, or allow import config

@smkhalsa Issue created from our DIscord discussion
A custom serializer's return type that is imported from another file is not shown in serializers.gql.dart causing a build error.
Only happens with generated BuiltLists? I have other custom scalars set-up the same way but addBuilderFactory functions are not generated for them so this problem doesn't occur...
Also, the addBuilderFactory function is generated multiple times...
Note: build_runner build is still successful
Error
lib/graphql/schema/serializers.gql.g.dart:182:59: Error: Getter not found: 'MyModel'.
          const FullType(BuiltList, const [const FullType(MyModel)]),
                                                          ^^^^^^^^^^^^^^
lib/graphql/schema/serializers.gql.g.dart:183:33: Error: 'MyModel' isn't a type.
          () => new ListBuilder<MyModel>())
                                ^^^^^^^^^^^^^^

Example
# schema.g.graphql
#...
"""JSON encoded custom scalar type"""
scalar MyModelPlural

type Foo {
  id: String!
  items: [MyModelPlural!]
}
#...

# build.yaml
#...
      ferry_generator|req_builder:
        enabled: true
        options:
          schema: flutter_app|lib/graphql/schema/schema.g.graphql
          type_overrides:
            MyModelsPlural:
              name: MyModel
              import: 'package:flutter_app/models/my_model.dart'
      gql_build|serializer_builder:
        enabled: true
        options:
          schema: flutter_app|lib/graphql/schema/schema.g.graphql
          custom_serializers:
            - import: 'package:flutter_app/graphql/serializers/my_model_serializer.dart'
              name: MyModelSerializer
#...

// my_model_serializer.dart

// ignore: implementation_imports
import 'package:gql_code_builder/src/serializers/json_serializer.dart';

// This import exposes "MyModel" which will be required, but missing, from serializers.gql.dart
import 'package:flutter_app/models/my_model.dart';

class MyModelSerializer extends JsonSerializer<MyModel> {
  @override
  MyModel fromJson(Map<String, dynamic> data) {
    return MyModel.fromJson(data);
  }
  @override
  Map<String, dynamic> toJson(MyModel model) {
    return model.toJson();
  }
}

// serializers.gql.dart

//...
// Correctly exposes "MyModelSerializer" but NOT "MyModel", causing built file to have missing type
import 'package:flutter_app/graphql/serializers/my_model_serializer.dart'
    show MyModelSerializer;

part 'serializers.gql.g.dart';

final SerializersBuilder _serializersBuilder = _$serializers.toBuilder()
  ..add(OtherSerializer())
  ..add(MyModelSerializer())
//...

// serializers.gql.g.dart

//...
      ..addBuilderFactory(
          const FullType(BuiltList, const [const FullType(MyModel)]),
          () => new ListBuilder<MyModel>()))
      ..addBuilderFactory(
          const FullType(BuiltList, const [const FullType(MyModel)]),
          () => new ListBuilder<MyModel>()))
     ..addBuilderFactory(
          const FullType(BuiltList, const [const FullType(MyModel)]),
          () => new ListBuilder<MyModel>()))
//...

adding the missing import MyModel into serializers.gql.dart fixes the issue, but I still haven't dug deep enough into built_value to see why/where it's adding those builder factories, and why it's only doing it for the list item and not the other overrides

@danielmahon built_value generates the serializers.gql.g.dart file based on the contents of your serializers.gql.dart.
I don't actually think this has anything to do with the custom serializer. built_value is building the BuilderFactories because one of your GraphQL operations uses a BuiltList<MyModel>, and BuilderFactories are what tell built_value how to serialize BuiltLists of non-standard types.
The easiest solution would be to just include an import of any type overrides by default. I've created PR #148 which implements this. Can you please confirm that it fixes the issue? NOTE: you will need to include your type_overrides map in the serializer_builder in your build.yaml file.
A more elegant solution that selectively imports the custom types only when they will be used in a BuilderFactory would not be trivial, and I think this solution is probably good enough.

@smkhalsa this works, thank you


Update modals and generate meaningful k8s name for images

Closes #1433 #1435 #1388 #1326
Description

This PR did the following things:

Add the comment back as mentioned in https://github.com/opendatahub-io/odh-dashboard/pull/1506#discussion_r1265789708 since we are not going to fix it in this phase and I removed it by mistake
Enhance the status toggle of Enable column in the table, for the error images, it will set default to disabled and the user cannot enable it. Also, add the sort to the Enable column as @vconzola requested here https://github.com/opendatahub-io/odh-dashboard/pull/1506#issuecomment-1633095279

Generate a meaning k8s name for the image stream that user imports, before the change, it was byon-${timestamp}, but now it's custom-${translated-k8s-name} where translated-k8s-name is the translation of the display name that user inputs. Also, add a tooltip next to the image name so the user could easily locate the image stream resource on the cluster.

Refactor the Import/Update modal of the custom notebook images, change the labels, and add helper text/tooltips based on the mockups

Highlights: Refactor the table for adding/editing packages and software in the modal. Take the software as an example, when the user starts to add software or edit software, he will be in the edit mode, which only allows the user to confirm or abandon the current change (the user cannot edit multiple lines at the same time and cannot submit or exit the modal).
What's more, when the user hits Enter in the edit mode, it will automatically confirm the current row and move to the next row. If the row is already the last row, it will create a new entry, which helps the user to quickly input and move on without clicking with the mouse every time. When the user hits Esc in the edit mode, it will abandon the current change of the row and exit the edit mode.
Edit mode: close button hidden, Submit and Cancel button disabled, other rows cannot be edited and removed, either

Non-edit mode: You can do anything you want

How Has This Been Tested?

Try to create some images with the correct path (like quay.io/opendatahub/workbench-images:jupyter-minimal-ubi8-python-3.8-pr-89) and incorrect path (like quay.io/opendatahub/workbench-images:invalid-tag) and you could check the status of the toggle on the Enable column. Try to create more and sort by the Enable column
Try to import/edit the image in every situation, play around with the edit mode of the software/packages

Test Impact

TBD
Request review criteria:

Self checklist (all need to be checked):

[x] The developer has manually tested the changes and verified that the changes work
[x] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has added tests or explained why testing cannot be added (unit tests & storybook for related changes)

If you have UI changes:

[x] Included any necessary screenshots or gifs if it was a UI change.
[x] Included tags to the UX team if it was a UI/UX change.

After the PR is posted & before it merges:

[ ] The developer has tested their solution on a cluster by using the image produced by the PR to main

@vconzola Could you please check the UX updates in this PR? Thanks!

lgtm

I think this works great overall.
However, we should have a sit down with UX and get feedback on the keyboard actions. I'm not sure I like the escape/enter action flows -- double escape closes the modal without warning. Keyboard flow doesn't really get you back in once you escape out (we should probably focus the "add software" at that point -- but it is the next tab index so it's reasonable)
I think we are already are aware of the issue with a bad image -- I just worry it tosses everything away and it's not just inconvenient for an image name. Which I think now with the added flow of keyboard actions, one could quickly lose more.
Probably useful to incubate these and get feedback across the board on them though.

/approve
@DaoDaoNoCode get someone else on the team to verify it again, I unfortunately lost my window to test the code again. Looks good though, thanks for making the desired changes.

@andrewballantyne Sure, let me squash the commits first.

/lgtm


Java timestamp parser and RubyDateParser

To improve the performance of parsing timestamp values, this PR introduces Java timestamp parser. It implements RubyDateParser, which is compatible with Ruby's strptime parser. The parser parses timestamp values by strptime tokens pre-tokenized by strptime lexer.

This PR will be closed and not merged. We're working for this feature on https://github.com/embulk/embulk/pull/611.

Close this ticket.


Is it working on GS66 10SF

Hello. is it working on MSI GS66 10SF?
with i7-10750H and RTX 2070

worked on mine like two years back. I don't have it installed anymore.

Work fine on GS66 664CN i7-10870H and RTX 2060
all NVIDIA gpu will be disabled, so in theory there is no difference


YouTubePlayer Crash

Hi,
I am successfully integrated YouTubePlayer inot IOS and Android using Xamarin Forms.
I have a media gallery an display video on the section of the video from the Video Id
It works perfect but sometimes app crashed . I am using Hockey app for app crash reports.
I didn't get the exact error detail so i am attaching the error log what i got from Hockey app sdk.
Please help me out and give me a chance of thanks.
Regards
ErrorLog.docx

This looks like an issue with the upstream YouTube iOS library.  Please log the issue upstream with them.


add a new console-simple template

add a new console-simple template
fix https://github.com/dart-lang/stagehand/issues/650

@kevmoo @kwalrath

cc @mit-mit

I wonder if we should change the README for console-full, since it differs from console-simple's by a single character.

I wonder if we should change the README for console-full, since it differs from console-simple's by a single character.

Makes sense; I updated the readme for the console-full sample to decribe a bit more what it does and help differentiate it from console-simple.

LGTM! (Although I think you'll need to regenerate because I changed the README.)

Thanks! Done.

@mit-mit, I'd like to land this PR (and split off discussions about changing the .gitignore files into a separate issue).

Happy to track in a separate issue, but I'm inclined to immediately open a PR so make the edit then, so kindly comment over in https://github.com/dart-lang/stagehand/issues/653


[AutoPR] apimanagement/resource-manager

Created to accumulate context: apimanagement/resource-manager

(message created by the CI based on PR content)


Chore/cf 2380 adding eslint

Hi @bkozera I've see you submit PRs and close them a couple of times now? Can you please explain what your goal is here? Thanks!

hi @andrewhathaway sorry for that!
We have forked your library and are using it and modify it.
The thing is when I create a PR in our repo default base branch is your branch so by accident I created a PR to your branch. I will check if I can set our fork as base branch for all the PRs


Create pipeline to put ONNX Fedora Model into an container image

Run the a pipeline to provide an “Model Container Image” which is used at the robot for the triton server.

[x] Pipeline deployed via GitOps https://github.com/cloud-native-robotz-hackathon/infrastructure/tree/main/datacenter/per-user/ai
[x] Pipeline example: https://github.com/rbo/AI-for-edge-microshift-demo/blob/main/push-model-to-edge-pipeline/push-model-to-edge.pipeline.yaml
[ ] Lab guide anpassen: https://github.com/cloud-native-robotz-hackathon/lab-guide
[ ] Make own version of quay.io/rbo/ubi-awscli:latest

Pipeline ready to go and public available:

quay.io/cloud-native-robotz-hackathon/model-container:trained
quay.io/cloud-native-robotz-hackathon/model-container:plain

Forward the issue to @nexus-Six for lab guide.

all done


Add Jackett torrent proxy server application

Add in yaml file for Jackett application from github.
Microsoft Reviewers: Open in CodeFlow

 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: wdupree sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Fails smartscreen validation but should be allowed. Also submitted for approval of smartscreen validation.


daemon is slow

publishes take >= 2 minutes
'get' commands and downloading blobs takes a long time as well

more details & logs to come

@jackrobison since you completed some work on this issue, I've been seeing the following publish error from time to time.  Saw it again this morning.
{"error":{"code":-32500,"data":["  File \"site-packages/twisted/internet/defer.py\", line 1299, in _inlineCallbacks","    ","  File \"site-packages/lbrynet/core/Wallet.py\", line 800, in _handle_claim_result","    ","exceptions.AssertionError: result in unexpected format:{'is_mine': False}"],"message":"result in unexpected format:{'is_mine': False}"},"id":null,"jsonrpc":"2.0"}

@jackrobison the daemon seems to be much faster, but I am not sure where you are at on things.  Are you still working on this, or can this issue be considered closed?


Request Timeouts on Deployment on Amazon EC2 Small and xLarge

Wonderful project here, I'm happy to start playing with and understanding.  Unfortunately,  I am having issues with scalability with just 100 checks on Amazon AWS EC2 instances.  The Mongo DB is running on  MongoLabs hosted DB.
Standard Amazon AMI Linux
Node 0.10.17
NPM 1.3.9
I started with a Small EC2 instances, loaded up the checks with 100 popular websites, but i see large amounts of Request Timeout errors:
20:33:47 www.twitter.com responded with error "Request Timeout"
20:33:47 www.blogspot.com responded with error "Request Timeout"
20:33:47 www.windows.com responded with error "Request Timeout"
20:33:47 www.aol.com responded with error "Request Timeout"
20:33:47 www.wikimedia.org went down Request Timeout
20:33:47 goo.ne.jp responded with error "Request Timeout"
20:33:47 www.craigslist.org responded with error "Request Timeout"
....
Out of the 100 sites, maybe 70 of them are consistently or intermittently fail when checked.  My settings are rather standard:
60 second checks
15 second timeouts
Other scalability tweaks I though of:

ulimit -n increased to max
http MaxSockets increased just in case
xLarge EC2 instance used

None of these have a noticeable effect on the Request Timeout problems.  Any other tweaks or setup steps I am overlooking?

Having the same issue here.

@emiliobool Am struggling with the email notification setup in uptime..I understand from your comments that you have the email notification setup..Can you please paste here your default.yaml file that has the email notification enabled? It will be really very helpful, thanks in advance!


improvements recent apps

refresh rate disable by pin / unpin
-Continuous = load a lot CPU
-10s speed is very slow but still wast CPU each 10s
-Disable option by pin / unpin can work like a favorite bar, also only update list manually when pin/unpin
https://user-images.githubusercontent.com/67331785/116781698-08b8b280-aa5b-11eb-812f-1da1a78644a4.mp4

add Quit and Start without open the settings.


You can add any new opportunities created related to Hacktoberfest

Adding any new swag opportunities or updates

This seems to be done for the moment .


Add method to write stdout to file.

I would like to write output to file directly instead of copying []byte to memory first. Example:
docker save debian:8.6 > /tmp/debian.tar
ref: http://stackoverflow.com/a/18987147

I see you named func called. "WriteOutput", the Output means contains stdout and stderr, What you do should better rename to WriteStdout

@codeskyblue updated. PTAL.

If you can convenient, update the README.md


libs to explore

mixinify - https://github.com/lelandrichardson/mixinjs

basscss rebass

http://intljusticemission.github.io/react-big-calendar/examples/index.html#intro

http://blog.arkency.com/2015/04/beautiful-confirm-window-with-react/

https://github.com/yahoo/httpmetrics

https://www.npmjs.com/package/why-did-you-update

This issue was moved to k-sheth/calendar-khana-lagao#38


Add a slight delay after composing a slurped nfd to let it exist full…

…y on disk

adding the resize of pickle onto here as it seems to be erroring out?

yep improperly sized emote parts cause an error during composition.


refactor(connector): added amount conversion to FISERV

Type of Change

[ ] Bugfix
[ ] New feature
[ ] Enhancement
[x] Refactoring
[ ] Dependency updates
[ ] Documentation
[ ] CI/CD

Description

added MinorUnit for amount conversion
Additional Changes

[ ] This PR modifies the API contract
[ ] This PR modifies the database schema
[ ] This PR modifies application configuration/environment variables

Motivation and Context

fixes #5947
How did you test it?

Checklist

[x] I formatted the code cargo +nightly fmt --all
[x] I addressed lints thrown by cargo clippy
[ ] I reviewed the submitted code
[ ] I added unit tests for my changes where possible

@ravikiran232 Please implement the suggested changes.

Hey @ravikiran232 Any updates on the changes!


(module name): short issue description

Feature Description
Config parameter to bind to interfaces other than localhost when HTTPS encryption is configured.
Use Case
When developing components, the debug console is invaluable. However, if developing and testing inside a VM or container using tools such as VSCode Remote, the debug console only supports localhost as seen here:
https://github.com/aws-greengrass/aws-greengrass-localdebugconsole/blob/323a4847e631a228eb3d40c3c2181678e3f5bd01/src/main/java/com/aws/greengrass/localdebugconsole/SimpleHttpServer.java#L119
This requires additional reverse proxy configuration during development and testing.
Proposed Solution
Provide a new configuration parameter such as bindHostname that defaults to localhost, but could be set to a specific network interface or <IP_ADDRESS>.
Then make that parameter effective only when httpsEnabled is set True.

[x] :wave: I may be able to implement this feature request
[ ] :warning: This feature might incur a breaking change

Closing, I see that bindHostname is read from the configuration key.


proxy issues with hugging face

"I have proxy restrictions in the company. Therefore, when I try to work with PrivateGPT (even though I have already downloaded the LLM model locally but not the embedder's), I get this error: requests.exceptions.ProxyError: (MaxRetryError("HTTPSConnectionPool(host='huggingface.co', port=443): Max retries exceeded with url: /mistralai/Mistral-7B-Instruct-v0.2/resolve/main/tokenizer_config.json (Caused by ProxyError('Cannot connect to proxy.', OSError('Tunnel connection failed: 403 Forbidden')))"), '(Request ID: daac27c7-b24f-4c19-a707-895d5061595f)')"

If it is just about the tokenizer one fix is to download it somewhere you have access to huggingface and place it into the /models folder. It is just 2mb in size I think.
If your proxy is working in general I found that you:

Have to pass the proxies argument to the hf function downloading the tokenizer.
Like this:

AutoTokenizer.from_pretrained(
    pretrained_model_name_or_path=settings().llm.tokenizer,
    cache_dir=models_cache_path,
    proxies={"http": <your proxy>, "https": <your proxy>}
)

Overwrite the session creation in site-packages/huggingface_hub/utils/_http.py
Like this:

def _default_backend_factory() -> requests.Session:
    session = requests.Session()

    session.proxies = {"http": <your proxy>, "https": <your proxy>}
    session.verify = False

    #session.mount("http://", UniqueRequestIdAdapter())
    #session.mount("https://", UniqueRequestIdAdapter())
    return session

If it is just about the tokenizer one fix is to download it somewhere you have access to huggingface and place it into the /models folder. It is just 2mb in size I think.
If your proxy is working in general I found that you:
1. Have to pass the proxies argument to the hf function downloading the tokenizer.
   Like this:

AutoTokenizer.from_pretrained(
    pretrained_model_name_or_path=settings().llm.tokenizer,
    cache_dir=models_cache_path,
    proxies={"http": <your proxy>, "https": <your proxy>}
)

2. Overwrite the session creation in site-packages/huggingface_hub/utils/_http.py
   Like this:

def _default_backend_factory() -> requests.Session:
    session = requests.Session()

    session.proxies = {"http": <your proxy>, "https": <your proxy>}
    session.verify = False

    #session.mount("http://", UniqueRequestIdAdapter())
    #session.mount("https://", UniqueRequestIdAdapter())
    return session

What exactly should I download?


Older spellings: offer variations where ö is replaced by ǫ

O caudata (= ǫ) would be more accurate letter for words that use "ö" in the Cleasby Vigfusson book. Using "ö" in Old Norse is a more modern practice that is mostly based on modern Icelandic and/or lack of letter ǫ in all keyboard setups.
Should the word contain letter ö, offer alternative version with ǫ. When that is done, also offer an explanation as to why this alternative form exists. Similar work is done for Old Swedish dictionary in this PR.

Might want to also change all "Letter Ö" (= the letter page) representation forms to something like "Letter ö/ǫ". No need to change the slug, but may make sense to point that alternative on the letter page levels too.

Might also want to add "written language" section to frontpage. Should mention this, being heavily abbreviated (probably crosslink to the sources page) and old fashioned english words like "speer" for ask.


Add new fluid example for attributable map

Description
This PR is to provide a fluid example, which is a simple multi-user web app using the experimental DDS attributableMap. It is distinct from the initial design https://github.com/microsoft/FluidFramework/pull/15101, and the description of the example can be found in examples/apps/attributable-map/README.md

I'm approving because I think it makes more sense to get this checked in and iterate upon it rather than block on a few issues. Please do add the experimental warning before merging though.
I have two major concerns that are (I think?) not demo specific, but rather about the general attribution feature:

No design should rely on scope.  This is a code smell that we don't have appropriate injection points, or that something is inappropriately reaching across code layers otherwise.
The pseudo-mixin pattern (not really a mixin, this is just classic class inheritance with unusual syntax) is not great, and I think a big part of what's driving you to force a feature-specific runtime factory.  I don't know enough about the feature to offer a better alternative offhand, but probably think about how you can avoid this pattern (and class inheritance in general)

I have discussed with these concerns with @Abe27342 before. Based on the current implementation/design for the mixinAttributor, it appears that the only way to enable the attribution in the ContainerRuntime is by passing a scope which implements IProvideRuntimeAttributor, Additionally, the attributor can be extracted from scope, which seems the unique way as well. I can double check this information when he returns.


gpio.open should accept array of pin options

gpio.open should support an array of config objects in order to export multiple ports and have an elegant callback that ensures all those ports are available to use.
Contract should look something like...
gpio.open([
  { pin: 4, direction: gpio.DIRECTION.IN },
  { pin: 17, direction: gpio.DIRECTION.OUT }
], function(err, gpioPins) {
  if(err) return console.log(err);

  var gpioPin4 = gpioPins[0];
  var gpioPin17 = gpioPins[1];
});

what open is supposed to return here ? an array of gpio instance (to be closed using close() ) ?

If it adheres to the current contract, then it should return the same variable as gpioPins (array of GPIOPin instances). If we want to be future proof, then it should return a promise (I'm leaning towards this).
I know the current API returns the created instance, but that original contract was created a long time ago without a lot of thought put in. export (and now open) is an async function call, there's no point in returning something that you can't use immediately. For example, this will never work...
var pin = gpio.open(...);
pin.set(); // throws error since open isn't done

We should advocate for all gpio operations to run inside the callback.
That's why I was checking the node version on your board. I think we should make the minimum engine be something like v4.0.0 and support promises now. I just booted up my original raspberry pi (used when I created this library) which has v0.6. It's completely unusable now bc it didn't meet npm min version requirement (therefore unable to perform npm install).


[Feature Request] Way to specify GPU ordinal

Hello.
I am currently employing the vllm library alongside dataparallel for my projects.
Up until version 0.2.6, it was feasible to designate specific GPUs for each worker explicitly, which was instrumental for optimizing resource allocation, particularly when not using tensor parallelism.
The code snippet below illustrates how this configuration was implemented:
def child_process(rank):
    os.environ["LOCAL_RANK"] = str(rank)
    from vllm import LLM

This functionality seems to be unsupported in versions of vllm later than 0.2.6.
This feature is crucial for achieving higher throughput, especially when working with smaller models on high-VRAM GPUs (e.g., a 2B parameter model on an A100 80G GPU).
Thank you!

I believe the environment variable PyTorch use internally is CUDA_VISIBILE_DEVICES does that achieve the same effect?

Oh, I forgot to adding a detail. The CUDA_VISIBLE_DEVICES  is usually work, however, if some library initialized torch (e.g., import torch or import transformers), then it does not work.
Actually, the above snippet should be modified as:
import torch

def child_process(rank):
    os.environ["LOCAL_RANK"] = str(rank)
    from vllm import LLM

Interesting. You are saying that once torch is imported, the cuda device is assigned?

Yes, more precisely, doing some gpu operation make effect.
The below is the minimum script to reproduce:
Case A (works well)
import os
from multiprocessing import Pool, set_start_method

set_start_method("spawn", force=True)
os.environ["CUDA_VISIBLE_DEVICES"] = "0,1"

import torch

def child(rank):
    os.environ["CUDA_VISIBLE_DEVICES"] = str(rank)
    from vllm import LLM

    llm = LLM("/nfs_data_storage/llama2_hf/Llama-2-7b-chat-hf")

def main():
    p = Pool(2)
    p.map(child, range(2))

if __name__ == "__main__":
    main()

Output A (expected)
[0] NVIDIA A100-SXM4-80GB | 29°C,   0 % | 13535 / 81920 MB |
[1] NVIDIA A100-SXM4-80GB | 31°C,   0 % | 13535 / 81920 MB |

Case B (Doesn't work)
import os
from multiprocessing import Pool, set_start_method

set_start_method("spawn", force=True)
os.environ["CUDA_VISIBLE_DEVICES"] = "0,1"

import torch

torch.tensor(1).to("cuda:0")

def child(rank):
    os.environ["CUDA_VISIBLE_DEVICES"] = str(rank)
    from vllm import LLM

    llm = LLM("/nfs_data_storage/llama2_hf/Llama-2-7b-chat-hf")

def main():
    p = Pool(2)
    p.map(child, range(2))

if __name__ == "__main__":
    main()

Output B (unexpected)
[0] NVIDIA A100-SXM4-80GB | 29°C,   0 % | 27440 / 81920 MB |
[1] NVIDIA A100-SXM4-80GB | 30°C,   0 % |     7 / 81920 MB |

I've also run into this limitation a bunch where I'd like to run mutiple models in the same script on different GPUs. Ideally there would be a way to specify the GPUs a model should be located on for each LLM(...) initialization. Setting CUDA_VISIBILE_DEVICES works great for a single model (and can be done programatically by setting os.environ["CUDA_VISIBLE_DEVICES"] before importing torch) but doesn't work for multiple models in the same process.
There was some discussion of a fix here but it would need to be implemented into a release.

Encountered the same issue. Could we consider adding a parameter to specify the mapping between rank_id and device_id? This would make it more flexible.

Hi @simon-mo is there some internal limitation/difficulties to selecting GPU ordinals through Python API (without env variables) ?


add windows 11 support

Hi,
Gave it a try, but the version check in Add-VirtIODrivers results in "w10" for me. Might not make a difference in output, since the mapped virtIO build-numbers are equal.
Example output of Get-WimFileImagesInfo. Note the difference in ImageName and ImageDisplayName:
Handle                  : WIMInterop.NativeMethods+WimImageHandle
ImageIndex              : 6
ImageName               : Windows 10 Pro
ImageEditionId          : Professional
ImageFlags              : Professional
ImageProductType        : WinNT
ImageInstallationType   : Client
ImageDescription        : Windows 10 Pro
ImageSize               :<PHONE_NUMBER>6
ImageArchitecture       : AMD64
ImageDefaultLanguage    : en-GB
ImageVersion            : 10.0.22000.318
ImageDisplayName        : Windows 11 Pro
ImageDisplayDescription : Windows 11 Pro

Hi, Gave it a try, but the version check in Add-VirtIODrivers results in "w10" for me. Might not make a difference in output, since the mapped virtIO build-numbers are equal.
Example output of Get-WimFileImagesInfo. Note the version for Win11 still is 10. Also note the difference in ImageName and ImageDisplayName:
Handle                  : WIMInterop.NativeMethods+WimImageHandle
ImageIndex              : 6
ImageName               : Windows 10 Pro
ImageEditionId          : Professional
ImageFlags              : Professional
ImageProductType        : WinNT
ImageInstallationType   : Client
ImageDescription        : Windows 10 Pro
ImageSize               :<PHONE_NUMBER>6
ImageArchitecture       : AMD64
ImageDefaultLanguage    : en-GB
ImageVersion            : 10.0.22000.318
ImageDisplayName        : Windows 11 Pro
ImageDisplayDescription : Windows 11 Pro

Could you please try to print out $image.ImageVersion.Major in WinImageBuilder.psm1 to make sure you got the right win11 installer image.
And, please comfirm that w11 does exsist in your virtio driver pack.
Also, please provide your auto generated Examples\config.ini which may be helpful to locate the problem.

Hi @aeloyq,
Here is the output (matches the Get-WimFileImagesInfo):
`    $majorvVersion = $image.ImageVersion.Major
$minorVersion = $image.ImageVersion.Minor
$imageInstallationType = $image.ImageInstallationType
$imageName = $image.ImageName
$imageDisplayName = $image.ImageDisplayName
Write-Log "Major: $majorvVersion"
Write-Log "Minor: $minorVersion"
Write-Log "ImageInstallationType: $imageInstallationType"
Write-Log "ImageName: $imageName"
Write-Log "ImageDisplayName: $imageDisplayName"

12.06.2022 18:28:22 - Major: 10
12.06.2022 18:28:22 - Minor: 0
12.06.2022 18:28:22 - ImageInstallationType: Client
12.06.2022 18:28:22 - ImageName: Windows 10 Home N
12.06.2022 18:28:22 - ImageDisplayName: Windows 11 Home N`

This is a Win11 installer ISO (and installs Win11 definitely ;)).
Confirm: Using virtio-win-0.1.217.iso, which does contain amd64\w11
Config:
config.ini.txt

Hi @aeloyq,
Here is the output (matches the Get-WimFileImagesInfo):
$majorvVersion = $image.ImageVersion.Major
$minorVersion = $image.ImageVersion.Minor
$imageInstallationType = $image.ImageInstallationType
$imageName = $image.ImageName
$imageDisplayName = $image.ImageDisplayName

Write-Log "Major: $majorvVersion"
Write-Log "Minor: $minorVersion"
Write-Log "ImageInstallationType: $imageInstallationType"
Write-Log "ImageName: $imageName"
Write-Log "ImageDisplayName: $imageDisplayName"

12.06.2022 18:28:22 - Major: 10
12.06.2022 18:28:22 - Minor: 0
12.06.2022 18:28:22 - ImageInstallationType: Client
12.06.2022 18:28:22 - ImageName: Windows 10 Home N
12.06.2022 18:28:22 - ImageDisplayName: Windows 11 Home N

This is a Win11 installer ISO (and installs Win11 definitely ;)). Confirm: Using virtio-win-0.1.217.iso, which does contain amd64\w11
Config: config.ini.txt

Hi @MrEasy,
That's really strange!
If you don't mind, please have another try whit this image link, or simply call dism /Get-WimInfo /WimFile:install.wim to fetch some information of installer image and make sure the index of win11 version here matches the one in $image = (Get-WimFileImagesInfo -WimFilePath $wimFilePath)[1] (note that the former one is 1-indexed and the latter one is 0-indexed, so you should minus one before checking).

Output of Get-WimInfo attached - looks good to me. Get-WimInfo.txt
Will check later the result in WinImageBuilder.

Hello,
We have not added support for the W11 on the drivers side as the versions of the virtio drivers (I mean the files), were exact matches for the ones in the w10 folder. Are the drivers different right now?

Hello,
We have not added support for the W11 on the drivers side as the versions of the virtio drivers (I mean the files), were exact matches for the ones in the w10 folder. Are the drivers different right now?

Unfortunately, this is still the case.
However, w11 (same as w10) drivers have worked for me so far with Windows 11. Perhaps it's because they both use the same major and minor version of the Windows NT kernel.
Interop.ps1 retrieves the erroneous image name information from the WIM file, which is the current issue. This could be due to the fact that the Windows 11 installer image contains unmodified information or that WIM file has a different data structure.

Seems already changed on master :)


@properties.defaults wrapper needs an overhaul

Right now, this wrapper is used to add_defaults to superclass _defaults - that should probably be more explicit. - These methods should happen on startup and not use self.
There should also be functions to dynamically calculate defaults of properties (something like @properties.default('prop_name').

Inheriting multiple defaults-wrapped _defaults functions doesn't actually work.
import properties

class A(properties.HasProperties):
    int_0 = properties.Integer('an integer', default=0)

class B(A):
    @properties.defaults
    def _defaults(self):
        return dict(int_0=1)

class C(B):
    @properties.defaults
    def _defaults(self):
        return dict(int_0=2)

a = A()
assert a.int_0 == 0  # True
b = B()
assert b.int_0 == 1  # True
c = C()  # Infinite loop

This is because: super(self.__class__, self)._defaults is called in C then in B, but self is still c so super is B again, etc.
Anyway, needs an overhaul.

Current solution: @properties.defaults wrapper removed. To replace this behaviour, _defaults is still a dictionary of default values, but it follows class inheritance. One default can be overridden on a class using _defaults while others remain unchanged. To allow for dynamic defaults, the values in this dictionary can be callable.
Quick example:
import properties
import random

class A(properties.HasProperties):
    """All defaults 0"""
    a = properties.Integer('int a', default=0)
    b = properties.Integer('int b', default=0)
    c = properties.Integer('int c', default=0)

class B(A):
    """defaults are explicitly overridden"""
    _defaults = {'a': 10, 'b': 20, 'c': 30}

class C(B):
    """default for a is changed to a randomly generated int.
    defaults for b and c are still 20 and 30, respectively.
    """
    _defaults = {'a': lambda: random.randint(0, 10)}

This is implemented in #76


Add support for RayCluster

What would you like to be added:
Support RayCluster as a queue-able workload in Kueue (much like RayJob).
Why is this needed:
Currently Kueue supports RayJob which works great when managing ray jobs that run on ephemeral ray clusters. However, there are many use-cases and existing workloads that depend on long-lived RayClusters. Being able to account for these RayClusters with Kueue would greatly improve integration of Kueue with Ray.
Completion requirements:
This probably needs a KEP, but very roughly the requirements would be:

Kueue should only account for ray worker nodes in ClusterQueue quotas (we may account for head nodes later)
Scaling of worker nodes should be blocked on quota reservations
Evicting or pre-empting RayClusters involves scaling worker groups to 0

This enhancement requires the following artifacts:

[X] Design doc
[X] API change
[X] Docs update

The artifacts should be linked in subsequent comments.

@alculquicondor initial thoughts on this? I can try to put together a KEP if this idea doesn't sound crazy :)

Hi, in my opinion an easy way to do this is to have Ray create "Kueueble" pods for the workers.

It sounds reasonable to me to add support for RayCluster.
The additional thing to take into consideration is to make sure RayJobs are not doubly queued once RayCluster is also queueable.
cc @kerthcet as one of the primary users of Ray+Kueue

+1
I think that supporting long-living resources would be worth it.

Make sense to me, several points here:

RayCluster is somehow similar to RayJob because RayJob reuses rayClusterSpec, so the code should be reuse.
RayCluster doesn't support suspend semantics, so it behaves as long-lived resources, right? Then we can't guarantee the resource utilization if the cluster is empty of jobs.

make sure RayJobs are not doubly queued once RayCluster is also queueable.

I think we can tell this via the clusterSelector field.

Do we still want a KEP for this? I think with the new suspend API (https://github.com/ray-project/kuberay/issues/1667), the implementation should be very straight forward.

Historically, we haven't written KEPs for integrations.
FWIIW, the implementation should be quite similar to that of Job, whereas the implementation for RayJob will change a little to be more similar to Job. Note that if a user is queuing a RayJob, it's RayCluster shouldn't be doubly queued.

FYI @vicentefb who is working on the feature now


Update gugu.toml

https://github.com/anoma/namada-testnets/pull/803
https://github.com/anoma/namada-testnets/pull/1174
https://github.com/anoma/namada-testnets/pull/1843
Description
All previous genesis validators should name their PRs "Update {validator_alias}.toml for tesntet-15" and provide links to previous PRs merged.
If this is an UPDATE for a previous genesis validator
Checks are made against your net_address. If this has changed since the previous testnet, make sure you provide links of previous prs merged from your previous git username.
Thanks in advance!
Checklist before merging

[ ] Only one toml is added in this PR
[ ] The file being added is indeed a .toml file
[ ] The toml being added is to the correct folder, and only to the correct folder
[ ] The eth_hot_key and eth_cold_key are present
[ ] The email, discord, elements telegram, and twitter fields are present and valid

Successfully validated transactions.toml file for commit hash a9ed5d3


Added 404 Page, with proper response

Resolves #14 open to different design suggestions

Fantastic work @RFX14


Doesn't work on front end form

The plugin works fine on back end forms, but doesn't work on front end. I inserted the field group with acf_form(), but click on stars and on clear button doesn't have any effect nor show an error in Javascript Console. Any hints?

Just found out that the problem is an error on another plugin I use on front end (acf-views). Deactivating this plugin makes work acf-star-rating as expected. Thanks for the plugin!


Copied Protos from server

Copied proto files from server

Typescript web is failing for unrelated reasons, being fixed in PR #869


ECO-1259: Minubo integration

Developer(s): @valerio8787

Peer Reviewer:

Ticket: https://spryker.atlassian.net/projects/ECO/issues/ECO-1259

Release: https://release.spryker.com/release-groups/view/60

Please confirm

[ ] No new OS components - or they have been approved by legal department
[ ] All new or heavily changed classes get an "A" rating (Scrutinizer), except Facades, Factories, QueryContainers and Tests

Documentation

[ ] Functional documentation provided or in progress?
[ ] Integration guide for projects provided or not needed?
[ ] Migration guides for all contained majors provided or not needed?

Release Table

Module
Release Type
Constraint Updates

Minubo
major (new)
Oms 8.1.0

Release Notes
Initial Release of Minubo Module. Module provides functionality to export order and customer data that was updated since last run of export. Data exported to Amazon S3 bucket as file with list of JSON-objects.

Module Minubo
Maxi-Major: New or fully refactored module.
Def of done (by responsible developer):

[ ] All methods in facade, client and plugin interfaces provide an API-doc.
[ ] All dependencies are defined, checked and corrected.
[ ] There are no violations of the architecture rules. All cleanups checked.
[ ] All new or changed business logic is covered by functional tests (in Zed business layer).
[ ] Migration guide provided (for existing modules).
[ ] New modules have module description in README, for existing ones they need to be up to date.

Change log
Initial Release
Module provides functionality to export order and customer data that was updated since last run of export. Data exported to Amazon S3 bucket as file with list of JSON-objects.

"Initial Release of Minubo Module"
should actually read what this is about IMO. A bit more high level details.
I fixed up the template regarding the module.

We cannot release on a non-master branch though.
Why doesnt this target "master"?


HDFS Namenode component check

Some relevant HDFS NameNode component checks:

Check if the RPC port is up
Check if the NameNode is not in Safe Mode
Check if a NameNode is active and the other standby

Also add systemd check


Upgrade Cypress version from 12.4.0 to 13.2.0 and make sure current tests are compatible with latest version

make sure you include @Elson9 @jTendeck

make sure you include @Elson9 @jTendeck

In the latest Cypress version 13.2.0, the OAuth callback is not handled properly. The session is not maintained correctly, leading to the home page not loading and causing the test to fail.
This issue only occurs when the spec contains multiple test scenarios. A single scenario in a spec file works fine.


Drawing rectangles and circles should be done using shaders

Replace existing code with shaders (or textures at least for rectangles). Compatibility with other rendering techniques (other than GLSL) could be broken but we don't really care (do we ?).

Won't fix


Incorrect optimization of integer arithmetic

Reproduction
$ out/ReleaseIA32/dart --background-compilation=false --optimization-counter-threshold=2 tests/standalone_2/pow_test.dart
Unhandled exception:
Expect.equals(expected: <1073741824>, actual: <-1073741824>) fails.
#0      Expect._fail (package:expect/expect.dart:496:5)
#1      Expect.equals (package:expect/expect.dart:124:5)
#2      main (file:///usr/local/google/home/kustermann/repositories/sdk-gclient/sdk/tests/standalone_2/pow_test.dart:86:12)
#3      _startIsolate.<anonymous closure> (dart:isolate-patch/dart:isolate/isolate_patch.dart:277)
#4      _RawReceivePortImpl._handleMessage (dart:isolate-patch/dart:isolate/isolate_patch.dart:163)

The root cause of this issue is that 3cc0cea37e56bc5c590905f2da4bc5d9db9d73e6 introduces re-using of type propagation information on use sites, which turns out to be unsafe in certain situations (e.g. due to widen-to-int32 optimizations).
workaround is on it's way.


Suggestion - Emulator V3.5.25

I wish to port my "The Resistance", Multiplayer game from telegram to Microsoft Bot framework. But then the new Emulator make it impossible to debug/build.
My game will require message send fore and back to user "chat room" and "private message", because some secret will be send to user as intel, like who is spy, and your secret selection.
Wiki:
https://en.wikipedia.org/wiki/The_Resistance_(game)
Telegram api make it easy because chat room id is less than 0, and private room id is more than 0. But Bot Framework doesn't have the concept of "room msg" and "private msg"
Also with the new Emulator, I can use other user to test "room". Let's say user1 input A, User 2 input B.
How to improve?

Create the "room" concept
Allow User A input.. and also able to switch to User B input (Maybe the bottom left hand corner)

Hi @teochenglim, thank you for the great feedback. These are good suggestions. #2 is a planned feature (ability to switch user in group conversation). Once that is implemented, supporting #1 will be straight forward.
We don't yet have a timeline for delivering these features, but I'll make sure they're on our roadmap.

Cool! Can't wait to see it is happening.

Thanks mate!


lightdm appears to have a dependency on accounts service

Just tried installing unstable and the lightdm display manager fails to start with:
"WARNING: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service"
Adding "services.accounts-daemon.enable=true", fixes the issue. Should this be a dependency of lighted?

Are you using gnome?
On Apr 28, 2015 3:51 PM, "Tim Williams"<EMAIL_ADDRESS>wrote:

Just tried installing unstable and the lightdm display manager fails to
start with:
"WARNING: Error getting user list from org.freedesktop.Accounts:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Accounts was not provided by any .service"
Adding "services.accounts-daemon.enable=true", fixes the issue. Should
this be a dependency of lighted?
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/7621.

Hi,
No I'm using i3. Just to reiterate,  everything works great with 'services.accounts-daemon.enable=true'. It's as if the greeter is expecting that service.
Best regards,
Tim

@wkennington maybe this new version has changed some requirement. On fedora it's clear it depends on accountsservice: http://pkgs.fedoraproject.org/cgit/lightdm.git/tree/lightdm.spec#n57
Also accountsservice is not a gnome thing.

Well, it's an optional runtime dependency unless you are using gnome and it
changes the behavior of how lightdm registers users to its interface and
sets up portraits. You don't have to enable it, but there is no way to get
rid of the warning.
On Apr 29, 2015 1:20 AM, "lethalman"<EMAIL_ADDRESS>wrote:

@wkennington https://github.com/wkennington maybe this new version has
changed some requirement. On fedora it's clear it depends on
accountsservice:
http://pkgs.fedoraproject.org/cgit/lightdm.git/tree/lightdm.spec#n57
Also accountsservice is not a gnome thing.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/7621#issuecomment-97349938.

It's really annoying to always enable account service because it breaks the
ability to hide users
On Apr 29, 2015 9:33 AM, "William Kennington"<EMAIL_ADDRESS>wrote:

Well, it's an optional runtime dependency unless you are using gnome and
it changes the behavior of how lightdm registers users to its interface and
sets up portraits. You don't have to enable it, but there is no way to get
rid of the warning.
On Apr 29, 2015 1:20 AM, "lethalman"<EMAIL_ADDRESS>wrote:

@wkennington https://github.com/wkennington maybe this new version has
changed some requirement. On fedora it's clear it depends on
accountsservice:
http://pkgs.fedoraproject.org/cgit/lightdm.git/tree/lightdm.spec#n57
Also accountsservice is not a gnome thing.
—
Reply to this email directly or view it on GitHub
https://github.com/NixOS/nixpkgs/issues/7621#issuecomment-97349938.

I

Closing this issue as I've confirmed the warning is  harmless. Apologies for the noise.


dnx-watch exit on Mono segfault

After some days working in docker on linux mvc application throw segfault exception and wait.
Stacktrace:
Native stacktrace:
    mono() [0x4b23dc]
    mono() [0x508a0e]
    mono() [0x428fad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0) [0x7f8a141bc0a0]
    /lib/x86_64-linux-gnu/libc.so.6(cfree+0x19) [0x7f8a13e9c939]
    mono() [0x4e80dd]
    mono() [0x421f22]
    mono(mono_conc_hashtable_remove+0x125) [0x624695]
    mono() [0x4220b4]
    mono() [0x5a6f02]
    mono() [0x5b0610]
    mono() [0x5a1c89]
    mono() [0x5a1cc0]
    mono() [0x5a215d]
    mono() [0x5874e8]
    mono() [0x623a36]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f8a141b3b50]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f8a13efd95d]

Debug info from gdb:

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

[DnxWatcher] fail: dnx exit code: 134
[DnxWatcher] info: Waiting for a file to change before restarting dnx...
This is not a good way on production. Is there any ways to restart application on segfaults?

@victorhurdugaci could you investigate?

Dotnet watch is now CoreCLR only. This is no longer applicable


tls13 client may send redundant change cipher spec(ccs) messages.

Summary
The tls13 client may send two change cipher spec(ccs) messages when MBEDTLS_SSL_TLS13_COMPATIBILITY_MODE is on. One is right after client hello and another is before server finish. The first one seems redundant.
Maybe we need a flag to bookkeeping if ccs is sent or not.
System information
This issue doesn't happen in development branch. (i.e. MVP). It happens in the tls13-prototype branch.
Mbed TLS version (number or commit id):
Operating system and version:
Configuration (if not default, please attach mbedtls_config.h):
Compiler and options (if you used a pre-built binary, please indicate how you obtained it):
Additional environment information:
Expected behavior
Only one ccs should be sent.
Actual behavior
Two ccs may be sent.
Steps to reproduce
programs/ssl/ssl_client2 server_addr=::1 server_port=4433 debug_level=5 force_version=tls1_3

Check write change cipher spec in the log
ssl_tls13_client.c:1993: |2| <= write client hello
ssl_msg.c:2140: |2| => flush output
ssl_msg.c:2152: |2| <= flush output
ssl_tls13_client.c:4111: |2| tls1_3 client state: 31
ssl_msg.c:2140: |2| => flush output
ssl_msg.c:2152: |2| <= flush output
ssl_tls13_generic.c:0284: |2| => write change cipher spec
ssl_tls13_generic.c:0324: |2| <= write change cipher spec
ssl_msg.c:2140: |2| => flush output

..
ssl_tls13_client.c:0969: |2| <= write EndOfEarlyData
ssl_msg.c:2140: |2| => flush output
ssl_msg.c:2152: |2| <= flush output
ssl_tls13_client.c:4111: |2| tls1_3 client state: 30
ssl_msg.c:2140: |2| => flush output
ssl_msg.c:2152: |2| <= flush output
ssl_tls13_generic.c:0284: |2| => write change cipher spec
...
ssl_msg.c:2861: |2| <= write record
ssl_tls13_generic.c:0324: |2| <= write change cipher spec
ssl_msg.c:2140: |2| => flush output
ssl_msg.c:2152: |2| <= flush output
ssl_tls13_client.c:4111: |2| tls1_3 client state: 7

Additional information

This has been addressed in #385.


chore: rename ceresdb to horaedb

This refers to https://github.com/CeresDB/horaedb/issues/1319

cc @jiacai2050 @chunshao90

@jiacai2050 may we push a new tag for downstream use. I think horaedb main repo need it.

go get github.com/CeresDB/horaedb-client-go

This should download latest tag.

I see this error, will push a new tag for use.
https://github.com/CeresDB/horaedb/actions/runs/7034371145/job/19142266529?pr=1324

https://github.com/CeresDB/horaedb-client-go/releases/tag/v1.2.0
Released.


Build and deploy API docs

if this was done correctly, it will:

check that build.sh runs successfully on PR
on merge to master (and nightly), run build.sh and then push everything under publish directory to the gh-pages branch (which is the source of the developer.code42.com site.

@unparalleled-js it looks like this repo is set up to dismiss approvals whenever a commit is pushed after one. Would you mind re-approving?


fix(ssr): hydrate strings in fragments

Right now, it seems that the hydrateChildren function optimizes too much. When you have a custom component that uses renderSlot and that renders a simple string it fails:

This PR removes the current check optimized = optimized || !!parentVNode.dynamicChildren so strings are converted to VNodes before they are compared in hydrateNode:
https://github.com/vuejs/vue-next/blob/92f11d6740929f5b591740e30ae5fba50940ec82/packages/runtime-core/src/hydration.ts#L379-L430

Are you calling renderSlot manually? It's a compiler-only helper so the runtime will assume its return content is always normalized vnodes: https://template-explorer.vuejs.org/#eyJzcmMiOiI8Q29tcD5cblx0PHNsb3QgbmFtZT1cInRpdGxlXCI+ZmVzZjwvc2xvdD5cbjwvQ29tcD4iLCJvcHRpb25zIjp7ImhvaXN0U3RhdGljIjp0cnVlLCJjYWNoZUhhbmRsZXJzIjp0cnVlfX0=
You should not be using this in manual render function code.

@yyx990803 thanks for your feedback and explains a lot! 😊  Maybe it's worth a renaming (e.g. with a prefix) to indicate internal usage only?


fixes #112 to link to the site URL for the mvn pom based on the current version

fixes #112 to link to the site URL for the mvn pom based on the current version

[merge]


Update MoistureSensor to use GPIO pins.

Issue #43

This change is

Coverage increased (+0.4%) to 86.168% when pulling d214a175cac94bd0abd0934ae9182e5f6fe0c498 on moisture_sensor into e824f3d3b5298b6fbbff97e1a709929d27d294e7 on master.

Coverage increased (+0.4%) to 86.168% when pulling df52b6f95ae2c035884fa29fea4c9b475d231029 on moisture_sensor into e824f3d3b5298b6fbbff97e1a709929d27d294e7 on master.

Coverage increased (+0.5%) to 86.199% when pulling 977de936b7f8831fa26cafc0cc911361dfa3314a on moisture_sensor into e824f3d3b5298b6fbbff97e1a709929d27d294e7 on master.

Coverage increased (+0.5%) to 86.199% when pulling 09d2aea2bc9990023d05425d1a2434cad116add2 on moisture_sensor into e824f3d3b5298b6fbbff97e1a709929d27d294e7 on master.

Coverage increased (+0.5%) to 86.199% when pulling 2931322c4da38038a170129e1399e1baa5b6b2ae on moisture_sensor into e824f3d3b5298b6fbbff97e1a709929d27d294e7 on master.

LGTM


4th October 2023 - Diversity Equity & Inclusion Special Interest Group Meeting

Date
2023 OCT 04 - 12:00pm EST / 5pm BST
Untracked attendees

Fullname, Affiliation, (optional) GitHub username
...

Meeting notices

FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact<EMAIL_ADDRESS>with any questions.

FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

Agenda

[ ] Convene & roll call (5mins)
[ ] Display FINOS Antitrust Policy summary slide
[ ] Review Meeting Notices (see above)
[ ] Approve past meeting minutes
[ ] Agenda item 1
[ ] Agenda item 2
[ ] ...
[ ] AOB, Q&A & Adjourn (5mins)

Decisions Made

[ ] Decision 1
[ ] Decision 2
[ ] ...

Action Items

[ ] Action 1
[ ] Action 2
[ ] ...

Meeting Info
Join Zoom Meeting
https://zoom.us/j/98492160513
Meeting ID: 984 9216 0513
Passcode: 691166

1 on this. Let's also sync up on our DEI keynote at OSFF.

Beeke-Marie Nelke / GS

Peter Smulovics / Morgan Stanley 🏦

Mimi Flynn / Morgan Stanley

Mike @ ZNGLY

James McLeod / FINOS

Takeaways from Oct 4th call:

Can we get BBM session at Morgan Stanley added to OSFF agenda?
DEI members need to advertise BBM session in their companies, we can find material on zngly LinkedIn
Blurb for Board slides (send to James): should include BBM stats, roll out of BBM to Americas (NYC, Canada) + asks for board (maybe around how we can celebrate/acknowledge more folks that are contributing to open source that is not code
Can we include a slide on diversity metrics (locations, roles of contributors etc)? We should ask Ryhddian if he can include his session

Closed as part of DEI SIG project board grooming


Applying metrics after the epoch

Dears, I am using tez to classify melanoma images (kaggle SIIM binary classification). With wtfml is possible to get AUC ~ 0.85. With tez, I am only getting AUC ~ 0.6. I saw that this happens, in tez, when using metrics.roc_auc_score(...) inside monitor_metrics method. This gives some ValueError exceptions, that must be handled returning auc = 0.5 (this error occurs when the data have only 1 class).
In the wtfml, the metrics.roc_auc_score(...) method is used only after Engine.evaluate. In this case, the data always have two classes (because the KStratified gives that).
I am wondering if it is possible, in tez, to apply the metrics.roc_auc_score(...) only after the epoch, and not in each train_bs. With that, the data always will have two classes, avoiding the ValueError exceptions.
PS.

In the class definition init I am using:
self.step_scheduler_after = "epoch"
self.step_scheduler_metric = "valid_auc"
In the monitor_metrics method:
try: auc = metrics.roc_auc_score(targets, outputs.ravel())
except ValueError: auc = 0.5
return {"auc": auc}
My model.fit is defined as:
model.fit(train_dataset, valid_dataset=valid_dataset, train_bs=32, valid_bs=16,
device="cuda", epochs=50, callbacks=[es], fp16=False, n_jobs=2)

You can do this by implementing your own custom callback. For example of a callback, take a look at EarlyStopping. You need to write something similar to that ;)

Thank you very much Abhishek.
As I needed the output (out) from the self.model, in order to apply the roc_auc_score as wtfml does, it was necessary to overload the validate_one_step method to return the loss, metrics, and out. With that, the fit method obtains the out (from the validate_one_epoch method) and use it to apply the roc_auc_score. In such case, the ROC obtained was ~0.87.
Both wtfml and tez are really good frameworks, each one with its benefits. Congrats for such amazing work !


Stax over tapscript

Stax porting :rocket:
Includes tests and some small fixes :)

Codecov Report
Patch and project coverage have no change.

Comparison is base (e5d88b4) 83.88% compared to head (633bb57) 83.88%.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #126   +/-   ##
========================================
  Coverage    83.88%   83.88%
========================================
  Files           17       17
  Lines         2178     2178
========================================
  Hits          1827     1827
  Misses         351      351

Flag
Coverage Δ

unittests
83.88% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Rename BSS appropriately.

The incoming BSS package in #179 does not submit batches. We need to rename the package and any other names that refer to 'batches'.

done.


add Gradient for SIRF

[x] Fix GradientOperator for SIRF data: PET(pseudo 2D, 3D) and MR
[x] Add test for GradientOperator for complex data
[x] Add tests for the GradientOperator and SIRF data
[x] Fix dot_test for LinearOperator in the case of complex data.

Closes #1018

The other problem with this is: will it work on complex data? This should be addressed somehow.

In case of complex data we could just offer the numpy implementation, to start with.

TypeError: allocate() got multiple values for keyword argument 'max_value'

the latest commit broke something else.

I propose to change this PR to address only the case of pseudo 3D (or pseudo 2D) geometries.
So, remove the unittests from SIRF and keep only the ones referring to the pseudo 3D case.
To fully handle the SIRF requirements, we should first close #985, then adapt our GradientOperator with a few minor changes using the new member dtype in the geometry and fix the unittests.

Or, do another PR, with the pseudo 3D fix, then address #985 and then finish this one.

Ready to review @paskino @gfardell


Apply ProfileXML using Intune

"Apply ProfileXML using Intune" section has incorrect example OMA-URI.  It should be ./user/vendor/MSFT/VPNv2/VPN profile name/ProfileXML

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

ID: 79add4e0-6997-5b15-542c-be3f1c2b1baf
Version Independent ID: 47bd5f53-cd36-3205-42b1-6d99c68e9b39
Content: VPN profile options (Windows 10)
Content Source: windows/security/identity-protection/vpn/vpn-profile-options.md
Product: w10
GitHub Login: @shortpatti
Microsoft Alias: pashort

@Markt1891, thank you for catching.  I've have fixed the example OMA-URI and it will be published later today.


Suggestion for lesson rewrite to start from web and only later move to terminal

Below I suggest a big rewrite of the Git lesson (days 1 and 2) where we would start from the web and introduce pull requests already on day 1. It would also affect day 3 (https://coderefinery.github.io/git-collaborative/). Of course we can also agree to only implement part of it.
Can you please give critical feedback and comments before we do the changes?
Summary of changes

Start from web (GitHub)
Only on day 2 we move to the laptop
On day 3 we add collaboration
Introduce good practices from the start with good exercise repositories with
a good layout and commit messages which we can discuss
Day 3: add more branch layout to it since we would have more time (freed up
by introducing pull requests earlier)

Timeline

We would try to implement these changes already for the workshop next month

Motivation for changes

Learners are more likely to start from an existing repo or to already have some project that is not yet on Git
Many do not work in the terminal but rather in an IDE or editor
Making a terminal available on Windows is not always easy
We try to explain basic concepts in a terminal but they might be easier to explain in a web interface
It should be possible to participate and learn without a functioning local installation of Git and Bash
Give everybody the feeling of accomplishment and everybody should be able to
do the most basic Git/GitHub tasks after the 2-3 half days
Avoid troubles with main/master naming

Why we should do it

We introduce forks and pull requests already on day 1: this can free up time for day 3 to do more interesting things there
Also the "non-programmers" can benefit from this course
In future we might not need "Collaborating and sharing using GitHub without command line" as standalone lesson anymore
Gives more opportunity to "sneak in" some branch design discussions
Might feel more motivating to see something "real" instead of starting from something empty
Might make the lesson more interesting and fun for new instructors and helpers to join

Why we should not do it

Big rewrite which might exhaust us
We risk introducing problems which we did not anticipate and observe earlier
Week 2 lessons might expect that command line Git has been taught
Maybe too GitHub centric
If we also try to add GitLab, it might become too much work and too confusing to follow
Exercise leaders and co-instructors might be surprised by the changes

Open questions

Not sure whether we should offer some VS Code track or not
Will it work and flow if somebody joins only on day 2 or only on day 3?
Should this rewrite be done in a separate repo?

Suggested exercises
Day 1 exercises

20 min: Fork a repository, browse branches and commits, discuss and answer some questions about the repo
20 min: On the web create branches and commits with useful commit messages, optional: release
20 min: Merge branches using pull requests, browse and discuss network, optional: resolve conflicts

Day 2 exercises

20 min: Configure Git together, clone repo and try some of the commands locally (terminal or editor)
30 min: Inspecting history (in web browser or locally)
30 min: Saving own work to GitHub/GitLab (web or terminal)

Day 3 exercises

30 min: Suggest and review changes within a repository
30 min: Suggest and review changes from a fork, update fork

My thoughts:

We should do something
As I think about the above plan, the problem I see is: this doesn't match the way people really work.  Web can show concepts, but it doesn't connect to what people actually need to do quick enough.  How many people would not return after the first day, after being theoretical the first day?

(Aside: I wonder how much of git is hard because we try to be too dogmatic about the right ways to do things?)
Here is my rough proposal:

Ways to attend

As much as possible, support web, VSCode(=codium), and command line.  VSCode will be more work but if it's what people use, we should use it (and they have figured out a practical user interface).

Day 1: Your own projects.  Everything you need to know to use git yourself.

explore on web to see what a project looks like (recipe book?), clone locally, commit, push.
Ex 1: Basic archaeology on the web
Ex 2: Config and clone from web, do some commits
Ex 3: more commits.  Maybe, make your own repo online, clone, and push. Needs thought.
(final wrap up: comments on 'init' yourself

Day 2: with a small group.  Centralized workflow.  Basically, what a small internal research group could do.

Cloning a repo, commit, push.  Simulate a merge conflict, resolve, and push. (this will be hard with a giant course, since we can't simulate small groups where pull-merge-push works, but we can think of something)
Ex?: Make own repo, clone, commit, push.  (but this is too similar to yesterday.  Needs thought)
Ex?: Merge conflict: Clone our repo, make an edit.  Pull again and see a merge conflict.  Resolve merge, push
Ex?: Recovery exercises.  (at least two methods: lose all your work and get to a known state.  Get to known state but save your work as uncommitted changes.)
Ex?: More archeology.

Day 3: Large projects and PRs

Clone repo, make branch, PRs.  The usual stuff.
Some exercises around pull requests.

This leaves the "right way" to the end but gets to the common way as soon as possible (and that's the point... the right way is dogmatic).  I'm not sure how exactly each of these can be done web/vscode/command line but I bet we can think of most.  And most importantly, I can easily make a recommendation: "Never used git before, watch the 3 hour day 1 CodeRefinery [actually much less, probably closer to 1-1.5 hours] and you learn what you need"
I think all the stuff above needs to be worked out on a board in details (probably somehow combining the plans together), and we need to play with vscode a lot to understand it, but we can do it next week with all the time we have.

Thank you! Let's work on it on the board next week.
Just wanted to note down some concerns/thoughts that I have:

many of my "customers"/researchers work in Spyder or R Studio or Notepad++
some of them do work in the web
if we leave out pull requests to the end, we have to explain more things and have to deal with failed pushes
if people start with cloning and pushing on day 1 instead of forking, we have to deal with access and with conflicts and failed pushes
spending whole day on the web does not have to be theoretical, it would still be exercise-driven and goal-oriented

Notes from pre-discussion:

generating form template flattens history
creating a PR on a fork by default is directed towards central (this might be confusing or hard to explain but also could be satisfying)
we need good metaphor for forking

Whiteboard notes from today:

Notes from today.

Should we have look what others are doing ?, e.g. youtube search

(copied notes from another document)
(day 1)
Motivation
(mostly same as before, but move to google docs example)
Your first project

Our recipe book

README.md
LICENSE
recipes/

few existing recipees

gitignore?

GH lets me upload files anyway without warning

(private and public copy)
added day 3: action to verify

check markdown
or check for certain ingredient

added day 3: pages deploy

Make a copy to work on (fork repository)
Exercise 1a: Fork (20 min)

Do the fork
This i

Archaeology part 1

Exercise 1b: Archeology

Explore a few things (copy from "inspecting history")

"grep" (which foods include a certain ingredient)
annotate (who has contributed to this recipe)

at which commit did an ingredient get introduced or modified?

Contributors page (Who all has contributed?)
How old is each recipe, and how many changes? (look at history)
When was each recipe last modified? (file browser)
Can you use these recipes yourself? (license)
Browse issues and pull requests, any idea what that might be good for?

Preparation:

RB creates starting repo
we need a group of staff preparing this
each adds one and maybe changes one recipe
we need two versions: repo and repo-recorded

Modify your copy (commit)

Exercise: commit

create a branch and commit to it
maybe also commit to main
browse network
compare branches
compare commits

Merge branches and contribute to the project

Exercise: Merge branches with PR

select from which to which
be careful about whether this is towards main on your copy or the repo where we forked from
browse network
optional: try also to send a PR towards the central repo (we merge few of those)

Demo:

conflict
delete branches
create release (or optional exercise step)

Discussion: Doing this locally.  We will start here tomorrow.

Quiz:

how to find out which branches are safe to delete?

(day 2)

What is Git, and what is a Git repository? (from git-intro)
Configuring Git command line (from git-intro)
Exercise: config/clone/commit/branch

Archaeology part 2
(copy from archeology)

Exercise: Arch part 2
Exercise: push to clone / remote add push to default, OR init add commit remote add push

Now working on the lesson-redesign branch: https://coderefinery.github.io/git-intro/branch/lesson-redesign/

We have basically now done this. What remains are filling in some blanks.


Custom tag view

Developer should be able to use custom tag view, built from scratch, without subclassing AMTagView. This feature could bring much more flexibility to the library.

Hi @igormatyushkin014
That's a good point. The implementation should be pretty easy too, I guess I can just extract the needed func calls in a protocol that the view needs to implement. How does that sound?

@andreamazz Yeah, I like the idea with protocol.

@igormatyushkin014
I've pushed some changes in the develop branch. You can now provide a UIView conforming to AMTag.
The view must handle its own sizing.
Let me know if that works for you.

I'll take the silence as a "it's working". Reopen if something is broken.


Is it possible to use vaitrace on AWS F1 instance?

Hello,
I have tried to run vaitrace with AWS F1 instance and always get the following error
ERROR:root:[]
ERROR:root:xmodel info raw info error

So I would like to know if there is any way to do profiling with vaitrace on AWS F1 instance because I need more detailed information on how the operations are executed on DPU circuits.

Hi @williamliao28 ,
The vaitrace tool is supported on AWS F1 instance, But the xclbin needs an update to run 2.5 models on F1 instance. We are working on it and will release another AMI soon. thanks~

Hi @williamliao28,
Please reopen this issue if you have any other questions. thanks!


Update to version 1 7

Added:

New function Get-MTASTS. (close #41)
Added support for multiple values for the -Name parameter. (close #43)

Updated:

Default DKIM-selectors.

Fixed:

DkimSelector not working for Invoke-SpfDkimDmarc (fixes #37).
Typo in SPF Length (fixes #38 #42).
SPF check not correct (fixes #44).
SPF Length (fixes #45).
DkimSelector not working for Invoke-SpfDkimDmarc (fixes #37).

Changed:

Updated the Readme/help docs (fixes #40)

Updated module to version 1.7


Shoulder Gear Ratio/Design

SHOULDER:
Required Torque: 65 N-m
Desired Gear Ratio: 10:1
Stage 1 Gears:

Gear 1- Motor Gear: 1.5M-15T w/ 10mm bore x 4mm keyway

Gear 2: 1.5M-45T w/10mm bore x 4mm keyway [need to request key cutout])

Stage 2 Gears:

Gear 1 (same as motor gear): 1.5M-15T w/ 10mm bore x 4mm keyway

Gear 2: 1.5M-50T w/ 10mm bore x 4mm keyway [need to request key cutout])

Pricing:
Stage 1 Gear 1: $4.34
Stage 1 Gear 2: $8.18
Stage 2 Gear 1: $4.34
Stage 2 Gear 2: $8.91

Is the decision to use compound gears then for the shoulder motor?

Yes
On Tue, Dec 1, 2020, 9:12 AM Khalil Estell<EMAIL_ADDRESS>wrote:

Is the decision to use compound gears then for the shoulder motor?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SJSURoboticsTeam/urc-central-2021/issues/140#issuecomment-736691879,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7AWVYZ2HL5BJJGRRD46ATSSUPV7ANCNFSM4UIN5U6A
.

Wasn't the hierarchy of design complexity something like this (from hardest to easiest):

Custom compound gears
Custom worm gearbox
Custom pulley gear system
Purchase and integrate keyway worm gearbox
Purchase and integrate keyway planetary gearbox

Any particular reason why we went all the way back to compound gears?

This design is actually not too complex, would only require one custom
bracket to hold the shaft and gears for the gearbox. I showed David a rough
design and it doesn't seem that complicated. Also allows more flexibility
if we want to increase gear ratio in the future. All of these parts exist
on aliexpress too.
This would require us to design a custom shaft since the RMD-X7 shaft is
not long enough to hold the worm, without the motor body interfering with
the shoulder plate. Attaching the gear to the shoulder would also require
an additional shaft since the gear would be too small to drill holes
through for mounting. Complexity wise, I'd say it is about the same as
option 1, but I think David has additional reasons why we preferred option
1 over the custom worm gear.
I am assuming this means a simple 10:1 gear ratio without any sort of
gearbox. I looked into small 15teeth/150teeth gear (and pulley) setups and
the 150T gear is extremely large and heavy (plus I couldn't find anything
past 150T) so if we wanted to increase the gear ratio in the future, it
would not be possible without changing the design completely.
I thought we didn't want to go with the prebuilt keyway worm gearbox
because they were gigantic and very heavy. And even with this option, we'd
likely still have to design and manufacture additional parts to mount the
RMD-X7 properly to the gearbox. The motor body could potentially also be
too large and interfere with the shoulder plate, but I can't say for sure
without having the gearbox in CAD.
I don't recall this option being brought up. I did look at prebuilt
planetary gearboxes but those seem to be designed for specific motors, and
I couldn't find one with a 10mm keyway.

On Tue, Dec 1, 2020 at 12:00 PM Khalil Estell<EMAIL_ADDRESS>wrote:

Wasn't the hierarchy of design complexity something like this (from
hardest to easiest):

Custom compound gears
Custom worm gearbox
Custom pulley gear system
Purchase and integrate keyway worm gearbox
Purchase and integrate keyway planetary gearbox

Any particular reason why we went all the way back to compound gears?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SJSURoboticsTeam/urc-central-2021/issues/140#issuecomment-736784469,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7AWV7CMUG4DQVREAP6YGDSSVDNZANCNFSM4UIN5U6A
.

Ok sounds like a decent plan, but I'm not very comfortable with the should being such a custom part as it has to take exceedingly high loads and if we are not careful in how we pick our gears, our gear could shatter.
Acknowledged. so I see where the complication comes from in this.
Acknowledged. This pulley system for this ratio is not feasible.
Yes, the gearbox could be heavy, but thats just because those were the first gearboxes I could find. I stated in the chat that they were far too large for our purposes and we would have to find something else.  Unless we feel like we wouldn't be able to find a worm gearbox that could fit our needs, we should continue to persue this.
This is a new one that I had not brought up yet. I found some light weight planetary gearboxes on AliExpress and though they could work but I didn't look into an exact one that could work. I may just start looking now to see if this is futile or something that we should go for. And I have noticed that many of them are for nema motors, but as long as the shaft fits and doesn't interfere with the body of the RMD-X7 we should be fine.

Ok, so something concerning I'm noticing as I look for gearboxes is the fact that many of the ones that I find, even the bulky ones, have a maximum rating of 25Nm. Which makes me think that we need to talk to these factories before purchasing these gears to make sure that they can support the 65Nm we plan to use them for.
Specifically many of the planetary gearboxes do not have sufficient maximum loads even though their gear ratios workout (their input shaft dimensions do not work either, but thats not the point)

Does it specify if the max torque rating is for the input or output shaft?
It makes a little more sense if the input torque limit is 25Nm because with
the 10:1 ratio the output will be 250Nm.
On Tue, Dec 1, 2020, 1:59 PM Khalil Estell<EMAIL_ADDRESS>wrote:

Ok, so something concerning I'm noticing as I look for gearboxes is the
fact that many of the ones that I find, even the bulky ones, have a maximum
rating of 25Nm. Which makes me think that we need to talk to these
factories before purchasing these gears to make sure that they can support
the 65Nm we plan to use them for.
Specifically many of the planetary gearboxes do not have sufficient
maximum loads even though their gear ratios workout (their input shaft
dimensions do not work either, but thats not the point)
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SJSURoboticsTeam/urc-central-2021/issues/140#issuecomment-736846749,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7AWV4ANSKJEW2EVV57NFDSSVRMBANCNFSM4UIN5U6A
.

It doesn't state which it is, but in general, most gearbox motors have similar torque output limits of <45Nm. So seeing these gearboxes state that the load is limited to something like 25Nm makes sense. Our previous motors claimed 5kg-m performance but when we used them with stresses that the arm produces when we pick stuff up, the internal gears shattered. And even though the ratio was correct the size of the internal gears were tiny and not really meant for that kind of stress.
We NEED to ping the manufactures of these parts to get confirmation about how much stress these parts can take.
I like this series of motors (although the gearbox doesn't have the correct input shaft diameter) and see what they say.
https://www.aliexpress.com/item/1005001708668098.html

That makes sense for the planetary gearboxes. We may want to go with a worm gearbox just because they are generally rated for higher torques. I found this NMRV-50 worm gearbox   with our required output torque specified from a different source (would need to confirm with aliexpress manufacturer)

I found a NMRV-30 worm gearbox which is smaller, maybe lighter (1.2kg) and seems to fit eh shaft sizes as well. I'll contact them to ask them about their maximum output torque.

Also I just realized that the 65Nm I calculated was with the arm fully extended and realistically we wouldn't be lifting the 5kg like that. If we controlled the elbow to be hanging straight down, our lever arm would then be only the length of the shoulder link (0.46m) giving us a required torque of 32Nm.

I think I mentioned that before multiple times, but it totally slipped my mind when we were discussing the arm torque this time around. And yes, it doesn't make sense to pick up an object of 5kg with an outstretched arm. You wouldn't do it with your own body, and it shouldn't be allowable for the Rover. Mission control pilots will have to keep that in mind when they operate the rover which is a perfectly valid and initiative requirement for the arm pilot when they pilot operates the arm.
So if we only need 32Nm of torque, which is the same as the elbow, we only need that same pulley system for this to work, correct? And keep in mind that the arm's motors can pulse torque above 6Nm for a short duration of time. That could help us get a heavy object into a lower torque position (curl the arm in to reduce the lever arm).

Sounds good. Would it make sense to use gears instead for the shoulder to
avoid potential slippage of the belts?
On Wed, Dec 2, 2020, 5:22 AM Khalil Estell<EMAIL_ADDRESS>wrote:

I think I mentioned that before multiple times, but it totally slipped my
mind when we were discussing the arm torque this time around. And yes, it
doesn't make sense to pick up an object of 5kg with an outstretched arm.
You wouldn't do it with your own body, and it shouldn't be allowable for
the Rover. Mission control pilots will have to keep that in mind when they
operate the rover which is a perfectly valid and initiative requirement for
the arm pilot when they pilot operates the arm.
So if we only need 32Nm of torque, which is the same as the elbow, we only
need that same pulley system for this to work, correct? And keep in mind
that the arm's motors can pulse torque above 6Nm for a short duration of
time. That could help us get a heavy object into a lower torque position
(curl the arm in to reduce the lever arm).
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SJSURoboticsTeam/urc-central-2021/issues/140#issuecomment-737226796,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7AWV3ND7VTKXILMKIH67TSSY5SDANCNFSM4UIN5U6A
.

Would it make sense to use gears instead for the shoulder to avoid potential slippage of the belts?

Honestly I'm not sure. I don't have a lot of experience with belts, but I think that our assumption that the belt will slip is a bit overblown. I'm confident that the belt will stay in place.
Also, if you are worried about the belt slipping for the shoulder at the same torque we expect the shoulder to have to deal with, then we would need to move the elbow to gears as well.

Is there a reason we'd want to use pulleys over gears? The only reason I
can think of is that it is slightly lighter but there are more
possibilities of failure when using a belt vs gears.
On Wed, Dec 2, 2020, 7:23 AM Khalil Estell<EMAIL_ADDRESS>wrote:

Would it make sense to use gears instead for the shoulder to avoid
potential slippage of the belts?
Honestly I'm not sure. I don't have a lot of experience with belts, but I
think that our assumption that the belt will slip is a bit overblown. I'm
confident that the belt will stay in place.
Also, if you are worried about the belt slipping for the shoulder at the
same torque we expect the shoulder to have to deal with, then we would need
to move the elbow to gears as well.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/SJSURoboticsTeam/urc-central-2021/issues/140#issuecomment-737299345,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7AWV2KMAOH6HBMDWUKGVTSSZLV5ANCNFSM4UIN5U6A
.

The purpose of pulleys is that you can place the gear far away from the driving gear location. This is a requirement for drive propulsion. It is also a requirement for elbow. Not 100% a requirement for wrist, but the new point of record (POR) for wrist is to use an offset design where the motors are placed away from the wrist in order to bring the weight closer to the shoulder.
So then it becomes a question of, what can actually use gears rather than a pulley? Well, the only thing I can think of is shoulder. But the neat thing about this 32Nm torque, discovery is that the shoulder and elbow can share the same exact hardware, thus reducing the BOM count further.
Basically it comes down to, do we really need additional hardware for the shoulder when we can just buy more of the same pulleys for shoulder.
Not only that, but we can use the same 15T input pulley gear for drive propulsion as well. Maybe we use a different output pulley gear since we only need 14Nm of torque for the rover as calculated by #73. (FYI: @HaadiElahi @davidbdias96) If we used the 80T pulley we would get ~20RPM of motion (5:333:1 ratio with a top speed of 105RPM), which is really slow. That would mean the top velocity for the rover is 0.34578544 m/s or better yet, it will take 3 seconds to move 1 meter.

That's fair, then the input pulley would be the same for elbow, shoulder, and drive propulsion and then the output pulley would change based on our desired torque.

Correct. And the output pulley would be the same for elbow, shoulder. The output pulley would be different for drive propulsion.
I feel like this is nearly ready for closing. @wilton-lee can you do the following things:

Make a concluding comment on this issue with just the end solution to the problem.
Update the first comment to indicate that the stuff you put there is not the final solution
Update the first comment with a link to the concluding comment stating that this is the approved solution.

Approved Solution: belt system with 5:1 gear ratio (same as elbow)

Required Torque: 32 Nm with optimized shoulder/elbow control

Gear Ratio: 5 to 1

Input Pulley: XL-15T (11mm width, 10mm bore, 4mm keyway)

Output Pulley: XL-80T (11mm width, bore N/A)


Use external snapshotter release branch in e2e pipeline

Signed-off-by: Chris Chien<EMAIL_ADDRESS>https://github.com/longhorn/longhorn/issues/4027
Use external snapshotter release branch instead of master branch to avoid unexpected error

@cchien816 Please backport to 1.2.x and 1.1.x. Thanks.