The widget crashes in my React v18 app - interpolating a keyframe declaration (iSKUCl) into an untagged string

I did test the widget in a clean React v18 project successfully, both with create-react-app and react-app-rewired. But I have a lot more dependencies in my production app (which is also React 18), and it seems it is related to styled-components, which I have installed.
Tried with both v5 and v6 of styled-components with no luck. This is the error from the chrome console, I don't know how to get past this. Downgrading to v3 will result in other incompatibilities with the app.

error.ts:32 Uncaught Error: It seems you are interpolating a keyframe declaration (iSKUCl) into an untagged string. This was supported in styled-components v3, but is not longer supported in v4 as keyframes are now injected on-demand. Please wrap your string in the css`` helper which ensures the styles are injected correctly. See https://www.styled-components.com/docs/api#css
react-dom.development.js:18687 The above error occurred in the  component:
at ThemeProvider (bundle.js:170672:5)
at SDKProvider (bundle.js:170603:5)
at WidgetProvider (bundle.js:170927:5)
at RouteExecutionStoreProvider (bundle.js:171296:5)
at ChainOrderStoreProvider (bundle.js:171067:5)
at HeaderStoreProvider (bundle.js:171214:5)
at SplitSubvariantStoreProvider (bundle.js:171956:5)
at StoreProvider (bundle.js:171023:5)
at QueryClientProvider (bundle.js:462091:5)
at AppProvider (bundle.js:125935:5)

Further tracing from the console:
<EMAIL_ADDRESS>
<EMAIL_ADDRESS>

We don't use styled-components, but instead use emotion. Maybe they have compatibility issues 👀 I'll try to take a look

@paintoshi should be fixed in v2.6.0, please upgrade 🙂

@paintoshi should be fixed in v2.6.0, please upgrade 🙂

I've updated to 2.6.0 but unfortunately seeing the same error. I have not been able to replicate the issue in some demo app yet, only in production code which I cannot share.

@paintoshi can you please share the detailed error as you did above with the information in which component the error occurred?

@chybisov Sure.

@paintoshi Thanks, I think I found the issue and it was a tricky one. 😄 Please try v2.6.1

@paintoshi Thanks, I think I found the issue and it was a tricky one. 😄 Please try v2.6.1

I'm impressed you managed to fix that one. I can happily report that it now loads in our app! Now I just have to figure out how this widget will interact with our current wallet integration. Thank you!

@paintoshi glad to hear that 🥳 Shoot us a message in Discord if you have any other questions with integration.


Rename Makefile targets

For all targets, follow the pattern <component|tool>-<action>-<environment>

@stevepiercy, @davisagli, @sneridagh, these are my suggestions:
help                                 Show this help
install                              Installs the dev environment using mrs-developer
start                                Starts the add-on in development mode
build                                Build a production bundle for the project containing the add-on
i18n                                 Sync i18n
format                               Format codebase
lint                                 Lint Codebase
release                              Release the add-on on npmjs.org
release-dry-run                      Dry-run the release of the add-on on npmjs.org
test                                 Run unit tests
test-ci                              Run unit tests in CI
storybook-start                      Start Storybook server on port 6006
storybook-build                      Build Storybook
backend-start-docker                 Starts a Docker-based backend for developing
acceptance-frontend-start-dev        Start acceptance frontend in dev mode
acceptance-frontend-start            Start acceptance frontend in prod mode
acceptance-backend-start             Start backend acceptance server
acceptance-test                      Start Cypress in interactive mode
acceptance-test-headless             Run cypress tests in headless mode for CI

Opinions?

Setting aside the non-descriptive descriptions for now (I prefer verbose to vague), I would prefer a pattern of thing-subthing-subsubthing-action for the Make target names. For most of the commands, it is more convenient to use a short name instead of a more descriptive name, as they are the most common or default. For example, test and test-ci are the most common tests to run, so a name like unit-test and unit-ci-test would be annoying. The naming convention needs flexibility.
Here's the names I would change. As long as you know that the action is always the last segment, and that thingies are the first segments, it will be easier for developers.
ci-test                              Run unit tests in CI
backend-docker-start                 Starts a Docker-based backend for developing
acceptance-frontend-dev-start        Start acceptance frontend in development mode
acceptance-frontend-prod-start       Start acceptance frontend in production mode
acceptance-headless-test             Run cypress tests in headless mode for CI

@stevepiercy  ci-test sounds wrong to me :( Also it's something that normally users don't do (at least me, it seems that people around use that command locally :)

@ericof LGTM. However, can you elaborate on the difference between "install" and "build"? I don't get this. I also don't get why "build" builds the production bundle and not the "dev bundle". I do not want to look into the details here since I am trying to look at those commands like a newbie. :)

@sneridagh "test" in this context is a verb or action. I much prefer a naming pattern where the thing to be acted on comes first, and is followed by the action to perform on the thing.

@stevepiercy I defer to your expertise and experience here :-)
That being said, could you simply copy the list in the first command and replace where adequate?
I will implement that on Monday

To document the rules:

Use kebab-case, where each word is separated by a hyphen.
Use hierarchical or taxonomic ranking, where the thing being operated upon is defined by [thing]-[subthing]-[subsubthing].
[thing] may be omitted when it is the project itself.
The final term is the action to be performed upon the [thing].

I also polished up the descriptions.
help                                 Show this help
install                              Installs the add-on in a development environment
start                                Starts Volto, allowing reloading of the add-on during development
build                                Build a production bundle for distribution of the project with the add-on
i18n                                 Sync i18n
format                               Format code base
lint                                 Lint code base
release                              Release the add-on on npmjs.org
release-dry-run                      Dry-run the release of the add-on on npmjs.org
test                                 Run unit tests
ci-test                              Run unit tests in CI
storybook-start                      Start Storybook server on port 6006
storybook-build                      Build Storybook
backend-docker-start                 Starts a Docker-based backend for development
acceptance-frontend-dev-start        Start acceptance frontend in development mode
acceptance-frontend-prod-start       Start acceptance frontend in production mode
acceptance-backend-start             Start backend acceptance server
acceptance-headless-test             Run cypress tests in headless mode for CI
acceptance-test                      Start Cypress in interactive mode

I would use check instead of lint. Latter is jargon, first is within a beginners English vocabulary.

However, asking i.e. Deepl gives no meaningful answer (German: Fussel/ fusseln).
At least the description should be meaningful then.

Updated to:
lint                                 Lint, or catch and remove problems, in code base

The term derives from a clothes drier filter that catches and removes lint from clothing through forced air and a wire screen.

Closing this, as it was implemented in cookieplone-templatea


Allow populator to have more control over RBAC

Populator pods created through RunController in populator-machinery may need to access to some k8s resources, therefore RBAC needs to be set for the populator pods.

We may be able to choose either of the below approaches:

Set the same ServiceAccount as the controller pod,
Add an argument to RunController to specify a ServiceAccount for the populator pod.

WDYT? @bswartz

@bswartz I've made a prototype on top of the cross-namespace snapshot PR.
It defines patchPodFunc and pass it to RunController so that library user can patch the pod.
Please check here for details. If it looks good, I will create a separate PR only for this change.


Docs - Prometheus metrics named as IotHub, but I assume also track MQTT publish at this point

Is your feature request related to a problem? Please describe.
On page obesevability there are descriptions like Messages sent to IoTHub per second	 as others that have IotHub inside, but output of publisher is MQTT now also, so

Is my assumption is correct that the metrics track MQTT publish messages?
Should we rename the description to Messages sent to **outputs** per second

You are correct.  I think changing the name of the output text is reasonable.

Changed names used when logging the diagnostics to the console in 2.9.4 but will keep the metric names as is.  New output:
  DIAGNOSTICS INFORMATION for          : MES
  # OPC Publisher Version (Runtime)    : <IP_ADDRESS>-preview+6a56240de5 [DEBUG] (.NET 8.0.0/win-x64)
  # Time                               : 2023-12-27T15:11:36.6854888Z
  # Ingestion duration                 :    00:00:00:56 (dd:hh:mm:ss)
  # Opc endpoint connected?            :           True
  # Connection retries                 :              0
  # Monitored Opc nodes succeeded count:              6
  # Monitored Opc nodes failed count   :              1
  # Subscriptions count                :              1
  # Ingress value changes              :            298 (All time ~5.27/s; 57 in last 60s ~5.27/s)
  # Ingress events                     :              0
  # Received Data Change Notifications :             57 (All time ~1.01/s; 57 in last 60s ~1.01/s)
  # Received Event List notifications  :              0
  # Received Keep Alive notifications  :              0
  # Generated Cyclic read notifications:              0
  # Generated Heartbeat notifications  :              0
  # Notification batch buffer size     :              0
  # Encoder input/output buffer size   :              0 | 0
  # Encoder Notifications processed    :             57
  # Encoder Notifications dropped      :              0
  # Encoder Network Messages produced  :             58
  # Encoder avg Notifications/Message  :              1
  # Encoder worst Message split ratio  :              0
  # Encoder avg Message body size      :          1,131
  # Encoder avg Chunk (4 KB) usage     :            0.3
  # Estimated Chunks (4 KB) per day    :              0
  # Egress messages ready to send      :              0
  # Egress messages dropped            :              0
  # Egress messages successfully sent  :             58 (0.99/s)


Request: add ourpython.com to the filter

Evidence: https://ourpython.com/python/avro-complex-records-with-union-record-type-support
Original: https://stackoverflow.com/questions/51031364/avro-complex-records-with-union-record-type-support

Thanks a lot!


Show Full Playlist

There should be a way for a user to see all of the songs that the DJ played on their show. Probably key decisions here are:
How far back should we go?
What should we display?
My suggestion would be to just show playcuts from the current show, but that may be a bit harder since the playlist isn't really organized by show. Alternatively, 2/3 hours seems fine.
I prefer my playlists minimal, without album art (since it just makes it a bit hard to quickly scroll through to find something)... here's a screenshot from WFMU's playlist in their app for some minimalist inspiration.

I like the minimalist look. I think 2 hours back would be fine. Maybe even 1.5 hours. In my personal experience I have never needed anymore than 2 hours back.
I like the format of the WXDU listings: Song/Artist/Album

I'm still not convinced that people want a playlist feature. Sharing and favoring are more important and have less design costs.

I would agree with @jakebromberg  except that there have been times when I'm in my car listening to the station, I hear a song I like, and I have no way to find out what it was. If I listen long enough the DJ will announce it, but often - on the old app - I would look back at the play history to find out. This is a rare case of course. One that would be remedied if that information showed up my car radio display. However, if you think the design cost would be too high then it might not be worth it.

