Issue 157 resolving support ticket form

Resolves #157

Description

Include summary of change and what issue is fixed, including relevant motivation and context.
[x] Clicking "Cancel" in this form redirects the user back to the Tickets index page (currently broken)
[x] Clicking "Resolve" in this form saves the notes left by the reviewer/resolver & updates the support_ticket's closed_at & closer_id fields.
[x] The new form looks like the attached form mockup.
[x] When clicking to view a "closed" support ticket, the view matches the 2nd attached mockup.
Explain the need for any added dependencies for this change. (gems, js libraries, etc.)
No dependencies.
How have you tested this?
I have done manual testing for this, screenshot attached.
I have added one test for adding closer_notes.
I did not find any existing view specific tests. I am not sure if we write feature specs on this project
Anything else we should know about?
Please review the view changes carefully. I am not familiar with the design practices for this project

Type of change

New feature (non-breaking change which adds functionality)

Screenshots

New HTML looks good. Nice work!
There are a couple small differences from the mock that I think we can still sort out in this change.

Looks like the top top cards on the mock do not have any space between them.
There is a "Resolution Description" caption above the closer_notes text area on the mock.

It also seems like we need to change the default background color to a very light shade. Feel free to add that in here, or not. We can add that separately since it looks like it should universally be the background shade on all pages.

I'll actually take it from here. This is a great addition already. I will touch up the styles/colors.
Thank you for this contribution!

@garettarrowood apologies for the delay in response. I see you have a PR for the style changes. I can make a separate PR with the two changes you have requested.

@goromlagche - No worries in anyway at all! I just happen to have some time this morning, and it sounded fun to mess around :).


Add io module to sphinx documentation

io module was missing in the online docs

Coverage remained the same at 82.627% when pulling e1b1fbf8f45bef98dfd2b7a1dad5b2eb63ba96ad on loicdtx:master into cd5da17b3ebb30b2a3473ea25badb7f358fbc9be on Toblerity:master.


rebrand Pipelines -> (tentative)  Entrypoints

Out with the old. The objects-formerly-known-as pipelines are going to become something else, tentatively Entrypoints as of Owen and KJ syncing on 12/4.
Pipelines as a concept still exist as the special case of an Entrypoint (or whatever) that actually does consist of multiple steps in a sequence

a one-step pipeline becomes an entrypoint. Pipelines still exist as workflows (lol needed another word) with multiple steps


Migration from using creme to river 0.9.0

This PR has updated chantilly to the usage of river, the evolved version of creme.
It is updated across the entire project, hence a very large set of changes.  Mainly, any reference to creme was simply changed to river and references to fit_one, changed to learn_one.  Tests ran successfully and the changelog was updated.  Please let me know if more updates are required or you have any comments.  The docker-compose example will not work correctly until a new version of chantilly is release to PyPI, however.
Additionally, I want to thank you for this awesome project.  I am working to deploy it using the docker-compose example to a VM in Azure and can add instructions at a later time.  Best Regards, Micheleen

Hey there! This is so cool! I haven't been maintaining Chantilly because I'm working on something else (not available yet), but it's really great to make this work. I'll send a new release to PyPI.

I've published a new release @michhar.
By the way, feel free to get in touch as some point if you want to have a chat. I'd be curious to hear about how you're using Chantilly.
All the best!

  Ok, I sent a connect your way!  Hopefully that works. :)


Continuous transition management

First off, thanks for creating tools related to controlling Hue lights. I've previously used f.lux to manage lights to transition my lights throughout the day but am exploring more customizable options.
As a disclaimer I haven't used hue-scheduler yet but plan to play around with it and read through the documentation.
I'm interested in creating a configuration where when lights are turned on they are set to a setting relevant to the sun's position.
In the current discrete state configuration it's my understanding that hue-scheduler will identify the state matching the current time, set the lights to the defined parameters, and then start transitioning to the next state if there exists a tr-before value defined.
For example in the example configuration:
Office    civil_dawn   ct:6500  bri:150  tr:10s
Office    sunrise      ct:5000  bri:200  tr-before:90min
Office    12:00        bri:255  tr-before:90min
Office    sunset       ct:3000  bri:200  tr-before:90min
Office    civil_dusk   bri:150  tr-before:90min
Office    23:59        ct:2000  bri:100  tr-before:90min

Let's assume sunset is at 18:00. If the Office light group is turned on at 16:00 then the Office lights will be set to ct:5000, bri:255 as hue-scheduler is taking control of the lights. Then 90 minutes before sunset (16:30) the lights will begin to transition to ct:3000, bri:200. However if the lights were turned on at 17:30 then the lights would still be set to the same ct:5000, bri:255 as the previous scenario and hue-scheduler will execute the same full state-to-state transition in 30 minutes to match the sunset state.
My ideal execution of the transition (when lights are turned on at 17:30) would be for hue-scheduler to calculate the mid-transition state, set the lights to that state, and then continue the transition to the next state. In other words, it doesn't matter when the light was turned on, the light configuration is based on the time of day (relative to the sun constant times).
Not to overload this issue but I'm assuming that tr-before cannot reference sun states (e.g. tr-before:civil_dusk-sunset). Also I believe a "solar_noon" constant would be useful :).
Interested in what you think about this proposed behavior.

I was about to post the same thing at some point, too. Actually, I am using a workaround that does the job for now but requires more configuration and doesn't make use of tr-before. Instead, the desired light interpolation can be scheduled statically with baby step sized changes. Due to the flexibility of hue scheduler and it's easy configuration it can be done within minutes.
Let's assume you want to transition the brightness from 200 to 140 within 60 minutes before sunset. Instead of:
Office  sunset  br:140  tr-before:60min

you'd configure:
Office  sunset-60  br:199
Office  sunset-59  br:198
Office  sunset-58  br:197
...

Even larger baby steps are usually not noticable, especially when you add a little tr-before. That way you can also find your own tradeoff between a fast reaction time and the amount of configuration you want to configure.
Of courese, it'd be nice if this desired transition behaviour would be integrated, natively. For me it'd be sufficient if it'd be the only one or configurable per schedule entry (having it as default would be preferable though).

This is a good, if verbose, workaround. I will try to experiment with it when I can.
I believe the current configuration states map more natively to the way the Hue devices expose their capabilities and what is available through the Hue app. The sort of continuous lighting change we're after is almost like a very long-running light effect. For this reason I'm not sure it would be a good fit for being the default but maybe an additional configuration type that could be supported.
In the end internally it could just look like this:
Continuous light configuration -> Automatically generated discrete states -> hue-scheduler execution
In the end it will always be discrete on some time-step. One minute intervals doesn't seem too bad.

This is a good, if verbose, workaround. I will try to experiment with it when I can.
I believe the current configuration states map more natively to the way the Hue devices expose their capabilities and what is available through the Hue app. The sort of continuous lighting change we're after is almost like a very long-running light effect. For this reason I'm not sure it would be a good fit for being the default but maybe an additional configuration type that could be supported.
In the end internally it could just look like this:
Continuous light configuration -> Automatically generated discrete states -> hue-scheduler execution
In the end it will always be discrete on some time-step. One minute intervals doesn't seem too bad.

Thank you for your interest in the tool and thank you both for starting the discussion about light state transitions. Right now Hue Scheduler does not support any custom interpolations, but rather reuses the transition system already provided by Hue lights.
You were almost right about how the transitions, or more specifically the custom tr-before implementation works. The main difference to your interpretation is that hue scheduler basically just uses tr-before to modify the start time of the sate by substracting the duration of the transition from the defined start time. In addition to that, the scheduler then dynamically shortens the transition time based on the time the lights are turned on after the set time. So your "tr-before" example could also be written like this at the given points in time:
Office    sunset       ct:3000  bri:200  tr-before:90min

# Equals at 16:30:
Office    sunset-90    ct:3000  bri:200  tr:90min
# Equals at 17:30:
Office    sunset-90    ct:3000  bri:200  tr:30min
# Equals at 18:00:
Office    sunset-90    ct:3000  bri:200

As a consequence this means that the scheduler does not explicitly set the previous state (again) when starting the transition but just keeps the current state of the light and uses the native transition feature of Hue lights.

My ideal execution of the transition (when lights are turned on at 17:30) would be for hue-scheduler to calculate the mid-transition state, set the lights to that state, and then continue the transition to the next state. In other words, it doesn't matter when the light was turned on, the light configuration is based on the time of day (relative to the sun constant times).

While you correctly identified the issue that hue scheduler currently does not support this kind of interpolation, I do like the approach and appreciate your suggestions and detailed descriptions of your uses cases. I will to look into adding some linear interpolations for tr-before over the next couple of days. If you have some more details on how you expect this feature to work, I'm happy to hear your thoughts. One issue that currently comes to mind is interpolating between states that use different color modes (i.e. ct vs hue and sat vs x and y).
Finally, I also have some small notes on the following statement of yours:

Let's assume sunset is at 18:00. If the Office light group is turned on at 16:00 then the Office lights will be set to ct:5000, bri:254 as hue-scheduler is taking control of the lights.

If we look at the relevant part of your example again:
Office    sunrise      ct:5000  bri:200  tr-before:90min
Office    12:00        bri:254  tr-before:90min
Office    sunset       ct:3000  bri:200  tr-before:90min

