request has gone into maintenance mode. Maybe replace it.

Dear team,
thanks for your work!
I would like to report that the package request which you are loading has went into maintenance mode https://github.com/request/request/issues/3142
Therefore, yarn is currently giving me:

warning node-sass ><EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
warning node-sass > node-gyp ><EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142

Maybe you find time (and a good replacement) to replace it for your upcoming major release.
Thanks!

That is not a big issue. We could possibly drop the usage of request completely but this could mean some issues for users connecting via proxy.

ftw I used node-fetch

As your message shows, "request" is also used by node-gyp, so removing it here wouldn't remove the transitive dependency or that second warning. Updating node-gyp is something we're not looking at till the next major version because of breaking changes

ftw I used node-fetch

Doing a quick look shows it doesn't have any support for proxies, and wouldn't be a suitable replacement

@nschonni Thanks for a response and a wonderful lib used by me and thousands.
I do think it puts pressure on gyp if they are the only ones not solving it. However, I have no awareness of the effort, so no matter what, thank you for your efforts!

We've looked at this a few times in the past. Previously we've been blocked on backwards compatibility since most request alternatives would require us to drop legacy Node support.
With v5 coming up we're in a position to make this breaking change. I've re-surveyed the http library landscape based the following resources:

https://github.com/request/request/issues/3143
https://www.npmjs.com/package/got#comparison

The most viable alternatives IMHO in order of preference are:

https://github.com/npm/make-fetch-happen
https://github.com/axios/axios

There are some shinier, newer options but most refuse to support proxies out right. For this reason make-fetch-happen is the most appealing as it has robust proxy support as a result of being used within npm itself.

@xzyfer just to throw my two cents in, I don't think backwards compatibility should be a factor whatsoever for a major release when it means keeping deprecated packages. My personal vote would be to remove the dependency completely, and people who rely on legacy node versions (who probably aren't updating a lot of things anyways) can use the older versions. I'd also say proxy support should be added in its own separately maintained package if it causes this much headache in updating the main package to not rely on deprecated packages

Does anyone have a workaround for this?   When I run yarn and it tries to compile node-sass, it throws an error.  I know this is due to the deprecated node-gyp trying to use VS2019 to compile.   I've installed the windows build tools for VS2017 and VS2015 but how do I get it to look there?
gyp ERR! stack Error: spawn C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\15.0\Bin\MSBuild.exe ENOENT gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:264:19) gyp ERR! stack     at onErrorNT (internal/child_process.js:456:16) gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:80:21) gyp ERR! System Windows_NT 10.0.18362 gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\ProjAngular\\SupervisionServices\\node_modules\\devextreme-cli\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library=" gyp ERR! cwd C:\ProjAngular\SupervisionServices\node_modules\devextreme-cli\node_modules\node-sass gyp ERR! node -v v12.13.1 gyp ERR! node-gyp -v v3.8.0 gyp ERR! This is a bug in node-gyp.

@nhustak can you try npm config set msbuild_path "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe" ? See https://github.com/sass/node-sass/pull/2862 and https://github.com/nodejs/node-gyp/issues/1663 for more context

Just got it myself, any update on this or.... ? Thanks

Just got it myself too, any plan to update it? Thank you!

@saper as a solution for proxy you could use standard node API and pass a hook for Agent, so people could easily use proxy-agent.

One more deprecation from request...
npm WARN deprecated<EMAIL_ADDRESS>request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated<EMAIL_ADDRESS>this library is no longer supported

Any progress on this?

AFAIK there is still no alternative with proxy support. If that situation
changes we will happily switch over.
On Fri, 12 Feb 2021, 1:19 pm Alessandro Barbieri<EMAIL_ADDRESS>wrote:

Any progress on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sass/node-sass/issues/2851#issuecomment-777924909,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAENSWGESBH45WLAEHI3WR3S6SF4BANCNFSM4KVWQI3Q
.

@xzyfer what's wrong with make-fetch-happen or axios or a hook for proxy-agent?
I still return to proxy support should be its own separate add-on if it causes this much of a problem in getting rid of deprecated insecure packages for the majority of users

FWIW node-gyp has replaced request with make-fetch-happen

According to https://github.com/sass/node-sass/issues/2851#issuecomment-817684689 and https://github.com/sass/node-sass/issues/2851#issuecomment-586930150 it's obvious that make-fetch-happen is final choice. Can someone please confirm this, to make it clear for some future PR's, eg to prevent unnecessary work, like https://github.com/sass/node-sass/pull/2961

Hi. I need some hit which node-sass version to use. 7.0.3 still depends on outdate request package.


kinematicbody2d doesn´t move over kinematic platform (left and right) when the collision shape is a raycast. it worked on godot 3.3.3

Godot version
3.4 beta
System information
windows/linux
Issue description
I have a 2d platform game. it runs fine in godot 3.3.2 and 3.3.3.
When I run it in 3.4 beta, my player doesn´t move over the platform that moves from side to side.
After lots of testings, I found that the problem if because of the raycast that I use in the player's collision shape.
If I change it to a capsule, it works, but with the raycast it doesn´t move to the left and right.
The player movement is done with move_and_slide.
Steps to reproduce
TestMovingPlat.zip
the attached file contains a tscn with a minimal project with the problem.
Minimal reproduction project
No response

Fixed by #52902.


Add support for fancy pointers to indirect

It's considerably more work to do this for indirect because the code currently traffics in cblock_t*, which probably needs to be std::allocator_traits<allocator_type>::rebind_traits<cblock_t>::pointer instead.


[Bug?]:  doesn't work in mode:async

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
Whenever solid-start's server rendering is in async-mode, <HttpStatusCode does nothing
Expected behavior 🤔
it should be possible to change status of responses using <HttpStatusCode> in async mode
Steps to reproduce 🕹
Steps:

checkout https://github.com/indeyets/solid-start-error and install dependencies
run npm run dev
notice that status is supposed to be be 404: https://github.com/indeyets/solid-start-error/blob/main/src/app.tsx#L23
run curl --HEAD -v 'http://localhost:3000/' (or use browser's developer tools) and see that it still returns 200 OK

Context 🔦
No response
Your environment 🌎
No response

Thanks for reporting. I think we hit this before but forgot to track it. This is likely a Solid core bug but will investigate.

Yeah this is an interesting one. Because I thought the issue was in Solid but it is more that while I can delay cleanup there we still have a problem because we are basing our undo on whether the response has been handled and really it depends on whether its been handled or conceptually we are done rendering. It's possible that we haven't returned the response and it is done rendering in which case we should skip it like this and there are cases where we have responded on the stream and shouldn't clear it even though we aren't done rendering.
Ideally we'd have a generic way to handle this, but for now I think start should mark when it thinks it is done rendering and we check either condition.


More flexible errorhandler

I needed this myself so I went ahead and implemented the error handler system that mimics Flask's (as mentioned in #284 )
Currently this takes precedence over the errors parameter in the Api() constructor

I don't know what the deal is with the failed tests. I think they have something to do with the media_types code path...?

The media_types failures have nothing to do with whatever you did here. Thats caused by a new version of werkzeug which was recently released (see #392).

If you merge from master, your current test failures will be fixed.

Do you prefer I merging from master or rebasing?

Merges are fine with me...

Are there any plans to merge this?

@jasich see the remaining issues in the PR diff

Hi @mtrbean @joshfriend
Any progress on this? I think it would be a significant improvement for FR and #250
Does it just need the comments in the diff addressed?
If @mtrbean isn't working on this anymore, I am inclined to take it over as I need this functionality for some work. Perhaps I can take care of it on Friday or Sunday...

@jo-tham You are welcome to try to pick this up. Any help would be much appreciated :)

+1

Here is a subclass of Api implementing custom error handlers, for people who want this now. Might also help integrating this feature into flask-restful.
https://gist.github.com/danijar/827bee07350a96bbf35b

I'd like to move forward with #544


Updated Russian translation

Added all missed translations (nuggets, mekanism.gui.buffer*, mekanism.pipe., tooltip.freerunner. etc)
Changed some long words to similar short ones to fit GUI (digital miner, item eject mode)
Changed incorrect Personal Chest name and description (long time ago it was correct).

Good work!


change the BrowserStack session name per test

I'd like to set a capability on a remote driver for every test.
Browser stack has a capability 'name' that you can set for each test so you don't get a name like "Session: 3ec58326928f08774a89f949039d87"
Is there a more generic need for this?
cheers
name
Allows the user to specify an identifier for the test run.
Example: logintest
the code I've used in the past to set this is...
        private string GenerateTestName()
        {
            var arr = TestContext.CurrentContext.Test.Name.Replace(")", "").Replace(",null", "").Split('(');
            if (arr.Length > 1)
            {
                return FeatureContext.Current.FeatureInfo.Title + " - " + SplitCamelCase(arr[0]) + " " + arr[1];
            }

            return FeatureContext.Current.FeatureInfo.Title + " - " + String.Join(" ", arr.Select(SplitCamelCase));
        }

I really like this idea. It is something I got working for SauceLabs in a test branch a couple months ago. The way I did it in my test branch was to have a new step where I defined additional driver configuration. The step was something like:
Given I have the following additional remote driver configuration
| Key | Value |
| x      | a       |
| y      | b       |
But, with that step I would need to explicitly say that "Test Name" (or whatever the key was) had a value of "Testing Feature Foo for Scenario Bar" (or whatever the test was). I thought that was kind of hacky, so I didn't carry it forward.
I really like your idea of automatically detecting the test name. I think one complication of this is that different test platforms (BrowserStack, SauceLabs, etc.) might user different configuration key names for their tests. Potentially we could have a special configuration value for the remote driver that specifies where the test name should go: if it is present, then the test name gets added to the remote driver's configuration under the specified configuration key; if it is not present, then it behaves as it does today (no test name is specified, and it defaults to the test platform's autogenerated test names). Does that sound like a fair way to implement it?

Cool idea, I haven't worked with this before, so pardon if this isn't representing the problem correctly. What if we used SpecFlow's attributes (which you can put on a feature or scenario), and then added a pre-scenario step to set this? That should be pretty simple to do overall and we can introduce some flexibility for various platforms there. Thoughts?

@dpiessens that would work, we just need somewhere to hook into to add capabilities before the driver is created. Scenario is right level, I remember there was some option to reuse the driver between scenarios but I doubt that works for remotes anyways.
@NickMcG I forgot this bit of code in case you want to use it
        private string SplitCamelCase(string input)
        {
            return Regex.Replace(input, "(\\B[A-Z])", " $1");
        }


Unable to download VesSAP data from repository