I would just like for us to think carefully about this first. The current paginated view that we have would have to change somehow if we were to represent the playlist in a vertical scroll view. I could run some experiments. I'm not opposed to showing a playlist, but I think this should rank lower than other features on the table.

shipped in 2.2


crashing

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
when i launch bloxtraproblox it says that i have crashed any help please?

Have you checked to see if this happens only when using Bloxstrap? https://github.com/pizzaboxer/bloxstrap/wiki/Switching-between-Roblox-and-Bloxstrap

Issue has been awaiting clarification for over a month, closing as stale. If you have anything further to add, just respond and I'll reopen.


Chown writable dir if already exists

Currently, writable dirs are only created/chowned if they don't already exist. We should probably chown them if they do already exist.
To reproduce:
run.config:
  engine: none

deploy.config:
  before_live:
    web.main:
      - mkdir -p /app/var/cache

web.main:
  log_watch:
    thing: /app/var/log/thing.log
  writable_dirs:
    - var
  start: sleep 1d

The log watch directory get created first, as root, and the /app/var doesn't get chowned because it already exists.

A workaround for now would be to add the following before_live hook into your boxfile.yml: sudo chown gonano /app/var.
The complete workaround boxfile is:
run.config:
  engine: none

deploy.config:
  before_live:
    web.main:
      - sudo chown gonano /app/var
      - mkdir -p /app/var/cache

web.main:
  log_watch:
    thing: /app/var/log/thing.log
  writable_dirs:
    - var
  start: sleep 1d


Upgrade to the hardhat toolbox

@nomicfoundation/hardhat-toolbox has a lot of what we need installed, and makes our config file a little smaller and neater.

it's included on typescript branch but it's not on main


Is there a way to parallelize or accelerate a loop of column-by-column jvp?

Hi, experts.
I am currently calculating a Jacobian column-by-column and calculating the squared sum of each column to calculate the Trace of the Jacobian.
The code looks something like this:
def jvp_func(x, tgt):
    return jvp(net, (x,), (tgt,))

tr = 0
for j in range(x[0].shape[0]):
    tgt = torch.zeros_like(x)
    tgt[:, j] = 1.
    _, grad = vmap(jvp_func)(x, tgt)
    tr += torch.sum(grad * grad, dim=1)

As you can see, my code calculates a batched Jacobian column by column (inside each j loop) and calculates the Trace.
(motivated by this code: https://github.com/facebookresearch/jacobian_regularizer/blob/main/jacobian/jacobian.py)
I am mainly doing this instead of calculating the entire Jacobian at once because the entire Jacobian is huge and it blows up the memory.
However, this code is quite slow. I am not sure if this code is doing a lot of redundant computation, e.g., I wonder if net(x) is being calculated repetitively on each loop of j.
Is there a way to parallelize the j loop, or at least remove any repetitive computation for each j loop to speed up the current code?
I briefly looked at functorch.compile.ts_compile but was not able to make it work, and am not sure if that is something that can be helpful.
Any suggestions will be highly appreciated!
Thank you,
Best regards,
Kiwan

However, this code is quite slow. I am not sure if this code is doing a lot of redundant computation, e.g., I wonder if net(x) is being calculated repetitively on each loop of j.

Yes, net(x) is being calculated repetitively on each loop of j. We either need something like jax.linearize or a good backend compiler with CSE to avoid this (cc @Chillee - would AOTAutograd help here? I don't know where CSE is implemented).

Is there a way to parallelize the j loop

I assume replacing the j loop with a vmap blows up your memory (you said that the entire jacobian is huge). So instead of replacing the j loop with a vmap, we can vmap it in chunks.
For example, instead of running the for-loop over all j, we could do it two js at a time:
def jvp_func(x, tgt):
    return jvp(net, (x,), (tgt,))

def make_tgt(j):
    tgt = torch.zeros_like(x)
    tgt[:, j] = 1.
    return tgt

def make_tgts(js):
    return torch.stack([make_tgt(j) for j in js])

def compute_tr(tgt):
    _, grad = vmap(jvp_func)(x, tgt)
    return torch.sum(grad * grad, dim=1)

tr = 0
for js in [ [0, 1], [2, 3], [4, 5], ... ]:
    tgts = make_tgts(js=[0, 1])
    tr0, tr1 = vmap(compute_tr)(tgts)
    tr = tr + tr0 + tr1

Thanks for the help! The code became much faster by doing a vmap over a certain number of iterations. I am still interested in learning if I can easily avoid doing net(x) every time, so I will wait for @Chillee to respond.
I think for torch.autograd, this can be done by using torch.autograd.grad(), with retain_graph=True? I wonder if there is something equivalent for functorch, if some cool new compiler cannot help.

torch.autograd, this can be done by using torch.autograd.grad(), with retain_graph=True

If you're okay with computing vjp instead of jvp, then you can use functorch.vjp (the transform version of torch.autograd.grad) to compute net(x) once and compute vjp multiple times


When navigating away from the page with unsaved work, prompt

As title - to prevent accidentally losing work, like I've just done.. :(

The check on navigate is a good feature and might be important, but I would suggest implementing a localStorage autosave/rehydrate first. It's pretty simple to get in and would probably cover that case without dealing with a prompt. Adds a bit of complexity to saving and reloading from the server, or opening maps in multiple tabs, but I think with what you got it's minor.
I can share some code if that's of interest

That sounds even better code would be appreciated 👍

I know I'm late to the party, but I also lost my work today. @ChristianDavis would you mind sending a PR?

Completed.


NuGet 1.0.5 introduces a breaking change

ITableStorage is expecting more members.
1.0.5 and 1.0.6 should really be unlisted from NuGet and republished as 2.0.0.

This is finally fixed :) I've unlisted 1.0.5/6 from NuGet.org. There's a new version <IP_ADDRESS>


fix(storage-resize-images): support backfill task in custom region

fixes: #1389
Consider location (region) the extension is installed when loading task queue.
Previously regardless of which region the extension is installed, it will look for a the Task Queue in us-central1.
See documentation for information: https://firebase.google.com/docs/reference/admin/node/firebase-admin.functions.functions.md#functionstaskqueue

Thanks @hipyhop.
This looks great, we'll just need to add an additional updates - I think the new location param in the config has affected one of the configuration tests.


Light Strip

Please explain your feature request in a one or two sentences.
Adding in support for Light Strip control through homebridge

Is your feature request related to a problem? Please describe.
Currently not supported as per plugin logs.

Any particular eWeLink devices that this relates to?
Sonoff Spider Z Light Strip Controller

Anything else?
{"bindInfos":{"gaction":["88dc433f-6f8b-4a78-975d-b0935d388980_ewelinkGoogleHome"]},"version":8,"init":1,"fwVersion":"1000.2.1050","switch":"off","colorR":0,"colorG":11,"colorB":255,"mode":0,"bright":100,"light_type":1,"speed11":70,"bright11":60,"speed16":60,"bright16":60,"ssid":"Flight","bssid":"0:95:103:198:108:62","lineSequence":{"1":"b","2":"g","3":"r"},"timeZone":2}

Hi @thepickpocket
Would you be happy to share this device to my ewelink account so i can properly see how the data is given and the different modes, functions etc?

@bwp91 I can definitely share it with you for a couple of days, just send me the ewelink account to share with :)

Country code 44 (UK)
<EMAIL_ADDRESS>

Shared :) Will revoke sharing on the 29th. Will that be enough time?

Thanks, I see it!
Are you happy for me to turn it on/off and change brightness/colour a few times over the next hour or so?

Absolutely :)

Okay, if you want to update to the beta version of the plugin, 8.6.1-beta.4, this device should appear in homebridge/homekit after restarting and should be controllable (on/off, brightness and colour).

Tested and works perfectly :) Thank you

Excellent!
I noticed the strip has a couple of extra modes (apart from the first two rgb modes which I didn't know the difference between) - there is also the cct mode and some black/white mode? The cct mode didn't seem to offer a range of colours so I didn't implement this, and the other black/white mode I didn't know what it was for so didn't implement this either.
There's also the scenes and the music mode which I haven't implemented. Potentially possible to create HomeKit buttons so switch into these modes if that could be useful for you? But the configuration of the modes would still need to be done within the ewelink app.

Thats perfect, it would be nice to have those buttons available but really not a trainsmash. The only thing that I noticed, is that if I change colours while the lights are off in homekit, and then switch it back on, the lightstrip does not change to the new colour. Maybe we just need to send a colour change signal every time its switched on?

if I change colours while the lights are off in homekit, and then switch it back on, the lightstrip does not change to the new colour

This should be fixed in 8.6.1-beta.5. It wasn't sending any colour change at all if the device was off.
The other buttons I will work on later today!

Awesome! Thanks!

is it okay to control your device again? need to put it to different scenes and modes...

yeah sure go for it :)

There are a lot of different scenes and music mode types, it is going to be a lot of code to implement them all.
Are there any scenes in particular that you personally use? and any type of music mode that you use? I'm happy to implement perhaps a couple of scenes and a music mode to begin with... doing them all initially will be very time consuming 😆

I really just use "Festi" scene and really dont use the music mode at all tbh :)

Are you near the light now?

Yes I am :)

If you update to 8.6.1-beta.9 version, then (you will need the Eve HomeKit app) you should see another button inside the accessory called 'Festive Scene'.
If you turn it on it will make the light go to the festive scene, also if you use the ewelink app to turn on the festive scene, this button should show as on. Turning this button OFF won't do anything, to stop the scene you will need to choose a colour. But once you choose a colour, the button should turn off (to let you turn the scene ON again if you want).
I've implemented this in the same way I implement scenes in my homebridge-govee plugin, so you can follow this wiki entry here on how to get the scene to appear in the home app:
https://github.com/bwp91/homebridge-govee/wiki/Scene%2C-Music%2C-DIY-Modes#step-3-the-eve-app

Thanks so much! :D

Are you able to confirm it working? Obviously I cannot see the physical device to see how the scene looks! 😝

Also feel free to unshare the device. I think I have everything saved for future reference if I need to add more scenes/modes. Thank you for sharing it with me, makes everything a lot quicker!


PROPOSAL: Introduce .NET Standard support in Common.Logging 4.0 and sunset Common.Logging 3.x after 3.4

The project team would like to solicit comments/input from the community on the following proposal.
With all the churn in the .NET stack over the past few years, (e.g., PCLs, .NET Framework Profiles, WinRT, .NET Core, .NET Standard), its been challenging to keep projects like Common.Logging entirely aligned with what's needed for its adopters within all of the differing flavors of .NET.
Since the original concept of .NET Standard was first suggested (and along with it a completely different model/architecture for mutli-targeting class libraries), we've struggled for some time to arrive at a go-forward strategy for Common.Logging that would be aligned with the future direction/architecture of the .NET platform vs. being (mostly) backward-facing and constrained by legacy design decisions being carried forward from years prior.  Part of the delay in our plans to support .NET Standard had been the gap between the arrival of .NET Standard and the availability of proper tooling/Visual Studio support for the concepts it represents.
Now that we've reached a point where the tooling is able to properly support the concepts, we think we've arrived at a go-forward strategy for this aspect of the project.  After review and consideration we're now leaning strongly towards the following approach to support .NET Standard in Common.Logging:

Common.Logging 3.4 will be the last release of the 3.x version branch (e.g., there will be no 3.5 release planned and we will only do 3.4.x bug-fix releases as needed for some limited time).
Common.Logging 3.4 will be the last release of Common.Logging to support the 'legacy' .NET Framework versions which fall below the floor established by .NET Standard 1.0 (e.g., < .NET 4.5).
Common.Logging 4.0 will support only .NET Standard, leveraging the new multi-targeting capabilities introduced in Visual Studio 2017 and abandoning PCL support entirely.  NOTE: given the differing availability of .NET APIs in each version of .NET Standard, we have not yet determined for certain the min. version of .NET Standard that will be supported by Common.Logging 4.0.  But it will at least target >= .NET Standard 1.0 and will not support any .NET Framework version that falls outside the scope of .NET Standard as defined here.
Common.Logging 4.0 will support only Visual Studio 2017 as an IDE for building and contributing to the project.  Support for building the project in legacy versions of Visual Studio will be dropped as they cannot support .NET Standard and the Community Version of Visual Studio 2017 is 100% free of charge and should be able to be used by adopters, contributors, etc. who desire to interact with the source code for the project.

Given that most versions of the .NET Framework < .NET Standard 1.0 have already reached (or are about to) their effective end-of-life re: support from Microsoft, this above approach seems a reasonable decision to make at this time.  That said, since this decision will effectively 'orphan' any users of Common.Logging that are still targeting < .NET 4.5 from having access to any new features and/or new loggers for which support were to be introduced, we wanted to offer this opportunity for users to offer comment/feedback before this approach is officially pursued.
Thanks in advance for any and all input!
-The Common.Logging project team

That all sounds reasonable to me, but would it be feasible to multitarget both netstandard and .NET Framework for those poor souls still on a version lower than 4.5? Would it require any extra work? I don't have any personal stake in it, just wondering.

I think I'd say that we can explore that and try to determine the LOE required to support that.  If it can be achieved with a reasonable effort, I'd say we should try to accommodate as best we can.
I think in general the objectives go like this:

Consolidate support for multiple versions of Visual Studio into only Visual Studio 2017.
Remove support for versions of .NET not supported by reasonably recent versions of logging frameworks supported by Common.Logging (if e.g., Log4Net hasn't supported .NET 2.0 for 5+ years, why are we still supporting .NET 2.0 with Common.Logging?)

If we can achieve the above with adding support for e.g., .NET 3.5 then I think we're interested in going there; and if not, then not :)

Hi! Even though I am not using this lib atm, going in this direction definitely seems the way to go. I am for my self in the process of updating/restructuring some of my packages.
However, supporting legacy (full)-Frameworks with netstandard-tooling seems to be less painful as it ought to be with PCLs.
Just wanted to provide one or two maybe helpful links ;)
And for the matter of the lost souls still sticking with eg. .net2.0:
If the community keeps alive those frameworks by still supporting them in libraries like this one, even though MS as already EOLed those frameworks, many people do not see any reason to make the framework shift in the first place (or maybe having a hard time to convince other "stakeholders" or teammembers to perform an update). That said, dropping support for this kind of legacy may help others argumenting to do an update, as more and more packages will drop legacy-support, rendering these older frameworks more and more useless in regards of available 3rd party solutions.

@earloc Thanks for the input (and the links).  I'd not seen the second of those, but was aware of the process outlined there (agree w/ the author that its scattered all over the place and its helpful to have it all in one place).
As mentioned, we're not surrendering on supporting older/legacy versions of .NET Framework where the effort is considered somewhat minimal.  But we are shifting our approach with an eventual 4.0 release to place less of an emphasis on continuing to support older versions of the framework to ensure continued compatibility and more of an emphasis on simplifying the complexity that supporting so many parallel versions of the framework has created for this project.
Your point that multi-targeting in VS 2017/net-standard is already much simplified from the PCL approach is well-taken, however.  It may well be that after a grand refactoring of the solution to rely upon this new approach, we discover that its "just as easy" to continue to support older framework versions.
That said, there are a number of pending ISSUES/suggestions for changes to Common.Logging 3.x that have been postponed to 4.0 because they would represent breaking changes (and SemVer precludes us from implementing them until we rev the major version number).  We're thinking that since 4.0 will already be breaking changes, this is also the time to make any necessary 'clean breaks' with the past legacy supported frameworks as well.
Thanks again for your feedback/input; more perspectives are definitely better than fewer!

Does it means that Microsoft.Extensions.Logging in .net core will be eventually deprecated and replaced with new Common.Logging 4 from .net standard, or they are going to co-exists? I have some libraries working with Common.Logging and want to use them in .net core. Should I rewrite everything to match Microsoft.Extensions.Logging or wait for Common.Logging 4?

I'm a bit in the same case than @jovanpop-msft
We have multiple libraries that are based on Common.Logging, and have start to build new applications based on AspNetCore.
For that, we have already re-built multiple librairies against netstandard2.0, including a dependency to Common.Logging 3.4 which is compatible with the netstandard 1.3
But now what should we do in our AspNetCore applications ? Use Common.Logging or Microsoft.Extensions.Logging which is designed with DI in mind from the start ?
We use NLog as the concrete implementation, and NLog team has provided an adapter to use it above Microsoft.Extensions.Logging. But Common.Logging team seems moving slower and is not yet ready.
The solution I've start to develop is to create a Common.Logging.ILoggerFactoryAdapter that is based on Microsoft.Extensions.Logging, so I can inject NLog in Microsoft.Extensions.Logging with the package provided by the NLog team, and then inject Microsoft.Extensions.Logging in Common.Logging so our legacy code based on Common.Logging can continue to works.
With that approach we probably won't need a new version of Common.Logging, and we will probably consider Common.Logging as a legacy framework, because if NLog team maintain themselves the adaptation to the Microsoft.Extensions.Logging abstraction I will be much confident than a maintenance done by a third party team like it was with Common.Logging due to the inherent delay between a new release of the product and the adapter when it's done by different teams.
What the community though about that approach ?
nb: I didn't find any adapter that already do that. But If it's successful we can open source it and release it

Creating an adapter between Common.Logging and Microsoft.Extensions.Logging was not a so good idea.
In some cases it doesn't work well. In particular when using nlog layouts like ${callsite} because it will render the name of the method in the adpater, and it's not fixable because we go trough 2 levels of adapters before accessing nlog.
So we choose to roll-back from that idea and compile internally an nlog adapteur for common.logging in netstandard. Which means that we are still interested by a new version of common.logging fully compatible with NetStandard which will sometimes live side by side with Microsoft.Extensions.Logging.Abstraction

@sbohlen Can we get an update on this? Is there any movement on v4.0 with .NET Standard and .NET Core support or has this project been abandoned? I don't see any significant progress over the past year. We are trying to determine if we should continue with Common.Logging for .NET Core projects and create our own adapters or migrate to Microsoft.Extensions.Logging since NLog and other logging frameworks provide their own adapters for that API. Thanks!

@sbohlen Could I help somehow with the move to version 4?

@tonycoelho, @mnivet, is it a good idea to help with the project? Might be do some fork and work on this support (at least for Common.Logging -> NLog)? I personally love common logging and it is really good working with slightly different approach than Microsoft Logging extensions.
I personally will be able to look at the sources sometime next week.

All pull requests are always welcome!
For what its worth, current plans call for me to be able to return to focus more on this effort beginning at the start of November (after a number of current other distractions are resolved elsewhere in my life).  My goal would be to have this (and other unaddressed issues) resolved by the end of calendar 2018 latest.
That said, if anyone wants to fork the repo and submit a PR for any open work (port to .net standard, support for later nlog, etc.), all pull requests are always welcomed!

@sbohlen I will look what I can do in terms of the porting to .net standard over this weekend.
Do you have some particular requirements for the porting or 4.x will be supported from the latest .netstandard 2.0 on current date?
@tonycoelho, @mnivet do you also have some preferences in version terms in the terms of porting?

I've just open to public the common.logging.nlognetstandard adapter that have been write internally in our company by . You can found it here:
https://github.com/TalentSoft/common.logging.nlognetstandard
@sbohlen how do you prefer to integrate that ?

Continue to have a lot of projects in the same big repository ? In that case I let you copy paste the code in your repo.
Or keeping it in a dedicated repository ? In that case I can transfert you the ownership.

Can we purge the support for Silverlight for the 4.x + version? as it seems that Microsoft are not willing to support it long term...

Hi all. I've done something in my fork.
@sbohlen  could we have discussion about what is done (might be a skype call for the 15 minutes?) as there are some breaking changes which could include the breaking of old build pipeline.
Here are the link to the current breaking changes: https://github.com/Defee/common-logging/blob/version_4x/breaking-changes.md .
@mnivet did your version included the integration with Microsoft.Logger as well?

@Defee no, That idea was abandoned as Iv'e explain a bit earlier in this thread
It doesn't work so well, and currently we just send CommonLogging traces to NLog and Microsoft.Extensions.Logging traces to NLog
NLog is a concrete log implementation that can correctly aggregate traces from that two abstractions (CommonLogging and Microsoft.Extensions.Logging) and provide an easy way to configure where all traces should be output.
Microsoft also provide native implementations above their abstraction but I'm not sure if we can use them directly in a CommonLogging adapter without re-writing a log configuration system because the configuration part in Microsoft logging system seem more tied to the log abstraction than to the log implementations

Microsoft also provide native implementations above their abstraction but I'm not sure if we can use them directly in a CommonLogging adapter without re-writing a log configuration system because the configuration part in Microsoft logging system seem more tied to the log abstraction than to the log implementations

I found something. Basically it is how NLog did their extension for the microsoft logging. I think for Common it should be the same way of doing it. It is not much work, but I need to find time to do that. Possibly early next month.

@Defee interesting idea. I've trying to adapt microsoft logging to common logging with mixed results.
But I've not try adapting common logging to microsoft logging.
Is that a better idea ? I'm not sure that it will provide better results on nlog layout renderers like ${callsite} that are based on the callstack...
My tries make me think that common logging and Microsoft logging are both interfaces that should be implemented (through adapters) by a final framework (like nlog), but that there is no real advantage to adapt one above the other, even if you reverse the order that I have tried.
Then, each project should choose to use common logging or microsoft logging, and DI must bind the chosen implementation (nlog or any other logging framework) to the the interface(s) that are used in the dependencies of the final app.
To achieve that properly we need to have more modern Common Logging packages that support NetStandard, and that are more DI oriented (with less static entry points and generic logger interface) so all types of projects can have a real choice between common logging and microsoft logging, because for instance netstandard project are limited to Microsoft logging, and net framework projects are limited to common logging, which is not a real choice