If the Office light group is turned on at 16:00, the lights will be just set to the maximum brightness level of 254. Since you didn't specify a color temperature for the "12:00" state, the scheduler will not modify any ct values of the lights at this point in time. If you want to make sure the ct is set to that value, e.g. after manually changing it at 11:00 and then resetting the manual override by turning off and on the lights at 13:00, you also need to specify the ct value in your state configuration.

Not to overload this issue but I'm assuming that tr-before cannot reference sun states (e.g. tr-before:civil_dusk-sunset). Also I believe a "solar_noon" constant would be useful :).

And you are right, such tr-before definitions are currently not supported, but I could think about them at some point. But for now I would focus on improving how tr-before works in general.
And thank you for pointing out that there was no "noon" sun time constant, I will include that in the next release.

Instead, the desired light interpolation can be scheduled statically with baby step sized changes. Due to the flexibility of hue scheduler and it's easy configuration it can be done within minutes.

And you are right, a workaround for this could be to just define all the interpolations yourself. Since there is no limit on the number of state you can define, it's absolutely possible to create your own continuous transitions like this. This would even work with dynamic sun times as you could just use the offset feature for that.
I'm however also interested in provide a less labor-intensive support for this natively.

I believe the current configuration states map more natively to the way the Hue devices expose their capabilities and what is available through the Hue app. The sort of continuous lighting change we're after is almost like a very long-running light effect. For this reason I'm not sure it would be a good fit for being the default but maybe an additional configuration type that could be supported.

You are right, the configuration of the light states directly map to the Hue API, with some additional support for features like tr-before and dynamic sun times. So one idea could of course be to create some different state configuration format or type to support these continuous transitions implemented by some of the popular alternatives.
To begin with, I would however look into improving the existing tr-before feature, but I'm open for suggestions on how the desired features could be implemented without requiring too much manual configuration, while still allowing great flexibility.

My geometrical interpretation of the problem domain:

The blue and green behaviour are implemented. Red is desired instead of green. Both are meaningful.
I agree with you, it should be possible to have either of them as default and let the other one apply via a new schedule entry keyword.
´While the current behaviour is more pleasing to the internals, I assume the desired behaviour is what users are looking for, usually. It's also what brought me here btw.
I'm just thinking about how fast the light should keep up with the current state really (the red arrow pointing to the top). Like the icing on the cake: an eye-pleasing transition (~500ms - 2000ms ?) might be preferable to an instantanous and potentially hue light change.

Hi, I wanted to let you know that I have now released version 0.9.0 of Hue Scheduler which adds interpolations between states as one of its main feature. Thank you @cswrd for providing the visualization of the problem. I managed to implement this behavior into the existing tr-before logic and added the additional interpolate:true property for convenience, if you want back-to-back transitions between your states without having to explicitly configure it. Basically interpolate:true acts as a more advanced version of tr-before as it dynamically uses the start of the previous state, all while considering day cross overs and day-of-week configurations.
To summarize, if you turn on your lights in the middle of the transition, Hue Scheduler now calculates the mid-transition point using the previous state and the already passed time, sets the interpolated value and continues the transition from this point on. This way it can ensure that the lights are always at the correct state, regardless when they are turned on.
Additionally, it's now possibel to reference absolute and solar times when using tr-before, so you can use the following configuration now:
Home  nautical_dawn      bri:160  ct:390  tr-before:20min          tr:3s
Home  civil_dawn         bri:254  ct:199  interpolate:true         tr:3s
Home  golden_hour        bri:254  ct:333  tr-before:15:00          tr:3s
Home  sunset             bri:170  ct:366  tr-before:golden_hour+5  tr:3s
Home  nautical_dusk      bri:40  x:0.6024  y:0.3433  interpolate:true  tr:5s

Note how its also possible to transition / interpolat between different color modes (CT to XY)
To solve the question regarding how long the transition time of the interpolated call should be, Hue Scheduler has a default value configured (400 ms), which can be adapted using the new command line argument --interpolation-transition-time. However, if the previous state already has a tr property defined, Hue Scheduler just reuses this value also for the interpolated call. In the above examples this would be tr:3s i.e. 3 seconds.
If your goal is to enable interpolations between all states per default, you can just provide the --interpolate-all command line flag, which implicitly sets interpolate:true for all states. This can however be overridden on a case-by-case basis for individual states by either setting interpolate:false or by providing a custom tr-before property, which always takes precedence over interpolate:true.
To work around the limited transition time of Hue lights (max ~100 minutes), Hue Scheduler automatically splits up long transitions into multiple chunks and uses the already mentioned interpolation feature to calculate multiple interpolation points to transition between. This also means that all interpolations are done using native Hue light transitions, without periodically setting their state every few seconds as e.g. Adaptive Lighting does. However, I may look into supporting other modes of interpolation / transition, if needed. As not all lights might support such transitions (e.g. Ikea Tradfri bulbs #5).
If you have any questions or feedback on this new behavior, feel free to reach out -- I'm happy to provide some more insights into the inner workings. And thank you again to both of you for all your valuable input and suggestions to further improve this tool. I really appreciate it! You can find the new release and full list of changes here: https://github.com/stefanvictora/hue-scheduler/releases/tag/v0.9.0

@stefanvictora Thank you very much for this new version. I run it in my own Docker container again and it works perfectly so far. I was able to reduce the configuration a lot. interestingly, the tradfri bulbs have a noticeable faster response time now. Even faster than the original hue bulbs. While the philips ones still take about 3-4 seconds, the tradfri ones react within 2 seconds now.

Hi @cswrd, thank you for the positive feedback! Glad to hear it's still working as expected for you and even helps you reduce the configuration effort. I hope the growing number of configuration properties are not getting too confusing. And that's interesting indeed, as I haven't really changed much that could improve such response time when physically turning on lights.
I was actually a bit worried about the Tradfri bulbs as the new interpolate functionality is using native transitions which as you reported are not without issues for the IKEA bulbs. Have you been able to workaround these issues? Or are you mainly transitioning single properties of the lights?
One possible future solution that came to mind was adding multiple interpolation approaches by e.g. updating lights every few seconds instead of using native transitions. Similar to what other tools like Adaptive Lighting are currently doing. But I haven't put much thought into this for now.

Hi @stefanvictora I am still using the more verbose configuration for the tradfri bulbs with tr:0. Maybe they work faster now due to the new hue API you trigger and some changes you've made regarding group events?
The approach you mentioned is the only I could think of too. I guess Ikea will never fix their bug.
Yes, the configuration is getting more complex, now. I think it might get easier for users just by shrinking down the readme already. I tend to write long descriptions by myself.


[e2e]: delegator-generic push main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/8550002367
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Thu Apr  4 06:05:50 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/8565716031
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.delegator-generic.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Fri Apr  5 06:26:50 UTC 2024
Tests are passing now. Closing this issue.


proposal: in net/rpc, allow receivers to recieve the connection for the request with context

Currently, there is no way for receiver methods to access the RPC connection or use per-connection context.
I propose to create a new interface RWCContext and a struct rpc.Conn with methods to get/set contexts, for example:
// net/rpc/server.go

type RWCContext interface {
  io.ReadCloseWriter
  Context() context.Context
  WithContext(ctx context.Context) *Conn
}

type Conn struct {
  io.ReadWriteCloser // the underlying connection
  ctx context.Context
}
func (c *Conn) Context() context.Context
func (c *Conn) WithContext(ctx context.Context) *Conn

A rpc.Conn can be created in the Server.ServeConn method and get passed to the ServerCodec that accepts it. For example:
conn = &Conn{
  ReadWriteCloser: rwc,
  ctx: context.Background(),
}
// gobServerCodec can still use the conn as it is a io.ReadWriteCloser
srv := &gobServerCodec{
  rwc:    conn,
  dec:    gob.NewDecoder(conn),
  enc:    gob.NewEncoder(buf),
  encBuf: buf,
}
// fooServerCodec accepts a *rpc.Conn
srv := &fooServerCodec{
  conn:  conn, // This field is a *rpc.Conn
}

The rpc.Register methods can then accept receivers with method signatures such as:
func (t *T) MethodName(argType T1, replyType *T2) error
func (t *T) MethodName(argType T1, replyType *T2, conn rpc.RWCContext) error

A new interface for ServerCodec would be needed to call methods with the second signature from above:
type ServerCodecConn interface {
  ServerCodec
  Conn() RWCContext
}

This would not break existing code and still allow the receiver methods to work with connection scoped contexts.

I have also been looking at context for RPC. I use it the PKG extensively.
Your suggestion is much better than mine. I had understood that the PKG was
"frozen". There has been no guidance as to what this exactly means. I don't
know whether to to fork or go through the contribution and submit
extensions or "bug fixes". Working under compliance, I have until Oktober
to convince the "Auditors" that we we have the in house skills to fork. or
that the PKG can be maintained.  We are are more worried above the
genererated code for the Gob in the light of "flavoured" type aliasing.
On 4 February 2017 at 08:44, Peter Nguyen<EMAIL_ADDRESS>wrote:

Currently, there is no way for receiver methods to access the RPC
connection or use per-connection context.
I propose to create a new interface RWCContext and a struct rpc.Conn with
methods to get/set contexts, for example:
// net/rpc/server.go
type RWCContext interface {
io.ReadCloseWriter
Context() context.Context
WithContext(ctx context.Context) *Conn
}
type Conn struct {
io.ReadWriteCloser // the underlying connection
ctx context.Context
}func (c *Conn) Context() context.Context
func (c *Conn) WithContext(ctx context.Context) *Conn
A rpc.Conn can be created in the Server.ServeConn method and get passed
to the ServerCodec that accepts it. For example:
conn = &Conn{
ReadWriteCloser: rwc,
ctx: context.Background(),
}// gobServerCodec can still use the conn as it is a io.ReadWriteClosersrv := &gobServerCodec{
rwc:    conn,
dec:    gob.NewDecoder(conn),
enc:    gob.NewEncoder(buf),
encBuf: buf,
}// fooServerCodec accepts a *rpc.Connsrv := &fooServerCodec{
conn:  conn, // This field is a *rpc.Conn
}
The rpc.Register methods can then accept receivers with method signatures
such as:
func (t *T) MethodName(argType T1, replyType *T2) error
func (t *T) MethodName(argType T1, replyType *T2, conn rpc.RWCContext) error
A new interface for ServerCodec would be needed to call methods with the
second signature from above:
type ServerCodecConn interface {
ServerCodec
Conn() RWCContext
}
This would allow the receiver methods to work with connection scoped
contexts.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/18937, or mute the thread
https://github.com/notifications/unsubscribe-auth/AEAf7L0-FPwWxH578OCz6gu9FPitN9ylks5rZCxcgaJpZM4L3E3Z
.