Hello,
I want to download the VesSAP dataset. I'm following the instructions mentioned here, however, I am unable to download the data.
In Filezilla, it fails to connect to the server. I get the following messages:
Status:	Disconnected from server
Status:	Connecting to ftp.isd.med.uni-muenchen.de:4253...
Response:	fzSftp started, protocol_version=11
Command:	open<EMAIL_ADDRESS>4253
Error:	Connection timed out after 20 seconds of inactivity
Error:	Could not connect to server
Status:	Waiting to retry...
Status:	Connecting to ftp.isd.med.uni-muenchen.de:4253...
Response:	fzSftp started, protocol_version=11
Command:	open<EMAIL_ADDRESS>4253
Error:	Connection timed out after 20 seconds of inactivity
Error:	Could not connect to server
I could not find a contact page on the website and hence thought to open the issue here. If this is not the correct place to open the issue, I apologize, and would be grateful if you could give me a relevant contact for this.
Thank you.

Hello, thanks for the feedback, we had to replace the HDD in the FTP server therefore it was down temporarily. Now it is back online (just tested now) and we don't expect this to be a repeating issue. Sorry for the inconvenience and have a nice day!

Thank you so much! It's working for me now :D

Hello! I'm also following the instructions given in this pdf but FileZilla reports connection error. The output messages of FileZilla are as follows:
Status:	Connecting to ftp.isd.med.uni-muenchen.de:4253...
Status:	Using username "ftpagert".
Status:	Access denied
Error:	Authentication failed.
Error:	Critical error: Could not connect to server
I've double checked the Host, Username, Password and Port. I'd be very grateful if you could help.
Thank you.


Marathon should optionally log all configuration values.

Perhaps this could be implemented as an additional --log_config flag.

Seems generally useful, how about making it the default in Chaos?

+1

Motivation: if we ask a customer to use flags --foo and --bar, we need a way to confirm those flags were correctly specified and accepted.

@air  Since it is difficult to implement this completely, is logging command line arguments acceptable for now? Shall we close this?

logging command line arguments

If that captures all the user-specified config, yep good to go.

...and I assume that if any of the flags are incorrectly specified or wrong, the log will show their rejection right?

@air Marathon will not start if it can't recognize all of the flags.

Cool, that seems to resolve that. Thanks @air and @ConnorDoyle !


Custom Renderer

Is it possible to use a custom rendering engine yourself ?

Custom renderer is very simple, many of the examples are custom renderers.


Move icons, debounce from Tekton and Topology plugins to plugin/shared-react

Part of epic: https://github.com/janus-idp/backstage-plugins/issues/580
This mainly affects files for:

icons
debounce

Reference:
https://sonarcloud.io/component_measures?metric=duplicated_lines&view=list&id=janus-idp_backstage-plugins
https://sonarcloud.io/component_measures?metric=duplicated_files&view=list&id=janus-idp_backstage-plugins

Icons were not moved, only debounce. Reopening.
https://github.com/janus-idp/backstage-plugins/blob/main/plugins/topology/src/common/components/icons.tsx
https://github.com/janus-idp/backstage-plugins/blob/main/plugins/tekton/src/components/common/icons.tsx

Logged a ticket https://github.com/janus-idp/backstage-plugins/issues/716 for refactoring icons to use MUI icons based on this converstaion - https://github.com/janus-idp/backstage-plugins/pull/715#discussion_r1317244432.


COMMAND Health checks impossible on busybox/scratch docker containers

COMMAND health checks are not possible to perform on busybox/scratch docker containers when the only content that exists in the container is the service providing statically-compiled binary. The particular docker container I am testing this with is the 'swarm' docker container being run in agent mode. In agent mode no TCP ports or HTTP services are exposed so HTTP/TCP health checks are not an alternative option.
I would also like to request a generic 'heartbeat/ping' health-check feature in cases where there is no other way to determine the health of the container.
In the circumstance that the container becomes unavailable or the hosting node is rebooted, Marathon is unable to determine that the container is no longer available/healthy.
This request was initially discussed with @karlkfi via https://dcos-community.slack.com/archives/general/p1469124050002174

@LinkMJB how would that heartbeat/ping check work if there's no way of contacting the container?
Mesos sends Marathon a TASK_FAILED/TASK_FINISHED update when the container exits. It will also notify Marathon if the agent is disconnected from the Master (sending a TASK_LOST update). Marathon will then wait a configurable amount of time for the task to come back before starting a new task.

Hey @gkleiman, I think the best way to support this would be to remove the hardcoded/implied 'sh -c' prefix to the COMMAND health check, to support statically compiled binary busybox images.

Note: This issue has been migrated to https://jira.mesosphere.com/browse/MARATHON-1794. For more information see https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8.

Note: This issue has been migrated to https://jira.mesosphere.com/browse/MARATHON-1794. For more information see https://groups.google.com/forum/#!topic/marathon-framework/khtvf-ifnp8.


Hashie warning "You are setting a key that conflicts with a built-in method"

Hashie 3.5.5
Grape 0.19.2
To reproduce:
require "grape"

class MyAPI < Grape::API
  params do
    requires :update, type: Boolean
  end
  get "hoge" do
    "update = #{params[:update]}"
  end
end

run MyAPI