Hi all!
I plan to have the forked version published on nuget with some kind of prefix somewhere over the next weekend. I will tear it down (de-list it) when the official decision (or announcement for upgrade) will be made from @sbohlen.
@snakefoot, could we have might be a Skype call/or other call just to see our diffs for NLog implementation ( I think it shouldn't be much)?

@Defee I have pretty much just taken the Serilog Implementation and renamed it to NLog. You can see my actual changes in PR #176 and compare to your own.

@Defee I have pretty much just taken the Serilog Implementation and renamed it to NLog. You can see my actual changes in PR #176 and compare to your own.

Sure will do over the week.
P.S. Tested now it seems it builds as of now and tests pass.
P.P.S. I was actually thinking to add ILogEvent interface addition to abstractions as for some things it is really useful (ex: app insights.)

@snakefoot
I saw that the stakeframe test is failing for the implementation when I merged your code.
I think I faces it before and added a workaround for it from my side:
        /// <summary>
        /// Actually sends the message to the underlying log system.
        /// </summary>
        /// <param name="logLevel">the level of this log event.</param>
        /// <param name="message">the message to log</param>
        /// <param name="exception">the exception to log (may be null)</param>
        protected override void WriteInternal(LogLevel logLevel, object message, Exception exception)
        {
            LogLevelNLog level = GetLevel(logLevel);
            LogEventInfo logEvent =
                LogEventInfo.Create(level, _logger.Name, exception, null,"{0}", new object[] {message});

            _logger.Log(declaringType, logEvent);
        }

        private static LogLevelNLog GetLevel(LogLevel logLevel)
        {
            switch (logLevel)
            {
                case LogLevel.All:
                    return LogLevelNLog.Trace;
                case LogLevel.Trace:
                    return LogLevelNLog.Trace;
                case LogLevel.Debug:
                    return LogLevelNLog.Debug;
                case LogLevel.Info:
                    return LogLevelNLog.Info;
                case LogLevel.Warn:
                    return LogLevelNLog.Warn;
                case LogLevel.Error:
                    return LogLevelNLog.Error;
                case LogLevel.Fatal:
                    return LogLevelNLog.Fatal;
                case LogLevel.Off:
                    return LogLevelNLog.Off;
                default:
                    throw new ArgumentOutOfRangeException("logLevel", logLevel, "unknown log level");
            }
        }

What side-effects can it bring?

I saw that the stakeframe test is failing for the implementation when I merged your code.

Thank you for reporting this. Guess that is the price of copy-paste-code. Guess it is time to divert from the Serilog-default-implementation.

What side-effects can it bring?

Well WriteInternal in my PR is never called (That is why it is empty). Because Common.Logging enforces use of string.Format but Serilog (And NLog) wants to use their own parsing of the format-string. Therefore they put great effort in avoiding Common.Logging "helper"-logic.
I have now updated my  PR #176 to include better handling of callsite.

Thanks @snakefoot! Will merge it again.

Common.Logging.Core
Common.Logging
Common.Logging.NLog45

I checked following things and what have I done back in November 2018:

[x] Migrating Common assemblies to the netframework2.0 (Common.Logging, Common.Loggin.Core)
[x] Updating the CommonLoggingIntegration with NLog. Taking into consideration PR: #176
[x] Migration for the Serilog implementation.
[x] Migration for the ApplicationInsigts.
[x] Migration for the log4net.
[ ] Making log4net tests pass.
[ ] Migration EntLib to support versioning for the net45+
[ ] Check implementation and posssibility of the migration of the ETWLogger
[ ] Check that nothing was broken for the old assemblies and the old solutions still build and tests pass there.

I wanted to suggest the following approach for the 4.x.x versioning

Use the .csproj for specifying nuget related properties (imho it is much more convinient then it was before with nuspec...)
Use different approach to handle compatibility and issues for the particular version integrations. (I outlined it below)
Decouple the solution/git repo a little bit so we have less mess with components.

Current Issues and breaking changes(as per my memory now):

I migrated all the assemblies to the 4.5+ versioning, so newer versions will not support old frameworks.
I plan to have separate solution which will have only new netstandard compatible assemblies and keep old solutions for a while.
I didn't find a way to support portable so it will be broken and can be replaced with the netstandard versions I bellieve.
As Silverlight will meet its sunset soon. I didn't migrate it to the netframework.
As there are a lot of known issues for the AssemblyInfo attributes it was moved to the .csproj files.
I haven't made any changes to nuspec files as I use .csproj to pack.
I remember I implemented the following lookup files for the common.logging in netstandard via Microsoft Configuration extensions: "appsettings.json", "appsettings.xml", "CommonLoggingCfg.json", "CommonLoggingCfg.xml". If you specified one of the files it should be working as usual. In future we might want to have the setup for configuration or passing IConfigurationOptions to common logging from upper layers and changed it as the preferable lookup for the common logging.

Suggested approach for the versioning integrations and checking those separately.

Separte the main Common.Logging assemblies which are related to the framework specificly with the integrations. Structure suggested:

Common.Logging.Core, Common.Logging, Common.Logging.Common - current repo
Common.Logging.NLog and relavant to NLog tests - separate repository which will have related integration assembly and Integrational tests.
Common.Logging.log4net and relavant to log4net tests - separate repository which will have related integration assembly and Integrational tests.
Common.Logging.EntLib and relavant to EntLib tests - separate repository which will have related integration assembly and Integrational tests. (if we still plan to support it)
Common.Logging.Serilog and relavant to Serilog tests - separate repository which will have related integration assembly and Integrational tests.
Common.Logging.ApplicationInsights and relevant tests - separate repository which will have related integration assembly and Integrational tests and also will have the integration with default ILogger from .netcore.

Use the branches in the above repositories related to integrations to monitor compatibility, also it might be a compatibility builds which will restore particular versions. Ex for NLog:

NLog - master - contains latest supported version, with common workarounds and files for all the versions. When the new versions is shipped by the NLog we just branch out new release and update the master to the latest.
NLog - release4.5 - containing the package verisions and amendements related only to this version.
NLog - release4.1 - containing the package verisions and amendements related only to this version, etc.

Use PackageReferences in the independant projects instead of the project references. So we can test against particular version of common.logging. It will also give a touch of real environment :()

The pros of the suggested approach are following:

Better management for the issues.
Better maintainability for the framework as the whole.
Faster delivery of particular version or integration. Better troubleshouting as you can just take relevant branch and see if it is version specific bug.
More independence for the integrations of the main code base.
Better use for the versions compatibility and builds as you can create a separate branch per integration version which will have the particular configuration or use CI builds to trigger other builds for the repos.

Cons:

More headache and maintainance for the CI builds and release builds.
Might be some code duplication for tests which can be resolved with the build tools.

PS.
@sbohlen, I can volonteer for the change above.

I vote for original proposition: version 4.0 only for Dotnet Core.
In theory NetStandard should be soon supported anywhere so it seems perfect solution.
Beware of these issues: https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET
In particular important issue is with configuration. Current dotnet implementation of Common.Logging doesn't support old configuration at all. Which is a mistake because of legacy applications.
I have following situation in my company:
Old applications (WCF, Web Forms) --> our common libraries --> Common.Logging
New applications (Asp.Net Core) --> our common libraries --> Common.Logging
So you see that we would prefer to have only one version of Common.Logging to be used anywhere. Otherwise we would have to multitarget common libraries.
But old applications require that app.config/web.config is handled properly by NetStandard version of Common.Logging
In my private clone of Common.Logging I've added support for old configurations. I've observed following:
ConfigurationManager is not supported in any version of NetStandard. It can be provided by NuGet package. This however have disadvantages: what if Nuget used for common.logging has incompatible version with that used by the client application?
Proposed solution: to create separate assembly Common.Logging.Configuration, It could be written in old .NET Framework as it would be used only for legacy applications. Disadvantage: configure will not be loaded automatically, client application have to call something like LogManager.Configure()
I think that it is acceptable.
Next thing is that Common.Logging should provide implementation for Microsoft.Extensions.Logging abstraction.
We need Common.Logging because we are using Spring.Net in our company, and we need Microsoft.Extensions.Logging because of ASP.NET Core.


Reduce memory consumption to save cash on Railway

Note: overall it didn't work yet. Memory leak in /web-scrape confirmed. Need to close connections, maybe related to beautiful soup or S3 uploads...

@jkmin3 do you have any ideas where a memory leak could be in /web-scrape?

Much improved, saving $40/mo easily.


Support transforming v3 spec to v2 in CLI

It would be nice to support transforming a v3 spec to v2 using the paperclip CLI. I think v2 and v3 only change in their structure, but if there's something more, then we can use vendor extensions to cover whatever we need.

This would be a nice project to be done in https://github.com/pickfire/babelfish as well, maybe we could collaborate?

@pickfire I'd love to do that, but it looks like babelfish is a converter for encodings, whereas OpenAPI is a specification which could be in any encoding (JSON/YAML), so this is probably not in the scope of babelfish?

Not really a converter for encodings, just a converter for stuff. Right now only encodings is there because encodings conversion is the easiest.
This is probably a good first non-encoding conversion.

... just a converter for stuff.

Isn't this ambiguous? Either way, it's probably time to update the scope of babelfish in its README and project description. 😄
Paperclip, on the other hand, is focusing entirely on tooling related to OpenAPI, which includes converting v3 to v2 and vice versa, which is why I believe it's well within the scope of this project.

One other thing I'd like to point out here is that the v2 and v3 spec aren't exactly interchangeable (v2 to v3 is straightforward, but the other way around isn't), so this also involves making a few decisions along the way, which may not be accepted by other OAPI tools because there's no universally accepted way to do that conversion.

Isn't this ambiguous? Either way, it's probably time to update the scope of babelfish in its README and project description.

True, but I do like it being ambiguous rather than sprinkling around how I see serde_*, even though some have very similar API (like serde_json and serde_cbor), it is not simple to just swap one with the other (like serde_yaml with serde_json).
So it might be good to have something for converting stuff, but at least try to get a similar API.

This would be a nice workaround for https://github.com/paperclip-rs/paperclip/issues/476
There are very few tools which can do this. c.f. https://stackoverflow.com/questions/56637299/convert-openapi-3-0-to-swagger-2-0

The transformations I needed to get my openapi 3 doc accepted by the v2 parser:

Replace openapi: 3.x with swagger: 2.0
Move components.schemas mapping to be top level definitions , and transform any $ref value in the same way, i.e. changing "#/components/schemas/ABC" to "#/definitions/ABC"

The result isnt perfect, but it is good enough for what I need atm .


template syntax error when using --debug

Operating system
Ubuntu 22.04
Helmfile Version
v0.155.1
Helm Version
v3.12.2
Bug description
When running without --debug, this error doesn't show up and the result is outputted as expected.
However, when running with --debug, helmfile issues this template syntax error in the logs which is quite confusing.
I was investigating a real problem, and decided to enable --debug to see if I could catch more information. I immediately found this template syntax error and realized after some time that it's apparently normal.
Maybe there is something that could be done in helmfile to avoid such a misleading --debug message?
Example helmfile.yaml
environments:
  default:
    values:
      - values.yaml.gotmpl

---

{{ $_ := .Values.thisIsAlwaysSet | required "thisIsAlwaysSet is not set" }}

repositories:
 - name: prometheus-community
   url: https://prometheus-community.github.io/helm-charts

releases:
- name: prom-norbac-ubuntu
  namespace: prometheus
  chart: prometheus-community/prometheus
  set:
  - name: rbac.create
    value: false

Error message you've seen (if any)
processing file "helmfile.yaml.gotmpl" in directory "."
changing working directory to "/tmp/tmp.KfYzjZq0Id"
first-pass rendering starting for "helmfile.yaml.gotmpl.part.0": inherited=&{default  map[] map[]}, overrode=<nil>
first-pass uses: &{default  map[] map[]}
first-pass rendering output of "helmfile.yaml.gotmpl.part.0":
 0: environments:
 1:   default:
 2:     values:
 3:       - values.yaml.gotmpl
 4:

envvals_loader: loaded values.yaml.gotmpl:map[thisIsAlwaysSet:true]
first-pass produced: &{default  map[thisIsAlwaysSet:true] map[]}
first-pass rendering result of "helmfile.yaml.gotmpl.part.0": {default  map[thisIsAlwaysSet:true] map[]}
vals:
map[thisIsAlwaysSet:true]
defaultVals:[]
second-pass rendering result of "helmfile.yaml.gotmpl.part.0":
 0: environments:
 1:   default:
 2:     values:
 3:       - values.yaml.gotmpl
 4:

envvals_loader: loaded values.yaml.gotmpl:map[thisIsAlwaysSet:true]
merged environment: &{default  map[thisIsAlwaysSet:true] map[]}
first-pass rendering starting for "helmfile.yaml.gotmpl.part.1": inherited=&{default  map[thisIsAlwaysSet:true] map[]}, overrode=<nil>
first-pass uses: &{default  map[thisIsAlwaysSet:true] map[]}
first-pass rendering input of "helmfile.yaml.gotmpl.part.1":
 0:
 1: {{ $_ := .Values.thisIsAlwaysSet | required "thisIsAlwaysSet is not set" }}
 2:
 3: repositories:
 4:  - name: prometheus-community
 5:    url: https://prometheus-community.github.io/helm-charts
 6:
 7: releases:
 8: - name: prom-norbac-ubuntu
 9:   namespace: prometheus
10:   chart: prometheus-community/prometheus
11:   set:
12:   - name: rbac.create
13:     value: false
14:

template syntax error: template: stringTemplate:2:35: executing "stringTemplate" at <required "thisIsAlwaysSet is not set">: error calling required: thisIsAlwaysSet is not set
first-pass rendering output of "helmfile.yaml.gotmpl.part.1":
 0:
 1:

first-pass produced: &{default  map[thisIsAlwaysSet:true] map[]}
first-pass rendering result of "helmfile.yaml.gotmpl.part.1": {default  map[thisIsAlwaysSet:true] map[]}
vals:
map[thisIsAlwaysSet:true]
defaultVals:[]
second-pass rendering result of "helmfile.yaml.gotmpl.part.1":
 0:
 1:
 2:
 3: repositories:
 4:  - name: prometheus-community
 5:    url: https://prometheus-community.github.io/helm-charts
 6:
 7: releases:
 8: - name: prom-norbac-ubuntu
 9:   namespace: prometheus
10:   chart: prometheus-community/prometheus
11:   set:
12:   - name: rbac.create
13:     value: false
14:

merged environment: &{default  map[thisIsAlwaysSet:true] map[]}
helm:wzGhr> v3.12.2+g1e210a2
helm:wzGhr>
---
#  Source: /tmp/tmp.KfYzjZq0Id/helmfile.yaml.gotmpl

filepath: helmfile.yaml.gotmpl
helmBinary: helm
environments:
  default:
    values:
    - values.yaml.gotmpl
repositories:
- name: prometheus-community
  url: https://prometheus-community.github.io/helm-charts
releases:
- chart: prometheus-community/prometheus
  name: prom-norbac-ubuntu
  namespace: prometheus
  set:
  - name: rbac.create
    value: "false"
templates: {}
renderedvalues:
  thisIsAlwaysSet: true
changing working directory back to "/tmp/tmp.KfYzjZq0Id"

Steps to reproduce
https://github.com/felipecrs/helmfile-template-syntax-error
Working Helmfile Version
N/A
Relevant discussion
No response

@felipecrs PR is welcome.

@felipecrs I found the issue. you can see this:
Helmfile currently relies on a hack called "double rendering" which no one understands correctly (I suppose) to solve the chicken-and-egg problem of rendering the helmfile template(which requires helmfile to parse environments as yaml first) and parsing the rendered helmfile as yaml(which requires helmfile to render the template first).

That makes sense. Maybe we should hide errors during first pass as they are almost "expected"?
Or is this "hack" supposed to be removed in V1 too?

@felipecrs yes. It will be removed in v1.

Ok, in this case I can close this issue. Thanks!


Support CRI v1 and v1alpha at the same time

#1392 switched the CRI api from v1alpha2 to v1, however it created an issue (#1484) as containerd v1.5 doesn't support v1, #1485 reverted it back to v1alpha2 to support containerd v1.5.
Different runtimes removed (or are removing) support for v1alpha (https://github.com/inspektor-gadget/inspektor-gadget/pull/1485#issuecomment-1494116963), hence we should make Inspektor Gadget compatible with both versions. containerd and cri-o support(ed) both versions at the same time https://github.com/cri-o/cri-o/pull/4408 & https://github.com/containerd/containerd/pull/5619, hence I think this is doable from a technical point of view.

In case we want to bump the k8s.io/cri-api to >= v0.26.0 we need to copy cri-api v1alpha2 locally as done here. In case we want to support v1alpha2 for longer period ?

IMO we need to continue supporting v1alpha2 for a long period. If the solution you proposed above is not too difficult I'd suggest to implement this now to be able to update the k8s.io/cri-api version.

IMO we need to continue supporting v1alpha2 for a long period. If the solution you proposed above is not too difficult I'd suggest to implement this now to be able to update the k8s.io/cri-api version.

The proposed solution shouldn't be hard to implement. Makes sense to be able to update k8s.io/cri-api version. I reopened the issue to track it.


Refactor completion provider to be more general.

Today the completion provider is tied to VS windows / VS mac. We should refactor it to be more general so it can be reused on multiple platforms.

572b55690dd23e9df3239681dba5fc3c46022e6e


Support For Composition Inverses

Summary
Added grammar support for built-in math functions:

asin

acos

atan

Details and comments
Per issue: 124
Files modified:   source/grammar/qasm3.g4
Lines Modified:   411-423

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

Hello, and thanks for this!
The examples given in #124 use the inverse trig functions with the names arccos, etc, as opposed to acos, as in this PR.  We should decide which actually want to have.  I personally prefer arccos, but C, Rust and Python all use acos.
We'll also need to add some tests of these to the CI runs, probably in the "builtin calls" file.

I personally prefer arccos

Same, OpenQASM tends to be biased towards spelling things out explicitly.

Sorry, been a little tied up lately.
I've updated it to use arc instead, I've also added in tests for all the built-in math functions


how to hide first and last arrow "react-splide"

But how do we do this in react-splide? It's hard to believe that there is no solution? Any work around to hide next-Arrow and prev-Arrow when first/last slide is active for react-splide? Thanks in advance!
Originally posted by @Learning-X in https://github.com/Splidejs/splide/discussions/471#discussioncomment-2471181

This has been already answered. Add styles to the disabled pseudo-class as you like.
https://developer.mozilla.org/en-US/docs/Web/CSS/:disabled


Allow writing out arbitrary text

If it was possible to write out arbitrary text as part of modeling it would be possible to export G-code, allowing one to directly do CAM.

@WillAdams
Apologies for the delayed response.
Nodi is currently developing Version 2, and Version 1 has now been deprecated. Version 2 is available as an early access release at https://v2.nodi3d.com/.
I appreciate your feedback and will consider it for inclusion in Version 2. If possible, I’d be grateful if you could also share your feedback on the Version 2 forum.


More flexible chained api

in addition to:
https://pepyakin.github.io/wasmi/wasmi/struct.ModuleRef.html#method.invoke_export
used in the following way
        instance.invoke_export(
            "test",
            &[],
            &mut NopExternals,
        ).expect("failed to execute export")

something like
instance.export("test").with_externals(&mut NopExternals).with_args(&[]).invoke()
?

How does this look for a start?
instance
    .export_by_name(func_name)?
    .as_func()?
    .with_externals(&mut NopExternals)
    .with_args(&args)?
    .invoke()
    .ok()?;

export_by_name() -> Option<ExternVal> and as_func() -> Option<&FuncRef> already exist.
The rest could be implemented by adding the following to func.rs:
impl FuncRef {
    pub fn with_externals<'a, E: Externals>(
        &'a self,
        externals: &'a mut E,
    ) -> BoundExternalsFunc<'a, E> {
        BoundExternalsFunc {
            func_instance: self,
            externals,
        }
    }
}

/// First step in chained function calling pattern.
pub struct BoundExternalsFunc<'a, E: Externals + 'a> {
    func_instance: &'a FuncRef,
    externals: &'a mut E,
}

impl<'a, E: Externals> BoundExternalsFunc<'a, E> {
    pub fn with_args(self, args: &'a [RuntimeValue]) -> Option<BoundFunc<'a, E>> {
        BoundFunc::new(self.func_instance, self.externals, args)
    }
}

/// FuncRef with verified arguments.
pub struct BoundFunc<'a, E: Externals + 'a> {
    func_instance: &'a FuncRef,
    externals: &'a mut E,
    args: &'a [RuntimeValue],
}

impl<'a, E: Externals> BoundFunc<'a, E> {
    fn new(
        func_instance: &'a FuncRef,
        externals: &'a mut E,
        args: &'a [RuntimeValue],
    ) -> Option<BoundFunc<'a, E>> {
        check_function_args(func_instance.signature(), &args).ok()?;
        Some(BoundFunc {
            func_instance,
            externals,
            args,
        })
    }

    pub fn invoke(&mut self) -> Result<Option<RuntimeValue>, Trap> {
        FuncInstance::invoke(&self.func_instance, self.args, self.externals)
    }
}

I can submit a pr, just checking first to see if this is approach it useful.

Hello, @bddap ! I'm very sorry for the delay and for that I missed your comment.
Yeah, it is a good start. But we can go beyond that. For example, there is a related problem with limits (#51). And we might want to add other configuration options.
Can you see an approach that can incorporate such changes?

This issue is no longer relevant due to the fact that the current wasmi version is using Wasmtime based API which mostly is pretty well designed already.


External devices

@mars979 I see you have new commits here? Is this ready to merge?

Sorry, missed your comment. I have a few more devices that need to be added, but we can merge these right now.


Fix link

The link to declare_builtin_fields.md was broken in several ways.  Is GitHub markdown the intended target or is there another environment (like crates.io, ...) with other requirements this links were intented to render in?
I haven't found what file the other link (declare_derive) was intended to link to.   It's broken as well. Perhaps the content is now inlined in custom_widget_declar_in_macro.md (this file, that contains the link)

Thank you! You fixed [builtin_fields] correctly. And declare_derive should link to the API document, we haven't released a version yet, so there is no API documents.


Flutter module

i want to make better documentation on flutter

cc @mravn-google who I believe is moving over contents from this branch. I suspect this PR should be closed?

Yes, it does appear to have been created by mistake.


ctx.session storage intent is delayed

Now, we use bot.use(session()) to store the intent of user's input.
We found that there was a long delay in updating and reading data during a spike in usage.
We plan to write the changes to our database. Wish us good luck.

Upgrade success!


Delete external techno queries

To follow product lifecycle, we need to delete external techno references.

Trello card: [#223] Delete external techno queries


MyTagCollection: Support reactive update

Support reactive data handling of data

Add reactive like update using protocol this is to not add additional dependency.
Addressed in PR


Enable globe lighting for 3D Tilesets

The Globe.enableLighting flag does not affect the lighting of 3D Tilesets.
The default Globe with viewer.scene.globe.enableLighting = true shows one side of the Earth dark, as expected:

The same view using Google's Photorealistic 3D Tiles appears uniformly lighted, except that the SkyAtmosphere is dark on one side:

Users should be able to apply global lighting to 3D Tilesets. This has already been requested on the forum.

Just a note here that Google's tiles use the glTF unlit extension because there is already lighting "baked in". That extension which would need to be ignored in order to implement this.


Remove lock around Get/Set Router Ctx

This change is

Afaict and as discussed offline, removing the lock does not change anything about the semantics of how the global context is used within the router.

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


ONS Tutorial updates

This is... A big pull request. In general, it shouldn't have a super large impact on the core functionality. There's a few things we need from this to move forward as it fixes a couple bugs that we have noticed along the way too.
Happy to either work on fixes herein, or... Fix up as pull requests after the fact. I'll leave that to you guys if you have any preference.

@dougbtv somewhat related/unrelated, would you mind fixing up the .travis-ci.yml file and making sure the linting is hitting the appropriate files? It would be good to validate that your changes are ansible-lint valid as well...


rbenv version shows symlinks acting like aliases

Show symlinks acting like aliases under $RBENV_ROOT/versions:

Before this symlink aliases would display just like any other version, making it hard to distinguish between "real" versions and symlinks that are just shortcuts.
:construction: Proof of concept. Needs code cleanup, tests. :construction:
This is slated for a post-1.0 release. In discussion with @sstephenson we thought that it would be a good idea to pair this with an rbenv alias command to manage such aliases.
(h/t to @tpope https://github.com/tpope/rbenv-aliases)

Show symlinks acting like aliases under $RBENV_ROOT/versions:

Before this symlink aliases would display just like any other version, making it hard to distinguish between "real" versions and symlinks that are just shortcuts.
:construction: Proof of concept. Needs code cleanup, tests. :construction:
This is slated for a post-1.0 release. In discussion with @sstephenson we thought that it would be a good idea to pair this with an rbenv alias command to manage such aliases.
(h/t to @tpope https://github.com/tpope/rbenv-aliases)


Transpiler handles approximation_degree=0.0 as approximation_degree=None

As noted in #8595 and elsewhere, the transpiler currently mishandles approximation_degree=0.0 as approximation_degree=None (which is approximation_degree=1.0). Following the definition of approximation_degree here:
https://github.com/Qiskit/qiskit-terra/blob/367ed4e34a3d662ef8ed8f2b91e8823bba1b8ca8/qiskit/compiler/transpiler.py#L178
approximation_degree=0.0 should maximally approximate (however that is defined by the relevant pass). Currently, I think there's a bug in handling approximation_degree IIRC in the TwoQubitBasisComposer (by this point, basis_fidelity)
https://github.com/Qiskit/qiskit-terra/blob/dbc81a8dcdae9e9294b9058babf5883258daaa5d/qiskit/quantum_info/synthesis/two_qubit_decompose.py#L1087
that causes this, but this would need to be confirmed first.

expected_fidelities gives an strange value in the case approximation_degree = 0.0, it gives an result of 1 instead of a small value.
qiskit-terra/qiskit/quantum_info/synthesis/two_qubit_decompose.py
line 1092
The values are
0		1.0
0.1		0.0010000000000000002
0.2		0.008000000000000002
0.3		0.026999999999999996
0.4		0.06400000000000002
0.5		0.125
0.6		0.21599999999999997
0.7		0.3429999999999999
0.8		0.5120000000000001
0.9		0.7290000000000001
1		1.0

Test code
` ``
ap_list = [0.0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9, 1.0]
for ap in ap_list:
circ_10 = transpile(
circuit,
basis_gates=["u", "cx"],
translation_method="synthesis",
approximation_degree = ap,
)


change "Twitter" to "𝕏 (Twitter)" In README.md Follow us Section

Twitter Badge is updated to new logo badge in README.md

In Follow us section:
Currently:

Suggested Change:

Done it other https://github.com/codedthemes/berry-free-react-admin-template/pull/80


Elasticsearch logs receiver segfaults fluentbit (debian-11)

Version: 2.10.0~debian11
When installing and setting up the elasticsearch logging receiver on debian-11, it seems that the configuration causes a segfault in fluentbit.
Output from journalctl for the fluentbit process:
Feb 14 14:05:17 brandon-testing-elasticsearch fluent-bit[65736]: Fluent Bit v1.8.12
Feb 14 14:05:17 brandon-testing-elasticsearch fluent-bit[65736]: * Copyright (C) 2019-2021 The Fluent Bit Authors
Feb 14 14:05:17 brandon-testing-elasticsearch fluent-bit[65736]: * Copyright (C) 2015-2018 Treasure Data
Feb 14 14:05:17 brandon-testing-elasticsearch fluent-bit[65736]: * Fluent Bit is a CNCF sub-project under the umbrella of Fluentd
Feb 14 14:05:17 brandon-testing-elasticsearch fluent-bit[65736]: * https://fluentbit.io
Feb 14 14:05:17 brandon-testing-elasticsearch fluent-bit[65736]: [2022/02/14 14:05:17] [engine] caught signal (SIGSEGV)
Feb 14 14:05:17 brandon-testing-elasticsearch fluent-bit[65736]: ERROR: no debug info in ELF executable (-1)ERROR: no debug info in ELF executable (-1)ERROR: no debug info in ELF executable (-1)ERROR: no debu>

I've found that this is related to the multiline config for Elasticsearch. It seems like it works just fine with the previous commit of fluentbit we were pointing to, but with fluentbit v1.8.12 this segfault occurs.
This probably effects other receivers that have similar multiline config (e.g. zookeeper), but I haven't tested these.

https://github.com/fluent/fluent-bit/issues/4944 fixes the ELF which underneath is a SIGSEGV problem but however, v1.8.13 has other issues: https://github.com/fluent/fluent-bit/issues/4991


[B11] Magic Mirror Lacks Check For Existence

I was making an infinite loop with a couple magic mirrors. I discovered if I broke the top dispensing mirror the loop continued as if the dispensing mirror was still there. This happens both in creative and survival.

The code to remove the mirror from the world was soft crashing meaning that the block was removed, but not the attached tile entity.


version 2 vote

The diagrams still say version 2 vote pod. Also timeout direction should be reversed. Look at the blog here
https://developer.ibm.com/code/2017/08/17/make-microservices-resilient-fault-tolerant-using-istio/

@Tomcli


build fail

../../ksyun/src/github.com/gohugoio/hugo/helpers/content.go:265:16: undefined: blackfriday.HTML_SMARTYPANTS_QUOTES_NBSP
commit : 0dbf79c2f8cd5b1a5c91c04a8d677f956b0b8fe8

I think we should use vendor.

go get -u gopkg.in/russross/blackfriday.v2

I think we should use vendor.

We do. Read the README -- if still issue, ask at https://discourse.gohugo.io/

No vendor directory in source code.

Build and Install the Binaries from Source (Advanced Install)
Add Hugo and its package dependencies to your go src directory.

go get -v github.com/gohugoio/hugo
Once the get completes, you should find your new hugo (or hugo.exe) executable sitting inside $GOPATH/bin/.

To update Hugo’s dependencies, use go get with the -u option.

go get -u -v github.com/gohugoio/hugo

I think it should add dep ensure to make sure the deps in readme.
SHOULD I fork the readme and make a pr?


date command return unexpected result

~ ➤ zsh --version
zsh 5.3 (x86_64-apple-darwin17.0)
~ ➤ date +%s%N
1524113639N
expected :
date +%s%N
1524113698007063000

%N is not a builtin date format character so its validity depends on the call to strftime, which is system dependent. In the online docs there isn't a valid specification for it: http://man7.org/linux/man-pages/man3/strftime.3.html
What do you expect it to be? I can't figure it out based on your expected output.

Nevermind, I see you were looking for nanoseconds. It seems your version of date doesn't support that: https://apple.stackexchange.com/a/135749.
Not an OMZ issue though, make sure to sort that out before posting an issue here. Thanks!


.36 .40

These changes create an effect to zoom in and I think it's a cool!

Yehi

Hi! I think your code break the design when the user aren't in the hover card. Try to add the transform style in the actual hover pseudo-class


Move Traits under correct chapter, because Traits is experimental feat.

17:34:53 [ERROR] Internal error in org.kie.workbench.common.stunner.core.processors.MainProcessorjava.lang.ExceptionInInitializerError

Jenkins, test again

18:20:29 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project drools-wb-drl-text-editor-client: Compilation failure
18:20:29 [ERROR] /home/jenkins/workspace/kie-docs-pullrequests/upstream-repos/drools-wb/drools-wb-screens/drools-wb-drl-text-editor/drools-wb-drl-text-editor-client/src/main/java/org/drools/workbench/screens/drltext/client/editor/DRLEditorPresenter.java:[176,44] non-static method showMessages(java.util.List<org.guvnor.common.services.shared.validation.model.ValidationMessage>) cannot be referenced from a static context

Jenkins, test again

18:35:33 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.5.1:compile (default-compile) on project drools-wb-dsl-text-editor-client: Compilation failure
18:35:33 [ERROR] /home/jenkins/workspace/kie-docs-pullrequests/upstream-repos/drools-wb/drools-wb-screens/drools-wb-dsl-text-editor/drools-wb-dsl-text-editor-client/src/main/java/org/drools/workbench/screens/dsltext/client/editor/DSLEditorPresenter.java:[122,44] non-static method showMessages(java.util.List<org.guvnor.common.services.shared.validation.model.ValidationMessage>) cannot be referenced from a static context

Jenkins, test again

Jenkins please retest this.

Build successful! See generated HTML docs (may take a while till they are available):
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs-pullrequests/245//artifact/docs/drools-docs/target/generated-docs/html_single/index.html
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs-pullrequests/245//artifact/docs/jbpm-docs/target/generated-docs/html_single/index.html
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs-pullrequests/245//artifact/docs/optaplanner-wb-es-docs//target/generated-docs/html_single/index.html

Not to hold this PR back, but traits have been there for a long time now. Maybe it's time to reconsider this "experimental" status and either make it official or deprecated?

Build successful! See generated HTML docs (may take a while till they are available):
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs-pullrequests/246//artifact/docs/drools-docs/target/generated-docs/html_single/index.html
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs-pullrequests/246//artifact/docs/jbpm-docs/target/generated-docs/html_single/index.html
https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs-pullrequests/246//artifact/docs/optaplanner-wb-es-docs//target/generated-docs/html_single/index.html

@triceo I see your point but this is really not my call - I also believe the answer is to take the necessary steps to make it official, but at the same time I don't believe those steps are feasible in time for 7.0


Document this code lense getting duplicated in some occasions

Description:
Document this code lense getting duplicated in some occasions.

Steps to reproduce:
Affected Versions:
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

This is not reproducible in alpha2 release. Thus closing the issue


ERROR ~ Error executing process > 'NFCORE_RNASPLICE:RNASPLICE:DRIMSEQ_DEXSEQ_DTU_SALMON:DRIMSEQ_FILTER (1)'

Description of the bug
My aim was to run rnasplice to output results for SUPPA2.  It is not clear whether the following is an error on my part, or there are no significant results.  !No genes left after filtering! makes we think it is the latter, but your opinion would be welcome.  I am happy to provide more information if it help.
Command used and terminal output
Command line:
nextflow run nf-core/rnasplice --input samplesheet_fastqs_minus.csv --contrasts contrastsheet_minus.csv --outdir RNA-seq_fastqs_minus_samples -profile singularity -r 1.0.2 --rmats --source fastq --fasta Saccharomyces_cerevisiae.R64-1-1.dna.toplevel.fa --gtf Saccharomyces_cerevisiae.R64-1-1.111.gtf --miso_genes <redacted> --aligner star_salmon --rmats_read_len 139

Output:
ERROR ~ Error executing process > 'NFCORE_RNASPLICE:RNASPLICE:DRIMSEQ_DEXSEQ_DTU_SALMON:DRIMSEQ_FILTER (1)'

Caused by:
  Process `NFCORE_RNASPLICE:RNASPLICE:DRIMSEQ_DEXSEQ_DTU_SALMON:DRIMSEQ_FILTER (1)` terminated with an error exit status (1)

Command executed:

  run_drimseq_filter.R salmon.merged.txi.dtu.rds tximport.tx2gene.tsv samplesheet_fastqs_minus.csv \
      4 \
      2 \
      2 \
      10 \
      0.1 \
      10

  cat <<-END_VERSIONS > versions.yml
  "NFCORE_RNASPLICE:RNASPLICE:DRIMSEQ_DEXSEQ_DTU_SALMON:DRIMSEQ_FILTER":
      r-base: $(echo $(R --version 2>&1) | sed 's/^.*R version //; s/ .*$//')
      bioconductor-drimseq: $(Rscript -e "library(DRIMSeq); cat(as.character(packageVersion('DRIMSeq')))")
  END_VERSIONS

Command exit status:
  1

Command output:
  (empty)

Command error:
  INFO:    Converting SIF file to temporary sandbox...
  WARNING: Skipping mount /usr/local/singularity-ce-3.11.2/var/singularity/mnt/session/etc/resolv.conf [files]: /etc/resolv.conf doesn't exist in container

  Attaching package: 'DRIMSeq'

  The following object is masked from 'package:base':

      proportions

  Error in dmDS_filter(counts = x@counts, min_samps_gene_expr = min_samps_gene_expr,  :
    !No genes left after filtering!
  Calls: <Anonymous> -> <Anonymous> -> .local -> dmDS_filter
  Execution halted
  INFO:    Cleaning up image...

Work dir:
  <redacted>/work/69/970b0a2cad7dab41066bb18623d068

Tip: when you have fixed the problem you can continue the execution adding the option `-resume` to the run command line

 -- Check '.nextflow.log' file for details

Relevant files
No response
System information
nextflow version <IP_ADDRESS>66, run locally on server
singularity container 3.11.2
Linux Ubuntu 22.04.3 LTS
nf-core/rnasplice 1.0.2

Hello @IanCodes
Would you mind re-running the pipeline with the following configuration:
min_samps_gene_expr: 0
min_gene_expr: 0
min_samps_feature_expr: 0
min_feature_expr: 0
min_samps_feature_prop: 0
min_feature_prop: 0
These parameters should effectively stop any filtering. If you still encounter the same issue, let me know and I can take a deeper look.

Hello @jma1991,
Thank you for your reply and apologies for the delayed response.
I ran the following command line:
nextflow run nf-core/rnasplice --input samplesheet_fastqs_minus.csv --contrasts contrastsheet_minus.csv --outdir RNA-seq_fastqs_minus_samples_MINSIG -profile singularity -r 1.0.2 --source fastq --fasta Saccharomyces_cerevisiae.R64-1-1.dna.toplevel.fa --gtf Saccharomyces_cerevisiae.R64-1-1.111.gtf --aligner star_salmon --rmats false --suppa true --dexseq_exon false --dexseq_dtu false --sashimi_plot false --edger_exon false --min_samps_gene_expr 0 --min_gene_expr 0 --min_samps_feature_expr 0 --min_feature_expr 0 --min_samps_feature_prop 0 --min_feature_prop 0
But I still got an error:
ERROR ~ Error executing process > 'NFCORE_RNASPLICE:RNASPLICE:DRIMSEQ_DEXSEQ_DTU_SALMON:DRIMSEQ_FILTER (1)'

Caused by:
  Process `NFCORE_RNASPLICE:RNASPLICE:DRIMSEQ_DEXSEQ_DTU_SALMON:DRIMSEQ_FILTER (1)` terminated with an error exit status (1)

Command executed:

  run_drimseq_filter.R salmon.merged.txi.dtu.rds tximport.tx2gene.tsv samplesheet_fastqs_minus.csv \
      0 \
      0 \
      0 \
      0 \
      0 \
      0

  cat <<-END_VERSIONS > versions.yml
  "NFCORE_RNASPLICE:RNASPLICE:DRIMSEQ_DEXSEQ_DTU_SALMON:DRIMSEQ_FILTER":
      r-base: $(echo $(R --version 2>&1) | sed 's/^.*R version //; s/ .*$//')
      bioconductor-drimseq: $(Rscript -e "library(DRIMSeq); cat(as.character(packageVersion('DRIMSeq')))")
  END_VERSIONS

Command exit status:
  1

Command output:
  (empty)

Command error:
  INFO:    Converting SIF file to temporary sandbox...
  WARNING: Skipping mount /usr/local/singularity-ce-3.11.2/var/singularity/mnt/session/etc/resolv.conf [files]: /etc/resolv.conf doesn't exist in container

  Attaching package: 'DRIMSeq'

  The following object is masked from 'package:base':

      proportions

  Error in dmDS_filter(counts = x@counts, min_samps_gene_expr = min_samps_gene_expr,  :
    !No genes left after filtering!
  Calls: <Anonymous> -> <Anonymous> -> .local -> dmDS_filter
  Execution halted
  INFO:    Cleaning up image...

Work dir:
 <REDACTED>/work/44/6b45b957ccdafc9f5e93c4b0b7cc34

Tip: view the complete command output by changing to the process work dir and entering the command `cat .command.out`

 -- Check '.nextflow.log' file for details

This may or may not be related, but I cannot reproduce results obtained from the stand-alone rMATS-turbo (4.2) with rnasplice.    The summary file of the stand-alone shows:
EventType       EventTypeDescription    TotalEventsJC   TotalEventsJCEC SignificantEventsJC     SigEventsJCSample1HigherInclusion       SigEventsJCSample2HigherInclusion       SignificantEventsJCEC   SigEventsJCECSample1HigherInclusion     SigEventsJCECSample2HigherInclusion
SE      skipped exon    22132   22465   756     385     371     841     436     405
A5SS    alternative 5' splice sites     10382   10438   168     94      74      185     109     76
A3SS    alternative 3' splice sites     13738   13777   332     190     142     346     191     155
MXE     mutually exclusive exons        2204    2243    74      24      50      82      26      56
RI      retained intron 6764    6926    364     199     165     407     233     174

Summary of rnasplice are all zeros.
The command line with the stand-alone was:
rmats.py --gtf Mus_musculus.GRCm39.106.gtf --b1 WT.txt --b2 mutAff.txt --libType fr-firststrand --readLength 90 --variable-read-length --novelSS --nthread 4 --od wt-mutRev_rMATsOUT --tmp wt-mutRev-rMATsTMP
For rnasplice I used:
nextflow run nf-core/rnasplice --input samplesheet.csv --contrasts contrastsheet.csv --outdir Rev_vs_Normal_Ens106_default_sig -profile singularity -r 1.0.2 --source genome_bam --fasta Mus_musculus.GRCm39.dna.primary_assembly.fa --gtf Mus_musculus.GRCm39.106.gtf --aligner star --rmats_read_len 90 --rmats  --rmats_novel_splice_site true --dexseq_exon false --dexseq_dtu false --sashimi_plot false --edger_exon false
The samplesheet was:
sample,condition,genome_bam,strandedness
N1,Normal,1295_521_2_510_S31_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
N2,Normal,1395_721_1_510_S30_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
N3,Normal,711_2_3_1295_115_HT_S32_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
N4,Normal,711_6_1293_113_HT_S33_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
N5,Normal,7_129_115_HT_S34_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
N6,Normal,722_1_511_HT_S35_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
R1,Rev,3131_3_K27_511_HT_S39_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
R2,Rev,3150_2_512_HT_S40_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
R3,Rev,3158_11_514_HT_S42_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse
R4,Rev,R27_3139_4_512_HT3_S41_L005-vsHsap_Aligned.sortedByCoord.sorted.bam,reverse

Sorry to dump this one here.  I can restart a separate thread if that helps.
Thank you.

H! I am having the same problem.
Did you finally solve it?

@SergioManzano10 I haven't had a response.  I will use the standalone tool for the time being.

Ok, could you provide me a link or something where the standalone tool is
explained?
Thank you.
El El dom, 12 may 2024 a las 15:52, IanCodes @.***>
escribió:

@SergioManzano10 https://github.com/SergioManzano10 I haven't had a
response. I will use the standalone tool for the time being.
—
Reply to this email directly, view it on GitHub
https://github.com/nf-core/rnasplice/issues/126#issuecomment-2106254243,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BENHAIEYLM2JRYQ7X2MPCZ3ZB5X2PAVCNFSM6AAAAABD2QMTLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGI2TIMRUGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

@SergioManzano10 I haven't had a response. I will use the standalone tool for the time being.

Apologies for the lack of progress on this issue. Is it possible to host your input files somewhere I can download and run locally? It's quite difficult for me to debug when the full test data seems to pass without issue.

Not me because are clinical/private data, but maybe @IanCodes can.
It would be so helpful!

@jma1991 I have an urgent deadline this week and a conference next week.  When I get back i'll look into sourcing the files to you.  I had to delete them last week to make space, so they need retrieving again.  I'll also need permission to send them.  I think Dropbox is probably the best route for me.  If that works for you could you private message me, here, an email address to send the link.

@jma1991 I have an urgent deadline this week and a conference next week. When I get back i'll look into sourcing the files to you. I had to delete them last week to make space, so they need retrieving again. I'll also need permission to send them. I think Dropbox is probably the best route for me. If that works for you could you private message me, here, an email address to send the link.

No problem, enjoy the conference. I'm not sure how to direct message on GitHub, but you can reach me on the nf-core Slack channel. Alternatively, if you have some public data that you used with the workflow and encountered the error, I can download it from SRA.

EDIT: I was easily able to get the files again, so if you can let me have contact details I can share them this week. Thanks.

That's great, please send an email to<EMAIL_ADDRESS>when you have availability.


Add callback test case for fs.readfile

There is no test case for fs.readfile.
I would like to add test case for checking if the function fails if you don't input a callback (and instead put in trash). (I could also try it for fs.writefile if work doesn't swamp me)
I would like to be assigned this issue.

Looks like my idea was a copy of #450 please close this issue


Docs: Improve the documentation

Improve the documentation

What exactly is needed on the documentation? I need a guide so I could work on it.

@djubreel First of all, thank you for joining. I will write a guide, but it will take some time. When I'm done, I'll tell you.
:)

@djubreel
i want to add a sub-command config for hiproxy. User can use this command to config hiproxy and the config fields will be stored in the user’s home-dir. for example:
hiproxy config set sys-proxy <IP_ADDRESS>:1087
hiproxy config get sys-proxy # <IP_ADDRESS>:1087
hiproxy config list
...

Could you do that?


[tcgc] remove primitive type consolidation

fixes https://github.com/Azure/typespec-azure/issues/163

All changed packages have been documented!

You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/221/
Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/221/


after click the bomb icon,  sd cannot be used and report this issue

Traceback (most recent call last):
File "D:\sd-webui-aki-v4\modules\call_queue.py", line 57, in f
res = list(func(*args, **kwargs))
File "D:\sd-webui-aki-v4\modules\txt2img.py", line 55, in txt2img
processed = processing.process_images(p)
File "D:\sd-webui-aki-v4\modules\processing.py", line 725, in process_images
sd_models.reload_model_weights()
File "D:\sd-webui-aki-v4\modules\sd_models.py", line 732, in reload_model_weights
sd_model = reuse_model_from_already_loaded(sd_model, checkpoint_info, timer)
File "D:\sd-webui-aki-v4\modules\sd_models.py", line 681, in reuse_model_from_already_loaded
send_model_to_cpu(sd_model)
File "D:\sd-webui-aki-v4\modules\sd_models.py", line 541, in send_model_to_cpu
if m.lowvram:
AttributeError: 'NoneType' object has no attribute 'lowvram'

Well, I can't fix that. I merely call the functions provided by the Webui.
That error is not on my part.


feat: add charmbracelet/skate

#5637 charmbracelet/skate: A personal key value store 🛼
$ aqua g -i charmbracelet/skate

Thanks.

Released. https://github.com/aquaproj/aqua-registry/releases/tag/v3.34.0


IStatefulServiceReplica.Open(); Error = System.NotSupportedException

On my 1-node development cluster, I get this error when my sateful service is deployed and then I rebuild the project in Visual Studio.
Expected Behavior
The service should restart without an exception
Current Behavior
Service goes into error state with:
'System.RA' reported Warning for property 'ReplicaOpenStatus'.
Replica had multiple failures during open on _Node_0. API call: IStatefulServiceReplica.Open(); Error = System.NotSupportedException (-2146233067)
Specified method is not supported.
   at Microsoft.ServiceFabric.Replicator.RecoveryManager.PerformRecoveryAsync(RecoveredOrCopiedCheckpointLsn recoveredOrCopiedCheckpointLsn, OperationProcessor recordsProcessor, CheckpointManager checkpointManager, TransactionManager transactionManager, LogRecordsDispatcher logRecordsDispatcher, ReplicatedLogManager replicatedLogManager)
   at Microsoft.ServiceFabric.Replicator.LoggingReplicator.PerformRecoveryAsync(RecoveryInformation recoveryInformation)
   at Microsoft.ServiceFabric.Replicator.DynamicStateManager.OpenAsync(ReplicaOpenMode openMode, TransactionalReplicatorSettings transactionalReplicatorSettings)
   at Microsoft.ServiceFabric.Replicator.TransactionalReplicator.OpenAsync(ReplicaOpenMode openMode, TransactionalReplicatorSettings transactionalReplicatorSettings)
   at Microsoft.ServiceFabric.Replicator.StatefulServiceReplica.System.Fabric.IStatefulServiceReplica.OpenAsync(ReplicaOpenMode openMode, IStatefulServicePartition partitionObject, CancellationToken cancellationToken)
   at Microsoft.ServiceFabric.Data.ReliableStateManagerImpl.Microsoft.ServiceFabric.Data.IStateProviderReplica.OpenAsync(ReplicaOpenMode openMode, IStatefulServicePartition partition, CancellationToken cancellationToken)
   at Microsoft.ServiceFabric.Services.Runtime.StatefulServiceReplicaAdapter.System.Fabric.IStatefulServiceReplica.OpenAsync(ReplicaOpenMode openMode, IStatefulServicePartition partition, CancellationToken cancellationToken)
For more information see: https://aka.ms/sfhealth

Steps to Reproduce

Deploy the stateful service to local 1-node cluster
In Visual Studio, rebuild the stateful service project

Service Fabric Runtime and SDK Version :

SDK: 4.0.470.9590
Runtime: 7.0.470.9590

Operating System :
Windows 10
Cluster Size :
1-node dev box

Any update / fix for this?


Use S.appendGlobalJs for JavaScript in XmlOrJsCmd.outSpan

Fixes #1788

👍 this looks good to me. Will merge tonight/tomorrow if there are no objections.


ceph: 15.2.7 -> 15.2.8

Motivation for this change
Although we probably aren't affected by: CVE-2020-27781, we might as well just get nixpkgs bumped to latest minor release.
this PR closes #109151 (if also backported to 20.09)
Regarding the boost bump: ceph v15.2.8 no longer builds with boost v1.6X, because of this change: https://github.com/ceph/ceph/commit/5d5f9a0d41721f08b19f8425149fd13f4ef13696 and it doesn't build with latest boost (1.75) either. The choice of v1.72 is based on the ceph cmake-files selecting that version, although I also tested it working fine with 1.73.
(https://github.com/ceph/ceph/blob/v15.2.8/cmake/modules/BuildBoost.cmake#L151)
The single-node and multi-node tests passed locally on my machine.
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[X] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[X] Fits CONTRIBUTING.md.

boost172 is the latest 1.7.x in 20.09 as well, so that seems like a good choice for multiple reasons. Waiting for tests to pass.

boost172 is the latest 1.7.x in 20.09 as well, so that seems like a good choice for multiple reasons. Waiting for tests to pass.

Oh, right, still broken in passthru.
@GrahamcOfBorg test ceph-multi-node ceph-single-node

Oh, right, still broken in passthru.
@GrahamcOfBorg test ceph-multi-node ceph-single-node

1 package marked as broken and skipped:
bareos

1 package failed to build:
sambaFull

3 packages built:
ceph ceph-client libceph

and sambaFull was already broken. LGTM

1 package marked as broken and skipped:
bareos

1 package failed to build:
sambaFull

3 packages built:
ceph ceph-client libceph

and sambaFull was already broken. LGTM


Create cgc.txt

Request to add Chandler Gilbert Community College (cgc.edu)

This request is so my students in my Java Algorithms class can utilize IntelliJ licenses for Java development.

@Spyro1001 First stage of verification passed, official domain is cgc.edu as far as I verified. This is just an informational note. Pull request is still in the review. I appreciate your patience while waiting for the final decision.


update sdk 33,update permission android sdk33

i have updated the latest sdk 33 for your library, if possible please merge and release the latest version, thanks

nice job, can you please just remove the .idea folder from the commit and i'll proceed with the merge

i just removed idea folder, please check it out <3, have a nice day.


Add publicPath support to webpack-plugin

Support webpack's publicPath option and add long term caching options into the webpack plugin.
Changes:

42dec1d - update webpack example to be a cross origin asset application
84d8536 - renames the loader filenames for clarity of their real intention
fac6af1 - fixes the bug with locating the worker and wasm assets paths when loaded with a publicPath
2e1adfd - adds support for long term caching into the output of the perspective loaders.
bc3585c - updates the webpack example to utilize the long term caching webpack options

Thanks for the PR!
Thoroughly tested, fixed one minor regression, but everything else looks good!