Sorry, as of Go 1.8, the package docs for net/rpc say:
https://beta.golang.org/pkg/net/rpc/

The net/rpc package is frozen and is not accepting new features.

You're welcome to fork & maintain the net/rpc page elsewhere. If it gains a large following we can link to it from the stdlib's net/rpc package docs perhaps.
See also https://golang.org/doc/faq#x_in_std for some background.


exec /commento/commento: exec format error when setting up with docker on raspberry pi 3b+

Hello!
I am following this tutorial to set up commento++:
https://noted.lol/commento-a-self-hosted-comment-system-for-websites-that-just-works/
When I use that exact dockerfile (while changing the COMMENTO_ORIGIN``to my own) and running docker-compose up`, I get the following logs on my raspberry pi 3b+:.
db_1      |
db_1      | PostgreSQL Database directory appears to contain a database; Skipping initialization
server_1  | exec /commento/commento: exec format error
db_1      |
db_1      | 2022-08-19 16:12:41.758 UTC [1] LOG:  starting PostgreSQL 12.5 on arm-unknown-linux-musleabihf, compiled by gcc (Alpine 10.2.1_pre1) 10.2.1 20201203, 32-bit
db_1      | 2022-08-19 16:12:41.758 UTC [1] LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
db_1      | 2022-08-19 16:12:41.758 UTC [1] LOG:  listening on IPv6 address "::", port 5432
db_1      | 2022-08-19 16:12:41.780 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
db_1      | 2022-08-19 16:12:41.871 UTC [21] LOG:  database system was shut down at 2022-08-19 16:11:44 UTC
db_1      | 2022-08-19 16:12:41.893 UTC [1] LOG:  database system is ready to accept connections
commento_server_1 exited with code 1

FYI: My dockerfile looks like this:
version: '3'

services:
  server:
    image: caroga/commentoplusplus:v1.8.6
    ports:
      - 8080:8080
    environment:
#   I tried both, neither work!
      COMMENTO_ORIGIN: https://commento.mydomain.com
#    COMMENTO_ORIGIN: http://<IP_ADDRESS>:8080
      COMMENTO_PORT: 8080
      COMMENTO_POSTGRES: postgres://postgres:postgres@db:5432/commento?sslmode=disable
#    Note: These are copied from the blog post. I want to disable them, but even commenting them out doesn't make the server start.
      COMMENTO_SMTP_HOST: smtp.mailgun.org
      COMMENTO_SMTP_PORT: 587
      COMMENTO_SMTP_USERNAME: mailgun.smtp.user
      COMMENTO_SMTP_PASSWORD: mailgun-password
      COMMENTO_SMTP_FROM_ADDRESS<EMAIL_ADDRESS>    depends_on:
      - db
  db:
    image: postgres:12.5-alpine
    environment:
      POSTGRES_DB: commento
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    volumes:
      - commento_data_volume:/var/lib/postgresql/data

volumes:
  commento_data_volume:

I don't really know where to go from here. According to the reactions on that blog post, everything should work fine :) I must be doing something wrong in a dumb way!

Bonus question:
I plan to run this behind a Caddy reverse proxy, but I don't think that's the issue here because the server doesn't even start up.
In any case, if I run it behind a reverse proxy (So caddy will forward traffic from commento.mydomain.com:80 -> <IP_ADDRESS>:8096, should I set my COMMENTO_ORIGIN to <IP_ADDRESS>:8080 or to commento.mydomain.com? I tried both, neither make the server start up.

This is expected as described by https://github.com/souramoo/commentoplusplus/pull/89#issuecomment-1091696774
If you have any suggestions on how to fix the build process errors caused by missing binaries in the arm64 images we base ourselves on, please do open a pull request and I'd love to merge it!
There is nothing in principle stopping us from compiling this for arm other than this!

Actually, exec format error suggests that the correct executable format is not present but the RPi3B+ is an arm64 device.
Please could you double check you are using the correct arm64 image rather than the amd64 image?

Wow! Thanks for the ultra fast reply!
I only see amd64 on the docker hub:  https://hub.docker.com/r/caroga/commentoplusplus/tags
How would I be able to install an arm64 image?

AFAIK I have the amd64 image:

So, there is currently no way to run this on a pi because of missing arm64 support, right?
I have no go or arm64 knowledge, but I suppose I can take a look, perhaps this weekend. I'd love to use this on my Pi!

I'm looking into the base images the Dockerfile uses, but I don't see anything that wouldn't support arm64.

golang-alpine seems to have support for multiple arm*  architectures
node-alpine seems to have support for multiple arm* architectures
alpine seems to have support for multiple arm* architectures
gcr.io/distroless/static-debian11 seems to have support for arm architectures

I found this a bit more difficult to figure out, so I just pulled one of these images (on my pi) and inspected the image and saw:

I feel like I am kind of out of my depth here, apologies! :)
@Wonderfall, you commented that support should be removed for arm because of issues, perhaps you can help me out here? Especially since you created the PR for a better dockerfile?
Thanks!

My first hunch is that arm is now actually supported! I will test a bit more now

Thanks for looking into this! Yes you're right, I have updated the docker build process - please try pulling the latest one as there should be an arm64 image now on dockerhub!

Hey @souramoo , I think this isnt't working yet.
If I use this docker compose file:
version: '3.7'

services:
  commento:
    image: caroga/commentoplusplus
    environment:
      COMMENTO_ORIGIN: 'https://commento.stenbrinke.nl'
      COMMENTO_PORT: '8080'
      COMMENTO_POSTGRES: 'postgres://postgres:postgres@db:5432/commento?sslmode=disable'
      #COMMENTO_FORBID_NEW_OWNERS: 'true' # enable this after your own registration
      COMMENTO_GZIP_STATIC: 'true'
    depends_on:
      - db
    ports:
      - 8080:8080

  db:
    image: postgres:12.5-alpine
    environment:
      POSTGRES_DB: 'commento'
      POSTGRES_USER: 'username'
      POSTGRES_PASSWORD: 'password'
    volumes:
      - /mnt/usb_hdd/commento:/var/lib/postgresql/data

running docker compose up gives me this error:
[+] Running 0/2
 ⠇ db Pulling
 ⠇ commento Pulling
no matching manifest for linux/arm/v7 in the manifest list entries

Could you still look into this?
Also, should another github release be required for this? I am pulling the latest images.
I still see version 1.8.7 on github and docker hub; I thought an architecture change would require 1.8.8 or 1.9.0` or something?  :)

I will look into this! I think it's looking for armv7 (32 bit arm) rather than arm64
The code for commento is the same so I kept the version number constant, just a further architecture we are compiling for, but if I need to make further changes to the codebase to get it to work I will bump the version number :)

Yes, linux/arm/v7 is currently not supported by Commento++ Docker images. Maybe just adding it in the GitHub Actions workflow can work, if all the dependencies (images and packages) work fine with that.

Actually, it shouldn't be the problem as the Raspberry Pi 3 is arm64.
Can you try the image from ghcr.io instead?

Hi @Wonderfall !
I tried changing my image to that, but I get the following error.
Pulling commento (ghcr.io/souramoo/commentoplusplus:v1.8.7)...
v1.8.7: Pulling from souramoo/commentoplusplus
ERROR: no matching manifest for linux/arm/v7 in the manifest list entries

For full disclosure, here is my dockerfile:
version: '3'

services:
  commento:
    image: ghcr.io/souramoo/commentoplusplus:v1.8.7
    ports:
      - 8080:8080
    environment:
      COMMENTO_ORIGIN: https://commento.stenbrinke.nl
      COMMENTO_PORT: 8080
      COMMENTO_POSTGRES: postgres://postgres:postgres@db:5432/commento?sslmode=disable
    depends_on:
      - db
    networks:
      - db_network
  db:
    image: postgres
    environment:
      POSTGRES_DB: commento
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    networks:
      - db_network
    volumes:
      - postgres_data_volume:/var/lib/postgresql/data

networks:
  db_network:

volumes:
  postgres_data_volume:

I run raspbian lite :) Running uname -a (thanks to this site) tells me that I have Linux raspberrypi 5.15.32-v7+ #1538 SMP Thu Mar 31 19:38:48 BST 2022 armv7l GNU/Linux

You can see here the supported platforms: https://github.com/souramoo/commentoplusplus/blob/master/.github/workflows/docker-image.yml#L53
I suggest you try installing an arm64 OS since your hardware should be capable.