Log:
W, [2017-06-06T14:18:35.531821 #46633]  WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#update defined at /Users/val00362/tmp/grapetest/vendor/bundle/ruby/2.3.0/gems/hashie-3.5.5/lib/hashie/mash.rb:209. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.

Hashie::Mash has built-in update method. It's conflicting with my parameter name. Similarly, you would see the warning when you used any of Hashie::Mash's 280+ methods. Is there any workaround about this? Or at least, some caveat to avoid these parameter names should be written in the README.

In 1.0 we're no longer using Hashie::Mash by default, so I think the problem would go away. However this is worth documenting since it's still available. Care to PR?

Thanks for info. To stop using Hashie::Mash sounds like a good idea. However, it would be better to leave fixing the docs to someone else, because I'm not good at writing. English is not my native language...

Try it! We'll correct your English (English is my 3rd language too :))

What are the recommendations to fix this warning message? Tried setting a nil logger but it doesn't seem to fix all cases.
  # config/environments/production.rb
  require "hashie"
  require "hashie/logger"
  Hashie.logger = Logger.new(nil)


[Backport] Add support for streaming ingestion with concurrent replace (#15039)

Backports #15039 to 28.0.0

A few tests are failing due to insufficient code coverage. Is it safe to merge @AmatyaAvadhanula?

Yes, @LakshSingla. The coverage was low originally. More tests will be added soon


[docs] Fix typo in the earliest service mesh versions

Signed-off-by: Pranav Singh<EMAIL_ADDRESS>Description
This PR fixes a typo to display correct service mesh versions on meshery docs
This PR fixes #
Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

🚀 Preview for commit fd73461745a2ca1ff1fbc252210a148b4e9d0de4 at: https://61d9ed10ab867cca0f2766ca--meshery-docs-preview.netlify.app


M32370: Word Missing?

Hello, @meganbradley,
Translator has reported possible source content issue.
Description: Is the object for "standardized" missing? Or should this read "was standardized"? Please advise.
Please review and merge the suggested proposed file change to avoid this error. If you make related fix in another PR, then share your PR number, so we can confirm and close this PR.
Many thanks in advance.

Hello, @meganbradley,
Translator has reported possible source content issue.
Description: Is the object for "standardized" missing? Or should this read "was standardized"? Please advise.
Please review and merge the suggested proposed file change to avoid this error. If you make related fix in another PR, then share your PR number, so we can confirm and close this PR.
Many thanks in advance.

Hello, @meganbradley,
Translator has reported possible source content issue.
Description: Is the object for "standardized" missing? Or should this read "was standardized"? Please advise.
Please review and merge the suggested proposed file change to avoid this error. If you make related fix in another PR, then share your PR number, so we can confirm and close this PR.
Many thanks in advance.
Cc: @jemash

@v-makoud @BillWagner
I made some changes - please review.


Really Bad Lip Sync Results For Use Case 1

Hi,
Thank you for sharing the model and it's great to see the progress made overall.
When testing, I've observed that while the results are somewhat as expected for talking face videos - i.e. use case 2, lip movements of picture - but the results are really bad when generating correct lip motion on a random talking face video - i.e. the Use Case 1 as mentioned in the repository. I am comparing with the results shown in Github or discussed in the paper.
In the results generated for Use Case 1, the lip motion seems almost the same as source video. Basically I'm trying to understand if it's supposed to be like that or not. It appears as if there is nearly no lip-sync at all - the lip movements are almost like those in the source video and not much indicative of words being played in the input audio. If input audio has a pause, the lip movements keep happening if the source video had lip movements.
I'm sharing some examples of the results to get a better idea of the model's capabilities - results are generated using a sample video of Obama and another sample audio of Obama
Here is another example with a different video of Obama and another sample audio of Obama:
To generate the results, I got someone to create a colab notebook and they used Librosa approach. I can share the notebook in case you want to see if some error was made.
Again, really appreciate the model and I feel it represents a great advance in the overall tech, just creating the issue just to see whether the quality of results is what is to be expected from the model or whether it can be improved. Thank you.

Just to save some time of the researchers and to give more details, here is the colab notebook used for inference:
https://we.tl/t-qy4Ho7LqTZ

Closing issue since no comments from researchers.

@abm505 I have faced similar issues while doing for the video, any suggestions?

One of the main limitations of the model is that it is inaccurate for some videos in the wild, especially during silences. This is a known issue in existing talking face models and is being addressed in future work. We will update this issue when the new work is released.

It appears as if there is nearly no lip-sync at all - the lip movements are almost like those in the source video and not much indicative of words being played in the input audio. If input audio has a pause, the lip movements keep happening if the source video had lip movements.

Please switch to this latest improved work: https://github.com/Rudrabha/Wav2Lip


Add four to one hash

This might not be necessary in this repo but I'm trying to do:

proofs on the leaf commitment over (value, r, rho, nullifier)
proofs on the merkle path

And this seems like a good place to test it, but otherwise feel free to reject.

The implementation looks good (also thanks for correcting a typo). I will take a look sometime tonight.

I made a small change. Now, to check if all the elements are constant or not, it does not just check elts[0].cs(), but elts.cs().
elts.cs(), the vectorized version of cs(), is defined here: https://github.com/arkworks-rs/r1cs-std/blob/09f3613aac63ebecfbd26e518a36eb59fe404f5c/src/lib.rs#L95
Basically, it tries to find a CS among all the elements inside the vector. If there is one, it takes that.
So, this subsumes a test that elts[0..4] are all constants.

Now waiting for the CI to pass. Thanks for contributing the code.


Add appearance css property and modifier

I'm going to go ahead and accept this change and tweak the ordering on my end, it's so trivial. Otherwise I think it can be easy to accidentally miss picking up this PR before the next release.


Set rseList for RelVal workflows

Fixes #11541
Status
ready
Description
Always calling  _getValidSites method for RelVal workflows from inside _makeTransferRequest fixes the problem with the Unbound local variable exception for RelVals with input data.
I did test  it by directly patching one of the pods in testbed and the result is: [1], in contrast to what it was before [2]
[1]
2023-04-12 13:38:01,642:INFO:MSTransferor: RelVal workflow '***_TC_PY3_Data_LumiList_Apr2023_Val_Val_230407_165853_5503' ignores sites out of quota
2023-04-12 13:38:01,642:INFO:MSTransferor: Creating rule for workflow ***_TC_PY3_Data_LumiList_Apr2023_Val_Val_230407_165853_5503 with 1 DIDs in container /DoubleMuon/Run2018D-v1/RAW, RSEs: T2_CH_CERN|T1_US_FNAL_Disk, grouping: ALL
2023-04-12 13:38:01,736:WARNING:Rucio: Resolving duplicate rules and separating every DID in a new rule...
2023-04-12 13:38:01,795:WARNING:Rucio: Found duplicate rule for account: wmcore_transferor
, rseExp: T2_CH_CERN|T1_US_FNAL_Disk
dids: [{'scope': 'cms', 'name': '/DoubleMuon/Run2018D-v1/RAW#93e06ee0-b249-4e73-8fe2-040c2b85461c'}]
2023-04-12 13:38:01,815:INFO:MSTransferor: Rules successful created for /DoubleMuon/Run2018D-v1/RAW : ['43802556ae134347b5df53f012bcaf96']
2023-04-12 13:38:01,816:INFO:MSTransferor: Transfer requests successful for ***_TC_PY3_Data_LumiList_Apr2023_Val_Val_230407_165853_5503. Summary: [{'campaignName': 'RelVal_Generic_Campaign',
  'completion': [0.0],
  'dataType': 'primary',
  'dataset': '/DoubleMuon/Run2018D-v1/RAW',
  'transferIDs': ['43802556ae134347b5df53f012bcaf96']}]

[2]
2023-04-12 13:27:51,715:INFO:MSTransferor: Handling data subscriptions for request: *****_TC_PY3_Data_LumiList_Apr2023_Val_Val_230407_165853_5503
2023-04-12 13:27:51,719:ERROR:MSTransferor: 	Error: local variable 'rses' referenced before assignment
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/WMCore/MicroService/MSTransferor/MSTransferor.py", line 214, in execute
    success, transfers = self.makeTransferRequest(wflow, rseList)
  File "/usr/local/lib/python3.8/site-packages/WMCore/MicroService/MSTransferor/MSTransferor.py", line 414, in makeTransferRequest
    if not rses:
UnboundLocalError: local variable 'rses' referenced before assignment

Is it backward compatible (if not, which system it affects?)
YES
Related PRs
None
External dependencies / deployment changes
None

hi @amaltaro,
After changing the commit to just link the rseList in the testbed cluster, I injected a test workflow and here is the result: [1]. So we are good.
[1]
2023-04-12 15:01:07,276:INFO:MSTransferor: Handling data subscriptions for request: ***_TC_PY3_Data_LumiList_Apr2023_Val_230412_145623_3886
2023-04-12 15:01:07,276:INFO:MSTransferor: Creating rule for workflow ***_TC_PY3_Data_LumiList_Apr2023_Val_230412_145623_3886 with 1 DIDs in container /DoubleMuon/Run2018D-v1/RAW, RSEs:
T2_CH_CERN|T1_US_FNAL_Disk, grouping: ALL
2023-04-12 15:01:07,326:WARNING:Rucio: Resolving duplicate rules and separating every DID in a new rule...
2023-04-12 15:01:07,397:WARNING:Rucio: Found duplicate rule for account: wmcore_transferor
, rseExp: T2_CH_CERN|T1_US_FNAL_Disk
dids: [{'scope': 'cms', 'name': '/DoubleMuon/Run2018D-v1/RAW#93e06ee0-b249-4e73-8fe2-040c2b85461c'}]
2023-04-12 15:01:07,433:INFO:MSTransferor: Rules successful created for /DoubleMuon/Run2018D-v1/RAW : ['43802556ae134347b5df53f012bcaf96']
2023-04-12 15:01:07,434:INFO:MSTransferor: Transfer requests successful for ***_TC_PY3_Data_LumiList_Apr2023_Val_230412_145623_3886. Summary: [{'campaignName': 'RelVal_Generic_Campaign',
  'completion': [0.0],
  'dataType': 'primary',
  'dataset': '/DoubleMuon/Run2018D-v1/RAW',
  'transferIDs': ['43802556ae134347b5df53f012bcaf96']}]
2023-04-12 15:01:07,920:INFO:ReqMgrAux: Update in-place: False for transfer doc: ***_TC_PY3_Data_LumiList_Apr2023_Val_230412_145623_3886 was successful.


Fix the linting issues

Fix the following linting issues reported during cloudpak certification
ProductHasNetworkPolicy
AllPodsRunsAsRestricted
NoWildCardPermissionsInResources
OperatorHasCSVs
RBACSpecifiesExplicitSCC
NoForbiddenSCCRBACRules
LicensingAnnotationsDefined
MeteringAnnotationsDefined
ContainerDefinesResources
ContainerHasLivenessProbe
NoPodPrivilegeConflicts
NoPrivilegedContainers
EphemeralStorageLimitsAndRequestsDeclared
PodSecurityContextDefined
NoHostNetwork
https://playbook.cloudpaklab.ibm.com/content-verification-linter/

We can fix some of these. Strike out which are fixed

Consolidating under one issue. Duplicate of #457


Add blog

👨💻 Changes proposed
Closes part of Issue #139
📄 Note to reviewers

Blog section prototype has been added.
When there are more than 5 blogs, pages will be automatically paginated.
CRUD Operations on Blogpost are possible.

However, Blogs section cannot be fully realized because there is no proper authentication system on the website yet.

@ephemeralshay solve merge conflicts

Hi @ephemeralshay, We have added an auth system to the website. You can use it to add/update/filter blogs now.

You can pull this PR as of now, I'll work on it further as time permits.

@KKhushhalR2405 You can pull this PR as of now, I'll work on it further as time permits.

@arpit456jain


Chat command to reselect teams

This probably just needs to invoke the gm_showteam ConCommand.

Resolved via commit f561f7cb583760eb7da0d0f36da1eabc08bed6ab.


Positioning of 'ntv2linuxdriverinterface.h' relative to other includes

I'm building v17.0.1 of the ntv2 library released on March 9th, 2024.
I build the SDK as follows:
cmake -DCMAKE_BUILD_TYPE=RELWITHDEBINFO -DAJA_NTV2_SDK_BUILD_NUMBER=$AJA_NTV_PKG_RELEASE -DAJA_INSTALL_HEADERS=ON -DAJA_INSTALL_SOURCES=OFF -DAJA_INSTALL_MISC=OFF -DAJA_INSTALL_CMAKE=OFF -DAJANTV2_DISABLE_DEMOS=ON -DAJANTV2_DISABLE_TOOLS=ON -DAJANTV2_DISABLE_TESTS=ON -DAJANTV2_DISABLE_PLUGINS=ON ..
make

Subsequently, I use checkinstall to create an internally-distributable .dpkg.  I notice that the location of where the ntv2linuxdriverinterface file is positioned upon install is quirky and is not in line with what I'd expect.
So ntv2card.h makes an include of ntv2linuxdriverinterface.h however, the include doesn't take account of relative locations (nor directory nesting).

I'm not sure if AJA_INSTALL_CMAKE will make things easier, but I don't want cmake to be a forced dependency on other code projects.
This is being built on Ubuntu v22.04.

Hi @zerodefect , letting you know that we are discussing this issue as well as #23 with the team. Should have an update soon.


Stash most recently used extension version

By submitting this pull request, I confirm that my contribution is made under the terms of the WTFPL license.
Problem/Feature
Might be a weirdness of my workflow, but I have a "dev" extension clientId that is distinct from the "prod" extension clientId. The dev version is perpetually local/hosted test v0.0.1 while the prod one goes through the lifecycle and is versioned as usual. By stashing the version ID of each extension that was most recently used it removes these extension context switch pain points:

I'm no longer prompted to re-enter the version of the dev extension since it has no 'active' version according to the API
I don't have to keep changing the version for the prod extension from the currently active version to the the in test/review one

Description of Changes:

Save version in extension config object
~Fix typo with bits product UI~ removed this since I just saw #25

Checklist

[x] I have self-reviewed the changes being requested
[x] I have made comments on pieces of code that may be difficult to understand for other editors
[x] I have updated the documentation (if applicable)
[x] I don't give a F*ck - Do What The F*ck You Want To with my Submission

👍 makes sense!

I tweaked/moved where it "grabs" the version number. But nice idea.
I'd been in two minds over preselecting for "non released" extension
I use a never to release version rather than a whole seperate clientID generally

Yeah, looks like it makes more sense there.
Using a specific never release version is probably a good idea for me to adopt in the future. This weirdness stemmed from needing to put the extension in a twitch dev organization and being too impatient to wait for the ~2 days for them to approve the org so I made a "dev" extension in my "personal" org.


NCEI 2.0 Checker

@lukecampbell @mbiddle-nodc
Adds NCEI 2.0 checks and tests. Still to do is the swath feature type detection and checker for 2.0.

@lukecampbell I just pushed updates for your suggestions.

Ok, I need to test this using the CChecker Web tomorrow

For the check dealing with "Recommended attributes for platform variable" it is still checking the legacy attribute name nodc_code, instead of allowing the new name ncei_code.
Example dataset: https://data.nodc.noaa.gov/thredds/dodsC/testdata/mbiddle/GOLD_STANDARD_NETCDF/2.0/NCEI_point_template_v2.0_2016-06-15_133828.496967.nc.html
Name                             Priority:     Score:Reasoning
--------------------------------------------------------------------------------
Recommended attributes for platform var:2:     2/ 3 : At least one attribute
                                                      should be defined to
                                                      identify the platform:
                                                      nodc_code, wmo_code,
                                                      imo_code, call_sign.

But the platform defines an ncei_code in accordance with NCEI 2.0 checks
	char platform1(maxStrlen64) ;
		platform1:comment = "Data is not actually collected from this platform, this is an example." ;
		platform1:long_name = "cordell bank monitoring station" ;
		platform1:ncei_code = "FIXED PLATFORM, MOORINGS" ;
		platform1:ioos_code = "urn:ioos:station:NCEI:Mooring1" ;

@mbiddle-nodc I have a question about the comment attribute. According to the 2.0 templates, it's recommended, which is a 2-point value on the compliance checker scale. What if there's no useful information to include about the variable?
When I'm making datasets metadata compliant I often find myself just throwing in a comment attribute with complete fluff just to get a perfect score.

Also, let's drop the allowed names for elevation/depth. People are always going to have names that aren't in our list but are still correct.
Right now we restrict the allowed names for height to a (rather small) set. In practice people are going to have probably on the scale of hundreds of different and absolutely ok names for elevation/height/depth/z.
@mbiddle-nodc would you concur?
For example: http://oos.soest.hawaii.edu/thredds/dodsC/pibhmc_bathy_5m_marpi
is flagged for having a bad name for elevation but its elev which is perfectly ok and fairly intuitive as to what it's for. Even if the name's not the standard_name and units make it abundantly clear.
	float elev(lat, lon) ;
		elev:long_name = "elevation" ;
		elev:_FillValue = NaNf ;
		elev:standard_name = "height" ;
		elev:units = "meters" ;
		elev:positive = "up" ;

I'm wondering if the comment attribute should just be ignored. If they have it, great! If not, it's not a problem. Would it be possible to have a note, but not deduct points?

@mbiddle-nodc with regards to the comment attribute, my idea was if it exists, we just check that it's a string and it's not empty, and award points for for those if it exists otherwise we don't check anything so it's a 0/0 check.

Ok, other than those three things, it's great and functions exactly how I imagined it would. I just tested it on a rather wide range of data using the IOOS catalog and I agree with all the corrective actions it recommends.

comment attribute check sounds good to me.
As for the allowed names for the elevation/depth variable, I don't think it should be checking for the name of the variable in the first place, unless I'm misunderstanding.  My guidance has been, call the variable whatever your like (1, 2, 3, x, y, z, joe, smith, etc) just let the attributes describe the contents.

Ok we're all on the same page then.

@lukecampbell I made the 3 updates: ncei_code check for v2.0 platform vars, only check comment if it exists, and remove the check on elevation variable name


Disable xattrs if layer has no xattrs or opaque directories

Issue #, if available:
Description of changes:
This is a rebase + update to #718
Original change
The original insight is that GetXAttr and ListXAttr are the most expensive FUSE operations, accounting for significant SOCI overhead in some use cases, but most layers don't actually contain any xattrs. If we can disable xattrs in these cases, then we can get better runtime performance with SOCI.
Since image layers are immutable, if the layer tarball doesn't contain any xattrs, then we can disable xattrs for the FUSE mount and the kernel will stop issuing the calls to the snapshotter.
Updates
Fix for opaque directories
The original insight is mostly correct, but it doesn't handle OveralyFS opaque directories. To delete a file in OverlayFS, you can either create a whiteout file in a high layer (.wh.$ORIGINAL_FILE_NAME) or you can implicitly delete all files in a directory by returning an opaque xattr (trusted.overlay.opaque=y). The image spec encodes opaque xattrs into the layer as a special file ($DIR/.wh..wh..opq) instead of directly putting the xattr into the tarball, and the snapshotter translates that back into an xattr at runtime. With the original change xattrs would be disabled so the opaque file wouldn't be converted back into an xattr which means that the files would be visible.
This change updates the logic for determining whether to disable xattrs to include checking  for opaque directories
--xattr-optimization -> --optimizations xattr
Following a suggestion on the original PR, I renamed the flag to --optimizations so that we can experiment with optimizations in the future. I'm on the fence on whether there should be a concept of "experimental optimizations" and "stable optimizations". I can also imagine that this xattrs optimization eventually just becomes on-by-default and disappears from the CLI entirely. Thoughts on this are welcome.
Everything is now "Disable Xattrs"
In the original PR, the discussions were back and forth on whether we should use variations of "Has xattrs", "No xattrs", or "Disable Xattrs". Since now it also includes whether the layer has whiteouts, I opted to stick to "Disable Xattrs" everywhere since it's not directly related to whether xattrs exist in the layer, but whether xattrs should be enabled for OverlayFS. This also has the nice property that the default false ignores the optimization as pointed out in the original PR.
Testing performed:
make check && make test && make integration

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Did some analysis on this and wanted to report my findings:
TL;DR is that this seems to deliver some very promising performance increases.
The images were tested by first starting up the SOCI snapshotter, waiting 15 seconds, pulling and running the container, then exiting 40 seconds after initially starting up the snapshotter, then waiting another 15 seconds before killing the process.
The prometheus metrics pictures are slightly edited just to show the exact values at each time frame, instead of having to send 4 separate pictures.
The first image that I tested was an alpine image with the fio package, which makes many kernel calls. The layer itself only has two lazy-loaded layers. One had xattrs while the other didnt.
Prometheus metrics (first one before change, second one after change)

Flamegraphs (first one before change, second one after change)

We can see that in the prometheus metrics, total CPU usage was cut by over 33%. In the FlameGraphs, we can see the server loop uses also has over 33% less CPU usage.
The other test was run with a rabbitmq image. Same was applied. This one had three lazy-loaded layers, and none had xattrs.
Prometheus metrics (first one before change, second one after change)

Flamegraphs (first one before change, second one after change)

Here we see total CPU usage down by about 45% in the Flamegraphs, and nearly 50% in the Prometheus metrics.

One final note (for another PR, not this one) — I think that this should be default behavior. As I mentioned above, I don't see a use case where this degrades performance, but also would like to have this structure in place for future experimental optimizations we decide to implement.
For DisableXAttrs, we should probably add a flag/config value to enable/disable this behavior during runtime, as well as log whenever DisableXAttrs is enabled for each layer. This is to ensure we have visibility on whether or not this functionality is enabled.
Unsure if I should open a new PR or just ship this and add this as a followup, though.


OSLCompiler : Check for write errors

Description
This fixes #1352 by checking for write errors after writing the .oso file. Without it, empty files could be written without error after running out of disk space.
Tests
I have not added any new tests, although in #1352 I did provide an example script to demonstrate the problem. I've been unable to find a way of simulating an empty disk without requiring root privilege, which I presume makes it unsuitable as a test.
Checklist:

[x] I have read the contribution guidelines.
[x] I have previously submitted a Contributor License Agreement.
[ ] I have updated the documentation, if applicable.
[ ] I have ensured that the change is tested somewhere in the testsuite (adding new test cases if necessary).
[x] My code follows the prevailing code style of this project.

Not sure what went wrong with the CLA the first time - it had been signed and I'd even received confirmation emails that I'd been added to the approved list. We started again from scratch with a new organisation and it appears to have worked this time.


Rename "Experiment" namespace

All namespaces in Ruby are global.
Current implementation uses global Experiment namespace.
Because Experiment is a common word there's quite a high chance of collision when integrating into existing application.
Additionally it's common convention to match gem name with the implemented namespace.
That's why I suggest renaming the namespace to AmplitudeExperiment.
If you agree with that I can help with the implementation and prepare a PR.
Summary
Rename Experiment namespace to AmplitudeExperiment.
Motivations

avoid namespace collision
follow conventions

Hi @gogiel That makes sense. I will update the namespace soon.

Hi @gogiel The namespace change is already made and released in v1.0.0.beta.5. Feel free to upgrade and let us know if there is any other concern. Thanks for your suggestion!


Add At the speed of light x I am steve by Super Kek

Song Name
At the speed of light x I am steve
Artist Name
Super Kek
Source
Youtube
Youtube Link
https://youtu.be/w23rJDVFOIA
Direct File Link
No response
Song ID
467339
Start Offset [ms]
0
Extra
Created from Auto Nong.
Created for level: 42584142
Downloaded: No

Don't question it


readme: badge logo broken

It would make sense to include the official logo in the repo and link to that location instead.
I want to mention that the "twitter" social badge is only shown on chrome to me.
On Firefox (see pic) it's just not there.

I fixed the logo.
I can't reproduce the Firefox issue with the Twitter badge. It does seem to load slower than the other badges. Maybe a transient issue? If you refresh, does it appear?

No, reloading doesn't change anything.
uBlock Origin seems to block it. Even though it is no official (tracking) badge from twitter...

Right, nothing would be tracked unless the user clicks. Worth reporting to them?

Using the logger, the list Fanboy’s Annoyance List is triggering on https://twitter.com/intent/follow?.
One would have to report at their forums, which I'm not registered with: https://forums.lanik.us/

Okay, will close this then, since it's not a problem with Shields.


Question to Texture class

I have looked into the source code of the Texture class and found something, i couldnt explain to myself: in the base constructor of the Texture the load(TextureData) method gets called. In this method the current texture is being bound. Then the wrap & filter is being set. And in both methods the texture will be bound again. Then after the texture is loaded, at the end of the load() method, the current texture is unbound again.
My question is: Is it really necessary to call the bind() method 4 times only to load a texture? And why is it unbound again? In my project, i load the textures once at startup in there own texture units. And to do that, the bind method is being called 5 times per texture.

https://github.com/libgdx/libgdx/wiki/Issue-Tracker


Wrap wasmer_instance in box

Kudos to @reuvenpo for this idea to solve #245
Closes #306. This supersedes #306, with two differences

It can be used on master, no matter if we use #245 or not. This reduces the diff.
It only uses one heap allocation for the entire lifetime of the wasmer instance

Marked as WIP to keep this out of the 0.8.0 release. But we can merge it soon after that into master.

Do we really need this in now? It doesn't have any benefit to it, unless we're also doing all the other things from #245. I guess it just sets the groundwork so any changes in the future are mindful of this, until we actually implement #245?

We don't need this at all. But it also does should not hurt.
The motivation is to keep the diff of #245 small and maintainable. The current branch is already horribly outdated and hard to update.


gender - English for developers - 3rd chapter, Task 41 - he/she they?

Describe the Issue
The course currently only supports binary gender, he and she, they is excluded.
Affected Page
https://www.freecodecamp.org/learn/a2-english-for-developers/learn-conversation-starters-in-the-break-room/task-41
Steps to Reproduce
-Advance to 3rd chapter, task 41
-oberserve the text
all platforms, all fw
Recommended fix or suggestions
Please make this course more inclusive, with something like:
What do/does (he/she/they) look like?
Screenshots

The string "What is (he/she) like?" also appears in Task 42.

"they" is taught in task 43.
Even if it is discussed in task43,  it can still be used in respective string from Task 41 onwards.

I have updated the issue as asked . Please review it .

Hi there,
Thanks for creating this pull request.
The linked issue has not been triaged yet, and a solution has not been agreed upon. Once the issue is open for contribution, you are welcome to update this pull request to reflect the issue consensus. Until the issue is open for contribution, we will not be able to review your pull request.

Hi there,
Thanks for your interest in contributing.
This issue has not been triaged yet, and a solution has not been agreed upon. Once the issue is open for contribution, you are welcome to create a pull request to reflect the issue consensus. Please also note that we typically do not assign issues. Instead, we accept the first pull request that comprehensively solves the issue.

Hmmmmmm,
While I am always advocating for inclusivity, in this case it may not make sense. Specifically because in English, even when using the singular "they", plural verb conjugations are used.
"What does (he/she) look like?" -> "What do they look like?"
"What is (he/she) like?" -> "What are they like?"

I have made the changes as @naomi-lgbt said .

Open for Contribution
The following tasks need to be updated with these texts.
Task 41
`To look like` is used to describe someone's or something's appearance, often implying a comparison.

When you're curious about someone's physical characteristics, such as their hair color, height, or overall look, you might use expressions like:

`What does (he/she) look like?` or `What do they look like?

The choice between these depends on the number and gender of the person you're asking about. Use `does` with singular pronouns `(he, she)` when referring to one person and `do` with `they` when referring to someone whose gender might not be known or if referring to people in a non-binary or plural sense.

**Note:** Remember that questions about a person's appearance can be sensitive. Some people may not feel comfortable discussing physical traits, and it's important to respect their feelings. Always use this question politely and in the right context, where it is appropriate to do so.

Task 42
When you want to know about someone's character or personality, you can ask, `What is (he/she) like?` or `What are they like?`.

This question is about the qualities of a person, not about their physical appearance. Example:

Imagine you meet a new student in your programming class and you want to know more about her. You can ask a classmate `What is she like?`.

You are not asking if the new student likes computers or games; you are asking about her personality. Maybe she's friendly, smart, or really good at coding.


[Windows] Add more compatible VS2022 VC components

Description
Add some additional VC components in order to fix some user's builds.
Related issue:
https://github.com/actions/runner-images/issues/9873
https://github.com/actions/runner-images/issues/9701
Check list

[x] Related issue / work item is attached
[ ] Tests are written (if applicable)
[ ] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run windows2019,windows2022


Update #163 - Dependencies.md

Add link to issue #1012

[ ] Have you signed the Contributor License Agreement?
[ ] Are you working against an Issue?

Microsoft Reviewers: Open in CodeFlow

Hi, sorry but I'll close this PR and make the update to the #163 specs file in the same PR that adds specs for the show dependencies feature. Sorry for all the noise


Building error in Mac OS Majave

I have a issue to compiling croaring-sys v0.3.7 in MacBook pro (OS Mojave) when I tried to install grin (https://github.com/mimblewimble/grin/blob/master/doc/build.md)
Error massage as below
Compiling grin v0.5.0 (/Users/USERNAME/grin)
Running `/Users/USERNAME/grin/target/debug/build/grin-c26cf48a5
error: failed to run custom build command for croaring-sys v0.3.7
process didn't exit successfully: /Users/USERNAME/grin/target/debug/build/croaring-sys-5cd7dcd423b72406/build-script-build (exit code: 101)
Versions of Clang, llvm, rusct is as below:
clang --version
Apple LLVM version 10.0.0 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
llvm-gcc --version
Apple LLVM version 10.0.0 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
rustc --version
rustc 1.31.1 (b6c32da9b 2018-12-18)
Does anybody has a good idea to solve this?
Thanks in advance!


deprecation warning messages link may happen broken

postcss-cssnext-warn-for-deprecations makes following warning message.

You are using @apply rule and custom property sets.
This feature won't be included in the next major release of postcss-cssnext.
This most likely won't get any more support from browser vendors as the spec is yet considered deprecated and alternative solutions are being discussed.
Read more about the reason here https://github.com/pascalduez/postcss-apply.

https://github.com/pascalduez/postcss-apply. has trailing period (full point), so this may break some console / terminal software link feature.
They have a feature that when they found link like text, it makes hyperlink by shift key.

https://github.com/pascalduez/postcss-apply ... Okay
https://github.com/pascalduez/postcss-apply. ... Not Good

In my environment, iTerm2 (macOS) and xterm (Linux) occurs just this pattern.

postcss-cssnext has been deprecated in favor or postcss-preset-env. Read more at https://moox.io/blog/deprecating-cssnext/


sync cherry-picked commit from main to release-2023b branch

sync cherry-picked commit from main to release-2023b branch
Cherry-picked commits:

https://github.com/red-hat-data-services/notebooks/commit/c9c35a43ee796c426fb5f54112bb84d187e6af9c
https://github.com/red-hat-data-services/notebooks/commit/48d469242f4314be5e303868e47690812435d793
https://github.com/red-hat-data-services/notebooks/commit/618e17c65917995ee291204ad38f0e7bee9da5b9
https://github.com/red-hat-data-services/notebooks/commit/f5e99b62004b77dd61e7b26980eaaf5552febab1

Merging this to proceed further with sync.


Investigate HTTP/2 behavior for RequestAborted and Abort

For Http/1.x RequestAborted is used to detect early disconnects and Abort is used to force them.
For HTTP/2 requests can be multiplexed over a single connection and it's possible to terminate individual requests while leaving the connection active. Investigate how Http.Sys surfaces this behavior and if RequestAborted and Abort can be adapted accordingly. We may also need to introduce a lower level connection Abort API to kill the underlying connection (if Http.Sys allows that).
Mirror of https://github.com/aspnet/IISIntegration/issues/753

Thanks for your feedback. We appreciate your letting us know about the problem you've encountered or suggestion but we are not planning to take further action on this issue because our focus has been on issues with significantly higher customer interest and issues impacting a broad number of customers.


You cannot use attributeBindings on a tag-less component

I've just migrated my application to ember.js 2.8 and it started throwing error in the console.
Uncaught Error: Assertion Failed: You cannot use attributeBindings on a tag-less component: <yyyyyy@component:xxxxx::ember382>
Due to this error, the app doesn't load and shows an empty page.
I've created a small demo app with just ember-hammertime and a tagless component and it still throws the same error: https://github.com/thagul/hammertime-2-8
To verify just run the app and check the console.

@chancancode I think this is something you need to know about.  The TL;DR here is that ember-hammertime reopens Component to add this binding here: https://github.com/runspired/ember-hammertime/blob/develop/addon/mixins/touch-action.js#L31
I'll update this to no-op on a tagless component, but is there a better pattern for this?  For hammertime to properly work it needs to be able to do this for all components that define click and have a valid tagName.

I think your existing AST transform is on the right track. This could be a compile time thing only, and for the rarer case where people want to dynamically change their touch action styling, you can give them an explicit mixin.
Once we have glimmer components and element modifier, you could just handle all the dynamic cases with an element modifier that goes right in the template.

Resolved by the release of 1.1.0

I'm still having the same error with latest v1.1.1 release.
I've updated the demo app at https://github.com/thagul/hammertime-2-8 with the latest version of ember-hammertime if it can help.
Thanks

confirmed - regression - for reference - the functionality just went through 3 iterations

https://github.com/runspired/ember-hammertime/commit/d061986d20c2e1bc34aca3c7a4373a25ff095067

https://github.com/runspired/ember-hammertime/commit/cded5afcbc8bab7a0d8ca5d533eda73e8a0789bf

https://github.com/runspired/ember-hammertime/commit/6275bec1678a5054b10dc4b812427bb080838b04

Haven't read the last, the 2nd tries to not replace attributeBindings, but given the file is a mixin and concatenated properties are meant to extend their parent class's array at each level of inheritance that shouldn't have been an issue (but maybe was, dunno)
Likely then its #3 that may be breaking it, but anyone is free to step in in the meantime (hopefully the info above helps a bit)

If either of you have time to dig in I can get a patch release out quick, I won't have time to do any investigating for a few days.

@runspired would you mind doing a patch release with this fix please? 😄

@rwwagner90 one was, it didnt fix it, we're close to having a fix in place that does.

Is there a fix planned for this?


Index Out of Range Error in tokenization using TF Hub for Pretrained Albert Models

I am getting Index out of Range error in tokenization.py when running a finetune Albert large model with TF Hub. I printed out the vocab file and printing out the token before the error. You can see the error and print-outs below.
Vocab File: b'/tmp/tfhub_modules/c88f9d4ac7469966b2fab3b577a8031ae23e125a/assets/30k-clean.model'
Token:

Traceback (most recent call last):
  File "/home/[user]/anaconda3/envs/tf-gpu/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/[user]/anaconda3/envs/tf-gpu/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/[user]/Documents/ml-tests/falling-albert/albert/run_classifier_with_tfhub.py", line 318, in <module>
    tf.compat.v1.app.run()
  File "/home/[user]/anaconda3/envs/tf-gpu/lib/python3.7/site-packages/tensorflow_core/python/platform/app.py", line 40, in run
    _run(main=main, argv=argv, flags_parser=_parse_flags_tolerate_undef)
  File "/home/[user]/anaconda3/envs/tf-gpu/lib/python3.7/site-packages/absl/app.py", line 299, in run
    _run_main(main, args)
  File "/home/[user]/anaconda3/envs/tf-gpu/lib/python3.7/site-packages/absl/app.py", line 250, in _run_main
    sys.exit(main(argv))
  File "/home/[user]/Documents/ml-tests/falling-albert/albert/run_classifier_with_tfhub.py", line 185, in main
    tokenizer = create_tokenizer_from_hub_module(FLAGS.albert_hub_module_handle)
  File "/home/[user]/Documents/ml-tests/falling-albert/albert/run_classifier_with_tfhub.py", line 161, in create_tokenizer_from_hub_module
    spm_model_file=FLAGS.spm_model_file)
  File "/home/[user]/Documents/ml-tests/falling-albert/albert/tokenization.py", line 249, in __init__
    self.vocab = load_vocab(vocab_file)
  File "/home/[user]/Documents/ml-tests/falling-albert/albert/tokenization.py", line 203, in load_vocab
    token = token.strip().split()[0]
IndexError: list index out of range

Albert Finetune Shell Script
#!/bin/bash
pip install -r albert/requirements.txt
python -m albert.run_classifier_with_tfhub \
--albert_hub_module_handle=https://tfhub.dev/google/albert_xlarge/1 \
--task_name=cola \
--do_train=true \
--do_eval=true  \
--data_dir=./data-to-albert \
--max_seq_length=128  \
--train_batch_size=32  \
--learning_rate=2e-05 \
--num_train_epochs=3.0  \
--output_dir=./checkpoints/test

I am getting the same errors on all the available TF hub models.

Seems like this happens because of '\n' lines in vocab file, similar case described here. But it is not clear how to handle this, maybe the files are corrupted?

I'm not sure what the python script is doing but the vocabulary is not simply a text file. It's a SentencePiece model file (which is basically a protobuf-serialized file) and must be deserialized using either protobuf directly or the SentencePiece python API.

'30k-clean.model' is 'spm_model_file', not 'vocab_file'.
The code changes are:
diff --git a/albert/run_classifier_with_tfhub.py b/albert/run_classifier_with_tfhub.py
index 92fef74..26f4339 100644
--- a/albert/run_classifier_with_tfhub.py
+++ b/albert/run_classifier_with_tfhub.py
@@ -156,6 +156,7 @@ def create_tokenizer_from_hub_module(albert_hub_module_handle):
     with tf.Session() as sess:
       vocab_file, do_lower_case = sess.run([tokenization_info["vocab_file"],
                                             tokenization_info["do_lower_case"]])
+    FLAGS.spm_model_file = vocab_file
   return tokenization.FullTokenizer(
       vocab_file=vocab_file, do_lower_case=do_lower_case,
       spm_model_file=FLAGS.spm_model_file)

Thanks @eaplatanios @KodairaTomonori .
I have resolved Index out of Range error but I got another error like blow.
LookupError: No gradient defined for operation 'module_apply_tokens/bert/encoder/transformer/group_0_23/layer_23/inner_group_0/LayerNorm_1/batchnorm/add_1' (op type: AddV2)

Do you have any ideas? Thanks!

Upgrade your tensorflow to at least 1.15.

Thanks @eaplatanios @KodairaTomonori .
I have resolved Index out of Range error but I got another error like below.
LookupError: No gradient defined for operation 'module_apply_tokens/bert/encoder/transformer/group_0_23/layer_23/inner_group_0/LayerNorm_1/batchnorm/add_1' (op type: AddV2)

Do you have any ideas? Thanks!

@YujiOshima Hi, I am still facing the same issue, can you help me with how did you resolve the issue?

This is what I am executing, I tried to enter the task_name as stsb,
python run_classifier.py  --data_dir /home/chirag/git/albert_pytorch/albert_english_pytorch/dataset/sts-b/train.tsv  --model_type sts-b_output  --model_name_or_path https://tfhub.dev/google/albert_xlarge/2  --task_name stsb --output_dir /home/chirag/git/albert_pytorch/albert_english_pytorch/outputs  --spm_model_file /home/chirag/git/albert_pytorch/albert_english_pytorch/prev_trained_model/albert_base_v2/30k-clean.model
I am getting the following ValueError message

Traceback (most recent call last):
  File "run_classifier.py", line 465, in <module>
    main()
  File "run_classifier.py", line 386, in main
    raise ValueError("Task not found: %s" % (args.task_name))
ValueError: Task not found: stsb

Any idea? Thanks

Thanks @eaplatanios @KodairaTomonori .
I have resolved Index out of Range error but I got another error like below.
LookupError: No gradient defined for operation 'module_apply_tokens/bert/encoder/transformer/group_0_23/layer_23/inner_group_0/LayerNorm_1/batchnorm/add_1' (op type: AddV2)

Do you have any ideas? Thanks!

@YujiOshima Hi, I am still facing the same issue, can you help me with how did you resolve the issue?

For version one you, if you use the latest tensorflow 1 it'll fix both problems. However, I have not found a sensible solution for version 2 yet.

Upgrade your tensorflow to at least 1.15.

I am using 1.15 but seeing the same issue, I am keep reading the thread...
$ python -c 'import tensorflow as tf; print(tf.__version__)'
1.15.0


BUG-75209 OpenStack credential validation scaffolding

BUG-75209 openstack credential validation + tests

Are you sure master is the right branch to merge?

Can this be merged @mhmxs ?


Bob is not working with pgx array types

Hi, I was trying to use bob with pgx. When I try to fetch items from QueryContext it gave me this error
pq: unable to parse array; expected '{' at offset 0

I believe this is a problem with scanner. Please take a look.
type BobExecutor interface {
	QueryContext(ctx context.Context, query string, args ...any) (scan.Rows, error)
	ExecContext(context.Context, string, ...any) (sql.Result, error)
}

type PGXPool interface {
	Begin(ctx context.Context) (pgx.Tx, error)
	Exec(ctx context.Context, sql string, arguments ...any) (pgconn.CommandTag, error)
	Query(ctx context.Context, sql string, args ...interface{}) (pgx.Rows, error)
	SendBatch(ctx context.Context, b *pgx.Batch) pgx.BatchResults
}

type BobExecutorPgx struct {
	pool PGXPool
}

type rows struct {
	pgx.Rows
}

func (r rows) Close() error {
	r.Rows.Close()
	return nil
}

func (r rows) Columns() ([]string, error) {
	fields := r.FieldDescriptions()
	cols := make([]string, len(fields))

	for i, field := range fields {
		cols[i] = field.Name
	}

	return cols, nil
}

func (v *BobExecutorPgx) QueryContext(ctx context.Context, query string, args ...any) (scan.Rows, error) {
	r, err := v.pool.Query(ctx, query, args...)
	if err != nil {
		return nil, err
	}

	return rows{r}, nil
}

func (v *BobExecutorPgx) ExecContext(ctx context.Context, query string, args ...any) (sql.Result, error) {
	tag, err := v.pool.Exec(ctx, query, args...)
	if err != nil {
		return nil, err
	}

	return driver.RowsAffected(tag.RowsAffected()), err
}

My immediate guess is that this is happening because the array types in pgx do not implement sql.Scanner.
If using github.com/stephenafamo/scan directly, it is possible to add the custom pgx types using WithScannableTypes. However, the code generated by Bob does not account for this.

I believe this will be fixed soon.
Ref:
https://github.com/golang/go/issues/67546
https://github.com/jackc/pgx/pull/2029
https://github.com/jackc/pgx/issues/1779

That would make a lot of things simpler 👍🏾


Ast typegen

NB: macro-free for the moment (self-rust-tokenize was not happy).
Problematic types so far:

[x]  WithComment. Presumably because of the manual serde derives, tsify isn't picking up on it.
[x]  PropertyKey - uses associated types, will need overriding, or an Omit typedef.
[x]  ArrayDestructuringField - associated types, fortunately just the one variant.
[x]  ObjectDestructuringField - associated types, ditto.
[x]  Marker - custom typescript section not taking effect
[x] ClassDeclaration - custom typescript section not taking effect.
[x] PublicOrPrivate
[x] Private
[x] AlwaysPublic

In general, everything that uses an associated type needs a bit of adjustment.

Awesome, looking good!
Don't have to worry about Marker its equivalent to a u16 or whatever, the type bounds are just for some tricks, it doesn't have any properties.
With WithComment I think I manually made serde just serialize the inner. So it's type should be just equivalent to T.
Got a bit panicked at the diff count but realised most of it is src/js-cli-and-library/package-lock.json 😄
Did you manage to get to macro_rules_attribute working?
I wonder why tsify doesn't work well with associate generics? I would think it could do where T:A: Tsify and T:A.tsify() etc?

Yeah, the Marker, WithComment and ClassDeclaration ones were the oddest thing - no matter what I did, debug builds would not pick up on typescript custom section produced in either of those three files, but release builds did :thinking: .
:stuck_out_tongue: well, the file count is still a little alarming.
re macro_rules_attribute, I think I'll get the wasm_bindings types fixed up then backtrack to swapping out the simpler ones (especially now I have a type-error free benchmark to compare against). I'm circumspect re how simple the SelfRustTokenize usage will have to be for the macro to work, but we'll see.

I wonder why tsify doesn't work well with associate generics? I would think it could do where T:A: Tsify and T:A.tsify() etc?

Mm, it would have to do some kind of de-genericizing to achieve it, so for something like:
struct Foo<T: KindTrait> {
   pub baz: T,
   pub bar: T::VariableType
}

struct Foobar {
  pub inner: u32
}
impl KindTrait for Foobar {
  type VariableType = u32;
}
fn main() {
  let outer: Foo<Foobar> = Foo { baz: Foobar { inner: 0 }, bar: 0 };
}

because you can't fully express the trait (especially the associated type) in TS, the closest you could get is:
type Foo<T, T_VariableType> = {
  baz: T;
  bar: T_VariableType;
}
type Foobar = {
  inner: number;
}
// impossible to encapsulate within the parent type
type Foobar_VariableType = number;
let instance: Foo<Foobar, Foobar_VariableType> = {
  baz: { inner: 0 },
  bar: 0
};

The current approaches (tsify, ts-rs, typeshare, probably bridge.rs too) usually do either of:
a. Notice it's inexpressible without cascading associate expansion, and panic.
b. Accidentally strip the parent (so instances of T::VariableType convert to VariableType), failing to hoist the associated type :unamused:.
We're quite fortunate that it's only FunctionBase and PropertyKey (with ~6 variants for FunctionBase, 2 trivially overridden variants for PropertyKey).

One thing - is there a combination of flags/params/methods that works for .d.ts files, or is that automatic?
I've played around a bit with running ezno on the generated typedefs - ignoring the export function complaints, there's a few that have me puzzled (e.g. type Foo = | number |string is, while ugly, fairly common).
For the meantime, I've added a quick tsc call to the wasm part of the CI.

:| it looks like the fuzz CI jobs have run afoul of the stdsimd issue that's crept into a number of dependencies (this one's in ahash) as of nightly 1.78.0 (released yesterday :sob: ). I could get them to sort of run locally (well, with SIGSEGVs on the main branch :-/), post updating to that nightly, you get the unknown feature 'stdsimd' error.

