URI of the preview definition not being sent correctly

Description
So I'm not fully sure if this belongs in core or not, but I realized when using the preview definition functionality with lspsaga, after the textDocument/definition has returned for the preview and the float created a textDocument/didOpen follows. However, the uri of that didOpen request that is sent is incorrect. Here is an example, and you should be able to mimic it with any server.
[Trace - 07:58:36 PM] Sending response 'textDocument/definition - (5)'. Processing request took 265ms
Result: [
  {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/worksheets/.metals/readonly/scala/concurrent/Future.scala",
    "range": {
      "start": {
        "line": 651,
        "character": 12
      },
      "end": {
        "line": 651,
        "character": 19
      }
    }
  }
]

[Trace - 07:58:36 PM] Received notification 'textDocument/didOpen'
Params: {
  "textDocument": {
    "uri": "file://",
    "languageId": "scala",
    "version": 0,
    "text": "\n"
  }
}

Expected Behavior
I'd expect the uri in textDocument/didOpen to match the uri that was returned from the definition. Is this possible at all?
Actual Behavior
The uri is just set to file://

yep the floatwindow has no filename .so looks like there is no filename to pass to textDocument/didOpen

the floatwindow has no filename .so looks like there is no filename to pass to textDocument/didOpen? How to manually request textDocument/didopen?

I don't manually do it actually. It happens automatically when textDocument/definition is returned and right after the float preview is created.

can you check the default handler response?

@ckipp01 Does the same with the builtin method
function PeekDefinition()
   local params = vim.lsp.util.make_position_params()
   return vim.lsp.buf_request(0, 'textDocument/definition', params, preview_location_callback)
end

I'm also a bit confused why a textDocument/didOpen is sent -- you're not actually opening a file but simply showing a "scratch buffer"?

So when just doing a normal textDocument/definition, then yea, there is no issues as you can see the response has the correct uri, and it opens it correctly, as expected
[Trace - 00:59:01 PM] Received request 'textDocument/definition - (23)'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/src/main/scala/example/Main.scala"
  },
  "position": {
    "line": 11,
    "character": 2
  }
}

[Trace - 00:59:02 PM] Sending response 'textDocument/definition - (23)'. Processing request took 104ms
Result: [
  {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",
    "range": {
      "start": {
        "line": 396,
        "character": 6
      },
      "end": {
        "line": 396,
        "character": 13
      }
    }
  }
]

[Trace - 00:59:02 PM] Received notification 'textDocument/didOpen'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",
[Trace - 00:59:01 PM] Received request 'textDocument/definition - (23)'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/src/main/scala/example/Main.scala"
  },
  "position": {
    "line": 11,
    "character": 2
  }
}

[Trace - 00:59:02 PM] Sending response 'textDocument/definition - (23)'. Processing request took 104ms
Result: [
  {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",
    "range": {
      "start": {
        "line": 396,
        "character": 6
      },
      "end": {
        "line": 396,
        "character": 13
      }
    }
  }
]

[Trace - 00:59:02 PM] Received notification 'textDocument/didOpen'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",[Trace - 00:59:01 PM] Received request 'textDocument/definition - (23)'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/src/main/scala/example/Main.scala"
  },
  "position": {
    "line": 11,
    "character": 2
  }
}

[Trace - 00:59:02 PM] Sending response 'textDocument/definition - (23)'. Processing request took 104ms
Result: [
  {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",
    "range": {
      "start": {
        "line": 396,
        "character": 6
      },
      "end": {
        "line": 396,
        "character": 13
      }
    }
  }
]

[Trace - 00:59:02 PM] Received notification 'textDocument/didOpen'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",[Trace - 00:59:01 PM] Received request 'textDocument/definition - (23)'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/src/main/scala/example/Main.scala"
  },
  "position": {
    "line": 11,
    "character": 2
  }
}

[Trace - 00:59:02 PM] Sending response 'textDocument/definition - (23)'. Processing request took 104ms
Result: [
  {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",
    "range": {
      "start": {
        "line": 396,
        "character": 6
      },
      "end": {
        "line": 396,
        "character": 13
      }
    }
  }
]