I'd like to suggest to add arm7 32-bit to the supported list :)
64-bit on raspberry pi 3b+ can work, but there are still some things that might cause issues. And personally I don't want to reinstall my entire system for this; that is probably understandable ;)
@souramoo  and @Wonderfall  What are your thoughts on this? I am currently setting up the system, and it seems to work completely fine on my system.

I have already created a PR for this ;): !121

It should work just fine if we add support for linux/arm/7, indeed.

Arm v7 compiled successfully - should now be present on all docker repos!


The IDE is not opening

I go to the login page, sign in with my github. Then i get redirected to ide.coder.com but then the page is unresponsive.

Hey @akashgurava, are you seeing a white page with { }?

I am having the same problem at ide.coder.com.  It's getting path the auth process.  In the developer console, you get about 6 503 bad gateway errors, then finally just a black screen.

Hey @akashgurava we are currently working on this and have an internal ticket. Closing this one out in favor of that one.

https://github.com/codercom/bugs/issues/343


fixed the issues with the curve being too large and reduced error from 6 to 3 percent

I fixed issues with the curve being too large and also the issue with only being able to have a minimum value of 3 percent now down from 6
I added a Bézier curve instead of just and arc because the rounded attribute does not allow customization for how curved we want it. I also added two circles to clean up some of the bezian curve spill over.
I attached an image take a look

There's some issues with changing the radius ima close this and try to fix


Added a flag to GPIO input macro, to only implement into_pull_up/down…

… functions if the pin supports it.
The solution seemed to fit the best into already macro-focused file.
Fixes #8

Look good to me! Thank you!


Fix Gradle and write tests

Allow some sort of command to be run, such as ./gradlew cucumber and make it run all feature tests
Also work with github applets to work with merge restrictions

Would like to restrict merges based on code coverage and all tests passing


etcdserver: etcd does not gracefully shutdown on SIGTERM