Awesome! Don't worry about fuzzing (those tests were broken already and will hopefully be fixed in #111).
In the Rust->extras workflow is it possible to use the debug profile to build? The --release flag is a bit overkill and slows down the CI time (it only needs to test, not using this build for benchmarks).
I am assuming the "can't find type Span" issue in extras is because https://github.com/kaleidawave/source-map/pull/3 needs merging and releasing first?

I've played around a bit with running ezno on the generated typedefs - ignoring the export function complaints, there's a few that have me puzzled (e.g. type Foo = | number |string is, while ugly, fairly common).

Interesting! Did it crash at all (could you put the output in a gist)? I think at the moment because promises and most of the standard library isn't there (e.g. WebAssembly.Module) it won't be correct at all. There are also some issues around multiple .d.ts files when involving the standard library. So perfectly fine to use TSC for now.

Everything else looks great. I am a bit busy at the moment but at the end of the week will merge and release the source map PR and then I will update this. I think this repo will get an release next week so these type definitions will be included 🎉

Interesting! Did it crash at all (could you put the output in a gist)?

Yep, I chipped away at the output until it parsed completely and came up with ~3-4 areas that throw parse errors. Here's the gist: https://gist.github.com/H-Plus-Time/fef7b91f2742fc0aed3dc6722756bb22
Re the release build - yeah, this one's necessary to avoid the loss of Marker, WithComment and ClassDeclaration in the debug build (there's something about the files those three are in, or how they're used in the parser crate that makes them vanish in debug, but reappear in release). Agreed it's not great that it slows down CI, though I'm still at a loss as to how the debug build drops those macro outputs (and only for those structs/enums).