[Trace - 00:59:02 PM] Received notification 'textDocument/didOpen'
Params: {
  "textDocument": {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",
...

But then doing a saga peek I get the following
[Trace - 01:00:31 PM] Sending response 'textDocument/definition - (25)'. Processing request took 79ms
Result: [
  {
    "uri": "file:///Users/ckipp/Documents/scala-workspace/tester/.metals/readonly/scala/Predef.scala",
    "range": {
      "start": {
        "line": 396,
        "character": 6
      },
      "end": {
        "line": 396,
        "character": 13
      }
    }
  }
]

[Trace - 01:00:31 PM] Received notification 'textDocument/didOpen'
Params: {
  "textDocument": {
    "uri": "file://",
    "languageId": "scala",
    "version": 0,
    "text": "\n"
  }
}
[Trace - 01:00:31 PM] Received notification 'textDocument/didChange'
Params: {
  "textDocument": {
    "version": 2,
    "uri": "file://"
  },
  "contentChanges": [
    {
      "text": "  Definition Preview\n\n  def println(x: Any) \u003d Console.println(x)\n\n  /** Prints its arguments as a formatted string to the default output,\n   *  based on a string pattern (in a fashion similar to printf in C).\n   *\n   *  The interpretation of the formatting patterns is described in\n   *  [[java.util.Formatter]].\n   *\n   *  Consider using the [[scala.StringContext.f f interpolator]] as more type safe and idiomatic.\n   *\n   *  @param text the pattern for formatting the arguments.\n"
    }
  ]
}

It's not a huge deal, but like you said, I don't fully understand why a didOpen and a didChange is then being sent back to the server.

Yeah, the same happens with the builtin handler. This sounds like an upstream (neovim, not nvim-lspconfig) issue. Can you open one there?

To be clear, I don't think a didOpen/didChange should be sent on a "scratch buffer" -- maybe check for a valid URI before sending it.

@clason in your example to test this what did you use for preview_location_callback?

@ckipp01 It's a built-in handler; should work out of the box.

Here's the didOpen handler: https://github.com/neovim/neovim/blob/b2fcfc65b7181cfb519ce1f827cb62f1120de5a0/runtime/lua/vim/lsp.lua#L286
You probably want to move that out and return if nil (like for the buf_is_loaded above).

👍🏼 I'll go ahead and close this. Lemme try to put something together for core for this.


Improve tectonic to allow events from more resources

Currently you can subscribe to one resource events or 'all'. We should improve this and allow subscribing to more than one resource. It will be handy to subscribe to VM and VMI events (maybe also VM's Pod)

@rawagner, still on the wish-list, right?

Yes, this will have to happen when moving our functionality to upstream openshift ui.
/remove-lifecycle rotten
/reopen


fix(array): Keep single empty row in AMS environments

I experimented in LaTeX, and it seems that {align}, {align*}, and even {aligned} environments (basically, all AMS environments) keep a single empty row if there is one, but remove a trailing empty row otherwise.  This PR implements this behavior.
This in particular prevents empty equation-numbered environment (e.g. {align}) from crashing (fix #2944).

Codecov Report

Merging #2947 (c815060) into master (bc718a0) will increase coverage by 0.01%.
The diff coverage is 100.00%.

:exclamation: Current head c815060 differs from pull request most recent head e490941. Consider uploading reports for the commit e490941 to get more accurate results

@@            Coverage Diff             @@
##           master    #2947      +/-   ##
==========================================
+ Coverage   93.92%   93.94%   +0.01%
==========================================
  Files          87       87
  Lines        6326     6327       +1
  Branches     1308     1309       +1
==========================================
+ Hits         5942     5944       +2
+ Misses        354      353       -1
  Partials       30       30

Impacted Files
Coverage Δ

src/environments/array.js
98.32% <100.00%> (+<0.01%)
:arrow_up:

src/environments/cd.js
99.15% <0.00%> (+0.84%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bc718a0...e490941. Read the comment docs.

@ylemkimon Thanks for the reviews!
How did you do a release with two PR fixes in it? (this one and #2949)


Replace GlobalRandom with Random.Shared

When I started this project with .NET 5 we had a need for an easily-accessible, therefore thread-safe Random instance and created GlobalRandom. With .NET 6 and onward we have Random.Shared which is a drop-in replacement. Nice!

Fixed in c607bb8


Sprint 2

Assignment
Points
Grade
Evidence

Pull Request (Integration)
2
1.6
 We submitted our pull request a day late.

Relevancy Checklist (Peer)
2

https://nighthawkcoders.github.io/portfolio_2025/csa/unit3-p1/unit3-3

Lesson (Group)
1
.8

Homework, Popcorn Hacks
1 x 8
.85, .85, 85, 93
https://docs.google.com/spreadsheets/d/1sGQtZm9GI2Rze5F7Eh_P1CMNO8Fyag4bCtOT0ddARmc/edit?gid=0#gid=0

Individual Contribution
1
.9
 In my first group I would try to contribute, though we would get distracted. In the new groups I can see my self trying to give more ideas, and discussing more code and contributing overall more.

Personal Notebooks / Blogs
1
0.9
https://anikabhatnagar20.github.io/anika_2025/ have been keeping this up to date and organized

Total
15

Assignment
Points
Grade
Evidence

Work Habits (Analytics)
1
.8
   Based on my github analytics there was an issue and they weren't synced so that wasn't updating the amount of commits, but on github my commits were there.

Team Planning (Issue)
1
.9
https://github.com/alishahussain/alishanew2025/issues/3

Presentation Memories
1
.75
Our team teach had a issue of not communicating and cross referencing withe each other which lead to a couple of miscommunications with the information which lead to a overall lower performance. For my part specifically I could have added more code example and perfect the one i did provide.

Grading and Feedback
1
.9
https://docs.google.com/spreadsheets/d/1W9nuXvCk3F3iMjvrlYa6nhQNuXGSQoxPxa-UzZm2o-g/edit?gid=1783700775#gid=1783700775 graded fairly

Beyond Perfunctory
1
.9
https://anikabhatnagar20.github.io/anika_2025/csa/unit3-p1/intro

Total
5

Learnings
https://anikabhatnagar20.github.io/anika_2025/2024/10/08/teamteachlearnings.html
Revision for team teach
https://anikabhatnagar20.github.io/anika_2025/ap csa/2024/10/09/introspective_IPYNB_2_.html

Assignment
Weightage
Grade
Comments

College Board Coverage
20
18
Good effort using College Board content, though more personal interpretation would better understanding.

Java Examples
30
25
Some examples were misused during the team teach, cross-checking would have avoided errors.

Popcorn Hack Usage
10
8
A variety of hacks were included to make the lesson more engaging, though some could have been clearer.

Homework
10
8
Homework was relevant and aligned with the material taught.

Grading Plan
10
10
Grading was fair

Original an Creative
10
8
Used a lot of College Board content; more original content or creative teaching would help improve this.

Total
90
77

I like your team-teach reviews; the bullet points are really clear. Your number game looks really cool, and it's a good application of coding. It's good that you have a reflection as well. Your team teach revision is a good way to go back and fix your mistakes. Great job!

I liked how you implemented the sorting algorithm with the card deck and included where each unit's material was being used

Greate prsentation. I liked how you added the main take away from each team teach. Your number game will really help you remember the college board concepts.

I liked how you made notes for each team teach. I also liked your number game and you fixed your popcorn hacks.

I liked how your team teach was based on feedback and bullet points were good. Your application of bubble sort is a great way to practice!

Hi Anika,
You took the initiative to apply your new knowledge to make a number game. Your team teach stood out to me because it was very easy to understand, there was no fluff. Nice iteration in revising your popcorn hacks.

Number sort was a nice way to show application of concepts. Review of team teach by improving on feedback was a great way to show reflection as well.

I like your team teach blog, your bullets are very clear. The number game also looks really good.

I really like how you applied how you learned by making a number sorting game and reflection on what unit information was used. I like how you revised your team teach by changing some of your examples and popcorn hacks.

I like how you made use of the sorting unit and how your game made use of all the information you learned. I also liked how you improved our team teaching. Great job taking the initiative and working on improving. Good job

hi anika i like your number game for the units and the reflection of the units. the revision of the team teach was a good addition as well

I liked how you made some notes, and that you made some corrections on your team teach. I think its very valuable to go back and reflect on what you did.

Hi Anika,
I liked the presentation notes you had.

The number game was really cool and the notes as well.


GVRView should support unregister view from activity.

GearVRf-DCO-1.0-Signed-off-by: Youwen Zhuang
<EMAIL_ADDRESS>

I see.. We automatically register the view but then we do not unregister automatically. When do you need to unregister? Do you think we can hide this in a finalizer so we can do it behind the scenes? Thanks.

Sometimes I need to create GVRView dynamically so I need a unregister to avoid memory leak.
In android framework, it supply unregister method rather than hiding it in a finalizer. So I think exposing interfaces to user is proper.

Actually this is probably the only way considering that the mRenderableViewGroup in GVRActivity holds a strong reference. Never mind my suggestion.
Still, how about updating the Javadoc to let people know that they need to use GVRActivity.unregisterView to get rid of the views they no longer need? We have the API already in place but it is not clearly communicated to what it applies and when to use it. I am not sure why we need to expose this API in the views in addition to GVRActivity.

Maybe you are right. But there is another thing that puzzled me. In GVRTextView, context register the mTextViewContainer. How can I unregister mTextViewContainer out of GVRTextView?

You need to have a reference to your GVRActivity-derived class. For example GVRContext.getActivity gives you that. Once you have it you can call GVRActivity.unregisterView. How does that sound?

Well, maybe I didn't catch your idea because of my pool English. Indeed, GVRActivity.unregisterView satisfies my demand so my commits is unnecessary. Thank you for your illustration.
By the way, maybe 'GVRTextView' should expose his member mTextViewContainer so that user can unregister it?


Update testnet deploy instructions to use Docker image for all operations

https://github.com/penumbra-zone/penumbra/wiki/Deployment-checklist#deployment-steps-for-the-existing-node
Currently we have to compile pd on the host (just to run generate-testnet) as well as have a Docker container present. We could use host directory volume mounts to make this better.

Closing as obsoleted by the new Strangelove docker setup.


i18n: Allow selecting a different language than device setting

Currently, the app UI follows the device setting for what language it should try to display in.
This issue is for an in-app setting to choose any language we have translations for, instead of always following the device.
An instance of:

#97.

Hi @chrisbobbe,
This storing of some client settings isn't yet implemented for Theme Switching among dark/light/system.
Am I right?
If yes. Then, where we might add this feature for language now and theme later on.
I would suggest keeping it here, in the menu button.

Thank you.

As an example of where this is desired, we heard from a user today:

In our team we use English as a default language in communication and collaborative apps, tho our native language is not English. Right now in Flutter app I can't change system language, but in legacy app it's not a problem.
[…] my system language is not English

So they want Zulip in English although they have a different language chosen for the system overall.


verify on deploy via etherscan

@robert-e-davidson3 Currently i'm passing the deploy artifacts into the verify task via args...  should we be pulling this from build artifacts instead?

@robert-e-davidson3 Currently i'm passing the deploy artifacts into the verify task via args... should we be pulling this from build artifacts instead?

This works fine for now. It's likely we will replace our deploy and verification with hardhat-deploy #43 but just getting stuff up quick now is great for phase 0.


Notification rules

Not all emails are equally important and deserve a notification. Right now K-9 Mail offers the following options:

never create a notification for new messages
only notify for messages from contacts
don't show notifications for messages where the sender address is one of your account's identities
only notify for messages in certain folders (using the clunky folder class mechanism)
don't notify during "quiet time"

Often more flexibility would be nice. But I don't want to keep adding special cases. Instead I'd like us to have a generic rules-based system for deciding whether or not to create a notification.
A notification rule should have the following properties:

description/comment: so users remember what the rule was all about
enabled state: sometime you want to disable rules without deleting them
action: the action that should be performed when the rule matches

mute: don't create a notification
notification_channel: create a notification using a particular notification channel; that way you can have different notification sounds, vibration on/off, etc
… maybe more in the future

action_extra: argument for the 'action' method, e.g. the ID of the notification channel
potentially multiple clauses: a rule matches when all clauses match

property: which property of the message is used for matching (e.g. sender, subject, body, header)
property_extra: free-form text to further describe the property, e.g. a particular header name
match: how to match the property (e.g. equals, contains, starts-with, etc.)
match_extra: free-form text to provide the argument for the 'match' method

We still want dedicated user interfaces for certain features, e.g. mute sender, mute thread/conversation. But we'll also want a user interface that gives access to all properties of a notification rule.
Examples
Separate notification channel for company-internal emails
clause:
  property: sender
  match: matches
  match_extra<EMAIL_ADDRESS>action: notification_channel
action_extra: company

High priority messages
clause:
  property: header
  property_extra: X-Priority
  match_extra: 1
action: notification_channel
action_extra: important

High priority messages from company-internal senders
clause:
  property: sender
  match: matches
  match_extra<EMAIL_ADDRESS>clause:
  property: header
  property_extra: X-Priority
  match_extra: 1
action: notification_channel
action_extra: important

Mute sender
clause:
  property: sender
  match: equals
  match_extra<EMAIL_ADDRESS>action: mute

Mute mailing lists
clause:
  property: header
  property_extra: List-Id
  match: exists
action: mute

Mute particular thread
clause:
  property: header
  property_extra: References
  match: contains
  match_extra<EMAIL_ADDRESS>action: mute

Implementation notes

Notification rules should be per account (per folder?)
Create dedicated database tables for notification rules
Add support for importing/exporting notification rules

I solve thus by using a different email address for critical email. (one could use postfix/gmail/etc rules to split 1 address)
I also use the "Missed notification reminder" app to notify once per minute until a critical email notification is acknowledged.
Recently I started getting random vibrations from LineageOS so i'd like an option to disable the silent "checking mail" notification from K-9.
I arrived at this configuration after finding sms and fcm unreliable.


updated flightgear (2016.1.1)

Changes to a cask
Editing an existing cask

[x] Commit message includes cask’s name (and new version, if applicable).
[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.

Thank you for the contribution. It needed some fixes, so they were made in 293730d7ade13e3d9ba2f93760b36e7b0ee97db4. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.


[FEATURE] Rudimentary authentication in longhorn-ui is beneficial

Is your feature request related to a problem? Please describe.
Longhorn UI should have at least rudimentary access control embedded in the web listener itself.
Access control external to the longhorn-ui container is liable to be bypassed through a number of means.
Describe the solution you'd like
When running in kubernetes, even without a longhorn ingress defined, in the absence of network policies other pods can port scan the possible IP ranges to determine, and then access the longhorn UI on tcp/80.
Regardless of access control being done on the ingress (nginx, traefik, etc), traffic that originates internal to the cluster can bypass these, and thus bypass the access control.
Describe alternatives you've considered
The only real alternative is to scale longhorn-ui down to zero when not in active use.
Additional context
I would propose one or both of these possible options.

Rudimentary HTTP authentication, holding user:pass in configuration element (configmap, secret, or crd).
"Pre shared" security header.  In the presence of, e.g., "X-Longhorn-Auth: foobarbaz" header the longhorn UI would be operable.  This header can be added by any arbitrary ingress method after any it's own authorization has completed.

A further option that may have merit.

Option to run the longhorn-ui in strictly read-only mode.  In the case of scaling to zero when not in use, it could flip to read-only to contain the risks of users bypassing access control.

I am trying to understand why we need to be concern about the internal traffic originated from the cluster. Longhorn UI is exposed as a service by default, which is bound to the RBAC. If the user doesn't have the access to the service and namespace, then they won't able to access the UI or backend API. So it seems RBAC should be sufficient?

Cluster internal traffic is a concern in case a pod gets compromised/you use your cluster for development/CI workloads. In any production system that is open to the internet compromise is a potential threat that needs to be mitigated. While I agree that a network policy is probably the "real" way to go about this, some sort of authentication scheme that would disallow just anything with the ability to send traffic to the service to delete all volumes/exfiltrate data would be nice, especially since not every Kubernetes distro comes with a NetworkPolicy enabled plugin by default.
#1805 is related
On that note how does longhorn-ui actually perform the changes? If the backend service basically also is unauthenticated and open to internal traffic that needs to be secured as well.

Not much more to add beyond what was just said.
Regardless of whether or not you trust your local users, this exposure could allow an otherwise benign web application flaw to pivot into something very destructive indeed.
Also, +1 to the question to confirm whether the backend, too, is vulnerable to internal + unauthenticated traffic.

Also, +1 to the question to confirm whether the backend, too, is vulnerable to internal + unauthenticated traffic.

Looks like it is vulnerable - as it is just proxied by the frontend webserver and provides plain HTTP without authentication.
If you want to ensure that other pods should not fiddle with the API, you should at least restrict ingress network traffic regarding the longhorn-system namespace.

And possibly, and SSRF vulnerability in any pod turns into a cluster takeover.
Having Longhorn completely negates RBAC since anyone with access to run a pod in any namespace can hit http://longhorn-ui.longhorn-system.svc/ and manipulate volumes.

I missed that comment, but yes indeed, the backend is vulnerable too. Any application running in the cluster, under any namespace, can hit http://longhorn-backend.longhorn-system.svc:9500/v1 and delete volumes etc. This is bad.

Hey team! Please add your planning poker estimate with ZenHub @jenting @PhanLe1010 @shuo-wu @joshimoo

I split out the MTLS auth for the internal communication into it's own issue here: https://github.com/longhorn/longhorn/issues/3839
I should have done this back then instead of tracking the MTLS part in this issue.


chore: sync with upstream

chore

:tada: This PR is included in version 1.10.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


API calls should not print results

I think noprint should default to True in the listen method of the contract translator ABI for the following reasons:

Why print the return value inside the method and provide an option to turn it off, when a developer can easily use print(ct.listen(log)) to print the return value to provide the same functionality?
It doesn't make any sense for API methods to print results as well as return them. API methods should provide an interface for programmers to deal with results, with the programmer deciding how that result is returned to the user, not the API.
It's not consistent with other API methods. This is the only method where you must pass noprint=True to it in order to preventing it to from printing the console.
It provides a headache for developers creating console applications.

Ideally the noprint argument should be removed entirely, but this may cause compatibility issues with Python applications already using this method, until a major version change is made.

Could you please rebase on latest develop?

Done.

thanks!


Jyoutir/add blog xthread

Description
Added blog from the x-thread viewable here:
https://x.com/trypearai/status/1843336384322601366
Related Issue
Changes Made

added blog into lib/blog/postData.tsx
corresponding images added to public/images/blog

Screenshots

Checklist

[ nang told me do this idk the issue numba] I have tagged the issue in this PR.
[ yes] I have attached necessary screenshots.
[yes ] I have provided a short description of the PR.
[yes ] I ran yarn build and build is successful
[yes ] My code follows the style guidelines of this project.
[n/a ] I have added necessary documentation (if applicable)

Is it just me or they appear as such? both locally and in the preview deployment 👀

hmm idk why its like that, it showed like that for me only once or twice - but fixed when i refreshed my page. unsure what is causing this


PicklingError on flag.users

We've been using Waffle for some time without issue, but recently upgraded to django 1.8 and waffle 0.10.1, and have started seeing a flood of these errors:
PicklingError: Can't pickle <class 'waffle.models.Flag_users'>: attribute lookup waffle.models.Flag_users failed

+1, I'm seeing this as well. Restarting the server seems to fix it. Here's a stack trace:
Traceback (most recent call last):
  File "/.../local/lib/python2.7/site-packages/django/core/handlers/base.py", line 108, in get_response
    response = middleware_method(request)
  File "./findoffice/middleware.py", line 9, in process_request
    if waffle.flag_is_active(request, 'multiple_markets'):
  File "/.../local/lib/python2.7/site-packages/waffle/__init__.py", line 41, in flag_is_active
    cache_flag(instance=flag)
  File "/.../local/lib/python2.7/site-packages/waffle/models.py", line 119, in cache_flag
    cache.add(keyfmt(settings.FLAG_USERS_CACHE_KEY, f.name), f.users.all())
  File "/.../local/lib/python2.7/site-packages/django/core/cache/backends/locmem.py", line 38, in add
    pickled = pickle.dumps(value, pickle.HIGHEST_PROTOCOL)
PicklingError: Can't pickle <class 'waffle.models.Flag_users'>: attribute lookup waffle.models.Flag_users failed

It also seems that this is occurring only on flags that have users set on them.

We're experiencing the same isssue

As a workaround, I disabled caching for django waffle by setting WAFFLE_CACHE_NAME to a dummy cache backend.
Note: this will cause a lot of extra sql statements to your db. We use django-cacheops to cache at the sql level, so this layer of caching was redundant for us.

We're doing the same workaround @gorillamania. Anyone had further experience with this?

I believe this was related to this bug with SimpleLazyObject which was fixed in 1.8.5 https://code.djangoproject.com/ticket/25389
I have not had this problem crop back up since upgrading to Django>=1.8.5

Seems like this was a Django bug, but it's also going to be fixed by #211, which changes from caching whole user/group querysets to caching lists of IDs.


Clean Merging (including code motion inside files)

This follows on from #1 , adding in the requirement dropped from that ticket:
Given a Git repository of files in multiple directories that has been worked on in two branches, provide a command line utility that merges one branch into another, taking into account code motion inside files.
Any divergent code motion is treated as an error and causes the merge to be aborted - the repository should be left as it was prior to the merge being attempted.
Code motion is only considered inside a file on a file-by-file basis - so when a method is extracted and placed elsewhere in the same file, it should be picked up as code motion in this ticket. Similarly for code rearrangement due to method sorting in something like IntelliJ.
Moving a class into its own file would not be picked up in this ticket, that job is for #26.

Update: breaking out code motion across files into its own ticket: #26 .

It may be the case that divergent code motion can be accomodated, at least in some situations by allowing both moves to take place; this can also pick up edits from the other side of the move in both cases. It is then up to user to decide whether to delete either or both moves, or simply accept both.
This doesn't work with ambiguous matches because multiple edits may associate to several of the matches, but that can be left as unsupported.

More pondering leads to this rule of thumb: if an all-sides match leads to a coincident edit in the merge with the left and right contributions to the match being moved to different locations, then we have two independent edits, each applying to the move on the opposite side.
Going further, if the two moves land in the same place and are picked up by the merge as either a coincident insertion or edit, then we have an edit collision that can be represented as an insertion / insertion conflict or an edit / edit conflict.
If the two moves land in the same place that happens to be a preservation or coincident insertion because of an ambiguous match, we don't care what happens as that's not supported yet, as long as the application doesn't crash.

Regarding edit collisions due to ambiguous matches, a quick-and-dirty approach is to store the rival edits as a set, so duplicated edits don't actually conflict. If a set turns out to have more than edit, they are simply concatenated in no particular order and a diagnostic can be issued. A deletion would form its own entry in the set too.
For now however, just store one edit or deletion for each side and issue a diagnostic if a collision occurs on the same side.

So in the implementation of the merge algebra for MergeResultDetectingMotion, we have to build up a mapping from the moved element or elements to either an edit or a deletion - and we have to supply the moved elements from the match and ignore any left or right element passed in by the calling merge algoithm, becase that favours the left side for preservations, coincident insertions and coincident deletions.
By using the left and right elements from the match, we can distinguish between edits and / or deletions associated with both sides.

Got a failure in CodeMotionAnalysisExtensionTest.codeMotion, analysis follows...

BASE FILE:
package com.sageserpent.kineticmerge.core

import com.eed3si9n.expecty.Expecty

object ExpectyFlavouredAssert:
  val assert: Expecty = new Expecty:
    override val showLocation: Boolean = true
    override val showTypes: Boolean    = true
  end assert
end ExpectyFlavouredAssert

LEFT FILE:
package com.sageserpent.kineticmerge.core

import com.eed3si9n.expecty.Expecty

object ExpectyFlavouredAssert:
  val assert: Expecty = new Expecty:
    // Swapped the next two lines around...
    override val showTypes: Boolean    = true
    override val showLocation: Boolean = true

  end assert
end ExpectyFlavouredAssert

RIGHT FILE:
package com.sageserpent.kineticmerge.core

import com.eed3si9n.expecty.Expecty

object ExpectyFlavouredAssert:
  val assert: Expecty = new Expecty:
    override val showLocation: Boolean = true
    override val showTypes: Boolean    = false // This edit should propagate.
  end assert
end ExpectyFlavouredAssert

DESIRED MERGE BASED ON INTUITION:
package com.sageserpent.kineticmerge.core

import com.eed3si9n.expecty.Expecty

object ExpectyFlavouredAssert:
  val assert: Expecty = new Expecty:
    // Swapped the next two lines around...
    override val showTypes: Boolean    = false // This edit should propagate.
    override val showLocation: Boolean = true

  end assert
end ExpectyFlavouredAssert

Outcome seen as of Git commit SHA: 9c5dd269b1dd719b5878dedc03c823deb9933d16 ...
11:43:26.972 [main] DEBUG c.s.kineticmerge.core.merge$ -- Preservation of SectionImplementation(*** STUNT DOUBLE ***,0,28) as it is common to all three sides.
11:43:26.974 [main] DEBUG c.s.kineticmerge.core.merge$ -- Left edit of SectionImplementation(*** STUNT DOUBLE ***,28,7) into SectionImplementation(*** STUNT DOUBLE ***,28,11).
11:43:26.975 [main] DEBUG c.s.kineticmerge.core.merge$ -- Preservation of SectionImplementation(*** STUNT DOUBLE ***,39,6) as it is common to all three sides.
11:43:26.975 [main] DEBUG c.s.kineticmerge.core.merge$ -- Edit conflict of SectionImplementation(*** STUNT DOUBLE ***,41,5) into SectionImplementation(*** STUNT DOUBLE ***,45,1) on the left and SectionImplementation(*** STUNT DOUBLE ***,41,12) on the right, coalescing with following left insertion of SectionImplementation(*** STUNT DOUBLE ***,46,7).
11:43:26.977 [main] DEBUG c.s.kineticmerge.core.merge$ -- Edit conflict of SectionImplementation(*** STUNT DOUBLE ***,41,5) into SectionImplementation(*** STUNT DOUBLE ***,46,7) on the left and SectionImplementation(*** STUNT DOUBLE ***,41,12) on the right, coalescing with following left insertion of SectionImplementation(*** STUNT DOUBLE ***,53,4).
11:43:26.977 [main] DEBUG c.s.kineticmerge.core.merge$ -- Edit conflict of SectionImplementation(*** STUNT DOUBLE ***,41,5) into SectionImplementation(*** STUNT DOUBLE ***,53,4) on the left and SectionImplementation(*** STUNT DOUBLE ***,41,12) on the right.
11:43:26.982 [main] DEBUG c.s.kineticmerge.core.merge$ -- Merge yielded:
MergeResultDetectingMotion(
  coreMergeResult = MergedWithConflicts(
    leftElements = Vector(
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 0, size = 28),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 28, size = 11),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 39, size = 6),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 45, size = 1),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 46, size = 7),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 53, size = 4)
    ),
    rightElements = Vector(
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 0, size = 28),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 28, size = 11),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 39, size = 6),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 41, size = 12)
    )
  ),
  changesPropagatedThroughMotion = Map()
)