After systemctl stop etcd.service, the status shows:
● etcd.service - etcd
   Loaded: loaded (/usr/lib64/systemd/system/etcd.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2015-02-10 23:05:36 UTC; 27s ago
  Process: 584 ExecStart=/usr/bin/etcd (code=exited, status=2)
 Main PID: 584 (code=exited, status=2)

It would be preferable if etcd gracefully shutdown.

fixed via #2289


ci: add otp 26

Current dependencies on/for this PR:

main

PR #20   👈

This comment was auto-generated by Graphite.


gcc: fix gcc8 for cross-compiled targets

Adds EXTRA_TARGET_FLAGS missing from 412093994b9a4fe0fa7da99d1947effc85d9070b.
Fixes #58164
Motivation for this change
This seems to have been a mistaken deletion that prevented gcc8 from compiling when the target platform is not the host.
Things done

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

[ ] NixOS
[ ] macOS
[x] other Linux distributions

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

Thanks!


 I don't know how or where it came from. I was just digging in the mine until this came up. In first person mode, this thing also appears and flashes in front of my eyes, which is annoying. It seems like this happened before and I don’t even remember how to remove it.
To Reproduce
I don't know.
Expected behavior
Not to do that
Screenshots / Videos
(https://cdn.discordapp.com/attachments/1076926906957574274/1076926907246977084/Base_Profile_Screenshot_2023.02.19_-_<IP_ADDRESS>.png)
Additional context
https://discord.com/channels/431403377977720862/1076926906957574274

If I'm not mistaken, this is an issue caused by a setting in OptiFine.
I'll look into it but no guarantees about fixing it.


Parse Statement Templates table (S')

Following https://github.com/DISSINET/InkVisitor/issues/755, statement-type Concepts became fully-fledged Statement Templates, i.e. S entity type with the attribute "template" set to "true" (or "1" or whatever the notation). Therefore, a new table of Statement Templates (sometimes I call them S') has been created, keeping the old C codes but recoding them to S entities (linked to no T).

Parse this table (which has, logically, the form of a simplified coding sheet. (Set all vars not stated to their defaults, modality to "positive allegation realis".)
Design parsing Coding sheets containing those Cs (e.g. XY - believed that - C1234). This action must do a couple of things:

Instead of the original pseudo-C (S'), create a substatement and put it in the original C's actant position.
Put this substatement just after the relevant statement in the order of statements.
This substatement will copy the template (S'), parsed as a statement according to the instruction rows and as S' always do, record (ask Adam where) that it has been derived from this S' (but set "template" attribute to "false" of course - the use of an Statement Template is a normal statement, not a template any more).
As usual with Statement Templates, do not forget to copy all metaprops of the template to the instance!!! E.g., its superclass (e.g. "C anticlerical attitude" etc.

Tomáš H. confirms it will be no problem to parse this only in phase 2. Moving.

Tomáš H.: use S* prefix for those.

Will not fix - we will do that only within InkVisitor.


Issue with building esp32 firmware (missing files apparently) (IDFGH-1750)

Environment

Development Kit:      [none]
Module or chip used:  [ESP32]
IDF version (run git describe --tags to find it):
v4.1-dev-104-gaa087667d
Build System:         [Make|CMake]
Compiler version (run xtensa-esp32-elf-gcc --version to find it):
xtensa-esp32-elf-gcc (crosstool-NG esp32-2019r1) 8.2.0
Operating System:     [Linux]
Power Supply:         [USB|]

Problem Description
Can't build esp32 firmware, says it's missing files (and when I navigate to there it indeed is missing) tried adding them to the directory manually but it doesn't work.
IDF_PATH is set correctly, and xtensa-esp32-elf/bin is added to the path

CC /home/srsbr/esp/esp-idf/components/bootloader_support/src/bootloader_clock.c
/home/srsbr/esp/esp-idf/components/bootloader_support/src/bootloader_clock.c:14:10: fatal error: esp32/rom/uart.h: No such file or directory
#include "esp32/rom/uart.h"
^~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:678: recipe for target 'build-GENERIC/bootloader//home/srsbr/esp/esp-idf/components/bootloader_support/src/bootloader_clock.o' failed
make: *** [build-GENERIC/bootloader//home/srsbr/esp/esp-idf/components/bootloader_support/src/bootloader_clock.o] Error 1

I just struck this problem now, myself.

Hi @rudecerik ,
I'm sincerely sorry noone got back to you about this earlier. I'm honestly not sure what this problem was, but I'm assuming it was transient in some way to do with paths.
If the issue still occurs on the latest release/v4.1 branch, please leave a comment and we'll reopen.


Allocate CQ buffers in the non-default direction

Currently, when we allocate program buffers, we just grow in the default DRAM buffer direction. This is not good, since we are sharing space with tensors and we can get holes between buffers.
Ideally, we'd want to grow our program/trace buffers from the other direction to ensure that they are contiguous/no holes. This would require exposing an extra param that specifies from which direction we want to grow the buffer.

@tt-aho @davorchap  this would address the issue with the move op in dram if we allocate program binary buffers / trace buffers top down in dram

yeah that case can still be hit


add missing features to defaults and test matrix

Fixes #42367
Fixes #42501

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[x] The "supports" clause reflects platforms that may be fixed by this new version.
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

I marked this as draft because the build is still broken in ways that do not appear to be baseline issues. Please feel free to un-draft when it's working :)

can someone help me understand why is it failing?
I don't have time nor resources to run the ci matrix. I think it has to be some port that is in the ci.baseline.txt marked as failing, because from the manifest support point of view there should be no problems. Either we try to fix them or i have to understand the feature link to remove it

It seems that the CI error occurs in linux:
CMake Error at cmake/OpenCVUtils.cmake:797 (message):
  Some dependencies have not been found or have been forced, unset
  ENABLE_CONFIG_VERIFICATION option to ignore these failures or change
  following options:

  WITH_GTK
Call Stack (most recent call first):
  CMakeLists.txt:1681 (ocv_verify_config)

-- Configuring incomplete, errors occurred!

config-x64-linux-out (3).log
You can get more details about CI error log from here: https://dev.azure.com/vcpkg/public/_build/results?buildId=109963&view=artifacts&pathAsName=false&type=publishedArtifacts

yes thanks, the error is above that line
Option WITH_GTK is enabled but corresponding dependency have not been
found: "HAVE_GTK" is FALSE
opencv now has a verification in place, that the feature you ask are then really activated. if not it errors, instead of silently building without that feature.
I admit i was concentrating on windows triplet. I was not able to obtain any log, just an error due to a cascade dependency failure which was very obscure.
first of all, I will fix linux asap because that's worrysome!!

Maybe it not the right point in time to deal with LAPACK here.
It doesn't work with openblas in vcpkg's current CI configuration.
It might be working well enough for some blas/lapack configurations.
(I worked on blas/openblas recently, after starting to look into lapacke. I think we might actually want to use BLAS, LAPACK and LAPACKE from openblas as a single lib, which is also expected by opencv's find modules.)

in fact i tried adding it to ci, verified it always fail and so I delisted lapack feature since it's non working. I don't plan to recover it in this PR.

rtabmap regression does not look due to this PR (i touched it but had to merge from master and since then it's failing...)

rtabmap regression does not look like it is due to this PR (i touched it but had to merge with master due to conflicts and since then it's failing...)

same error in #42351. It's requiring attention for sure

Might https://cmake.org/cmake/help/latest/policy/CMP0156.html#policy:CMP0156 help with the rtabmap regression? (Assuming CMake detects a "tradtional linker" on Linux.)
Implementation: -DCMAKE_POLICY_DEFAULT_CMP0156=NEW in rtabmap.

could it be due to a bug in cmake 3.30?
https://cmake.org/cmake/help/latest/release/3.31.html
see release notes of 3.31 and how they modified exactly this feature you're talking about

This has always been a little bit flaky with CMake.
I know the 3.31. release notes, but they don't reduce confusion. I don't see anything being added which improves the behavior for traditional linkers. And the failing build has 3.30.

I cannot even reproduce the error locally to better diagnose and fix the error...

Implementation: -DCMAKE_POLICY_DEFAULT_CMP0156=NEW in rtabmap.

trying this suggestion blindly in CI

nope, the test failed.
I'd really like to be able to reproduce it locally to better diagnose and fix the problem... unfortunately here it works...
can you @FrankXie05 or @BillyONeal ?

In any case, I would check the cmake trace that there is no unexpected REMOVE_DUPLICATES on link lib lists. But this trace will be huge for opencv with this feature set.

i tried to add an explicit --trace-expand on the rtabmap port. Let's see the results. I'm lost if it is inconclusive on what to do to fix this regression, that as of today is blocking two PRs related to opencv (which might be at fault?)
Any help is appreciated


Improve logging

To be able to track down issues quicker and also improve the overall dev experience I figured it would be nice to have a little more logging capabilities.
I've added a basic error log that kicks in when there is an error upon plugin registration.
In case there is an exception it will create a error.log file within the KiBuzzard subdir containing the exception.
But the bigger improvement is that there is now a basic configuration for python's logging module.
You have two ways of logging stuff.
# In plugin.py there already is a self.logger object so you can:
self.logger.info("This is from the plugin.py file! It should log even before the dialog was opened.")

# In every other file you can easily pull in the logger via:
import logging
logger = logging.getLogger(__name__)
logger.info("This is from dialog.py and should log as soon as you hit Cancel!")

All logs (also regular stderr or stdout) will be written to a kibuzard.log file in the root plugin directory.
This is the kibuzzard.log file you get with the above examples:
04-12 13:43:11 KiBuzzard.KiBuzzard.plugin 25:This is from the plugin.py file! It should log even before the dialog was opened.
04-12 13:43:19 KiBuzzard.KiBuzzard.dialog.dialog 56:This is from dialog.py and should log as soon as you hit Cancel!

The file is not bloated as it gets reinitialized every time the plugin loads.

Awesome! This will help a lot, thanks.

It might also be helpful to remind users to post their kibuzzard.log file when they submit a bug.


Fix the undeclared PEM_R_HEADER_TOO_LONG in pvkfmt.c at line 279

It just got fixed, I hadn't noticed this PR before now...  either way, it wasn't enough, this should also have affected crypto/pem/pem_err.c
Closing this.


Formatter inconsistencies

VSCode Version: 1.19.3
OS Version: Windows 10

Steps to Reproduce:

Create an extension with the following fomatter in activate().

    let formatter = vscode.languages.registerDocumentFormattingEditProvider('myfiletype', {
        provideDocumentFormattingEdits(document: vscode.TextDocument): vscode.TextEdit[] {
            let ret = [];
            ret.push(vscode.TextEdit.replace(document.lineAt(1).rangeIncludingLineBreak, "aaa" + counter + "\n         aaaa\n\n"));
            ret.push(vscode.TextEdit.replace(document.lineAt(0).rangeIncludingLineBreak, "bbb" + counter + "\n         bbbb\n\n"));
            counter++;
            return ret;
        }
    });
    let counter = 0;

Run the extension and in a corresponding file (with at least a few lines), execute Format Document twice.

The result is fine.

bbb1
         bbbb

aaa1
         aaaa

aaa0
         aaaa

In the code, comment the line counter++; (or remove + counter +) from the lines above.

Execute the extension with the same file and run Format Document twice.

The result is

bbb0
aaa0
         bbbb

         aaaa

aaa0
         aaaa

Notice that the line order changed.
This looks like the .replace commands are cached somehow and if nothing changes – counter stays the same or there is no need for a counter – then it is not correctly re-evaluated and the two commands mix up. This might even be a JS compiler bug?

The command is surely run an invoked two times but it's a weird edit sequence because they overlap. Needs some drilling


Problem with decoding Datamatrix barcode

Good day everyone,
I have a problem with decoding Datamatrix with ZXing librariy v.2.1.0 (v.1.4.0 does not work either.)
The binarazed image is attached. Many, but not all, online barcode scanners are able to decode the image. Also all of 4 mobile readers in my phone can read the barcode. The value in all cases is
X00757802875181858104010000000000000319815214512968170650529622727009008910041585626882644047396078270256999175399935731643453045115000000000
It worth mentioning, similar barcodes (the same size and structure, printed on device of the same type)  are reliably decoded.
Thank you in advance for any advice.

The problem is the upper right corner of the symbol. There is a local vertical stretching or deformation. The current approach of placing a regular sampling grid over the symbol fails in that case. You might want to have look at #252.

Thank you for the answer. I made stretching corrections based on timing marks, and as a result, the image was successfully decoded.
May I suggest adding axis stretching correction to the ZXing library? Vertical stretching can be caused by barcode printers, and this is not just a single occurrence.
Anycase, I'll use image stretching if ZXing returns matrix position, but zero-lencht text.

Sorry for the delayed response. I somehow missed your last comment. Can you explain to me what you mean by

stretching corrections based on timing marks

and

adding axis stretching correction to the ZXing library

I just discovered that my response sent via email did not appear in the thread, so I will repeat it here.
The attached image gives an illustration.

The DataMatrix fragment on the left exhibits a distortion along the Y-axis, which is particularly noticeable in the first three rows. This type of distortion can be corrected as the number of timings can be calculated and the dimensions of the image are known. Due to the irregular nature of the distortion, I perform the correction on a row-by-row basis.
The likely cause of the Y-axis distortion is an eccentricity in the barcode printer or some other mechanical issue. While I'm not certain how common this problem is, if it proves to be a frequent issue, incorporating the correction directly into the library could be a viable solution.

Thanks for following up on this but...

the number of timings can be calculated

again, I don't know what you mean by that statement. Can you point me to some source code with your changes?

Yes, I can send the code snippets to you. Could you please provide your email address where I should send them?

zxingcpp at gmail.com

I sent the code to you mail. Please find it.

Hello, I have the same problem with this photo.  Another program reads it without a problem.  Is there such a solution?


chore: Support --container-runtime kubelet arg removal and kustomize v5 for k8s 1.27

What this PR does / why we need it:
The containerd addon provides a kubeadm init and join configuration that sets the field kubeletExtraArgs.container-runtime. However, Kubernetes 1.27 removed this kubelet argument: https://kubernetes.io/blog/2023/03/17/upcoming-changes-in-kubernetes-v1-27/#removal-of-container-runtime-command-line-argument.
Kubernetes 1.27 also introduced a new major version of kustomize, v5:

Upgrades functionality of kubectl kustomize as described at https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv5.0.0 and https://github.com/kubernetes-sigs/kustomize/releases/tag/kustomize%2Fv5.0.1.

This was causing the flannel addon to fail since it was using the legacy style patches specification.

This is a new major release of kustomize, so there are a few backwards-incompatible changes, most of which are rare use cases, bug fixes with side effects, or things that have been deprecated for multiple releases already:

https://github.com/kubernetes-sigs/kustomize/pull/4911: Drop support for a very old, legacy style of patches. patches used to be allowed to be used as an alias for patchesStrategicMerge in kustomize v3. You now have to use patchesStrategicMerge explicitly, or update to the new syntax supported by patches. See examples in the PR description of https://github.com/kubernetes-sigs/kustomize/pull/4911.

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Steps to reproduce

Does this PR introduce a user-facing change?

Does this PR require documentation?

There is a bug in kustomize v5.x where it doesn't allow me to migrate legacy kustomization.yaml files via kustomize edit fix as I get the following error:
rafael@rafael-k8s127-dev-test-20230426103405:~$ kustomize edit fix
Error: invalid Kustomization: json: cannot unmarshal string into Go struct field Kustomization.patches of type types.Patch
Usage:
  kustomize edit fix [flags]

Examples:

	# Fix the missing and deprecated fields in kustomization file
	kustomize edit fix

Flags:
  -h, --help   help for fix
      --vars   If specified, kustomize will attempt to convert vars to replacements.
               We recommend doing this in a clean git repository where the change is easy to undo.

Global Flags:
      --stack-trace   print a stack-trace on error

In the interim I'm going to use kustomize-v3.5.4 until the aforementioned bug is fixed. The drawback is that for Kubernetes 1.27 these warnings will appear when the Flannel addon is applied:
# Warning: 'patchesStrategicMerge' is deprecated. Please use 'patches' instead. Run 'kustomize edit fix' to update your Kustomization automatically.


disconnect a user from a voice channel

General Troubleshooting

[x]  I have checked for similar issues.
[x]   I have updated to the latest JDA version.
[x]   I have checked the branches or the maintainers' PRs for upcoming features/bug fixes.

Issue
Issue Type

[ ]   Bug Report
[x]   Feature Request

Description
Disconnect a user from a voice channel, without moving/kicking him.
Modify Guild Member

JDA 4 already has the option to kick a user from VC by providing null as channel.

This is already available in JDA v4 with guild.kickVoiceMember(member).queue()


Added this repo as a submodule

I'm totaly new here. I coud add this repo into my repo as a submodule.
I also could build on Linux and Windows.
I've two thing I don't know and I don't find the right answer.
1.) In the past OpenCL 1.2 was only a header file. What is this package?
cmake path/to/opencl/app -DOpenCLHeaders_ROOT=/chosen/install/prefix
I added it in the main file and fails? Where should is put this? When the package is created? What kindof package?
Why a package helps me? I want to use for many things OpenCL?
2.) The package doesn't find:
cmake_minimum_required(VERSION 3.0)
cmake_policy(VERSION 3.0...3.18.4)
project(proj)
add_executable(app main.cpp)
find_package(OpenCLHeaders REQUIRED)
target_link_libraries(app PRIVATE OpenCL::Headers)
Is this repo create a package for easy usage and I just to add it to the target? I'm big fun of OpenCL and I want to understand it. :-)
Could you be so kind give an example?
Thanks,

I've one problem: I've already use conan and I don't know how to add it. Furthermore I have to do it both on Linux and Windows. How can I pass to conaninfo file to my app?

Hello!
Here are two repos that use the OpenCL headers.  Both currently use the OpenCL headers without needing the CMake package, though the "OpenCL SDK" will be upgraded shortly:

https://github.com/KhronosGroup/OpenCL-SDK
https://github.com/bashbaug/SimpleOpenCLSamples

In short, you don't need to use the CMake package, though building and using the CMake package can arguably simplify some dependencies.
I don't use conan, but if you'd be interested in adding conan support for an OpenCL headers package we'd be happy to work with you to add support.  Glad to hear you're an OpenCL fan!


Invalid axios.all TypeScript Definition

The TypeScript definitions for axios.all are not correct in that they don't conform to the ES6 Promise.all interface. The first issue is that it assumes that the return value from axios.all is an array of promises whose resolve values are an array of Axios.AxiosXHR types. The resolve values could be of any type, not just Axios.AxiosXHR.
Second issue is that the .all interface is poorly designed. It has a hardcoded number of paramter types of maximum length 10. This is also incorrect as it could be of any size. Instead it should just use a generic array of type T[] where T can be of any (or some common base class).
My suggestion is to just look at ES6-Promise.d.ts and copy what they have there.

The interface for all should just be
all(values: [T | IPromise]): IPromise<T[]>;

Also it looks like the spread function is also not correct as it only assumes there are two parameters, but destructuring has no limit to the number of attributes

Thanks for catching this. I don't use TypeScript, so I am not well versed in how this stuff works. Would be happy to accept a PR to fix these issues.

Thanks, I will try to do so soon as I really do like axios. As a workaround for this, I was able to utilizing Promise.all (by referencing es6-shim.d.ts) instead of axios.all to allow for my TS code to compile without errors.

Closing in favor of a single issue for all typescript requests (#379).


Run Infer on standalone Jar/War files.

I want to run Infer in bulk on a few Jar files. Is there a way to run infer capture without the --sourcepath option and just tell it to ingest all the class files it sees in the --generated-classes?

This isn't currently possible. There is a --dependencies that was used for this, but the last time I tried this it failed so probably has bit-rotted.

Thx. Do you know what the --sourcepath is used for? Would it be possible to just touch the filenames that it needs, or do I actually have to run it through a decompiler?

touch might just work. I believe (look at jMain:capture_libs) this is what --dependencies used to do on the fly.

Run Infer on standalone Jar/War or classes files path, we also need it .


B550 unsupported (Ryzen 5600x)

It would be nice to see some 5 AMD's series taken care of.
So far nobody should buy a B450 nowadays :-D

Yes please! I got a B550m Mortar

Yes please! I got a B550m Mortar

Sorry, won't happen. I'm not adding support for any new motherboards. It seems they all use a different mechanism for LEDs.


[Compiler/Decompiler] Better support for Bitfield and Enum types

This makes enums real types, like bitfields.
So far:

Fixed bugs where boxed arrays of enums/bitfields were broken
Made enum types real types in the compiler. They can be used for fields, pointers, function args/return values, locals, etc, just like bitfields. Just like bitfields, they require casting to and from int.  Most of the reason for doing this was to make the type systems of the compiler/decompiler match more closely.
Support for decompiling bitfield enum constants that appear in code

To Do:

Support bitfield enum constant in static data too (should be easy)
Fix bad casting with (logior <bitfield-enum> <constant>).  The type pass correctly determines that the result of this is also a bitfield enum, but somehow things go wrong later on.
Try to find some examples of non-bitfield enums and add those too.

Looks good
    lwu v1, 4(s4)             ;; (set! v1-17 (l.wu (+ arg0 4)))[37] [s4: process ] -> [v1: process-mask ]
    ori v1, v1, 512           ;; (set! v1-18 (logior v1-17 512))[38] [v1: process-mask ] -> [v1: process-mask ]
    sw v1, 4(s4)              ;; (s.w! (+ arg0 4) v1-18)[39] [v1: process-mask s4: process ] -> []

Also good:
    (set! v1-17 (-> a1-0 mask))
    (set! v1-18 (logior v1-17 512))
    (set! (-> a1-0 mask) v1-18)

Wrong:
set! (-> arg0 mask) (logior (the-as int (-> arg0 mask)) 512))

if it attempted to cast the 512 to a process-mask it would get decompiled properly.

A bunch of bitfield enum things now work properly
operations with logand and logior
;; old
(nonzero? (logand (-> arg0 mask) 256))
;; new
(nonzero? (logand (-> arg0 mask) (process-mask process-tree)))
;; old
(set! (-> pp mask) (logior (-> pp mask) 1024))
;; new
(set! (-> pp mask) (logior (-> pp mask) (process-mask going)))

operations with logand and lognot that were constant folded:
;; old
(set! (-> obj mask) (logand -961 (the-as int (-> arg0 mask))))
;; new
(set!
   (-> obj mask)
   (logand
    (lognot (process-mask sleep sleep-code process-tree heap-shrunk))
    (-> arg0 mask)
    )
   )

Setting a value:
;; old
(set! (-> a0-57 mask) (the-as uint #x4011c))
;; new
(set! (-> a0-57 mask) (process-mask pause menu progress process-tree camera))

Still needs support for static data, and for non-bitfield enums.

Pull Request Test Coverage Report for Build 772584499

107 of 129 (82.95%)  changed or added relevant lines in 14 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.02%) to 69.281%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

common/type_system/Type.cpp
18
20
90.0%

common/type_system/defenum.cpp
16
18
88.89%

decompiler/util/data_decompile.cpp
14
17
82.35%

decompiler/IR2/FormExpressionAnalysis.cpp
19
34
55.88%

Files with Coverage Reduction
New Missed Lines
%

game/system/iop_thread.cpp
1
96.08%

Totals

Change from base Build 765419526:
0.02%

Covered Lines:
33723

Relevant Lines:
48676

💛  - Coveralls


Using directives together with properties removes already existing content.

Description
Using lit-html asyncAppend directive together with LitElement properties causes the content to be completely overwritten.
Live Demo
https://stackblitz.com/edit/lit-element-example-4yr9zg
Steps to Reproduce

Create an async generator that yields a value every x seconds
Use asyncAppend directive, from lit-html, to generate new content
Add a property that changes upon an event.

Expected Results
Content added through asyncAppend should still be present after the property has changed.
Actual Results
Content added through asyncAppend disappears after the property has changed.
Browsers Affected

[x] Chrome
[x] Firefox
[ ] Edge
[ ] Safari 11
[ ] Safari 10
[ ] IE 11

Versions

lit-element: v0.6.3
webcomponents: v2.1.3
lit-html: v0.13.0

Closing. This appears to be an issue in lit-html itself.


[ptf_nn_agent] enable capturing vlan tag by using afpacket

Signed-off-by: Mykola Faryma<EMAIL_ADDRESS>Fixes #107

Opened https://github.com/p4lang/ptf/pull/109


install bot in another conv

Novel for first use of useRPC I think (other than ones from initial commit).
Also cc @adamjspooner


Getting 401 on confluence publish

https://confluence.corp.mycompany.com
parent page id provided
Personal Access Token provided

Is this a cloud or on premise instance?

Same with me. Confluence ist installed on premise (by the providing company). Feature would be excellent!

Closing off in favour of #91 . I did an evaluation today with the results on https://github.com/markdown-confluence/markdown-confluence/issues/91#issuecomment-1537293277


Kashirin & Sivak to review

Not all mech. implemented yet.
DB account server & leaderboard no attached to project yet too.

Провел первичное ревью


Theme is not applied when importing a component

Hi!
I'm aware it might sound silly, but I was trying react-toolbox and I couldn't make it import styles. I've checked react-toolbox-examples and I think I'm doing mostly the same, but I can't see any difference that explains why I'm noot seeing styles in my imported component. This is what I'm doing:
import React from 'react'
import Button from 'react-toolbox/lib/Button'

export default () => (

      <Button label='Primary Button' />

)

And this is what I see:

It seems that CSS Modules is loading the styles:

And the generated HTML:

My webpack.config:
resolve: {
    extensions: ['', '.scss', '.css', '.js', '.jsx', '.json'],
    modulesDirectories: [
      'node_modules',
      path.resolve(__dirname, './node_modules')
    ]
  },

  module: {
    loaders: [{
      test: /\.jsx?$/,
      loader: 'babel',
      exclude: path.resolve(__dirname, './node_modules')
    }, {
      test: /\.s?css$/,
      loader: 'style!css!sass!postcss'
    }, {
      test: /\.ejs$/,
      loader: 'ejs-loader'
    }]
  },

  postcss: [autoprefixer],

  sassLoader: {
    data: '@import "theme/_config.scss";',
    includePaths: [path.resolve(__dirname, './src/client')]
  },

The config in my custom theme:
@import "~react-toolbox/lib/colors";

$color-primary: $palette-blue-500;
$color-primary-dark: $palette-blue-700;

Please let me know if you need something else to identify the error... I know it may sound a silly question but I've spent some time already and I can't figure out what's going on :(

Seeing the same thing except with the AppBar. The outer  tag of the component has an empty class attribute so none of the styling is applied.

Seeing the same thing except with the AppBar. The outer  tag of the component has an empty class attribute so none of the styling is applied.

I was having this issue as well. Changing my webpack config to this seems to have alleviated the issues.
var path = require('path');
var webpack = require('webpack');

var config = {
    devtool: 'inline-source-map',
    // devtool: 'eval-source-map',
    entry: [
        './src/app.js', 'webpack-hot-middleware/client'
    ],
    output: {
        path: path.join(__dirname, 'dist'),
        filename: 'bundle.js',
        publicPath: '/dist/'
    },
    plugins: [new webpack.NoErrorsPlugin()],
    module: {
        loaders: [
            {
                test: /\.js$/,
                loaders: ['babel']
                // exclude: /node_modules/
            }, {
                test: /\.less$/,
                loaders: ["style", "css", "less"]
            }, {
                test: /\.scss$/,
                loader: 'style!css?sourceMap&modules&importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]!sass?sourceMap'
            }
        ]
    }
};

module.exports = config;

It should be documented. What I miss in your posted config is the configuration parameter to enable css modules (which is modules in css loader querystring. Glad it's fixed! :)


[connectivity] No Location Permission preprocessor flag

Description
On iOS, if you do not specify NSLocationAlwaysUsageDescription or NSLocationWhenInUseUsageDescription, you can be rejected by iOS simply because Connectivity uses APIs that required them.  However, you may not wish to ever use this sensitive data, and only want to use Connectivity to check and listen for the user's reachability status.  This PR allows a user of the plugin to specify whether they would like to disable any code that uses these sensitive APIs by specifying a macro in their Podfile, similar to how the permission_handler plugin works.
I updated the README to explain how user's can utilize this.
Related Issues
Resolves: https://github.com/flutter/flutter/issues/40418
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

I have read the updated the README. Are there instructions on, "specifying a macro in their Podfile"?

are there instructions on, "specifying a macro in their Podfile"?

@kauaicreative, the README is modified to show how you specify a macro in the Podfile, particularly this bit:
To do so, add the following to your `Podfile`:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      ... # Here are some configurations automatically generated by flutter

      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [
        '$(inherited)',
        'DISABLE_CONNECTIVITY_LOCATION_CODE=1'
      ]
    end
  end
end

To re-enable that code, you should remove the `'DISABLE_CONNECTIVITY_LOCATION_CODE=1'` and insure `pod install` is run again.

I'm wondering if it safe to revert back to connectivity from simple_connectivity.

I am using this fork in my app with success and it is currently up to date with the plugins repo, but I think it may be better to stick with simple_connectivity until i get some feedback on this PR

Would be great to get this merged. The permission_handler plugin is already using macros like this.

Will it possibly take a while to get this approved?  And if so, @KevinTheGray do you feel pretty good about me going into production with your simple_connectivity version?

@stephenhuey I think it might be a little while, since it hasn't started review yet.  Once the review starts, I'm sure there will be some additional feedback that might take a bit to get done.
I think simple_connectivity is safe for production, it looks like it offers everything connectivity does, without the location requirements.

This issue is very critical since it doesn't allow us to submit app to App Store on iOS 14. I'm getting an error after App Store processing that I traced back to this - "ITMS-90842: Invalid SDK usage - App clip 'Runner.app/AppClips/AppClip.app' uses the SDK selector 'requestAlwaysAuthorization', which is not supported. Ensure your app clip is using supported SDK features."

@KevinTheGray - please update here when you've resolved the "Conflicting files"
FYI @Vanethos

@brunobowden Thanks for the feedback!  I'll make those changes.   I'm actually not sure why the README got formatted like that.. I switched to VSCode recently and I think it autoformatted the file like that for some reason.  I'll get that reverted.

@KevinTheGray - thanks for doing a thoughtful job on this. I hope that this works for @cyanglaz.

Change title in commit and GitHub. Again, assume that Android could adopt the same policy, so this is the basis for a cross platform "Don't make me require Location Permissions" config.
Suggested Title: [connectivity] No Location Permission preprocessor flag

Thanks again! I'll go through this and update asap

@KevinTheGray - see the failure here. Nice to get all the checks passing ready for review:
https://github.com/flutter/plugins/pull/2771/checks?check_run_id=1207080912

@KevinTheGray - still two failures: both CRC checks. My first suggestion would be to rebase and hope that someone else has fixed this. I expect this is causing other PRs to fail too:
https://github.com/flutter/plugins/pull/2771/checks?check_run_id=1248587802
https://github.com/flutter/plugins/pull/2771/checks?check_run_id=1248587782
Downloading ios-release tools...                                    8.2s
/Users/anka/flutter/bin/cache/artifacts/engine/ios-release/Flutter.framework.zip  bad CRC f7b6ef7b  (should be d52a7539)
Downloading ios-release tools...                                    7.9s
/Users/anka/flutter/bin/cache/artifacts/engine/ios-release/Flutter.framework.zip  bad CRC 56124e25  (should be d52a7539)

@brunobowden Just pulled in master and it's currently passing now.  I'll keep an eye on it, seems like the CI will periodically re-trigger and sometimes fail even if I haven't pushed any new changes

Thanks @KevinTheGray. I'd just like to keep it warm for when @cyanglaz gets a chance to look at it.

@cyanglaz @bparrishMines - perfectly respect the decision on making a separate plugin. It does make the most long term sense. Any ideas on the time frame?
@KevinTheGray - good working with you on the PR. Though this may not make the light of day, better things will come in its' place.

@brunobowden thanks for the reviews!  The separate plugin approach will definitely keep things simpler going forward. In the meantime i can just use my branch until the separation is complete.

@KevinTheGray - how do you use your branch? Is it published as a plugin? I might have an interest in using it for the WHO app depending on the timeline for wifi_info_flutter plugin.

You can add this to your pubspec.yaml dependencies
connectivity:
    git:
      url: https://github.com/KevinTheGray/plugins
      ref: kg-connectivity-ios-permissions
      path: packages/connectivity/connectivity

you can also lock it to a certain commit if desired: https://dart.dev/tools/pub/dependencies

@KevinTheGray it says "Package doesn't exist (the pubspec for connectivity 0.5.0 from git has version 0.4.10"

@anotherglitchinthematrix that's strange, can you share your puspec.yaml?  I just created a new flutter project to test it out, and it seems to be working for me.

@KevinTheGray Sure, thank you.
version: 0.5.0+82

environment:
  sdk: ">=2.6.0 <3.0.0"

dependencies:
  flutter:
    sdk: flutter
  provider: ^4.3.2
  hive: ^1.4.3
  http: ^0.12.2
  xml: ^4.2.0
  html_unescape: ^1.0.1+3
  firebase_core: ^0.5.0
  firebase_crashlytics: ^0.2.1+1
  firebase_analytics: ^5.0.16
  firebase_auth: ^0.18.1+1
  cloud_firestore: ^0.14.1+2
  firebase_messaging: ^7.0.2
  collection: ^1.14.13
  intl: ^0.16.1
  share: ^0.6.5+2
  url_launcher: ^5.7.2
  path_provider: ^1.6.18
  connectivity: ^0.4.9+3  # I revert it to original.
  dio: ^3.0.10
  dio_http_cache: ^0.2.11

dev_dependencies:
  flutter_test:
    sdk: flutter
  hive_flutter: ^0.3.1
  hive_generator: ^0.7.1
  build_runner: ^1.10.1
  flutter_launcher_icons: ^0.8.0

flutter_icons:
  android: true
  ios: true
  image_path: "asset/icon/icon.png"
  adaptive_icon_background: "asset/icon/icon.png"
  adaptive_icon_foreground: "asset/icon/icon.png"


fix: upgrade to version 3.2.115

from: https://github.com/jenkins-x/jx

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign garethjevans
You can assign the PR to them by writing /assign @garethjevans in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
618b60a691490da01304848a1f0e93e097d9cc4c
link
/test gsm

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

@jenkins-x-bot-test: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm
618b60a691490da01304848a1f0e93e097d9cc4c
link
/test gsm

gsm-kapp
618b60a691490da01304848a1f0e93e097d9cc4c
link
/test gsm-kapp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest


sort domain for main repo

doathon.opencon2017.org should be good.

got this domain successfully propagating. Set up www.doathon.opencon2017.org too, but still awaiting testing. Uses the same settings as the other domain so assuming it'll work and closing this.


[netcore][51.cafe bot] ReservationProperty.cs readonly properties not assigned correctly

Sample information

Sample type: [samples]
Sample language: [dotnetcore]
Sample name: <51.cafe-bot>

Describe the bug
The bot throws an exception when trying to parse the city entity.
To Reproduce
Steps to reproduce the behavior:

Go to /samples/csharp_dotnetcore/51.cafe-bot/
Open CafeBot.sln
Select and run CafeBot project
Open the bot in Bot Framework Emulator
Send Book a Table
The bot will send What city?
Send Seattle
The bot will reply with Sorry, it looks like something went wrong

Expected behavior
The bot should ask for the date after receiving the city.
Additional context
The exception gets thrown in line 105 in ReservationProperty.cs file, because the variable PartySizeEntity is not set. This originates from line 12 to line 20 of the same file, as multiple read-only variables are being assigned with values from luisEntities[] array, but this is being initialized after the assignmetn of the read-only variables.
A possible way to fix this is to move the luisEntities[] array initialization before the assignment of the read-only variables.
[bug]

Note: Does not repro in the JS cafe bot sample. Only the csharp sample is impacted.

Fixed via #957


Type hint for configure_scope suggests it can return None but it should not

How do you use Sentry?
Sentry Saas (sentry.io)
Version
1.12.1
Steps to Reproduce
import sentry_sdk
with sentry_sdk.configure_scope() as scope:
    pass

Expected Result
configure_scope should always return ContextManager and should never return None.
Instead of:
-> (ContextManager | None)

should always return:
-> (ContextManager)

Actual Result
Pylance complains:
(function) configure_scope(callback: ((Scope) -> None) | None = None) -> (ContextManager | None)

Object of type "None" cannot be used with "with"

Pylance reportOptionalContextManager

Workaround
import sentry_sdk
scope_ctx = sentry_sdk.configure_scope()
if scope_ctx is not None:
    with scope_ctx as scope:
        pass

or using :=:
import sentry_sdk
if (scope_ctx := sentry_sdk.configure_scope()) is not None:
    with scope_ctx as scope:
        pass

Hello @rafrafek, I tried to reproduce your error, but with the code you provided, my type hint shows up correctly, as you can see in the screenshot below:

Since everything appears to be working correctly on my end, I will close the issue for now.
However, if you are still experiencing this problem, please feel free to reopen the issue. And, if you reopen the issue, please also provide us with more details regarding your editor setup, so that we can reproduce the problem you found.

Thanks for looking into it!
I think it was fixed in 1.17.0 thanks to Fix: Rename MYPY to TYPE_CHECKING #1934 so now Pylance/Pyright can detect overloads properly.

Great! Thank you for reporting the issue, and glad to hear it is working now


[chef-17] backport Bump deps for net-ssh 7.x for RHEL 9 and Ubuntu 22.04 ssh and badssl self signed cert test

Description
Backport of bump deps for net-ssh 7.x for RHEL 9 and Ubuntu 22.04 ssh new algorithms support and backport fix for badssl self signed cert test. Cert was updated on Oct 28th 2022.
Related Issue

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

[x] I have read the CONTRIBUTING document.
[x] I have run the pre-merge tests locally and they pass.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] All commits have been signed-off for the Developer Certificate of Origin.

@jaymzh @tpowell-progress @PrajaktaPurohit @johnmccrae This PR has balooned a little into fixed pipelines for chef-17 branch. I almost have them fixed. I'm not sure what is causing the unit test for gems from non api website spec to fail. The other windows failures are around habitat and failure to find chef-utils 17.10.26 gem. Do you guys have any insights into how to fix these?

Let's put this near the top of the priority for Chef 17 merges

@Stromweld 👋 thank you for this PR; can I ask if there's a possibliity it will be merged soon? it's causing major problems for folks on chef 17 🙏

@Stromweld thank you for this PR
@tpowell-progress can I ask if there's a possibliity this will be merged soon? it's causing major problems for folks on chef 17 🙏


remove ByMeACoffee btn

Resolves #67
What changed
"Buy Me a Coffee" button is removed from the navbar
(Prettier has automatically formatted the file)

Hi @ann-kilzer, I have changed the format back to the original:)

Hi @theyokohamalife, I'm not sure if the conflict is solved now after I updated my branch, could you tell me?


Automated cherry pick of #9592

Cherry pick of #9592 on release-6.3.
/cc  @AshishDhama
NONE

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

Trying to auto merge this PR.

Pull Request successfully merged
SHA: 6f1db374daac622d865b3eb258bc3f9410071f5d


Fixed missing word in persistent-volumes.md

There was a word missing in persistent-volumes.md. I added it.

Hi @divya-mohan0209 , as I am currently reading the entire documentation, I will likely find more trivial errors in the near future. Should I just open a draft PR and commit all my findings to there?

Hey @ClimberJ , I meant this very specific page that you have read through. Trivial edits are accepted if they improve the quality of the documentation.


deployment and testing of METdatadb

Describe the New Feature
Create scripts to run METdatadb on AWS and WCOSS. Test strips and the loader on AWS
Acceptance Testing
The test data  from the local server should be loaded into the database on AWS
Time Estimate
Estimate the amount of work required here.
Issues should represent approximately 1  day of work.
Relevant Deadlines
NONE.
Funding Source
NONE.
Define the Metadata
Assignee

[ ] Select engineer(s) or no engineer required
[ ] Select scientist(s) or no scientist required

Labels

[ ] Select component(s)
[ ] Select priority
[ ] Select requestor(s)

Projects and Milestone

[ ] Review projects and select relevant Repository and Organization ones or add "alert:NEED PROJECT ASSIGNMENT" label
[ ] Select milestone to next major version milestone or "Future Versions"

Define Related Issue(s)
Consider the impact to the other METplus components.

[ ] METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy

New Feature Checklist
See the METplus Workflow for details.

[ ] Complete the issue definition above, including the Time Estimate and Funding source.
[ ] Fork this repository or create a branch of develop.
Branch name: feature_<Issue Number>_<Description>
[ ] Complete the development and test your changes.
[ ] Add/update log messages for easier debugging.
[ ] Add/update unit tests.
[ ] Add/update documentation.
[ ] Push local changes to GitHub.
[ ] Submit a pull request to merge into develop.
Pull request: feature <Issue Number> <Description>
[ ] Define the pull request metadata, as permissions allow.
Select: Reviewer(s), Project(s), Milestone, and Linked issues
[ ] Iterate until the reviewer(s) accept and merge your changes.
[ ] Delete your fork or branch.
[ ] Close this issue.

Loading data to AWS was successful.
A loading script for local usage was added

Loading data to AWS was successful.
A loading script for local usage was added


@-moz-document url-prefix()  removed

CSS declarations targeting mozilla browsers are removed by the plugin:
@-moz-document url-prefix() {
...
}

+1


Add support for ~ in zigLanguageClient.path

When attempting to do ~/Code/zls/zig-cache/bin/zls, the extension fails with
[Error - 12:51:26 PM] Starting client failed
Launching server using command ~/Code/zls/zig-cache/bin/zls failed.

Perhaps show the error next time? Solution was /home/lunar/Code/zls/zig-cache/bin/zls

Same issue I was pointing to ~/zls/zls and couldn't figure out why it wasn't starting.
I realize this is a separate issue but it would be great if zls just printed out the correct path after running configure.


⚠ Prueba_Error_500 has degraded performance

In da3106f, Prueba_Error_500 ($URL_ERROR_500) experienced degraded performance:

HTTP code: 200
Response time: 7945 ms

Resolved: Prueba_Error_500 performance has improved in 5a735e1 after 566 days, 13 hours, 30 minutes.


Add "#pragma once" to the test header files

I'm not sure if this applies to precompiled headers, if not, please just close the PR.

Thanks!


fix(sys): use APPDIR environment variable when running as an appimage

What kind of change does this PR introduce? (check at least one)

[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Documentation
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes. Issue #___
[ ] No

The PR fulfills these requirements:

[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
[x] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
@wusyong @FabianLars I know I said it would be fine to use the pkg-config thing in an AppImage, but I was wrong :joy: easier to do it this way I believe.

In the case of AppImages tauri will run pkg-config in the bundler to get the path to the library, then copy it to /usr/bin/${libName}.so in the appimage directory.

I think I'll even expose the logic to get the lib path so we can reuse it.


What is musabgultekin/functionary-7b-v1

Hey,I think your repo is interesting, but I have some questions.
In your README.md, run python3 server.py --model "musabgultekin/functionary-7b-v1" to start server ,but what is musabgultekin/functionary-7b-v1 an how can I get it.

Oooooo,I have a another question, is it same to Code Interpreter ? Or what's difference about them?

Hey,I think your repo is interesting, but I have some questions. In your README.md, run python3 server.py --model "musabgultekin/functionary-7b-v1" to start server ,but what is musabgultekin/functionary-7b-v1 an how can I get it.

Its the model's name on huggingface.

Oooooo,I have a another question, is it same to Code Interpreter ? Or what's difference about them?

No its not, this allows calling arbitrary functions in any language. Not python code.


Can't import Publicodes in the Svelte REPL

I guess something is wrong in the package.json?
https://svelte.dev/repl/5caf4d5ff3e74ec09b565c73c7b96c79?version=3.44.2

Maybe this is a problem with the Svelte REPL https://github.com/sveltejs/svelte-repl/issues/176 ?


Add Haskell benchmark

Add a Haskell grpc benchmark.
The library is here: https://github.com/awakesecurity/gRPC-haskell

[ ] gRPC server implementation
[ ] Dockerfile to build an image with the gRPC server
[ ] update build.sh, clean.sh and bench.sh scripts

I tried and I failed.
I'm stuck at including the grpc library in the project.
If someone wants to give it a try: https://github.com/LesnyRumcajs/grpc_bench/tree/haskell-perf