Ah interesting. I didn't know arhat was valid TS syntax. Will have to fix that.
Have just updated the source-map crate. Will have a look at the PR later, update versions and merge.

So I decided to include the manual definitions in lib.rs (it is definitely something weird with the comments and other files, as the custom_typescript_definition didn't work in there when I tested locally). (I should try to figure out a minimum repro to file somewhere). And it was working locally 🎉 and checked with TSC. And now it is broken in CI saying there is a definition is duplicated, which means it was generated? 🥴🥴🥴, I have no idea

I should also try figure out the clash you mentioned (I wrote those macros, so I might be able to figure out if I go back down the cargo-expand rabbit hole again)

I renamed the derive bundle as I saw the comment 👍! Unfortunately I can't call it ASTNode as it clashes with the trait :( so derive_ASTNode it is.
clippy and rustfmt are also broken as it seems there was a new Rust release last week!

I will fix and merge when my patience has regenerated 😅 I am excited to get this in the next release!

Had an idea of how Tsify could support ADTs / the TS it could generate
interface PropertyKeyAssociatedTypes extends Record<any, any> {}

interface PropertyKey_<T extends keyof PropertyKeyAssociatedTypes> {
    name: PropertyKeyAssociatedTypes[T]["name"]
}

// Example 1 of what could be generated for a impl with ADTs
declare const x: unique symbol;
type PropertyKeyWithX = PropertyKey_<typeof x>;
// Override
interface PropertyKeyAssociatedTypes {
    [x]: { name:string }
}

// Another example
declare const y: unique symbol;
type PropertyKeyWithY = PropertyKey_<typeof y>;
// Override
interface PropertyKeyAssociatedTypes {
    [y]: { name: undefined }
}

type Example1 = PropertyKeyWithX["name"]
type Example2 = PropertyKeyWithY["name"]

Ah, thanks for the mass-rename, and the fix for the macro incompat (it was seriously just invocation order? I really should have checked that).

possibly caused because all are generic

You know, that might actually be it - I hadn't thought to check for similar files with only generics (just ones that had at least one generic, explicit serialize impl).

Yeah I was trying it and looks like order has an effect. It should technically work, so must be a bug/edge-case in Rust macro expansion. That apply macro is really useful, thanks for showing me that! Wish I knew about it when I was added serde support and things!

This is strange, somehow the Marker and ClassDeclaration issue is fixed on the remote/CI (I don't think I touched anything to fix it) but I still get it locally (on my Windows machine, latest Rust (same as CI, should be the same dependencies). Maybe a cache issue? Still on both remote and my machine WithComment is missing on debug? I have added this temp fix in for debug builds:
https://github.com/h-plus-time/ezno/blob/cb6a4d27aa0100b5d76294e674c4efcbf31ca609/parser/src/lib.rs#L269-L294
I assume it is still the case from your previous comment and the declaration file is okay for the release build that is published to NPM.
It seems like an external issue, do you think it is okay to merge now or do you want to do some more experimentation in this PR? I am out of ideas and I don't know a lot about how wasm-bindgen works 😅

Yeah, I think if it works on my most recent commit in CI, we're good (I've run cargo clean between the npm run build and npm run build-release steps just to make absolutely certain). It's likely a weird cache thing in CI that's causing the magical self-fixes.
As for the underlying issue, yeah, agreed, it's likely some external heisenbug buried within tsify or wasm-bindgen :shrug:.
I reckon it's good to merge - imho, it's the basis of a useful test feedback loop (simultaneously a. predictable (as opposed to testing against one of the big, well-known public TS projects) b. sufficiently advanced c. digestible), so even a somewhat brittle version is worth it.

Looks like it is a cache issue in CI. Clearing the CI cache has fixed the missing type declarations? Now as they are being correctly generated, the "fix" I added to debug builds now produces duplicates 😅. All this missing vs duplicate, debug vs release, local vs CI has got my head in a spin 😆
So theoretically if I remove this:
https://github.com/kaleidawave/ezno/blob/15bfa43122585e99e0b7a64b7139343da58a6592/parser/src/lib.rs#L269-L293
It should work on debug (and I will add a temp test for the release build as well)
As long as it works on release on the CI (which is how it is published) it should be fine for merging. While the local problems are annoying it shouldn't be important for local development for now.

Awesome, debug passes (and although release branch didn't fire, I did test it on my GitHub actions testing repository and it worked, so it should be fine for publishing). I know about the difference so will be looking out for it appearing in CI. Will merge now! Thanks for the addition, will be included in the next blog post! 🎉


fix(gitbook): add npmrc for --save behavior of npm@5

disable npm@5 --save by default.

Deploy preview ready!
Built with commit 1f8bff02ff325d2ab77d26fbbb9132cc42bdba9a
https://deploy-preview-335--mcs-lite-introduction.netlify.com

Deploy preview ready!
Built with commit 1f8bff02ff325d2ab77d26fbbb9132cc42bdba9a
https://deploy-preview-335--mcs-lite-ui.netlify.com


PHP Warning:  count(): Parameter must be an array or an object that implements Countable in vendor/liliom/laravel-firebase/src/FirebaseMessage.php on line 293

Some of those functions return numbers or strings, which you can't perform count() on. Maybe turn that into !empty() ?

solved #2


Different INPUT behavior comparing to QBasic or QB64

The results of running the following piece of code on QBasic and QBJS are different.
INPUT "Enter a number: ", x

x = x + 5
PRINT "X is now: "; x

Regards to QBasic,

it considers x as a number instead of a string;

note: if you use a variable name x$, then it will accept a string.

if you input "abc" and press ENTER, it will prompt you with Redo from start and ask you to input again;

note: empty strings are allowed.

Regards to QBJS,

it considers variable x as a string;
when user input "abc", the PRINT result will be abc5.

This issue may be related to #33.

Thanks for reporting the issue @afbytes!  I've added it to the list for the next release.  You can see the list of what is being worked on next on the Roadmap page in the wiki.

Hi @afbytes, this issue has been resolved as of 0.6.0.  The input method will now convert the entered value to the appropriate type.  At present it is still required to declare your variables for this to work properly.  Support for implicit variable declaration is planned for a future release.  The following will now work as expected:
DIM x
INPUT "Enter a number: ", x

x = x + 5
PRINT "X is now: "; x


'AkechiDRG' implementation

AkechiDRG.cs

[x] Implement AkechiDRG.cs
[x] Remove Dragon Sight code from ActionQueue/Melee/DRG.cs
(NOTE: deprecated)
[x] Test

AIHints.cs

[x] Implement FarthestTargetWithinRadius()
(NOTE: for abilities like Geirskogul, Nastrond, & Wyrmwind Thrust to hit farthest target; best use-case is for targeting adds inside raids without having to switch targets for these fast oGCDs, These abilities are 15y x 2y AOE rect so although they're not exactly wide, it is still optimal to hit boss & however many targets between boss & farthest target, even if only 2 targets. I would like to change how this is done & implement this as an option, but that is a TODO for another day.

Will move out of /Standard after #531 is merged

For AOE targeting, you might look at how my brd module does target selection.


Add rahulposture's file

The first commit for the process of committing a change on GitHub.

Merged the pull request.


或许能用得上

https://wdbible.app/1co.11.cunps
这里有很多中文圣经，不知道您是否可以和开发者联系获取API的事

Thanks

I just created a task for this

I can provide the text files of the simplified Chinese version of the Bible and wonder if you can call them up?


properties, and model graphs

[ ] Linked issue related to your pull request using '#XXX'
[ ] Used the tag [WIP] or [RTR] for on-going changes, or for ready to review
[ ] Did you write new tests to cover your changes?
[ ] Did you write a proper documentation (docstrings and ReadMe)

This change is

Codecov Report
Base: 82.24% // Head: 81.19% // Decreases project coverage by -1.05% :warning:

Coverage data is based on head (ce5f945) compared to base (a5e760b).
Patch coverage: 56.79% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #59      +/-   ##
==========================================
- Coverage   82.24%   81.19%   -1.06%
==========================================
  Files          51       51
  Lines        3430     3424       -6
==========================================
- Hits         2821     2780      -41
- Misses        609      644      +35

Impacted Files
Coverage Δ

bionc/protocols/biomechanical_model.py
71.90% <32.69%> (-13.10%)
:arrow_down:

bionc/bionc_casadi/joint.py
91.42% <100.00%> (ø)

bionc/bionc_casadi/natural_segment.py
81.04% <100.00%> (ø)

bionc/bionc_numpy/joint.py
91.57% <100.00%> (ø)

bionc/bionc_numpy/natural_segment.py
93.33% <100.00%> (ø)

bionc/protocols/joint.py
78.57% <100.00%> (+0.79%)
:arrow_up:

bionc/protocols/natural_segment.py
62.82% <100.00%> (-9.95%)
:arrow_down:

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.


Drawing lag when there are many existing objects

Hi!
Really appreciate the awesome plugin!!
The only gripe I have is that when there are many existing objects/strokes, new lines gets noticeably laggy. The issue only happens with the plugin version, not the online version on tldraw.com, and I was wondering if we can do anything about it.
Related issue: https://github.com/tldraw/tldraw/issues/1247
Thanks!

@thanhnguyen2187 Could you try the latest release?

Thanks!! I noticed that the lag also improved when I upgrade my OS (was using NixOS 24.05 and switched to NixOS 24.11). Maybe libinput also has something to do with it? Either way, it's way better now. Really appreciate your work!!

No problem, thanks!


break speed limit

Hi Hotz,
Saw that the speed limit is 25kmh due to ACC limitation, to overcome this,  you can cut ACC controller from powertrain CAN loop and generate faked ACC signal(especially torque and deceleration request), then you can play with full speed range. Hope this helps.

Sorry, my mistake. Of course you've overcome this, the limit is just for the usrs.

Thanks for your input! As you pointed out, we are already generating our own ACC CAN messages.


Defect: Sitemap links are not working as intended

Defect:
When on the site map the Home link on the navbar adds a '#labs' to the url, this should not be added
The links for labs, goals, and contact should redirect and add these extensions ie. '#labs'
Acceptance Criteria:

[ ] Sitemap labs goes to '#labs'
[ ] Sitemap labs goes to '#goals'
[ ] Sitemap labs goes to '#contact'
[ ] Normal navigation should be unaffected
[ ] Everything else should be unaffected

Context & More Info
Here is a link to a video that demonstrates the issue: https://drive.google.com/file/d/1D2n9mLtwjrt5m9U8c03nnr0PoPZZf70I/view?usp=sharing
In words: clicking the home button in the navbar from the Sitemap page will add the #labs anchor. Clicking the home button in the navbar from any of the labs will add the #goals anchor. In both of these situations, you will still be taken to the main part of the landing page; but, if you refresh the page, you'll be taken to whatever part of the page corresponds with the added anchor.

Hi! I want to work on this issue, please assign me to this.


Feature: Added "send to" menu when right clicking a file

Resolved / Related Issues
Items resolved / related issues by this PR.

Closes #7350

Validation
How did you test these changes?

[x] Built and ran the app
[x] Tested the changes for accessibility

Screenshots (optional)
Add screenshots here.

@yaira2 Does it appear?

Can't test this but send to menu was turned off because it locks the app if you have disconnected network drives iirc. Haven't checked in a long time.

@gave92 are you comfortable releasing to preview to see if this is still an issue?

Fairly sure it's still an issue but probably impacts only few users.


How to train extremenet with multi GPUs, such as 4*1080Ti.

Hi,
You can change the batch size here https://github.com/xingyizhou/ExtremeNet/blob/master/config/ExtremeNet.json#L4 and images per batch here https://github.com/xingyizhou/ExtremeNet/blob/master/config/ExtremeNet.json#L22 (and make sure the sum of chunk_sizes equal to batch_size) to fit your GPUs.

To retrain COCO, Is that possible that for weaker GPU hardwares, it is likely to have RuntimeError: CUDA error: out of memory?

CUDA_VISIBLE_DEVICES=1,2,3 python train.py ExtremeNet
I ve changed  "batch_size": 12, "chunk_sizes": [4,4,4] for 3 GPUs:


System.TypeInitializationException: 'The type initializer for 'LLama.Native.NativeApi' threw an exception.' RuntimeError: The native library cannot be found...

Hi! Thanks for the work you've done on this!
I’m following the example on this page - https://scisharp.github.io/LLamaSharp/0.4/GetStarted/
but get the above error when trying to run it with the .NetFramwork 4.8 however, it runs perfectly fine when using .NetCore.
I’ve tried with LLamaSharp 0.4.0 and the 0.4.1 preview, using both the Cuda 11 and CPU backends but get same error.
Also tried LLamaSharp 0.3.0 but this generates errors in the code of “The type or namespace name 'type/namespace' could not be found” for InteractiveExecutor, ModelParams, etc.
Note: as stated above, when I use the same example code in a .NetCore application, it works fine (but I would like to use an assembly that .NetCore doesn’t support hence trying to get it working in .NetFramework).
Line that threw exception:
var ex = new InteractiveExecutor(new LLamaModel(new ModelParams(modelPath, contextSize: 1024, seed: 1337, gpuLayerCount: 5)));
Exception details:
_System.TypeInitializationException
HResult=0x80131534
Message=The type initializer for 'LLama.Native.NativeApi' threw an exception.
Source=LLamaSharp
StackTrace:
at LLama.Native.NativeApi.llama_context_default_params()
at LLama.Utils.InitLLamaContextFromModelParams(ModelParams params)
at LLama.LLamaModel..ctor(ModelParams Params, String encoding, ILLamaLogger logger)
at LlamaSharpTestNet4.Program.Main(String[] args) in N:\CSharp2023\LlamaSharpTestNet4\Program.cs:line 20
This exception was originally thrown at this call stack:
[External Code]
Inner Exception 1:
RuntimeError: The native library cannot be found. It could be one of the following reasons:

No LLamaSharp backend was installed. Please search LLamaSharp.Backend and install one of them.
You are using a device with only CPU but installed cuda backend. Please install cpu backend instead.
The backend is not compatible with your system cuda environment. Please check and fix it. If the environment is expected not to be changed, then consider build llama.cpp from source or submit an issue to LLamaSharp._

I was having issues as well here is some helper code to assist dotnet runtime when loading external libraries. Im on OSX x86-64, the included dynlib would not load on my architecture it is really arm64 (this is from package LLamaSharp.Backend.Cpu --version 0.4.1-preview, I resorted to just building libllama from the github repo.
add this line at the beginning of the program to add the loader code:
LibLLamaHelper.LibraryLoadAssist("<PATH to libllama.so/dll>"); <- note the path needs updated if you are using a build from source otherwise if you are using  LLamaSharp.Backend.XXX it should load the correct libraries from the paths. (Not fully tested)
Add this helper to your project. It will also give better error messages than the standard The native library cannot be found, ex I was getting
using System.Runtime.InteropServices;
using System.Reflection;

public static class LibLLamaHelper
{
  static IntPtr libllama = IntPtr.Zero;
  public static void LibraryLoadAssist(string? forcePath = null)
  {
    NativeLibrary.SetDllImportResolver(typeof(LLama.Native.NativeApi).Assembly, (string libraryName, Assembly assembly, DllImportSearchPath? searchPath) =>
    {
      var path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);

      switch (libraryName)
      {
        case "libllama":
          if (libllama != IntPtr.Zero) return libllama;

          var libraryPath = string.Empty;

          if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
          {
            libraryPath = forcePath ?? Path.GetFullPath(Path.Combine(Path.GetDirectoryName(typeof(LLama.Native.NativeApi).Assembly.Location), "runtimes", "osx-x64", "native", "libllama.dylib"));
          }
          else if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
          {
            libraryPath = forcePath ?? Path.GetFullPath(Path.Combine(Path.GetDirectoryName(typeof(LLama.Native.NativeApi).Assembly.Location), "runtimes", "win-x64", "native", "libllama.dll"));
          }
          else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
          {
            libraryPath = forcePath ?? Path.GetFullPath(Path.Combine(Path.GetDirectoryName(typeof(LLama.Native.NativeApi).Assembly.Location), "runtimes", "linux-x64", "native", "libllama.so"));
          }

          if (!File.Exists(libraryPath))
          {
            throw new InvalidOperationException($"{RuntimeInformation.RuntimeIdentifier} Library Missing: '{libraryPath}'");
          }

          Console.WriteLine($"Loading {libraryName} from {libraryPath}");

          try
          {
            libllama = NativeLibrary.Load(libraryPath);

          }
          catch (Exception ex)
          {
            Console.WriteLine($"ERROR: {ex}");
            throw;
          }
          finally
          {
            Console.WriteLine($"result {libllama}");
          }

          return libllama;
      }

      Console.WriteLine($"Loading {libraryName}");

      return NativeLibrary.Load(libraryName, assembly, searchPath);
    });
  }
}

@mhail Thanks for this! Though I have an issue with "NativeLibrary" in the LibLLamaHelper class.
Even though I've added System.Runtime.InteropServices and System.Reflection, Visual Studio still gives the error: "The name 'NativeLibrary' does not exist in the current context"
When I select to show potential fixes, all it suggests is generating a new type/property/variable etc, named 'NativeLibrary'.
By the way, I'm trying to get this working in a .NetFramework 4.8 application. Not .NetCore as the original LLamaSharp example already worked in .NetCore for me.

Yes NativeLibrary.SetDllImportResolver is only available in the 'core' versions of dotnet: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cross-platform#custom-import-resolver
Possibly patch out the catch of DllNotFoundException in
https://github.com/SciSharp/LLamaSharp/blob/a53ede191e3d2302886842d781b6b737ec47b415/LLama/Native/NativeApi.cs#L20
This obscures any details of the error or helpful messages, by throwing a new RuntimeError.   Also check out the docs on DllNotFoundException, and its detailed link on Dynamic-Link Library Search Order

I was having issues as well here is some helper code to assist dotnet runtime when loading external libraries. Im on OSX x86-64, the included dynlib would not load on my architecture it is really arm64 (this is from package LLamaSharp.Backend.Cpu --version 0.4.1-preview, I resorted to just building libllama from the github repo.
add this line at the beginning of the program to add the loader code: LibLLamaHelper.LibraryLoadAssist("<PATH to libllama.so/dll>"); <- note the path needs updated if you are using a build from source otherwise if you are using LLamaSharp.Backend.XXX it should load the correct libraries from the paths. (Not fully tested)
Add this helper to your project. It will also give better error messages than the standard The native library cannot be found, EX I was getting ERROR: System.DllNotFoundException: Unable to load shared library '/bin/Debug/net7.0/runtimes/osx-x64/native/libllama.dylib' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(/bin/Debug/net7.0/runtimes/osx-x64/native/libllama.dylib, 0x0001): tried: '/bin/Debug/net7.0/runtimes/osx-x64/native/libllama.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64h' or 'x86_64')), '/bin/Debug/net7.0/runtimes/osx-x64/native/libllama.dylib' (no such file), '/bin/Debug/net7.0/runtimes/osx-x64/native/libllama.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64h' or 'x86_64'))
using System.Runtime.InteropServices;
using System.Reflection;