override val showTypes: Boolean    =  was matched and was considered to be preserved in the same spot, contrary to the intuitive view that it would move on the left side towards the start of the file. It appeared as (..., 35, 6) on the base and right and (..., 39, 6) on the left.
override val showLocation: Boolean = true was considered to be moved, being dealt with as a left-edit at its source and with the moved section appearing in a conflict at the end. It appeared as (..., 28, 7) on the base and right and (..., 46, 7) on the left.
The initialiser true for override val showTypes: Boolean    =  true on the base and right was expected to match as a base + right match, being edited into false. This didn't happen (and as a single token, wouldn't be picked up anyway as a match), but puzzlingly, the merge algorithm didn't get the chance to make a last-minute fallback match either...
... what did happen as that on the base, the entire:true<newline>end assert<newline>end ExpectyFlavouredAssert became a section in its own right (..., 41, 5) ...
... on the left, true<newline> and then end assert<newline>end ExpectyFlavouredAssert (note additional newline) became two sections (..., 45, 1) and (..., 53, 4) with the moved section (..., 46, 7) sitting between them ...
... and on the right, false // This edit should propagate.<newline>end assert<newline>end ExpectyFlavouredAssert came in as a final section (..., 41, 12).

So we got a conflict at the end.

The minimum sure-fire match size was 5, and as there was just the one file, no smaller matches would have been considered. So the obvious match of end assert<newline>end ExpectyFlavouredAssert across all sides didn't happen as that would be four tokens long with whitespace condensed into the preceding token.
The final section on each side was generated as a filler, hence the lack of consistency between them.