public static class LibLLamaHelper
{
  static IntPtr libllama = IntPtr.Zero;
  public static void LibraryLoadAssist(string? forcePath = null)
  {
    NativeLibrary.SetDllImportResolver(typeof(LLama.Native.NativeApi).Assembly, (string libraryName, Assembly assembly, DllImportSearchPath? searchPath) =>
    {
      var path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);

      switch (libraryName)
      {
        case "libllama":
          if (libllama != IntPtr.Zero) return libllama;

          var libraryPath = string.Empty;

          if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
          {
            libraryPath = forcePath ?? Path.GetFullPath(Path.Combine(Path.GetDirectoryName(typeof(LLama.Native.NativeApi).Assembly.Location), "runtimes", "osx-x64", "native", "libllama.dylib"));
          }
          else if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
          {
            libraryPath = forcePath ?? Path.GetFullPath(Path.Combine(Path.GetDirectoryName(typeof(LLama.Native.NativeApi).Assembly.Location), "runtimes", "win-x64", "native", "libllama.dll"));
          }
          else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
          {
            libraryPath = forcePath ?? Path.GetFullPath(Path.Combine(Path.GetDirectoryName(typeof(LLama.Native.NativeApi).Assembly.Location), "runtimes", "linux-x64", "native", "libllama.so"));
          }

          if (!File.Exists(libraryPath))
          {
            throw new InvalidOperationException($"{RuntimeInformation.RuntimeIdentifier} Library Missing: '{libraryPath}'");
          }

          Console.WriteLine($"Loading {libraryName} from {libraryPath}");

          try
          {
            libllama = NativeLibrary.Load(libraryPath);

          }
          catch (Exception ex)
          {
            Console.WriteLine($"ERROR: {ex}");
            throw;
          }
          finally
          {
            Console.WriteLine($"result {libllama}");
          }

          return libllama;
      }

      Console.WriteLine($"Loading {libraryName}");

      return NativeLibrary.Load(libraryName, assembly, searchPath);
    });
  }
}

Hi @mhail ,
any chance you could provide guidance on how you built for the diff os ? nix , win, osx ?

yes you need to use the targets in the llmacpp make file: make libllama.so <- https://github.com/ggerganov/llama.cpp/blob/1d1630996920f889cdc08de26cebf2415958540e/Makefile#L280
this passes the -shared flag to cpp that will make the shared library. I believe this will make the appropriate file on each platform even though the target is named libllama.so
More details can be looked up in the man pages for gcc/cc for the shared option.
If you want to cross compile for multiple platforms it get really tricky and llama.cpp supports a lot of different options for metal, various processors and toolchains. It is mentioned to use zig for cross compiling, I have not use that before.

I'll close this now since it's a very old question, but if there's still any issues to resolve please feel free to reopen it.
Important PSA.
There is no compatibility from one version of llama.cpp to the next. Anything might change i the binaries and if you're very lucky using the wrong binaries will just result in a crash. If you want to compile llama.cpp yourself make sure you are using exactly the right version! You can usually find it listed in the readme for any given version.