What happens with a minimum match size of 4? (Git commit SHA: 5a9a82be8b8efb3cbebd369a28f0a77deafd25c0)
Now we see an all-sides match for end assert<newline>end ExpectyFlavouredAssert, good.
13:26:03.567 [main] DEBUG c.s.k.core.MappedContentSources -- Filling gap on side: base at path: *** STUNT DOUBLE *** prior to following section with: SectionImplementation(*** STUNT DOUBLE ***,41,1).
13:26:03.567 [main] DEBUG c.s.k.core.MappedContentSources -- Filling gap on side: left at path: *** STUNT DOUBLE *** prior to following section with: SectionImplementation(*** STUNT DOUBLE ***,28,11).
13:26:03.568 [main] DEBUG c.s.k.core.MappedContentSources -- Filling gap on side: left at path: *** STUNT DOUBLE *** prior to following section with: SectionImplementation(*** STUNT DOUBLE ***,45,1).
13:26:03.568 [main] DEBUG c.s.k.core.MappedContentSources -- Filling gap on side: right at path: *** STUNT DOUBLE *** prior to following section with: SectionImplementation(*** STUNT DOUBLE ***,41,8).
13:26:03.618 [main] DEBUG c.s.kineticmerge.core.merge$ -- Preservation of SectionImplementation(*** STUNT DOUBLE ***,0,28) as it is common to all three sides.
13:26:03.620 [main] DEBUG c.s.kineticmerge.core.merge$ -- Left edit of SectionImplementation(*** STUNT DOUBLE ***,28,7) into SectionImplementation(*** STUNT DOUBLE ***,28,11).
13:26:03.620 [main] DEBUG c.s.kineticmerge.core.merge$ -- Preservation of SectionImplementation(*** STUNT DOUBLE ***,39,6) as it is common to all three sides.
13:26:03.621 [main] DEBUG c.s.kineticmerge.core.merge$ -- Right edit of SectionImplementation(*** STUNT DOUBLE ***,41,1) into SectionImplementation(*** STUNT DOUBLE ***,41,8).
13:26:03.621 [main] DEBUG c.s.kineticmerge.core.merge$ -- Left insertion of SectionImplementation(*** STUNT DOUBLE ***,46,7).
13:26:03.622 [main] DEBUG c.s.kineticmerge.core.merge$ -- Preservation of SectionImplementation(*** STUNT DOUBLE ***,53,4) as it is common to all three sides.
13:26:03.625 [main] DEBUG c.s.kineticmerge.core.merge$ -- Merge yielded:
MergeResultDetectingMotion(
  coreMergeResult = FullyMerged(
    elements = Vector(
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 0, size = 28),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 28, size = 11),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 39, size = 6),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 41, size = 8),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 46, size = 7),
      SectionImplementation(path = "*** STUNT DOUBLE ***", startOffset = 53, size = 4)
    )
  ),
  changesPropagatedThroughMotion = Map()
)

That is fully merged, seems promising ... but the test still fails!

Ah - the test expectations were too rigid - was using default equality to compare tokens, which takes whitespace into account. The tests were cutover to use the whitespace-insensitive Token.equality and after backpatching the test to check whether the changes in expectations had any effect on legacy testing, this was merged in via Git commit SHA: a694056de420681c4de0f20e65e183e77c43482a.
Test now passes.

This is good, but I'm uneasy about how much has been proven.

The test analysed above didn't actually propagate any edits via moves - the edited code stayed put and the non-edited code leapfrogged over it. That is perfectly valid in its own right, but we need to prove propagation of edits (and deletions) works.
Related to this is the ambiguity on the longest common subsequence algorithm about which LCS to choose when there is more than one possibility. This happens here because two lines of code are reordered - so one gets to be part of the LCS and the other is considered to move.
We can jemmy the test cases so as to stumble across one that has to move an edit (or deletion), but here's a thought: it seems intuitively obvious that when reordering a long section of text with a smaller section of text, it is the smaller one that should be considered as moving - at least if both the moved and the LCS section both belong to distinct all-sides matches across each side. If one section is only matched in a pairwise match and the other in an all-sides match, it seems reasonable to treat the all-sides match is being part of the LCS (and that it was the longest common subsequence algorithm will do in a tiebreak).

Another wrinkle is that the nice intuitive picture of a single section moving on one side of the merge and being edited on the other generally won't be the case unless the minimum match size is quite large.
What will happen instead is that there will be three sections on each side - a leading and trailing one that are both matched on all sides, moving in tandem, and a middle one that has a pairwise match between the base and the side with the move - and an unmatched section that is the precisely the edit change. I expect this to work with the current implementation as of a694056de420681c4de0f20e65e183e77c43482a, but this needs testing...

As of Git commit SHA: d3e02cbe84038cda1245293b526447d8f96eb47c, CodeMotionAnalysisExtensionTest.codeMotion has been bolstered to show the propagation of an edit through a section move, and it passes.
Code motion has arrived!

Added support for favouring moves of small sections over moves of large sections by modifying LongestCommonSubsequence. This is delivered as of 55d0e5df1e2b91407eee4ee8631b1121356e7f0b.

As of Git commit SHA: 9a2fddb45e1231b24a167707c55bf7378a4edc31 the longest common subsequence algorithm favours  subsequences with longer section when choosing between longest common subsequences of the same length.
This is reflected in the downstream merge, where it is the smaller sections that get picked up as code motion when they interchange with larger sections.
The test failure noted above in CodeMotionAnalysisExtensionTest.codeMotion is due to the lack of support for edit anchoring. What happened was that a large construct was moved on one side and a small suffix of it edited on the other - the unchanged prefix moved cleanly through the merge, being picked up as an all-sides match, but the small suffix was not picked up as a pairwise match on the base and on the other side from the edit.
This lead to the suffix moving on the other side from the edit as is, and an ordinary delete versus edit conflict at the source of the move. Had the suffix been large enough to match, then this would have resulted in a move of the suffix in tandem with the prefix; the edit being propagated through the move.
Edit anchoring is a possible way of dealing with this - unmatched sections are considered to be anchored to adjacent matched sections, so as long as the matched sections move in tandem, they could pick up the unmatched section as a move, thus allowing edit propagation.
A new ticket will be made for edit anchoring; for now, we have something worth getting out there...

This went out in release 1.1.0, Git commit SHA: 26a9c9a64451864b3373536b8f8d934ca869a71c.

Evidence (screencast of a demonstration of Kinetic Merge):
https://github.com/sageserpent-open/kineticMerge/assets/1765601/2d676e20-dce0-441a-b4a2-fcbaa8aff35d
https://github.com/sageserpent-open/kineticMerge/assets/1765601/783172ef-7688-45ab-83ab-2e0aa633ce01
https://github.com/sageserpent-open/kineticMerge/assets/1765601/370ddbce-98c7-42d2-8c81-f5c2756d051d


(3.0.53) browse class menu item would be useful in debugger ...

if there are two possible classes in the frame, it would be useful to be given a choice as well ..

We have these features:

double click on class name in debugger to highlight, and Browse Class is on popup menu
select receiver in variables pane and you have Browse Object Class on popup menu.

I think this means you can browse the class for anything related to the current frame...


Add logo img

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Enable usage of external CloudFront resource

This is a pretty big internal refactoring, which enables to use the module with a CloudFront resource that is defined outside of the module itself.
This enables further customization options than creating a variable / attribute for every customization CloudFront has to offer.
Breaking changes

Removes the following attributes:

cloudfront_custom_behaviors
cloudfront_geo_restriction
cloudfront_origins
cloudfront_viewer_certificate_arn
cloudfront_minimum_protocol_version
create_domain_name_records
domain_names
domain_zone_names

Custom domain example is fully reworked

ToDo

[x] Create new example with-existing-cloudfront
[ ] Rewrite custom domain example
[x] Rename cloudfront_custom_behaviors -> cloudfront_ordered_cache_behaviors

Fixes #55.

Currently blocked by an error when using an external CloudFront:
│ Error: error creating Lambda Event Source Mapping (arn:aws:sqs:eu-central-1:111111:terraform-next-js-existing-cloudfront21111111): InvalidParameterValueException: The provided execution role does not have permissions to call ReceiveMessage on SQS
│ {
│   RespMetadata: {
│     StatusCode: 400,
│     RequestID: "b55a27a7-9663-4594-81fc-a67290f91314"
│   },
│   Message_: "The provided execution role does not have permissions to call ReceiveMessage on SQS",
│   Type: "User"
│ }
│
│   with module.tf_next.module.statics_deploy.aws_lambda_event_source_mapping.this,
│   on ../../modules/statics-deploy/main.tf line 316, in resource "aws_lambda_event_source_mapping" "this":
│  316: resource "aws_lambda_event_source_mapping" "this" {


[feature request] adjustable shortcuts

Hi, I am using NNW for years now – for a long time on older machines – and got used to the shortcuts of older versions. I have to admit the new ones are reasonable too, but is there a possibility to add an extension to the preferences to edit the shortcuts used in the app?
Cheers tt.

Duplicate of #508


feat: Managed cached endpoint

Closes #1596
@ptbrowne I am not 100% happy about the fact that we have implicit connection between GQL schema and GQL context. As we already were relaying on such method, I re-used the approach, do you think it's fine or maybe see another way we could make this more clear, instead of comments? 😅
How to test

Wait until the PROD endpoint is fixed by Zazuko ⏳

cc @Rdataflow, waiting for the PROD endpoint to be fixed so we can properly test the change and implement any potential additional requirements (e.g. encoding the cube iri) 👀

Maybe you could extract all possible variable types with some typescript-fu:
type ExtractResolversObject<O> = O extends ResolversObject<infer S> ? S :never
type B = ExtractResolversObject<QueryResolvers>
type ExtractResolver<O> =  O extends Resolver<any, any, any, infer S> ? S : never
type Vars = ExtractResolver<B[keyof B]>

then you can as the variableInfos from the graphql context to Vars ?

Thanks for the idea @ptbrowne, I will check it out tomorrow 💯

Ah this time, the end to end tests seem to have found something, I do not recognize the usual culprits in the failed E2E tests.

Yes, I think it might be related to the fact that with this PR, the PROD endpoint is broken, so any test relying on it won't work. I'll re-check once it's fixed by Zazuko 👀

@bprusinowski can you add statistics on visit frequency to address case b)? (i.e. visits per chart key)

@Rdataflow yes, that's the plan to try to add a new table to our database that would store information on views per chart config 👍

@Rdataflow yes, that's the plan to try to add a new table to our database that would store information on views per chart config 👍

@bprusinowski curious: is there already some PR around ?

@Rdataflow yes, this was already implemented in https://github.com/visualize-admin/visualization-tool/pull/1613 😄

@bprusinowski the new varnish config is now on PROD 👍 and unblocks this PR 🚀

@Rdataflow the changes should soon be on TEST :)

@bprusinowski by inspecting the traffic I spotted 3 types of queries which shall also be passed to ${endpoint}/${cubeIri} (currently they are sent to default endpoint)
rationale is to harden the cached charts for the case of db outage and max out long term cache :smile:

query 1: cube upgrade queries (as Ludovic will take into account to purge all versions :+1: )

PREFIX cube: <https://cube.link/>
PREFIX schema: <http://schema.org/>

SELECT ?iri WHERE {
  {
    # Versioned cube.
    SELECT ?iri ?version WHERE {
      VALUES ?oldIri { <https://environment.ld.admin.ch/foen/ubd000503bis/2> }
      ?versionHistory schema:hasPart ?oldIri .
      ?versionHistory schema:hasPart ?iri .
      ?iri schema:version ?version .
      ?iri schema:creativeWorkStatus ?status .
      ?oldIri schema:creativeWorkStatus ?oldStatus .
      FILTER(NOT EXISTS { ?iri schema:expires ?expires . } && ?status IN (?oldStatus, <https://ld.admin.ch/vocabulary/CreativeWorkStatus/Published>))
    }
    ORDER BY DESC(?version)
  } UNION {
    {
      # Version history of a cube.
      SELECT ?iri ?status ?version WHERE {
        VALUES ?versionHistory { <https://environment.ld.admin.ch/foen/ubd000503bis/2> }
        ?versionHistory schema:hasPart ?iri .
        ?iri schema:version ?version .
        ?iri schema:creativeWorkStatus ?status .
        FILTER(NOT EXISTS { ?iri schema:expires ?expires . })
      }
      ORDER BY DESC(?status) DESC(?version)
    }
  } UNION {
    {
      # Non-versioned cube.
      SELECT ?iri ?status WHERE {
        VALUES ?iri { <https://environment.ld.admin.ch/foen/ubd000503bis/2> }
        ?iri cube:observationConstraint ?shape .
        ?iri schema:creativeWorkStatus ?status .
        FILTER(NOT EXISTS { ?iri schema:expires ?expires . } && NOT EXISTS { ?versionHistory schema:hasPart ?iri . })
      }
      ORDER BY DESC(?status)
    }
  }
}
LIMIT 1

query 2: some dimension version query pattern

PREFIX cube: <https://cube.link/>
PREFIX schema: <http://schema.org/>
PREFIX sh: <http://www.w3.org/ns/shacl#>

SELECT ?dimensionIri ?version ?nodeKind WHERE {
  <https://environment.ld.admin.ch/foen/ubd000503bis/2> cube:observationConstraint/sh:property ?dimension .
  ?dimension sh:path ?dimensionIri .
  OPTIONAL { ?dimension schema:version ?version . }
  OPTIONAL { ?dimension sh:nodeKind ?nodeKind . }
  FILTER(?dimensionIri IN (<https://environment.ld.admin.ch/foen/ubd000503bis/treibstoffe>))
}

query 3: possible filters query

PREFIX cube: <https://cube.link/>
PREFIX schema: <http://schema.org/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?dimension0_v WHERE {
  <https://environment.ld.admin.ch/foen/ubd000503bis/2> cube:observationSet/cube:observation ?observation .
  ?observation <https://environment.ld.admin.ch/foen/ubd000503bis/treibstoffe> ?dimension0 .
  ?dimension0 schema:sameAs ?dimension0_v .
  VALUES ?dimension0_v { <https://environment.ld.admin.ch/foen/ubd000503bis/Treibstoffe/treib1> }
}

LIMIT 1

😱 thanks for spotting this @Rdataflow, I will investigate why this is the case 👍


Missing type operations?

I recently wrote a migration where I had to times a value by 100 and couldn't figure out how to do that (I eventually wrote a custom express). So unless I missed it I think these are missing: https://www.sqlite.org/datatype3.html#operators
I could give this a go if you'd like (though will have to wait for my RSI to go away).

It's true that some binary expressions aren't exposed as operators yet, but +, -, * and / are defined as operators on Expression<num>, do you mean those?
PRs for additional operators are definitely welcome!

Hmm. It wasn't showing up and it was failing when trying to do * on a column but I also did t look very hard.

Hm, so it's definitely there and there are tests for it:
https://github.com/simolus3/drift/blob/10eb6b9a9c05a081965aada27f21d91ad40a7cef/drift/test/database/expressions/algebra_test.dart#L15-L20
I wonder if this the analyzer acting up or if you called it on a Expression with the wrong type? I'll close this issue since it looks like it's working correctly. But please let me know if you can't get it working, perhaps there's something wrong elsewhere.

Hm, so it's definitely there and there are tests for it:
https://github.com/simolus3/drift/blob/10eb6b9a9c05a081965aada27f21d91ad40a7cef/drift/test/database/expressions/algebra_test.dart#L15-L20
I wonder if this the analyzer acting up or if you called it on a Expression with the wrong type? Since it's an extension, did you add the drift import if you're using it outside of the main database files? I'll close this issue since it looks like it's working correctly. But please let me know if you can't get it working, perhaps there's something wrong elsewhere.

Huh its working now... Maybe its because i was switching between a local copy of drift


Register JParsec at Coveralls

Hi @abailly and @fluentfuture,
I would like to have continuous feedback on code coverage when I'm contributing to jparsec. I've seen Coveralls is offering this service with a smooth integration with Travis.
So, if you think it might be a good idea to have code coverage, can you please register jparsec at Coveralls ? I would have done it myself but I'm no longer in the collaborators list after the repo has been moved to the jparsec organization.
I'll then take care of the rest in a PR.
Thanks.

Hi Greg,
Invited you to be part 'core' team, please confirm in issue you've got
rights to do what you request. DEfinitely a good idea.
--
Arnaud Bailly
twitter: abailly
skype: arnaud-bailly
linkedin: http://fr.linkedin.com/in/arnaudbailly/
On Mon, Mar 23, 2015 at 5:09 PM, Gregory SSI-YAN-KAI <
<EMAIL_ADDRESS>wrote:

Hi @abailly https://github.com/abailly and @fluentfuture
https://github.com/fluentfuture,
I would like to have continuous feedback on code coverage when I'm
contributing to jparsec. I've seen Coveralls is offering this service with
a smooth integration with Travis.
So, if you think it might be a good idea to have code coverage, can you
please register jparsec at Coveralls https://coveralls.io/ ? I would
have done myself but I'm no longer in the collaborators list after the repo
has been moved to the jparsec organization.
I'll then take care of the rest in a PR.
Thanks.
—
Reply to this email directly or view it on GitHub
https://github.com/jparsec/jparsec/issues/38.

Hi Arnaud,
Thank you for the invitation.
Unfortunately, I don't have the rights to register jparsec at Coveralls. I guess only the 'owners' team has the right to do so.

Apologies for handling this issue only now. For some unknown reason I cannot see jparsec's repositories on https://coveralls.io/repos so I cannot add them. Any idea why it could be so? I can see all other projects I own or from organisations I am part of but not those ones :-(

Hi Arnaud,
Thanks for the feedback. I just managed to register jparsec's repo! The problem was due to the fact that I did not make my membership to jparsec organization public, so coveralls was not able to see the repo.
I'll be working on the remaining tasks soon.

Cool! So I must have encountered same issue...
Thanks for your work!
Regards
Arnaud
Le jeudi 30 avril 2015, Gregory SSI-YAN-KAI<EMAIL_ADDRESS>a
écrit :

Hi Arnaud,
Thanks for the feedback. I just managed to register jparsec's repo! The
problem was due to the fact that I did not make my membership to jparsec
organization public, so coveralls was not able to see the repo.
I'll be working on the remaining tasks soon.
—
Reply to this email directly or view it on GitHub
https://github.com/jparsec/jparsec/issues/38#issuecomment-97839466.

--
Arnaud Bailly
twitter: abailly
skype: arnaud-bailly
linkedin: http://fr.linkedin.com/in/arnaudbailly/

Hi Arnaud,
Can you add the 'jparsec' repo to the 'core' team ? I don't seem to be allowed to push changes...

Looks like on needs to pay something for using coveralls, was not able to figure out how it works.


Install onto pi running klipper

Hey
is it possible to install spoolman onto a Pi 4 running Klipper?
and could I use this method: https://github.com/Donkie/Spoolman/issues/12
if not, what would you recommend?

You can install docker on your Pi. Just follow the instructions in the README


New Application: Jpeg Decoder

Added a new category of image processing under Applications. In the repository link provided, I've implemented image decoder for Jpeg Huffman encoded images in Mojo and have also compared it's performance with C and python as well.

Hi @reviewers Did you got a chance to look at the PR ;)


V 1.9.9 is crashing

TypeError: Cannot read properties of undefined (reading 'displayName')
at HomebridgeMagichomeDynamicPlatform.configureAccessory (/usr/local/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:93:100)
at /usr/local/lib/node_modules/homebridge/src/bridgeService.ts:328:25
at Array.filter ()
at BridgeService.restoreCachedPlatformAccessories (/usr/local/lib/node_modules/homebridge/src/bridgeService.ts:288:69)
at Server.start (/usr/local/lib/node_modules/homebridge/src/server.ts:188:24)
[9/1/2023, 12:48:09 PM] Got SIGTERM, shutting down Homebridge...
[9/1/2023, 12:48:09 PM] AssertionError [ERR_ASSERTION]: Cannot generate setupURI on an accessory that isn't published yet!
at Bridge.Accessory.setupURI (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:994:11)
at Server.setServerStatus (/usr/local/lib/node_modules/homebridge/src/server.ts:155:45)
at Server.teardown (/usr/local/lib/node_modules/homebridge/src/server.ts:199:10)
at signalHandler (/usr/local/lib/node_modules/homebridge/src/cli.ts:93:12)
at process.emit (node:events:514:28)
at process.emit (/usr/local/lib/node_modules/homebridge/node_modules/source-map-support/source-map-support.js:516:21)
[e.g. While using the HomeKit app on iPhone, after setting a MagicHome light tile's brightness to 0%, the tile will not respond again to brightness or color changes until after clicking the tile on again. Other HomeKit tiles, including other MagicHome lights, will continue to respond and are otherwise unaffected.]
To Reproduce
e.g.
Steps to reproduce the behavior:

In the HomeKit app, long press a MagicHome light's tile to display the brightness slider
Slide the brightness down to 0%
Attempt to increase brightness and change color
Observe that the light is unresponsive
Tap the MagicHome light's tile on>off>on
Observe that the light is now responsive again

Expected behavior
A clear and concise description of what you expected to happen.
e.g. After sliding a MagicHome tile's brightness down to 0%, sliding it back up will again increase the brightness without the need for tapping the tile off and on again.
Additional context
Add any other context about the problem here.
Host Hardware

Hardware: [e.g. Raspberry Pi 3b+]
OS: [e.g. HOOBS Install Image]
OS Version: [e.g. buster]

Homebridge and MagicHome

Homebridge / HOOBS version [e.g. 1.1.6]
Homebridge MagicHome Dynamic Platform version [e.g. 1.9.2]
Link to the MagicHome Device on the seller's website.

Screenshots
If applicable, add screenshots to help explain your problem.

I'm receiving the same error on bootup which crashes homebridge entirely and wont allow me to start it. I'm running this from a docker container on an unraid server.
[9/1/2023, 1:41:56 PM] TypeError: Cannot read properties of undefined (reading 'displayName')
at HomebridgeMagichomeDynamicPlatform.configureAccessory (/usr/lib/node_modules/homebridge-magichome-dynamic-platform/src/platform.ts:93:100)
at /usr/lib/node_modules/homebridge/src/bridgeService.ts:328:25
at Array.filter ()
at BridgeService.restoreCachedPlatformAccessories (/usr/lib/node_modules/homebridge/src/bridgeService.ts:288:69)
at Server.start (/usr/lib/node_modules/homebridge/src/server.ts:188:24)
[9/1/2023, 1:41:57 PM] [Homebridge UI] Homebridge Config UI X v4.50.5 is listening on :: port 8124
[9/1/2023, 1:41:57 PM] AssertionError [ERR_ASSERTION]: Cannot generate setupURI on an accessory that isn't published yet!
at Bridge.Accessory.setupURI (/usr/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Accessory.ts:994:11)
at Server.setServerStatus (/usr/lib/node_modules/homebridge/src/server.ts:155:45)
at Server.teardown (/usr/lib/node_modules/homebridge/src/server.ts:199:10)
at signalHandler (/usr/lib/node_modules/homebridge/src/cli.ts:93:12)
at process.emit (node:events:514:28)
at process.emit (/usr/lib/node_modules/homebridge/node_modules/source-map-support/source-map-support.js:516:21)

went to the Alpha, 2.0.0 but it doesn't work that great, not like previous versions, please assist...

Hello @richierockskool  , @xstefanx
The alpha version was mistakenly uploaded as latest, automatically updating your accessories to the latest version. While the alpha is backward compatible with old accessories, it makes accessories non forward compatible.
I have resolved this partially by reverting to version 1.9.9 as latest but you will need to either:

use a backup of your accessories and restore from there
purge your magichome accessories and let 1.9.9 rediscover them.

I apologize for this mistake and it was certainly not my intention. As you said, the alpha version is still missing quite a few features and has many bugs.
Apologies,
Zack

Thank you Zack a simple uninstall and re-install of 1.9.9 works great, add the accessories and good to go.

I removed my docker, replaced the appdata folder with a backup I had, and reinstalled the docker. All seems well now. Thanks for the quick response. We've grown very accustom to being able to rely on this plugin. Thanks for creating it!

@richierockskool
Great to hear it's back up and running. I hope you didn't have to spend too much time renaming and redoing other customizations in HomeKit.
@xstefanx
Happy to hear you had a backup and that it's resolved. I'm glad that you are finding it reliable and useful.
Please note that the goal is to eventually migrate to release version 2.0.0. However, I will not do this until all previous features have been implemented and the alphas have been thoroughly tested by several users. Realistically, not any time soon. The logs you have provided have been helpful!
Thank you both for your patience in this matter. I will mark this issue as closed but feel free to re-open it if you encounter a similar problem or open a new one if you discover another issue. Please enjoy.


iscsi: Change default provisioner name in storageclass to iscsi-provisioner

This patch changes default provisioner-name to iscsi, as all of PVC
and storageClass examples in this project defined the provisioner as
iscsi.

For example, iscsi-provisioner-pvc.yaml
has volume.beta.kubernetes.io/storage-class: "iscsi".
Therefore, the check in shouldProvision()
https://github.com/kubernetes-incubator/external-storage/blob/8732beaa43a3b00d39e2c9ced21f2d662e6a0969/lib/controller/controller.go#L573-L578
regards inconsistent class.

the provisioner name and the storage class name are two different things. not sure about the value of this change, but if you do it all the examples will break. the link between the storage class and the storage provisioner is in the storage class, so at least the example storage classes should be updated.

I'm sorry. I made a wrong comment. As pvc's provisioner need to be consistent with storageclass's name, but the patch should have just changed provisioner name in storageclass. I updated the PR.

There is still an inconsistency here, now the storage classes look for an iscsi-provisioner but in the examples the iscsi-provisioner pod is stated with:
            - name: PROVISIONER_NAME
              value: iscsi

Thank you. Updated.

lgtm.

ping @wongma7 I'm sorry for bothering you, but I feel that you missed this.

@nak3 and @wongma7 yesterday I suggest to use the following name for the provisioner name: iscsi-targetd.
So all storage class examples and the default in the code (in start.go) should be set to iscsi-targetd
The documentation should also be updated.
The reason is that as discussed before, there could be other iscsi implementations in the future. This works only for targetd.

@raffaelespazzoli Sure, sounds good idea. Updated this PR.

@nak3
Please update title of this PR and commit from iscsi-provisioner to iscsi-targetd too.

Sure, thanks. I have done. (If squash of commit is also necessary, please let me know.)

yeah, once @raffaelespazzoli or @wongma7 give lgtm, usually it's time to squash commits to one.

Hi, I have been giving more thoughts to this issue (I am restructuring the ansible playbooks and trying to come up with sensible defaults).
Multiple provisioners can be deployed in a cluster and a provisioner can connect to one targetd server, but can create volumes on multiple volume groups. Which volume groups is used is determined by the stroageclass.
So a good naming convention for the storage class would be to associate a provisioner and a volume group, so to avoid clashes in a crwded cluster (unlikely, but possible). Therefore the patter could be: <provisioner-name>-<volume-group>
Here are my defaults for the ansible script:
volume-group name: vg-targetd
provisioner name: iscsi-targetd
storageClass name: iscsi-targetd-vg-targetd

Let me know what you think.

I agree that provisioner-name + volume-group = storage class would be a good naming convention. It could be unique for multiple volume group name.
But, I am concerned about it when we use thin provisioning. It would be something like:
storageClass name: iscsi-targetd-vg-targetd/somepool

It is a little bit long and storage, I feel. But anyway I'll follow your decision.

@raffaelespazzoli based on your previous comment, I updated this PR with:

provisioner name metadata.name in StrageClass of README to iscsi-targetd
default command option's value of provisioner-name to iscsi-targetd

hi,
the changes proposed in this PR have been introduced by another PR:
https://github.com/kubernetes-incubator/external-storage/pull/430
Please verify.

Yes, I checked https://github.com/kubernetes-incubator/external-storage/pull/430. But still a few points (REAMDE and command default value) should be updated, I think.

/lgtm
/area iscsi/targetd


Don't start combat if the combat tracker is not hidden.

Your plan was to make a new setting to do this, but I opted for a lighter touch for now.

Alright. This should work too.


Added tests for upcoming refactor

I think this should work now.
This PR adds tests for #613.
This is still WIP, but there are some tests for indent and outdent at the moment.

Great, thanks. I'm just going to pull this into that branch now, and we'll merge it all together.


reason for returning S_d \sqrt(\Sigma_d) as the network embedding

Thanks for sharing the code. I'm curious about why after obtaining the approximated deepwalk matrix (after max(x, 1) and taking log), in the last step of NetMF,  it is $$U_d \sqrt(\Sigma_d)$$ from SVD that is returned as the final embedding? The paper doesn't seem to justify the benefit of this instead of some other embedding.

Yes, there are other choices.
We mainly follow Levy and Goldberg (https://papers.nips.cc/paper/2014/file/feab05aa91085b7a8012516bc3533958-Paper.pdf) to use $U_d \sqrt(\Sigma_d)$. See their Eq.13.


Adding Attribute

LICENSE-APACHE2  and LICENSE-GPL3

Added to to do list https://github.com/selendra/kaabop/projects/1#card-53557205

Added to to do list https://github.com/selendra/kaabop/projects/1#card-53557205


V2 - Company Not Found - The Page you are looking for was not found message is displayed after user logins to SSO

Prerequisite

Create a CLA group with CCLA enabled
Add github repository for the CLA group
Generate template

Steps to Follow

Login to Github as corporate contributor
Navigate to the repository used in prerequisite
Create PR
CLA check fails
Click on CLA NOT SIGNED
Contributor is redirected to Contributor Console
Click on Proceed as a Corporate Contributor
Click on building icon
Click on Organization not listed? + Click Here
Enter company name and website that does not exist
Click Next
Click Proceed
Click Yes
Click Proceed
Login to SSO
After login, user is redirected to contributor console. However The Page you are looking for was not found message is displayed

@nirupamav I have tested flow as per the steps you mentioned but it's worked as per expectation (PFA). can you provide more details may be use-case will be different

I faced this issue again today. Looks like an intermittent issue

@amolsontakke3576 is this related to an Auth0 redirect issue?  Can we move to QA if you are not able to reproduce?  Not the URL that @nirupamav has posted in the screenshot.

I had made some changes in the flag which is used to show proper message after outh0 redirection.
It looks like working fine for now.

I tried couple of times today and was not able to reproduce the issue. Looks like it is intermittent issue. Will reopen the ticket if I face the issue again


Getting sameSite cookie warning from auth0.is.authenticated

Description
Firefox console reports that
"Cookie “auth0.is.authenticated” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute.
Checking<EMAIL_ADDRESS>shows that the cookie is being created with secure: true, sameSite: 'none', as well as the actual cookie: set-cookie: auth0=... Path=/; Expires=Mon, 10 Aug 2020 23:33:29 GMT; HttpOnly; Secure; SameSite=None.
This is an issue when using Brave with default settings, or if a user has crossSite cookies disabled because it doesn't save the user login session.
Reproduction

Followed the most recent React SDK blog post creating an SPA.

Environment

Version of this library used: "^1.0.0"
Other relevant versions: Arch Linux using Firefox/Brave Browsers

Hi @chefinDan - this is expected at the moment, we're currently looking at options in auth0-spa-js for how to resolve this warning before it turns into an error.

@adamjmcgrath, it seems that Chrome has started to roll out this kind of cookie rejection to 100% of users since Aug. 11 (source: https://www.chromium.org/updates/same-site?pli=1#20200811). Due to this change, I believe Chrome is preventing getAccessTokenSilently() from being used with dynamically changing scopes. I plan on opening a separate issue for this once I can confirm it's an SDK bug.

Hi @rpaulucci3 thanks for your input

it seems that Chrome has started to roll out this kind of cookie rejection to 100% of users since Aug. 11

Chrome is rolling out 2 things:
SameSite=None-requires-Secure
Any cookie that requests SameSite=None but is not marked Secure will be rejected.
SameSite-by-default
Treat cookies as SameSite=Lax by default if no SameSite attribute is specified.
So, with the "SameSite=None-requires-Secure" changes, Chrome will reject cookies if they explicitly are set to SameSite=None but not marked as secure. We use<EMAIL_ADDRESS>which does not set SameSite=None for its cookies (https://github.com/auth0/auth0-spa-js/blob/v1.9.0/src/storage.ts#L21-L23) so will not be effected by this change.
Since we're not setting a value for SameSite we will be effected by "SameSite-by-default" - the default value of the cookie's SameSite will go from None to Lax. This will effect cookies that are required in a cross-origin context (such as HTTP Form Post, embedding an iframe) - for SPAs this essentially means you're effected if you're setting a cookie on a domain that doesn't match the one in the address bar. Therefore if your SPA is served in an iframe those cookies will be blocked as a result of this change. We strongly recommend you don't serve your app and login flow in an iframe, so we don't expect this to cause problems.

Due to this change, I believe Chrome is preventing getAccessTokenSilently() from being used with dynamically changing scopes.

getAccessTokenSilently() does rely on third-party cookies, those of your tenant's on auth0.com. Be assured that the cookies on auth0.com have been updated to accommodate this change, so will not be effected, more details here https://auth0.com/docs/sessions-and-cookies/samesite-cookie-attribute-changes#browser-cookie-changes

dynamically changing scopes

If you're calling getAccessTokenSilently() with different scopes and it's not working. Especially if you're on localhost, It may be rejected because of user consent issues. If that's the case have a look at https://auth0.com/docs/authorization/user-consent-and-third-party-applications#skip-consent-for-first-party-applications and our example that shows how to handle consent_required errors https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#4-create-a-useapi-hook-for-accessing-protected-apis-with-an-access-token

@adamjmcgrath getAccessTokenSilently() does rely on third-party cookies, those of your tenant's on auth0.com. Is there any plan to move away from this? It prevents this functionality from working in contexts where 3rd party cookies are blocked, such as Incognito Mode, or whole browsers such as Safari and Brave.

@charliemic Yes - we implemented the option to use rotating Refresh Tokens for exactly this reason, but it's not the default.
This is implemented in the underlying SDK - Auth0 SPA SDK, which accepts the useRefreshTokens option, and you are able to configure that using auth0-react in the provider:
ReactDOM.render(
  <Auth0Provider
    domain="YOUR_AUTH0_DOMAIN"
    clientId="YOUR_AUTH0_CLIENT_ID"
    redirectUri={window.location.origin}
    useRefreshTokens={true}
  >
    <App />
  </Auth0Provider>,
  document.getElementById('app')
);

You also need to configure Refresh Token Rotation in your Auth0 Client app for this to work.

Ah, it was the token rotation we're missing - thanks for the help! 👍

@stevehobbsdev I have set useRefreshTokens to true and enabled Refresh Token Rotation in my client app settings but isAuthenticated is still false after page reload when using incognito mode or Safari for instance.
Any idea on what could be missing here? Thanks in advance!

How interesting - I'm still getting this issue despite setting cacheLocation and useRefreshTokens. Any idea what else I could try?


[Sticky] Magellan links is not scrolling to anchored section in 6.5.0-rc.1

Expected Behavior
Magellan link should scroll to that section on click
Current Behavior
but its not working
Possible Solution
its working on last release

How to reproduce:

Go to > https://foundation.zurb.com/sites/docs/sticky.html#javascript-reference
try Clicking other Sticky Navigation e.g. "Sticky Navigation", "Stick to Bottom"
page is not taking to that section

Context

Your Environment

Foundation version(s) used: Latest (6.5.0-rc.1)
Browser(s) name and version(s): Firefox, Chrome
Operating System and version (desktop or mobile): Mac
Link to your project:

Checklist (all required):

[x] I have read and follow the CONTRIBUTING document.
[x] This is a bug report or a feature request.
[x] There are no other issues similar to this one.
[x] The issue title is descriptive.
[x] The template is fully and correctly filled.

Duplicate of https://github.com/zurb/foundation-sites/issues/11355


Doc Update: Jetson Nano instructions generate warnings and errors

In order to avoid running into warning messages and an error when trying to install docker-compose these changes to the documentation ensure that with Jetpack 4.3 everything runs smoothly.

Great work with Mongo! We've been bashing our heads trying to find out why it keeps crashing! (See https://github.com/opendatacam/opendatacam/issues/423)
Regarding docker compose. Have you tried what happens if you install docker-compose via APT? I never installed it via pip and to me it feels like this is no longer necessary and we can simplify the instructions here. (At least for the last year I always installed docker-compose via APT and never had any problems)

@tdurand Any opinion about merging this and releasing v3.0.2 as this seems to fix an important issue

go ahead, sorry low bandwidth those days to check the repo issues ;-)

Understood. I'm on vacation next week and will prepare the new release when I come back.

Thank you! I've merged your code into the release candidate branch. I want to add a few more minor things and hope to release v3.0.2 by the end of the month!


Load Still Image Before GIF

Currently, loading GIF previews takes a LONG time. On a 3G or 2G connection, GIFs do not load.
Instead of loading the GIF as a preview, a downsized still image should be loaded instead. Once the still has been loaded, the GIF should auto download and replace the still once loaded.
For the future, an autoplay toggle could be added for users on slow connections. With autoplay off, users tapping a GIF would initiate the download instead of the GIF automatically downloading in the background. Gotta be data conscious!

Feature created in PR #1


I have stash server located on port that differs from 80.

It doesn't work for me.

I used demo server to test it which has a different port than the default one and it was working.
Did you follow all instructions of the readme file Installation section ? Especially the second point. You have to change domain name value to let it works.


chore: fix some problematic function names in comment

Description

fix some problematic function names in comment
Type of change

[ ] Docs update

How has this been tested?

[ ] Test A
[ ] Test B

How has this been benchmarked?

[ ] Benchmark A, on Macbook pro M1, 32GB RAM
[ ] Benchmark B, on x86 Intel xxx, 16GB RAM

Checklist:

[ ] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I did not modify files generated from templates
[ ] golangci-lint does not output errors locally
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

 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.


[FP]: CVE-2022-36537 for zk-<IP_ADDRESS>.jar

Package URl
<EMAIL_ADDRESS>CPE
cpe:2.3:a:zkoss:zk_framework:<IP_ADDRESS>:::::::*
CVE
CVE-2022-36537
ODC Integration
{"label"=>"Maven Plugin"}
ODC Version
8.1.2
Description
CVE-2022-36537 does not include ZK 9.6.2 - therefore I suppose its a FP.

This is due to incomplete affected software configurations in the NVD. Please report such cases to them so that they can correct the registration which currently signals from 9.6.0 up to (excluding) 9.6.2 as a vulnerable version range.


diag info incorrect by set_letkf_obs

Note line<PHONE_NUMBER> OBSERVATIONS TO BE ASSIMILATED
from
 Processing obshdxf for n=1 to n=nobs=       33862
 and filtering bad observations...
1632996328 OBSERVATIONS TO BE ASSIMILATED
 cnt_obs_u =            0
 cnt_obs_v =            0
 cnt_obs_t =            0
 cnt_obs_s =            0
 cnt_obs_x =            0
 cnt_obs_y =            0
 cnt_obs_z =            0
 cnt_obs_ssh =            0
 cnt_obs_eta =            0
 cnt_obs_sst =            0
 cnt_obs_sss =        16875
 gross_cnt =          138
 gross_2x_cnt =            0
== OBSERVATIONAL DEPARTURE =============================================
           U           V           T           S         SSH         eta         SST
         SSS
  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33
  -9.784E-02
  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33  -9.990E+33
  -9.784E-02
== NUMBER OF OBSERVATIONS TO BE ASSIMILATED ============================
           U           V           T           S         SSH         eta         SST
         SSS
           0           0           0           0           0           0           0
       16737
========================================================================
After Quality Control:      16737 OBSERVATIONS TO BE ASSIMILATED IN MYRANK 000

This is because the variable obsqc0 is not explicitly initialized as zero.
https://github.com/UMD-AOSC/Ocean-LETKF/blob/c4f622fac761bec9fe448d8edebb4ca7e51850a0/src/letkf/letkf_obs.f90.new#L130
Will be fixed in next PR.
 Processing obshdxf for n=1 to n=nobs=       33862
 and filtering bad observations...
     33471 OBSERVATIONS TO BE ASSIMILATED
 cnt_obs_u =            0
 cnt_obs_v =            0
 cnt_obs_t =            0
 cnt_obs_s =            0
 cnt_obs_x =            0
 cnt_obs_y =            0
 cnt_obs_z =            0
 cnt_obs_ssh =            0
 cnt_obs_eta =            0
 cnt_obs_sst =            0
 cnt_obs_sss =        33756
 gross_cnt =          285
 gross_2x_cnt =            0


fix: bug 1501

Render callback gives the wrong error when I edit memory in it

:tada: This PR is included in version 0.285.2 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


assert type checking

I found a way to get your run-time type checking with type checking in strict mode.
pros:

easier to enable strict type checking
fewer lines
no run-time type checking if running in optimized mode

cons:

AssertionError instead of TypeError
a new pattern to get used to
no run-time type checking if running in optimized mode

These edits were automated, not typed by me. It may have broken something.
I wrote a python script to look for patterns and change the python code.
I don't want to pressure you into accepting this. I'm not sure whether it's a good change, just an idea to consider.

It looks like the git diff is catching some differences between unix and windows line endings.

updated to not change line endings


Refactor joiner to reduce symbol bloat.

Using Steven Schveighoffer's "horcrux" trick.  In my range-heavy project, this single change resulted in a 50% reduction in executable size(!). This is on top of the reductions already realized by my own application of the same trick (see forum discussion below).
Relevant discussions:

Forum discussion 1
Forum discussion 2
Steven's blog post explaining the technique
Relevant DMD pull (5855)

This PR is just one of many to come.  Some of the most common range functions in Phobos are Voldemort types, which cause nasty symbol size bloat. These PRs aim to reduce this bloat and make heavily ranged-based code more viable for D. (At least until the DMD PR is pulled. But this problem is quickly becoming a showstopper for me in the meantime, because yesterday I started running into DMD's 10MB symbol size limit. Not to mention ELF errors caused by excessively large symbols.)

Does @rainers recent work on compressed mangling help with this?

Does @rainers recent work on compressed mangling help with this?

Yes, the new mangling never repeats a type in the mangling.


Should be able to test and change fundamental from editor

currently the fundamental can only be changed/verified from the waveform analyzer panel in AudioEvents.

This will require regeneration of spectrogram / melograph (for transcriptions with associated audio files). Perhaps a loading screen while it is updating? Also, will require porting that component from the edit/.upload audiofile modal which deals with setting the fundamental.

Implemented in editor overhaul


Drop support for python v3.8

v3.8 is End-of-Life and causing problems in upstream dependency resolution (via pip).
I also upgrade the pre-commit hooks and ran them. I switched to ruff format from black, thus all the various format changes.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.43%. Comparing base (5564d7c) to head (a688f96).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #105      +/-   ##
==========================================
- Coverage   99.43%   99.43%   -0.01%
==========================================
  Files          14       14
  Lines        1418     1414       -4
==========================================
- Hits         1410     1406       -4
  Misses          8        8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Enable integration tests for Azure in the CI

What does this PR do?
Enable integration tests for Azure in the CI

The app was created in https://github.com/DataDog/cloud-inventory/pull/20422 and https://github.com/DataDog/cloud-inventory/pull/20461 with the help of the #cloudops team.
The secret was manually created by the cloudops team. I added an alert for the expiration, which is in 2 years

Which scenarios this will impact?
Motivation
Additional Notes
I'll store the secret in the Agent Platform 1password vault

/merge


Check local file exists before installing a windows package

Description
This raises an error if a local file does not exist when attempting to install a windows_package
Issues Resolved
#7290
Check List

[x] New functionality includes tests
[ ] All tests pass
[ ] RELEASE_NOTES.md, has been updated if required (not required for bugfixes, required for API changes)
[x] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

Awesome, thanks Josh!

No worries @thommay
Will this be put into Chef 13 too? 😁

You're welcome to back port it, yes.

This is a breaking change. This check occurs at compile time, not converge time; if your recipe downloads a package file using another resource and then runs it using windows_package, it will no longer work.

came here to to say that ^

So @tas50 is going to follow up on this but I can say with relative certainty that this is not at compile time. The define_resource_requirements method is not even called until Provider#run_action happens at converge time.

@zanecodes @nhudacin If you could provide more details about what problem you are hitting, either here or on Slack, that would help us diagnose the issue.

@coderanger I'm working on  a minimal test case right now. In our case, we have a windows_package resource with a notifies :create, "[resource name]", :before declaration that creates the source package, so I'll see if notifies is causing our problem.

before notifications are ... funky. They use the resource requirements system to guess if the resource would be updated (it uses the same systems as Why Run mode under the hood). So in this case it wouldn't know if the resource is going to be updated or not if the file doesn't yet exist.


Audio not working with firefox 35

Steps to reproduce:

Download and install firefox beta
Open play music or any other example

Error displayed: An unknown error occured while processing decodeAudioData. (view_full.html)

@photonstorm
Reviving the dead ticket but I've some information about the issue.
This regularly happens with Firefox Developer Edition(47.0a2) (Haven't checked the regular one).
It has a pattern;
if you refresh the game multiple times (not necessarily frequently), every 15-20 times maybe, Firefox starts failing decoding both and audio. I believe this is some sort of issue with Firefox. Restarting Firefox fixes the problem.

@Nidre  Thanks for the comment, but to be honest that information isn't much use, sorry :) (there's nothing I can actually debug, it sounds like FF just being a dick.. but who knows?)

@Nidre File a ticket to Firefox (https://bugzilla.mozilla.org/), they usually fix such things quite in a decent time.


Can you provide all metric result of waymo dataset?

Hi! Thanks for wonderful code!
I am trying to reimplement your code on OpenPCDet. However, my result is lower than you about 6 percent, on whole waymo dataset with 12 epochs. So I want to compare other metric result with yours, such as Veh, Ped or Cyc L1/L2 AP/APH. Can you provide that result?

<EMAIL_ADDRESS>

thx!

<EMAIL_ADDRESS>


[FVTT v11.315/SWFFG 1.804] Skill lists out of order

When creating a new Character or Minion actor, the skill list is not behaving properly. Social category disappears completely, with skills that belong there being moved into General category. This only happens with actors created after the update to 1.804 (might be the case in 1.803 as well).

Done, will be released in 1.805. Thanks for the report (and further detail on Discord.)

Hey @wrycu, does Brawl skill should be below General skills?


Migrate to Bootstrap 4

You can see the error here: https://travis-ci.org/bertho-zero/react-redux-universal-hot-example/jobs/580273336#L698

Huh. I guess I didn't test it on production. Will sort it out and push a commit.

The error of webpack-isomorphic-tools/plugin is frustrating to solve. This pull request works and there's no errors in the console when I tried after a yarn build and yarn start so if anyone wants to work on getting this PR to pass the tests, you're welcome.


[X] I'm not trying to run Raspotify on a ARMv6 device

Compatible OS

[X] I'm running Raspotify on a compatible OS

Compatible Configuration

[X] I'm running Raspotify on a compatible Configuration

Latest Version

[X] I'm running the latest version of Raspotify

Are you sure?

[X] I'm not running Raspotify <IP_ADDRESS> on a Pi v1 or Pi Zero

Due Diligence

[X] I have done my due diligence

What happened?
Whenever I try to play a song, it stopped directly
I'm using the 0.44.1~librespot.v0.5.0-dev-67d3195 release
Relevant log output and/or the contents of /etc/raspotify/crash_report if any ( sudo journalctl -u raspotify -b and sudo cat /etc/raspotify/crash_report )
[2024-10-06T17:13:00Z ERROR librespot_playback::player] Unable to load encrypted file: Error { kind: Unavailable, error: hyper_util::client::legacy::Error(Connect, Custom { kind: Other, error: ConnectError("tcp connect error", Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }) }) }

It’s a new installation.
I don’t use a firewall (only the ISP one) but I'm behind pi-hole. Maybe it’s related.
I have this problem since the beginning and looked around to find a solution, like editing the host file to bypass the spotify's resolver, without success.

Bypassing pi-hole did the trick
Thank you for your work, time and support