14574 implement header footer

Description
Adds header and footer to next-build
Renders nav components and mega menu.  Not all content-build functionality is ported over.
Data is sourced from a JSON object in importHeaderData.js.  This data was pulled from the prod JSON file
Relates to #14574
https://github.com/department-of-veterans-affairs/va.gov-cms/issues/14574
Testing done
Local visual testing
Screenshots

QA steps
What needs to be checked to prove this works?
Navigate to any existing page in next build and verify that the header and footer are rendered
What needs to be checked to prove it didn't break any related things?
What variations of circumstances (users, actions, values) need to be checked?
As user navigating va.gov

Do this

[ ] Validate that the header renders

Then

[ ] Validate that the footer renders

Then validate Acceptance Criteria from issue

[ ]  Header and footer menus render when a Next Build static page is viewed
[ ] Data is accurate and sourced from a current headerFooter.json and written to page

Definition of Done

[ ] Documentation has been updated, if applicable.
[ ] Tests have been added if necessary.
[ ] Automated tests have passed.
[ ] Code Quality Tests have passed.
[ ] Acceptance Criteria in related issue are met.
[ ] Manual Code Review Approved.

Is this PR blocked by another PR?

[ ] DO NOT MERGE

looks like couple lint errors related to <img> tags in TopNav.tsx
./src/templates/globals/header/TopNav.tsx
10:19  Warning: Using `<img>` could result in slower LCP and higher bandwidth. Consider using `<Image />` from `next/image` to automatically optimize images. This may incur additional usage or cost from your provider. See: https://nextjs.org/docs/messages/no-img-element  @next/next/no-img-element
35:19  Warning: Using `<img>` could result in slower LCP and higher bandwidth. Consider using `<Image />` from `next/image` to automatically optimize images. This may incur additional usage or cost from your provider. See: https://nextjs.org/docs/messages/no-img-element  @next/next/no-img-element
45:74  Error: `'` can be escaped with `'`, `‘`, `'`, `’`.  react/no-unescaped-entities
51:19  Warning: Using `<img>` could result in slower LCP and higher bandwidth. Consider using `<Image />` from `next/image` to automatically optimize images. This may incur additional usage or cost from your provider. See: https://nextjs.org/docs/messages/no-img-element  @next/next/no-img-element
59:76  Error: `'` can be escaped with `'`, `‘`, `'`, `’`.  react/no-unescaped-entities
79:15  Warning: Using `<img>` could result in slower LCP and higher bandwidth. Consider using `<Image />` from `next/image` to automatically optimize images. This may incur additional usage or cost from your provider. See: https://nextjs.org/docs/messages/no-img-element  @next/next/no-img-element
97:13  Warning: Using `<img>` could result in slower LCP and higher bandwidth. Consider using `<Image />` from `next/image` to automatically optimize images. This may incur additional usage or cost from your provider. See: https://nextjs.org/docs/messages/no-img-element  @next/next/no-img-element

I will look at why tugboat didn't auto-build this PR.


Update tests.md with example

Added example about where to find the line to move past the next test.

Hello @apprentiLAB-Suzanne,
thanks for your PR. It is a good thing to show an actual file. The bob exercise might be unknown, so I would show it and not make the person search for the source code of the bob test. Probably something like:

To include the next test you have to move the line with if defined(EXERCISM_RUN_ALL_TESTS) past the desired test.
See the example below from the Bob exercise:

-#if defined(EXERCISM_RUN_ALL_TESTS)
TEST_CASE("shouting")
{
    REQUIRE("Whoa, chill out!" == bob::hey("WATCH OUT!"));
}
+#if defined(EXERCISM_RUN_ALL_TESTS)

Hi @vaeng,
thanks for the suggestion, I updated the PR !
I kept "next test", instead of "desired test". I find that it might be simpler for beginners, if you prefer otherwise I can change it 🙂
Cheers


Connection stops working on Linux

Description
After some variable amount of time passes, my outline connection can no longer reach the internet.
To Reproduce
I had been using a Digital Ocean server in the SFO2 just fine for a while. But an update to the outline client (I presume from 1.0.3 -> 1.0.4) and a change to a Frankfurt server seems to have messed something up.
I will get a successful connection to the outline server and will be able to run just fine for some amount of time. Eventually no connections can be made. The outline client still shows me as "connected", and the ss-local command is still running. If I disconnect from the outline server I then go back to working (not through the proxy though). Attempting to reconnect produces an error. If I manually kill off the still running ss-local command I am then able to reconnect, and the process repeats.
Expected behavior
The connection to the proxy should remain stable or know when it's encountered a problem and correctly recover.
Logs
Here is the "hanging" ss-local command (showed using pgrep, with what I assume is semi-personal information blocked out with ****)
26342 /tmp/.mount_OutlinnMygIv/resources/app.asar.unpacked/third_party/shadowsocks-libev/linux/ss-local -l **** -s **** -p **** -k **** -m chacha20-ietf-poly1305 -t 28 -u
Logs from Outline-Client: (including a disconnect so I could continue to write this bug :smile:)
loading web app from file:///tmp/.mount_OutlinnMygIv/resources/app.asar/www/electron_index.html
Checking for update
Outline is starting
Update for version 1.0.4 is not available (latest version: 1.0.4, downgrade is disallowed).
Pipe connected
Got data from pipe for action: resetRouting
UDP forwarding enabled
Got data from pipe for action: getDeviceName
Got data from pipe for action: configureRouting
Promise "DNS lookup" resolved before 10000 ms.
Promise "Reachability check" resolved before 10000 ms.
tun2socks exited with code 1
Got data from pipe for action: resetRouting

I will gladly attempt again, I have pulled down the Frankfurt
Desktop

OS: Ubuntu 18.04
Latest Chrome doesn't work, curl doesn't work. No TCP connections seem to be able to go through.
DNS queries also no longer work (digs of google against <IP_ADDRESS>, <IP_ADDRESS>, and <IP_ADDRESS> all timeout)

Additional context
I am in Slovakia so I do not think there is any censorship, etc. going on right now.
I will gladly attempt to reproduce or collect more logs with some information on how that works but I have only been using outline for a short amount of time so my knowledge is fairly limited.

@alexmherrmann Thanks for the detailed report - sorry you've been having problems with Outline.
I'm afraid I don't know what's happening. The output of this command would help me debug: (again, removing any identifying information such as your proxy server's IP address):
route -n

If you can send me the output both while the connection is working and when it's stopped working, that would be great.
Thanks!

Sorry about the (incredibly) late reply. My use case for outline was suppressed for a while so I had stopped using it and shut down my server. Running the updated client has fixed it for whatever reason. I've been using it semi-regularly and haven't had the same problem occur. If it does happen again I'll return to this issue but for my purposes it can be closed. Thanks.


kore-repl: intermediate state represented as stuck

When running test/itp-nth-ancestor/nth1-spec.k with kore-repl, the final proof graph looks like:

This means that one of the intermediate states (node 7) is considered stuck by  kore-repl, before being proven after the following step. Also, we should investigate why there are two Simpl/RD transitions, with node 7 at the middle, instead of a single Simpl/RD transition. We should probably rename Simpl/RD as well.
These issues have probably appeared because we changed the proof transition system without updating how we represent this information in kore-repl.

[ ] ClaimState.Remaining is not a final stuck proof state anymore, so we should not represent it as such in kore-repl
[ ] Investigate the Simpl/RD issue

Node 5:
<T>
  <k>
    apply ( lemma ) ~> apply ( <~*.i ) ~> .
  </k>
  <g>
    #if ( B1 == ?B2 ~> . ) ==K ( none ~> . ) #then ?B2 <~ B2 #else B1 == ?B2 and ?B2 <~ B2 #fi ~> .
  </g>

    p1 |-> nth ( 0 , B1 , ?B2 )
    p2 |-> ?B2 <~ B2

</T>

Node 6 (on which claim 1 applies):
  <T>
    <k>
      apply ( <~*.i ) ~> .
    </k>
    <g>
      B1 <~ B2 ~> .
    </g>

      p1 |-> nth ( 0 , B1 , ?B2 )
      p2 |-> ?B2 <~ B2

  </T>
#And
  {
    false
  #Equals
    ( B1 == ?B2 ~> . ) ==K ( none ~> . )
  }

Node 7 (remainder):
  #Not ( {
    false
  #Equals
    ( B1 == ?B2 ~> . ) ==K ( none ~> . )
  } )
#And
  <T>
    <k>
      apply ( lemma ) ~> apply ( <~*.i ) ~> .
    </k>
    <g>
      #if ( B1 == ?B2 ~> . ) ==K ( none ~> . ) #then ?B2 <~ B2 #else B1 == ?B2 and ?B2 <~ B2 #fi ~> .
    </g>

      p1 |-> nth ( 0 , B1 , ?B2 )
      p2 |-> ?B2 <~ B2

  </T>

Claim 1:
    #Top
  #And
    <T>
      <k>
        apply ( lemma ) ~> _DotVar2 ~> .
      </k>
      <g>
        B1 == B2 and B2 <~ B3 ~> .
      </g>

        _DotVar4

    </T>
#Implies
  #wAF ( <T>
    <k>
      _DotVar2
    </k>
    <g>
      B1 <~ B3 ~> .
    </g>

      _DotVar4

  </T> )

Node 5:
<T>
  <k>
    apply ( lemma ) ~> apply ( <~*.i ) ~> .
  </k>
  <g>
    #if ( B1 == ?B2 ~> . ) ==K ( none ~> . ) #then ?B2 <~ B2 #else B1 == ?B2 and ?B2 <~ B2 #fi ~> .
  </g>

    p1 |-> nth ( 0 , B1 , ?B2 )
    p2 |-> ?B2 <~ B2

</T>

Node 6 (on which claim 1 applies):
  <T>
    <k>
      apply ( <~*.i ) ~> .
    </k>
    <g>
      B1 <~ B2 ~> .
    </g>

      p1 |-> nth ( 0 , B1 , ?B2 )
      p2 |-> ?B2 <~ B2

  </T>
#And
  {
    false
  #Equals
    ( B1 == ?B2 ~> . ) ==K ( none ~> . )
  }

Node 7 (remainder):
  #Not ( {
    false
  #Equals
    ( B1 == ?B2 ~> . ) ==K ( none ~> . )
  } )
#And
  <T>
    <k>
      apply ( lemma ) ~> apply ( <~*.i ) ~> .
    </k>
    <g>
      #if ( B1 == ?B2 ~> . ) ==K ( none ~> . ) #then ?B2 <~ B2 #else B1 == ?B2 and ?B2 <~ B2 #fi ~> .
    </g>

      p1 |-> nth ( 0 , B1 , ?B2 )
      p2 |-> ?B2 <~ B2

  </T>

Claim 1:
    #Top
  #And
    <T>
      <k>
        apply ( lemma ) ~> _DotVar2 ~> .
      </k>
      <g>
        B1 == B2 and B2 <~ B3 ~> .
      </g>

        _DotVar4

    </T>
#Implies
  #wAF ( <T>
    <k>
      _DotVar2
    </k>
    <g>
      B1 <~ B3 ~> .
    </g>

      _DotVar4

  </T> )


Issues with context & styled-components in node module

I'm running in to an issue where I am using a private node module that contains small components that use styled-components and expect a theme to be set by the package that includes it. This was working fine in<EMAIL_ADDRESS>but after upgrading to beta 26 it stopped working. The theme passed in to the component from the external package is just empty.
I've tried to reproduce this outside my project but failed to do so because it works fine when you define the components that use the theme inside the project itself. I've narrowed it down to a specific version, it works in beta 18 but breaks in beta 19. I've tried looking at the changes made in that release but couldn't find anything that would explain this.
Do you might have an idea what's changed that would have this effect?

Try to reproduce it with the npm modules. You can install npm modules locally with file://<path-to-module-dir> (Doesn't work with yarn)
Those paths can be relative urls as well.
With this, we may could see the real problem.

I've been digging in the code of styled-components a bit and I think the issue is related with context. It subscribes to a "channel" on the context named __styled-components__ but that appears to be missing in the component loaded from my private npm module.
So basically this if statement fails, and then it looks for a theme passed in as prop, which is obviously not there, resulting in an empty theme.
Did the bump from beta18 to beta19 caused any changes to the context that could cause this?

@rovansteen https://github.com/zeit/next.js/commit/8b94534260d7589482c844758117415936fa0996 this was added in beta.19. I'm not sure if it is related. But there were some fixes on it since then. So could you please try the latest beta?

@timneutkens unfortunately it's still broken. I've tried something simple with the styled-components example in the repo and it breaks when you add a theme. I created a separate issue for that https://github.com/zeit/next.js/issues/1416 I hope that fixing that also fixes this problem.

Closing this for now because I am not able to setup a minimal reproduction of the issues I ran into. Might try next.js for this project later, keep up the good work!


Airflow Hook: panic assignment to entry in nil map

Hi,
I'm testing an Airflow hook locally but when I merge from branch I get the following error:
**panic: assignment to entry in nil map**

goroutine 623 [running]: github.com/treeverse/lakefs/pkg/actions.(*Airflow).Run(0xc00aacb0...)
	/build/pkg/actions/airflow.go:93 +0x128
github.com/treeverse/lakefs/pkg/actions.(*Service).runTasks.func1(0x28d01c0, 0x1e72f98)
	/build/pkg/actions/service.go:197 +0x325
github.com/hashicorp/go-multierror.(*Group).Go.func1(0xc00ac9e7a0, 0xc00aca8bc0)
	/go/pkg/mod/github.com/hashicorp/go-multierror@v1.1.0/group.go:23 +0x5c
created by github.com/hashicorp/go-multierror.(*Group).Go
	/go/pkg/mod/github.com/hashicorp/go-multierror@v1.1.0/group.go:20 +0x66

How to reproduce the error
My hook file uploaded under _lakefs_actions/ of the main branch.
name: Good files check
description: set of checks to verify that branch is good
on:
  pre-commit:
  pre-merge:
    branches:
      - main
hooks:
  - id: trigger_my_dag
    type: airflow
    description: Trigger an example_dag
    properties:
       url: "http://airflow-poc-web:8080"
       dag_id: "k8s_test_dag"
       username: "****"
       password: "****"

When I try to merge from the test branch to master I get the error.

Hey @kipliko - Thanks for opening the issue, I was able to reproduce it locally.
In some cases, the additional properties map is lacking initialization and that what causes the panic. PR #2534 has the fix, but I still need to add tests and then release a version.
Meanwhile there's a quick detour you can take that will unblock you for now. Just need to add some dummy properties to your yaml file, such as:
name: Good files check
description: set of checks to verify that branch is good
on:
  pre-commit:
  pre-merge:
    branches:
      - main
hooks:
  - id: trigger_my_dag
    type: airflow
    description: Trigger an example_dag
    properties:
       url: "http://airflow-poc-web:8080"
       dag_id: "k8s_test_dag"
       username: "****"
       password: "****"
       dag_conf:
          some: "additional_conf"

Let us know if that did the trick for now.


Some Diff highlights don't extend throughout the whole length of a line

Don't know if this is intentional, but when comparing diffs with long lines that take up multiple line spaces, only the first line is highlighted but not the rest of the overflown parts of the line.

So in the Image you see a diff between two different versions of text that I'm working on. The paragraphs on the left are all new additions, yet, they are not highlighted. Notice how all the lines that have line numbers are highlighted and those that have dots, are not.

Not intensional although need to ask @mupchrch .  I checked the issues over at split-diff  I don't see any other reports there, but split-diff is the awesome package that git-time-machine uses to display the diff and the highlights are added by it.  I just accepted a pull request to update the version of split-diff that is used and will post a new release soon.
Thank you for letting us know about this.

@mixania The highlighting issue has been fixed for git-time-machine as of v1.5.0, which was released end of April if my findings are correct. 😃
@littlebee One thing I noticed is that soft wrap is enabled in the above screenshot. The stand alone split-diff package actually disables soft wrapping of lines while it's enabled (otherwise the diffs wouldn't align properly). I could move this logic into the updateDiff function that git-time-machine calls if you think it is something that makes sense. Let me know!

thanks @mupchrch!  I'm not sure if disabling word wrap would work in this case tho.  It looks like soft wrap is necessary where entire paragraphs of text are on a single line?

That's fair, I agree. I think I will log a bug to my repo and then I can move the logic to updateDiff when/if I can fix the bug.

closing this ticket.  see ref issue in split-diff


FreeRDP Client execution problems in Windows10

I followed the below steps to execute the wfreerdp.exe in Windows 10, but nothing happening after launching the freerdp client

Downloaded code from the below GIT repository
https://github.com/FreeRDP/FreeRDP
Followed the FreeRDP compilation by following the below documentation.
https://github.com/FreeRDP/FreeRDP/wiki/Compilation

To avoid libUsb build erros
cmake . -DCHANNEL_URBDRC=OFF
To Get RDP Server
cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DWITH_SERVER=ON -DWITH_SAMPLE=ON -DWITH_CLIENT=ON

Used Visual studio 2022 to compile the code and able to build the code without any errors.

Pointed build path to Debug folder and got the binaries into the debug folder

Tried to run with the below command in command prompt to launch wfreerdp.exe
C:\FreeRdp\FreeRDP\FreeRDP-master\Debug\wfreerdp.exe /v: HOST IP /port:3389 /u:DOMAIN\USERNAME /p:PASSWORD /cert-ignore

Am I missing any step to run the FreeRDP client successfully in windows 10?
Even I tried with below latest stable nightly static build binaries (wfreerdp.exe) but it doesn't work.
C:\FreeRdp\FreeRDP\FreeRDP-master\Debug\wfreerdp.exe /v: HOST IP /port:3389 /u:DOMAIN\USERNAME /p:PASSWORD /cert-ignore
https://ci.freerdp.com/job/freerdp-nightly-windows/lastStableBuild/arch=win64,label=vs2013/

did you check the output of the binary? (on windows you need to do something like wfreerdp.exe <yourargs>  >logfile.txt 2>&1 to get the output to a file)

@Ranga1987 looks like the target is not reachable? (network/server down/...?)

@akallabeth  Thanks for help, the problem is VM is not reachable at that point of time


port to r2.1 - Fix for JIRA Issue SWDEV-212838

TF graph optimizer will (sometimes) create _FusedConv2D nodes (which is fusion of Conv2D + [BiasAdd, Relu]).
The runtime implementation for these _FusedConv2D nodes is CUDA specific, and cannot be supported on ROCm.
So for ROCm, we need to ensure these _FusedConv2D* graph optimizations are disabled

@sunway513

Can one of the admins verify this patch?

Thanks @deven-amd , let's watch for this CI run:
http://ml-ci.amd.com:21096/job/tf-develop-upstream-releases/job/tensorflow-upstream-rel2.1-nightly/189/


Uncaught SyntaxError: Unexpected token < in JSON at position 0

This article doesn't load:
https://brainspell.herokuapp.com/view-article?id=24996404
this is the error in the web console:
Uncaught SyntaxError: Unexpected token < in JSON at position 0
    at JSON.parse (<anonymous>)
    at Object.<anonymous> (view-article:212)
    at j (jquery.js:2)
    at Object.fireWith (jquery.js:2)
    at x (jquery.js:4)
    at XMLHttpRequest.b (jquery.js:4)

Fixed. There were some edge cases associated with this article (having no mesh descriptors to display).

thank you!

sorry... now I get the infamous:
Mixed Content: The page at 'https://brainspell.herokuapp.com/view-article?id=24996404' was loaded over HTTPS, but requested an insecure script 'http://spin.js.org/spin.min.js'. This request has been blocked; the content must be served over HTTPS

Yes I see this now. It must be a result of how we are handling Github user accounts for collections. If you allow your browser to load unsafe scripts, the page will load, but I'll get a better solution pushed.

Ok fixed this as well.

it's working, thanks!


Add Sara to list of Maintainers for FAIR lesson

While reviewing #117 I noticed Sara El-Gebali needs to be added as (lead?) maintainer on the FAIR lesson.

Created https://github.com/LibraryCarpentry/librarycarpentry.github.io/pull/119 to add @selgebali 🎉

Closed via #119


crash while ctrl+c on input

Description
What steps will reproduce the problem?

i invoked an input,
at the prompt in the consol pressed ctrl+c

What is the expected output? What do you see instead?
i would expect to stop running the code instead of crashing
Please provide any additional information below
File "/usr/lib/python3.6/site-packages/qtconsole/base_frontend_mixin.py", line 163, in _dispatch
handler(msg)
File "/usr/lib/python3.6/site-packages/spyder/widgets/ipythonconsole/shell.py", line 417, in _handle_error
super(ShellWidget, self)._handle_error(msg)
AttributeError: 'super' object has no attribute '_handle_error'
Version and main components

Spyder Version: 3.2.2
Python Version: 3.6.2
Qt Versions: 5.7.1, PyQt5 5.8.1 on Linux

Dependencies
pyflakes >=0.6.0 :  1.5.0 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  None (NOK)
numpy >=1.7      :  1.12.1 (OK)
sphinx >=0.6.6   :  1.6.3 (OK)
rope >=0.9.4     :  None (NOK)
jedi >=0.9.0     :  0.10.2 (OK)
psutil >=0.3     :  5.0.1 (OK)
nbconvert >=4.0  :  4.2.0 (OK)
sympy >=0.7.3    :  None (NOK)
cython >=0.21    :  None (NOK)
qtconsole >=4.2.0:  4.2.1 (OK)
IPython >=4.0    :  5.3.0 (OK)
pylint >=0.25    :  1.7.2 (OK)

This is a duplicate of issue #5158 and it was fixed in Spyder 3.2.3. Please update.


(feat) Add expect() and should for Sequence

It simply uses  ExpectCollection(sequence.toList()).
It can not handle infinite sequences.
It needs a list instead of a sequence when using to.equal() or not.to.equal().

Examples:
expect(sequenceOf(1, 2, 3)).to.contain.any.elements(1, 2, 3)
expect(sequenceOf(1, 2, 3)).to.contain.any.elements(1, 4)

Looks good to me despite the fact that equal doesn't work as expected. But IMO using equals on sequences is not that useful at all. If necessary we could simply introduce an ExpectSequence impl later on.

Thanks for your contribution. I'll publish a new version to Maven Central in a few days.


OAK-9566 | Improve index stats

Added support for Json format
Fixed issue with local index dir size - currently with composite node store - it was just reporting size of read only mount
Added new stats for indexCreationTimestamp, ReindexCompletionTimestamp, suggestDirSize, If the index has hidden property index node and if it has a hidden read only libs mount.

@thomasmueller -

Could you add an example output, in Json format, to https://issues.apache.org/jira/browse/OAK-9566 ?

Attached a sample o/p to the jira. Please note that the values in it are not correct, since It's from an earlier revision and was not run on composite node store - but the format is same so it'll give an idea about how it's structured.

Or (might be easier) add a test case with Json output... anyway having a test case would be good.

I added a couple of tests cases. See IndexPrinterTest#asyncIndexInfoJson and  IndexPrinterTest#indexInfoJson

I wonder if the timestamps would be better listed in UTC? Right now we have
"Last indexed up to": "2021-09-17T12:52:02.619+05:30",

That would become
"Last indexed up to": "2021-09-17T07:52:02.619Z",

Where the "Z" is from here: https://www.w3.org/TR/NOTE-datetime

@thomasmueller

I wonder if the timestamps would be better listed in UTC?
Sure - I transformed them in UTC now.

https://issues.apache.org/jira/browse/OAK-9566?focusedCommentId=17417733&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17417733

The example uses "2021-55-20T16:55:53.53 UTC", you have used seconds instead of month...
While "2021-09-20T16:55:53.53 UTC" is clear for the user, is not a standardized format... https://www.w3.org/TR/NOTE-datetime specifies "2021-09-17T07:52:02.619Z".
If we want "human readable", then what about "2021-09-20 16:55:53 UTC" (no "T", and no fractional seconds).


Documentation split into user/developer facing.

Also push all documentation into a docs folder.

Closed with release of fw-v0.4.0


Improve documentation for file uploader

It took me some time to figure out how to use the uploader to allow users uploading images.
Basically what I needed was to add the following items to CKEDITOR_CONFIGS:
'filebrowserImageBrowseUrl': '/ckeditor/browse/',
'filebrowserImageUploadUrl': '/ckeditor/upload/',

As this might be trivial for those who are familiar with ckeditor, including the description into the documentation would make a new-comer's life easier IMHO.

As far as I know no extra configuration is required (unless you are trying to use some other upload method).

@riklaunim That's weird.
I'm using and django-ckeditor==5.0.2 with django==1.8.5.
With an empty config, upload tab is hidden in the image property dialog.
The browse button is not displayed either unless filebrowserImageBrowseUrl  is set.

is it in /admin/ or on custom views (that needs {{form.media}}) ?

@riklaunim It's in admin. My model is like,
from ckeditor.fields import RichTextField
class MyModel(models.Model):
    body = RichTextField()

RichTextField is non uploading. while RichTextUploadingField is with upload enabled.

:+1: Put these in the docs please.

It is, read it will you.

@riklaunim Wow thanks! Truly it is in the docs (and bolded). Can't believe I missed that...


build -> dist fix

This fixed the demo pages for me.

There is info about it in readme:

Framework7' JS and CSS files in Kitchen Sink are temporary linked to build/ to make development process easier on this stage. So to make it work you need to build Framework7 (see Build section) or to re-link JS and CSS files to dist/ folder.

My suggestion then is (as an easy hack) to have CSS files linked in via build and dist
Should I set that up as a PR?


Accessing PDF attachments of publications cause HTTP 500

Hi There,
We have just noticed that if a publication has a PDF file attachment (presumably any attachment) then the file link returns an HTTP 500. When I reproduce the issue on the Web Server itself, I get the following error instead of the default HTTP 500 page:
Error occurred:

Traceback (most recent call last):
  File "D:\Websites\KerkoBibliography\wfastcgi.py", line 847, in main
    result = handler(record.params, response.start)
  File "C:\Python38\lib\site-packages\flask\app.py", line 2463, in __call__
    return self.wsgi_app(environ, start_response)
  File "C:\Python38\lib\site-packages\flask\app.py", line 2449, in wsgi_app
    response = self.handle_exception(e)
  File "C:\Python38\lib\site-packages\flask\app.py", line 1866, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "C:\Python38\lib\site-packages\flask\_compat.py", line 39, in reraise
    raise value
  File "C:\Python38\lib\site-packages\flask\app.py", line 2446, in wsgi_app
    response = self.full_dispatch_request()
  File "C:\Python38\lib\site-packages\flask\app.py", line 1951, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "C:\Python38\lib\site-packages\flask\app.py", line 1820, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "C:\Python38\lib\site-packages\flask\_compat.py", line 39, in reraise
    raise value
  File "C:\Python38\lib\site-packages\flask\app.py", line 1949, in full_dispatch_request
    rv = self.dispatch_request()
  File "C:\Python38\lib\site-packages\flask\app.py", line 1935, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "C:\Python38\lib\site-packages\kerko\views.py", line 154, in item_attachment_download
    return send_from_directory(
  File "C:\Python38\lib\site-packages\flask\helpers.py", line 771, in send_from_directory
    return send_file(filename, **options)
  File "C:\Python38\lib\site-packages\flask\helpers.py", line 647, in send_file
    rv.last_modified = last_modified
  File "C:\Python38\lib\site-packages\werkzeug\_internal.py", line 259, in __set__
    value = self.dump_func(value)
  File "C:\Python38\lib\site-packages\werkzeug\http.py", line 872, in http_date
    return _dump_date(timestamp, " ")
  File "C:\Python38\lib\site-packages\werkzeug\http.py", line 819, in _dump_date
    d = gmtime(d)
OSError: [Errno 22] Invalid argument

StdOut:

StdErr:

It appears to me that, wherever parameter "d" is coming from, it is not in the expected format or of the expected value type. Changing line 819 in "C:\Python38\lib\site-packages\werkzeug\http.py"  from "d = gmdate(d)" to "d = gmdate()" makes it immediately working. This makes me believe that either an additional check is missing from the if else block or the check "isinstance(d, (integer_types, float))" is not suitable to determine how to handle parameter "d".
Thanks,
Laszlo

PDF attachments usually work fine in Kerko, so you must have stumbled on something new or unusual. So just by changing the gmtime() call, the file downloads normally? Could you tell me what is the version of Werkzeug in your environment, and the type and value of d when the error happens?

That is correct, changing it to gmtime() fixes it immediately. I guess the only downside of this is that the last modified time of the downloaded file will change every single time you download it. It will be the time of the download instead of the actual time when the file was last modified. This is with kerkoapp v0.6, I believe werkzeug is 0.16.0. Not sure what the value is but it's one of the integer_types (int or long). Cheers.

I'm wondering about the actual value of d because it might tell a bit more about what's happening (the problem may not be in Werkzeug, but upstream in Kerko or Flask). I'm not able to reproduce the problem. Have you tried the latest Werkzeug and Flask versions, in case it is a known issue that might have been fixed?

Closing this for inactivity. Please report back if the issue persists with the latest package versions. A couple of bug fixes related to attachments were made in Kerko 0.7.

Closing this for inactivity. Please report back if the issue persists with the latest package versions. A couple of bug fixes related to attachments were made in Kerko 0.7.


Domain conflicts with original thermal integration

The domain in use, thermal, conflicts with the original project forcing people who have the old one installed to remove it.  Renaming the domain will avoid this situation.

Anyone using this integration up to and incuding version 1.3.0
will need to update their configuration by changing
platform: thermal to platform: thermal_vision


Add category index.

This creates an index for the category folder so that you can import all the packages at once if you want to. It is generated along with the categories by the generate script.

This works with the slug package for me.

@tdanecker Are there any other specific things that you would like to see improved on the generator?

@tdanecker Thank you! Are there any other specific things that you would like to see improved on the generator?

@tdanecker Would you mind making a patch release so that I can use this PR in my Lite version, or are you planning on waiting for the next Unicode release?


[Feature] Full support for theming components

A theme is generally considered more than just a color palette for the site. Typography, border radius, shadows, button shapes, etc are important parts of a theme that cannot be customised at this time. Material is a set of design guidelines, not a specific look and feel, and this has been emphasised by the latest documentation and articles about Material. For example:
https://material.io/design/material-studies/
Plain material makes all apps lose their identity, so there should be a way of customising it. There are currently two ways of allowing for this:

By adding some sort of CSS-in-JS code that allows the manipulation of the elements, as for example Material UI does in React.
By separating the styles into a SCSS/LESS library with variables that allow customisation, as for example Bootstrap and SemanticUI do.

The current situation is that Angular Material doesn't support JS methods to change the theme, and the CSS used by the library is not documented so "hacking" a theme is a daunting task.

For the time being we have no plans to support APIs for anything beyond color and typography.
We feel strongly that theming should be done at compile time. Dynamically changing styles at run-time  (like AngularJS did) incurs what we consider to be an unacceptable performance cost.
Customization through something like Sass variables is not a viable option for a component-centric model of development because, by the time the component is consumed, the source Sass has already been compiled into CSS and associated with the component as one atomic unit. To make this work, you would have to insert a dependency (overrides) into your dependency, which doesn't play well with build systems and packaging in general.
We'll have a lot more options for theming once we no longer support IE11 (roughly Jan 2020), when CSS custom properties become available.


Ensure BadgerDB GC is enabled as a separate goroutine

Ensure BadgerDB GC is enabled as a separate goroutine -- unlike LevelDB, it needs to be done by the DB user (Wavelet)

PR #349


vuln -> extscan

Classify findings coming from Scan as extscan. vuln expects
dataflow info as well, which is missing for results coming from Scan.

I have added this change as part of a different PR. This is no longer required


v0.3 Pinch Valve Migration

All components created from .step files in assets folder.
.idw, .dwg, .stl, .pdf are available for each of the three parts - rotor, bearing and base
closes #941

Migration was not properly done, only Step files imported. Closing this PR as implementation has been taken over by another team member.

Migration was not properly done, only Step files imported. Closing this PR as implementation has been taken over by another team member.


[Windows] Fix sub-window initial transparency and always-on-top state.

Fixes https://github.com/godotengine/godot/issues/71642

Thanks!

Yes, thank you!


Internal server error on authorization attempt

Problem: 500 error on authorization attempt.
Steps to reproduce:

Follow the installation instructions
Go to http://localhost:8080/home
Click on login with fieldview button
Get directed to https://climate.com/static/app-login/index.html?scope=openid+fields%3Aread+imagery%3Awrite&page=oidcauthn&response_type=code&client_id=partner-fooco&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Flogin-redirect
Put in credentials, get prompted for accepting account access.
Click allow.

Result:
I get sent to https://climate.com/api/oidc/authorize with the following content:

HTTP ERROR 500
Problem accessing /oidc/authorize. Reason:
Internal Server Error

@blackary thanks for pointing this out! the underlying issue here is that partner-fooco isn't a registered ID in our system. but our http response should be better. we'll have a fix out for that shortly. in the meantime i'll update the example to be a bit more clear about example value for the CLIMATE_API_ID.

@blackary we've pushed out a fix, so you'll now get a 400 with a message ("Invalid client")


The best way to extract rtpmap from a SessionDescription

Hey guys,
I'm trying to extract the rtpmap from a SessionDescription so that I know which payload types have been chosen in the answer and the only way I see is looping through MediaDescriptions then Attributes, looking for key rtpmap and parse its value.
Is there a better way to do this?
Cheers
Quentin

Hey @asticode!
Great to see you here, huge fan of your work :)
You can get the negotiated codecs (and the PayloadTypes they are using) by calling RTPSender.GetParameters and RTPReceiver.GetParamaters.
This gives you access to RTPParameters and you can scan through for the Codec.MimeType and when you find it you can get they value from the PayloadType member.
You can get the RTPSenders and RTPReceivers by calling GetSenders and GetReceivers on the PeerConnection.

Hey @Sean-Der,
Thanks, I'm also really impressed by the amazing work you've been able to pull off with the Pion ecosystem ❤ I'm hoping to switch all our webrtc use cases to Pion in the near future!
Thanks a bunch for the elegant solution, that's way better than what I had in mind 👍
Cheers


Support backwards compatibility

I added a dataVersion field to account for this but it's not used for anything yet

Doing some searches for Unity serialization and backwards compatibility didn't bring up useful results, so I had a look at what Modular Avatar does.
https://github.com/bdunderscore/modular-avatar/blob/13023d1f244240ac0cc7666874a1e3cccd57b00d/Runtime/ModularAvatarMergeArmature.cs#L54 and followup searches for FormerlySerializedAs brings up https://www.reddit.com/r/Unity3D/comments/p5pcps/how_to_update_a_script_handle_old_serialized/, suggesting that FormerlySerializedAs + OnValidate is probably the way to go.
The dataVersion field looks enough for now and there doesn't seem to be any further action needed.

Actually, we should have a check that dataVersion isn't higher than the currently-known value.


Loads not requested Indonesian stemmer and ja normalizers

Profiling my node application, I noticed the following lines:
      1   50.0%          LazyCompile: ~loadDictionary ...\node_modules\natural\lib\natural\stemmers\indonesian\stemmer_id.js:129:24
      1  100.0%            Eval: ~<anonymous> ...\node_modules\natural\lib\natural\stemmers\indonesian\stemmer_id.js:1:1
      1   50.0%          LazyCompile: ~loadDictionary ...\node_modules\natural\lib\natural\stemmers\indonesian\prefix_rules.js:31:24
      1  100.0%            Eval: ~<anonymous> ...\node_modules\natural\lib\natural\stemmers\indonesian\prefix_rules.js:1:1
      1    4.2%        LazyCompile: ~replacer ...\node_modules\natural\lib\natural\util\utils.js:33:18
      1  100.0%          Eval: ~<anonymous> ...\node_modules\natural\lib\natural\normalizers\normalizer_ja.js:1:1

My natural usage is very simple (typescript code):
import {PorterStemmerIt, PorterStemmer} from "natural";
const stword = (language === "it") ? PorterStemmerIt.stem(word) : PorterStemmer.stem(word);

My words are only in English or Italian.
Why the references to Indonesian stemmer and the Japanese normalizer?
I'm doing anything wrong with stemmer usage?
Thanks for your help!
mario
natural: 1.0.1
node 12.16.1
os: Windows 10 64 bits

I don't know. I checked for dependencies in the stemmers for English and Italian, and did not find any so far. Strangely, both the Japanese stemmer (which used a normalizer for Japanese) and the Indonesian stemmer have an implementation that deviates from the Porter stemmers.

I retried with a larger, different corpus and it does not happen anymore. The problem is probably an artifact of the profiler sampling. Sorry for the noise.
mario


Additional Fluxbb tests and fixes

Add [code] to markdown support
Use more standard <s> instead of github's ~~
Fix newline requirement for quote

@harry-wood Any chance you could merge this branch? Maybe squash it.

I was very puzzled about why the ~~ strikethrough syntax would give issues (bear in mind that I tested this stuff on https://community.openstreetmap.org and https://meta.discourse.org/ and importing into a discourse docker image, so I know that ~~ works!) but I think I've got to the bottom of it
I see where someone was pointing out that it didn't work. https://community.openstreetmap.org/t/migrating-content-from-old-forums/446/152 . Their example coming from this original bbcode involving [s] within a [list]. I believe strikethrough must have worked fine everywhere else, but not within a list, and ... bad news... we have a [list] problem that goes beyond strikethrough.
I took the decision to do [list][*] syntax conversion to into html

 rather than trying to do markdown list syntax. I thought it would be more trouble free, given how awkward markdown lists are with their indentation. Trying to get the indentation right especially for nested lists... that's nasty. But I've just realised...
When we give discourse an
 tag with content in it, all syntax support is disabled on that first line. Try pasting this into a discourse:

**bold?** *italic* ~~strikethrough~~  [url]http://google.com[/url]

But perhaps we can still avoid markdown list indentation hell. Try this.

**bold?** *italic* ~~strikethrough~~  [url]http://google.com[/url]

Not pretty, but this works! So maybe we can just bung in some extra newlines after every
. The joys of discourse syntax parsing quirks.
So I guess I'll add that into the list handling logic, which is over in the discourse PR (regex preprocessing logic. Not in this gem)
Here we need to take out changes to do with strikethrough. Unless I'm mistaken, that was fine as I had it.

~~ was not supported in discourse when I checked. See: https://meta.discourse.org/t/please-add-strikethrough-and-underline-support-in-markdown/22843

I see where someone was pointing out that it didn't work. https://community.openstreetmap.org/t/migrating-content-from-old-forums/446/152 . Their example coming from this original bbcode involving [s] within a [list]. I believe strikethrough must have worked fine everywhere else, but not within a list, and ... bad news... we have a [list] problem that goes beyond strikethrough.

This was fixed. The older posts was where I was still testing multiple different versions of the importer.
There are some list item discourse specific fixes here: https://github.com/Firefishy/discourse/commits/osm-test-import
Please focus just on this PR.

There have been no issues raised about the formatting on the test import site for the last few weeks despite me asking. In my view the fluxbb bbcode -> discourse markdown is now "good enough".
Please only look at comments AFTER the last import: https://community.openstreetmap.org/t/migrating-content-from-old-forums/446/164?u=firefishy

I didn't merge this directly, but I've just finished picking through it. We can close it. I've cherry-picked / taken inspiration from here into my PR: https://github.com/nlalonde/ruby-bbcode-to-md/pull/6
I didn't bring in the <s> change because I've done fix to the
 issue over in the discourse PR https://github.com/discourse/discourse/pull/18953/commits/5e86c4311ee94db8ffebff447ea96d6c105c55a8  ...which I believe is the only problem there.


UI should feel more like an IDE

[ ] sidebars/panels should be resizable

switching from a bespoke react app to a vscode distro (eg @CodinGame/monaco-vscode-api or theia) would definitely help make it feel more like an IDE, but comes at the cost of needing to use a different [less documented] framework

switching from a bespoke react app to a vscode distro, eg @CodinGame/monaco-vscode-api or theia would probably help

switching from a bespoke react app to a vscode distro (eg @CodinGame/monaco-vscode-api or theia) would definitely help make it feel more like an IDE, but comes at the cost of needing to use a different [less documented] framework

currently exploring this in the vscode branch

closed with #15


Cover art

Is there a way to have komf search for higher resolution covers? Some of mine are quite pixelated.

Komf chooses the cover art from whatever the first source that matches. And unfortunately mangaupdates has lower quality covers. I'll consider adding some configuration that will allow choosing cover art from other providers

With https://github.com/Snd-R/komf/releases/tag/0.8.0 you can now enable metadata aggregation from multiple sources. Enable mangaupdates and any other provider that you want covers from and disable thumbnail metadata field in mangaupdates.


docs(hertz): add engine docs

What type of PR is this?
docs

What this PR does / why we need it (en: English/zh: Chinese):

en: add engine docs and move the Engine document order to the top.
zh: 添加 engine 文档并将 Engine 文档顺序调至最前。
Which issue(s) this PR fixes:

thanks

预览看了 Engine 文档一下没啥问题，大家可以再 review 一下 cc @GuangmingLuo @rogerogers @welkeyever

Too fast, I haven't submitted my changes yet 🤣


Map not showing on release build

As per title.
Tested on the following App.vue:
<template>
  <div id="app">
    <MglMap class="mglmap" container="map" :zoom="10.5" :access-token="accessToken" :map-style="mapStyle" :center="sgCenter">
      <MglGeolocateControl/>
      <MglNavigationControl/>
    </MglMap>
  </div>
</template>

<script>
import 'mapbox-gl/dist/mapbox-gl.css';
import 'v-mapbox/dist/v-mapbox.css';
import<EMAIL_ADDRESS>import {MglMap, MglNavigationControl, MglGeolocateControl} from 'v-mapbox'
export default {
  name: 'App',
  components: {MglMap, MglNavigationControl, MglGeolocateControl},
  data(){
    return {
      accessToken: '<omitted>',
      mapStyle: 'mapbox://styles/mapbox/dark-v9',
      sgCenter: [103.82161, 1.35433],
    };
  }
}
</script>
<style scoped>
.mglmap {
  height: 100vh;
  position: absolute;
  z-index: 0;
}
</style>

map works on npm run serve, npm run build --mode development but not on npm run build
Edit: Changed test code

- import {MglMap, MglNavigationControl, MglGeolocateControl} from 'vue-mapbox'
+ import { MglMap, MglNavigationControl, MglGeolocateControl } from 'v-mapbox'

seems you're importing the wrong package

Updated test code with suggestion. Still unable to see the map on release build

@vinayakkulkarni  I'm also facing the same issue. New release build. And map is not loading...

@vinayakkulkarni
I'm seeing 100% width and height being occupied, but still map is blank.  Do you have some samples where you tested this with latest build? I appreciate your help

@vvavepacket: can you reproduce this with a demo repo or codesandbox?

@vinayakkulkarni here you go https://github.com/woshikie/mapbox-bug-demo

@woshikie & @vvavepacket: I've fixed some minor issues, released a new version & have done a demo on codesandbox.

I have updated my repo with the latest package and this is the output from my npm run build.
dist.zip
You can see for yourself that the map is not showing. It is showing, however, on debug builds, which we can see on CodeSandbox or npn run serve
If you don't have a development web server to run the files, you can use python as a web server.
Assuming you are using python 3 and you extracted the zip file to your current working directory:
python -m http.server --directory dist
You should be able to reach your python web server on http://localhost:8000 (by default)

@woshikie  @vinayakkulkarni
Thanks for the update, unfortunately the issue still stands...
I can confirm that release build is not working. I deployed it to my local web server and it doesn't work. I inspected the layout and it seems that the css files are not being loaded properly, as I can see the classes are not attached to the mapbox divs.


Should we have a reference implementation?

.... whose only job is to be a reference implementation?

I agree with Mike. Instead of an RI, we will have test data and a coordinated release schedule with major implementors.


Add MLE estimation of Markov chains

This is already accomplished on the Python side in https://github.com/QuantEcon/QuantEcon.py/pull/658
An ongoing discussion for the Julia side is here:

https://discourse.quantecon.org/t/estimate-markovchain-from-data-using-ml/239
https://discourse.quantecon.org/t/estimating-markov-chain-probabilities-in-julia-using-proportions/981

@msilva913 proposes
function estimate_markov(X::Vector, nstates::Int64)
    P = zeros(nstates, nstates)
    n = length(X) - 1
    for t = 1:n
        # add one each count is observed
        P[X[t], X[t+1]] = P[X[t], X[t+1]] + 1
    end
    for i = 1:nstates
        # divide by total number of counts
        P[i, :] .= P[i, :]/sum(P[i, :])
    end
    return P
end

Note that this will lead to division by zero errors for states that are never visited.  The Python code handles this by dropping such states.

Is it estimate_mc_discrete (#161)?


Re-write LocalStateQuery client logic to eliminate acquire failures

Issue Number
ADP-647, #2320

Overview

[x] Allow send-ing a composition of queries against a single acquired point, not just one.
[x] Makes acquire failures practically impossible
[x] Re-add multi-era support with reduced boilerplate
[x] Some polish still needed
[x] Re-add tracing of query times (less granular than before, but done)

Comments
Pretty sure this is

eliminating acquire failures
the right direction

But also

Might introduce a new set of problems

Failures
I have run tests locally a lot on this branch. One new failure I occasionally see is
  src/Test/Integration/Framework/DSL.hs:1797:7:
  1) API Specifications, SHELLEY_STAKE_POOLS, STAKE_POOLS_JOIN_01rewards - Can join a pool, earn rewards and collect them
       expected a successful response but got an error: DecodeFailure "{\"code\":\"created_invalid_transaction\",\"message\":\"That's embarrassing. It looks like I've created an invalid transaction that could not be parsed by the node. Here's an error message that may help with debugging: HardForkApplyTxErrFromEra S (S (S (Z (WrapApplyTxErr {unwrapApplyTxErr = ApplyTxError [LedgerFailure (DelegsFailure (WithdrawalsNotInRewardsDELEGS (fromList [(RewardAcnt {getRwdNetwork = Mainnet, getRwdCred = KeyHashObj (KeyHash \\\"9c0ff007dd21bbf24960bd12ae4009efb8cad076228ef1a54c7b5dbe\\\")},Coin<PHONE_NUMBER>)])))]}))))\"}"
       While verifying (Status {statusCode = 500, statusMessage = "Internal Server Error"},Left (DecodeFailure "{\"code\":\"created_invalid_transaction\",\"message\":\"That's embarrassing. It looks like I've created an invalid transaction that could not be parsed by the node. Here's an error message that may help with debugging: HardForkApplyTxErrFromEra S (S (S (Z (WrapApplyTxErr {unwrapApplyTxErr = ApplyTxError [LedgerFailure (DelegsFailure (WithdrawalsNotInRewardsDELEGS (fromList [(RewardAcnt {getRwdNetwork = Mainnet, getRwdCred = KeyHashObj (KeyHash \\\"9c0ff007dd21bbf24960bd12ae4009efb8cad076228ef1a54c7b5dbe\\\")},Coin<PHONE_NUMBER>)])))]}))))\"}"))

  To rerun use: --match "/API Specifications/SHELLEY_STAKE_POOLS/STAKE_POOLS_JOIN_01rewards - Can join a pool, earn rewards and collect them/"

Important part is WithdrawalsNotInRewardsDELEGS. So seems we are not aware of the rewards having already been spent. Maybe this PR makes the rewards slower to update, somehow, not sure.
Edit: digging through my notes, I have seen this failure on another branch — once. I think this PR makes it more likely to occur, but not be inherently related, then.

When running locally, I'm consistently running into this new failure:
  src/Test/Integration/Scenario/API/Shelley/StakePools.hs:541:29:
  5) API Specifications, SHELLEY_STAKE_POOLS, STAKE_POOLS_JOIN_01 - Can rejoin another stakepool
       While verifying (Status {statusCode = 200, statusMessage = "OK"},Right (ApiWallet {id = ApiT {getApiT = WalletId {getWalletId = 4139b85eb0c5b1408f4f84e8570818298efde7ea}}, addressPoolGap = ApiT {getApiT = AddressPoolGap {getAddressPoolGap = 20}}, balance = ApiT {getApiT = WalletBalance {available = Quantity {getQuantity =<PHONE_NUMBER>00}, total = Quantity {getQuantity =<PHONE_NUMBER>00}, reward = Quantity {getQuantity = 0}}}, delegation = ApiWalletDelegation {active = ApiWalletDelegationNext {status = NotDelegating, target = Nothing, changesAt = Nothing}, next = [ApiWalletDelegationNext {status = Delegating, target = Just (ApiT {getApiT = PoolId {getPoolId = "\187\DC1L\179}u\250\ENQ&\ETX(\194\&5\163\218\226\149\163=\v\166t\165\235\RS>V\142"}}), changesAt = Just (ApiEpochInfo {epochNumber = ApiT {getApiT = EpochNo {unEpochNo = 40}}, epochStartTime = 2021-01-14 14:28:09 UTC})}]}, name = ApiT {getApiT = WalletName {getWalletName = "Fauce
t Wallet"}}, passphrase = Just (ApiWalletPassphraseInfo {lastUpdatedAt = 2021-01-14 14:27:37.265958 UTC}), state = ApiT {getApiT = Ready}, tip = ApiBlockReference {absoluteSlotNumber = ApiT {getApiT = SlotNo 1930}, slotId = ApiSlotId {epochNumber = ApiT {getApiT = EpochNo {unEpochNo = 38}}, slotNumber = ApiT {getApiT = SlotInEpoch {unSlotInEpoch = 30}}}, time = 2021-01-14 14:27:55 UTC, block = ApiBlockInfo {height = Quantity {getQuantity = 980}}}}))
       expected: Just (ApiT {getApiT = EpochNo {unEpochNo = 39}})
        but got: Just (ApiT {getApiT = EpochNo {unEpochNo = 40}})

which I think might be due to queuing problems.

When running locally, I'm consistently running into this new failure:
  src/Test/Integration/Scenario/API/Shelley/StakePools.hs:541:29:
  5) API Specifications, SHELLEY_STAKE_POOLS, STAKE_POOLS_JOIN_01 - Can rejoin another stakepool
       While verifying (Status {statusCode = 200, statusMessage = "OK"},Right (ApiWallet {id = ApiT {getApiT = WalletId {getWalletId = 4139b85eb0c5b1408f4f84e8570818298efde7ea}}, addressPoolGap = ApiT {getApiT = AddressPoolGap {getAddressPoolGap = 20}}, balance = ApiT {getApiT = WalletBalance {available = Quantity {getQuantity =<PHONE_NUMBER>00}, total = Quantity {getQuantity =<PHONE_NUMBER>00}, reward = Quantity {getQuantity = 0}}}, delegation = ApiWalletDelegation {active = ApiWalletDelegationNext {status = NotDelegating, target = Nothing, changesAt = Nothing}, next = [ApiWalletDelegationNext {status = Delegating, target = Just (ApiT {getApiT = PoolId {getPoolId = "\187\DC1L\179}u\250\ENQ&\ETX(\194\&5\163\218\226\149\163=\v\166t\165\235\RS>V\142"}}), changesAt = Just (ApiEpochInfo {epochNumber = ApiT {getApiT = EpochNo {unEpochNo = 40}}, epochStartTime = 2021-01-14 14:28:09 UTC})}]}, name = ApiT {getApiT = WalletName {getWalletName = "Fauce
t Wallet"}}, passphrase = Just (ApiWalletPassphraseInfo {lastUpdatedAt = 2021-01-14 14:27:37.265958 UTC}), state = ApiT {getApiT = Ready}, tip = ApiBlockReference {absoluteSlotNumber = ApiT {getApiT = SlotNo 1930}, slotId = ApiSlotId {epochNumber = ApiT {getApiT = EpochNo {unEpochNo = 38}}, slotNumber = ApiT {getApiT = SlotInEpoch {unSlotInEpoch = 30}}}, time = 2021-01-14 14:27:55 UTC, block = ApiBlockInfo {height = Quantity {getQuantity = 980}}}}))
       expected: Just (ApiT {getApiT = EpochNo {unEpochNo = 39}})
        but got: Just (ApiT {getApiT = EpochNo {unEpochNo = 40}})

which I think might be due to queuing problems.

bors try

bors try

bors try

bors try

bors try

bors try

I like that this PR

has generalised the query types across eras.
has eliminated the possibility of acquire failures by removing the Point argument from CmdQueryLocalState (as suggested by @KTorz on ADP-647).

But otherwise I am finding the changes confusing, and have some suggestions to simplify:

To keep the LocalState current, have localStateQuery follow the tip variable via a skip queue, ReAcquiring whenever the tip changes.

You have noted the awkwardness of passing AnyCardanoEra around. I agree - let's remove it. We can just run the query for all eras, starting at Mary, and stopping when one succeeds. Then we don't need to use the result of the era query in subsequent queries.

Now, if queries can no longer fail, why do we need Monad? If queries no longer have a Point argument, then they can no longer change the state. They have no effects. The purpose of Monad is to do different things based on the results of previous actions - that's no longer required.
But we do want to run multiple queries against the same LocalState in sequence and collect their results. So we need Applicative only.

I like that this PR

has generalised the query types across eras.
has eliminated the possibility of acquire failures by removing the Point argument from CmdQueryLocalState (as suggested by @KTorz on ADP-647).

But otherwise I am finding the changes confusing, and have some suggestions to simplify:

To keep the LocalState current, have localStateQuery follow the tip variable via a skip queue, ReAcquiring whenever the tip changes.

You have noted the awkwardness of passing AnyCardanoEra around. I agree - let's remove it. We can just run the query for all eras, starting at Mary, and stopping when one succeeds. Then we don't need to use the result of the era query in subsequent queries.

Now, if queries can no longer fail, why do we need Monad? If queries no longer have a Point argument, then they can no longer change the state. They have no effects. The purpose of Monad is to do different things based on the results of previous actions - that's no longer required.
But we do want to run multiple queries against the same LocalState in sequence and collect their results. So we need Applicative only.

To keep the LocalState current, have localStateQuery follow the tip variable via a skip queue, ReAcquiring whenever the tip changes.

I briefly tried doing something like that. But we cannot run monadic actions in the acquired state, before deciding what query to send. So it seems that they really want us to idle only in the idle state.

We can just run the query for all eras, starting at Mary, and stopping when one succeeds. Then we don't need to use the result of the era query in subsequent queries.

There's another option: QueryHardFork GetCurrentEra. This seems much neater to me than trying all eras for every query.
I am giving it a shot. I think the code will turn out cleaner, and also fix a on-startup-blocking problem I discovered yesterday with the current approach of getting the era from the tip sync client.

if queries can no longer fail, why do we need Monad?

As you said (although you argued for its removal):

[..] result of the era query in subsequent queries.

Besides the currentEra >>= \case use case, I hope the flexibility might be useful in the future as the differences between the eras grow larger.
I don't see how restricting ourselves to Applicative would make things better.

To keep the LocalState current, have localStateQuery follow the tip variable via a skip queue, ReAcquiring whenever the tip changes.

I briefly tried doing something like that. But we cannot run monadic actions in the acquired state, before deciding what query to send. So it seems that they really want us to idle only in the idle state.

We can just run the query for all eras, starting at Mary, and stopping when one succeeds. Then we don't need to use the result of the era query in subsequent queries.

There's another option: QueryHardFork GetCurrentEra. This seems much neater to me than trying all eras for every query.
I am giving it a shot. I think the code will turn out cleaner, and also fix a on-startup-blocking problem I discovered yesterday with the current approach of getting the era from the tip sync client.

if queries can no longer fail, why do we need Monad?

As you said (although you argued for its removal):

[..] result of the era query in subsequent queries.

Besides the currentEra >>= \case use case, I hope the flexibility might be useful in the future as the differences between the eras grow larger.
I don't see how restricting ourselves to Applicative would make things better.

before deciding what query to send. So it seems that they really want us to idle only in the idle state.

That said, we could probable circumvent that by sending a Era query, and waiting for the next query in the response action…

before deciding what query to send. So it seems that they really want us to idle only in the idle state.

That said, we could probable circumvent that by sending a Era query, and waiting for the next query in the response action…

Slightly concerned about the rare WithdrawalsNotInRewardsDELEGS failures, but not sure it's directly caused by this PR, and think it's still worth merging.
bors r+

Slightly concerned about the rare WithdrawalsNotInRewardsDELEGS failures, but not sure it's directly caused by this PR, and think it's still worth merging.
bors r+

bors try

bors try

bors r+

bors r+


refactor: add turborepo, pnpm and tsup

This PR introduces the replacement of Lerna and NPM (closes #236) with Turborepo, PNPM and adds tsup for build. Also, this pull request adds some general improvements listed bellow:
Tasks

[x] Add Turborepo as monorepo manager
[x] Change to PNPM instead of NPM
[x] Use imports directly with publishConfig setting (don't need build --watch tasks)
[x] Use tsup for build using esm | cjs | iife formats
[x] Change Github actions to use PNPM
[x] Use npm-run-all in order to run docker services and test in serial
[x] Add docker services commands inside a Makefile (529a8d51)
[x] Tests Github Actions

👉🏻 And after some changes I struggle with other issues (that's already solved too):

[x] Create an index.ts entry point for wordlists and merkle-shared packages in order to follow monorepo "pattern"
[x] Exclude node_modules and dist files on tsconfig.base.json

🤩 Wins
Now we have some new benefits because of the new toolchain:
✅ A very good cache system on the build pipeline (thanks to Turborepo)
✅ So much faster package installations (thanks to PNPM)
✅ Consume packages internally without watch builds
✅ Better package.json definitions with specific builds for CommonJS and ESM modules (thanks to tsup)
✅ Since we're using tsup and pnpm we don't need references and composite: true on tsconfig files anymore
Development Breaking changes

The run-services command was renamed to services:run
We have now a ci:test command that runs services:run, test and services:clean

🔗 References
→ Why use PNPM? https://pnpm.io/motivation
→ Why use Turborepo? https://turborepo.org/docs#why-turborepo

→ About the Github Actions: I'm using Act locally in order to run the actions, but can't run yet the publishing-related actions. The build action is running, but it's getting stuck in the test step (because I don't have a secret.GITHUB_TOKEN configured locally)
→ About publishing: One possible way we have to test publishing using another tools without messing around with our versions is making something like that: https://developer.entando.com/v6.1/tutorials/ecr/how-to-create-local-npm-registry.html#start-local-nexus-as-a-docker-container
I'll try here locally!

Since we already with a very big pul request, I'll let this pull request using Lerna just for publishing and create another one in other to replace this part of the system on it.

How would we publish on npm with the new setup?

I won't be able to fully review until tomorrow but I have some qs:
1- Does pnpm support something like Yarn's "Offline Cache"? https://yarnpkg.com/features/offline-cache
I think it would be great if we could commit all of our deps to the repo (like Yarn does in their repo) so we avoid left-pad-like issues and also easily track dep changes.

2- How hard would it be to move to Yarn 2/3 if we decided to in the future? How hard are we depending on pnpm?

I won't be able to fully review until tomorrow but I have some qs:
1- Does pnpm support something like Yarn's "Offline Cache"? https://yarnpkg.com/features/offline-cache
I think it would be great if we could commit all of our deps to the repo (like Yarn does in their repo) so we avoid left-pad-like issues and also easily track dep changes.
2- How hard would it be to move to Yarn 2/3 if we decided to in the future? How hard are we depending on pnpm?

About offline support @AlicanC, PNPM has already https://pnpm.io/cli/install#--offline

The only thing we're depending on PNPM direct import, to do that we're using a main field on package.json pointing directly to the index.ts file and adding a publishConfig appointing to the compiled files (as you can see here). I think that don't have anything anymore coupling us with it. So, a change in the future for any other package manager should be easy.

How would we publish on npm with the new setup?
I've been doing
lerna version --conventional-commits --no-push
npx lerna publish from-git

manually for versioned releases

Yes @QuinnLee, I don't change anything related to lerna publish mainly because the pull request is already too big, I'm working on another one just to see about this. So, we keep the same flow for publishing using Lerna.
For now, I'm checking Rush for publishing, and in fact, what I'm seeing is a lot of very good features.

How can I work on SwaySwap and fuels-ts at the same time using this setup? Meaning:

I have two VSCode windows open: fuels-ts and swayswap/client
I add a new API on fuels-ts
I save
I go to swayswap window and just use the API

I used to do this by doing yarn lerna exec -- yarn link on fuels-ts and yarn link fuels on swayswap, but I can't install with Yarn since we changed to workspace:* versions that Yarn doesn't seem to support.

I also used to run npx tsc --build --watch at fuels-ts root to watch all packages and build them on changes. This doesn't seem to work now. (Probably because we removed the references setup.) How can I achieve the same?


Extended RelationType with Types from SCCM 1906

Added the following Types (as per CI_RelationTypes table in database)
7 Self
8 Reference
9 AppToDTReference
10 AppDependence
11 Intention
12 Platform
13 GlobalConditionReference
15 ApplicationSuperSeded
16 ApplicationType
17 ApplicationHost
18 ApplicationInstaller
19 SupersedOrDependent
20 VirtualEnvironmentReference
21 AppDCMReference
22 DeploymentTypeToPolicyTemplateReference
23 CIInheritanceRelation

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

@TheToor : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off


Adding Optional Argument Type Replacement

In relation to the Wundergraph issue found here: https://github.com/wundergraph/wundergraph/issues/284, we require the ability to provide an override on a GraphQL argument's type. This PR adds in this functionality.
@jensneuse, let me know if you're happy with the naming conventions.

Merged with few changes in #456
Thank you for the contribution!


test: migrate reqresp unit tests to vitest

Motivation
Consolidate the testing frameworks and migrate to vitest.
Description
Migrate reqresp unit tests to vitest.
Steps to test or reproduce

Run all tests

@wemeetagain Please re-review this PR. I went through the changes again and made sure only the absolute necessary changes are included from the src.

:tada: This PR is included in v1.14.0 :tada:


Update Chinese translation

Ref: #2847
Have a nice day :)

coverage: 60.677%. remained the same
when pulling 87a60aad74115c7eb6b7dd172dffba700373c848 on CookiePieWw:zh-trans
into 86f84e5fe42cc80458e220f141a604ceed03b4a1 on newsboat:master.


Improve getting started section in landing page of github for new users

This section could use a bit more material to get new users up and running more quickly.

@hoytak - what page are you referring to? The top level README? Also, what additional content do you think we should add?


Add input reader repository

#349

When running the cartesi-rollups-node for a second time using the same db instance , This error occurs :
2024-06-25T23:07:57.250 ERR Unable to run migrations error="no change"

This error should be treated differently, as it will happen on a node restart

When trying to Setup the database with "actual" values, like deployment_block = 0x10 I am getting a fk error :
"unable to setup database state: ERROR: insert or update on table \"node_state\" violates foreign key constraint \"node_state_current_epoch_fkey\" (SQLSTATE 23503)\n"

I seems it is expecting all epochs from block zero til deployment block to be at the database

When trying to Setup the database with "actual" values, like deployment_block = 0x10 I am getting a fk error :
"unable to setup database state: ERROR: insert or update on table \"node_state\" violates foreign key constraint \"node_state_current_epoch_fkey\" (SQLSTATE 23503)\n"

I seems it is expecting all epochs from block zero til deployment block to be at the database

This error is due to the foreign key of the epoch not being followed. When setting up the database, you have to be sure the first block of the epoch and the current epoch (which on the setup is the deployment block) is the same.
This will change for the next update of the database for the multi-dapp.

Got another error while testing.
Every time the node is started, the Repository Setup function is always adding a new config row, even if it is a node restart ( when the same Postgres instance is the same ) . It should be checked and then just logged

Also just a comment:
Using go test coverage during tests, I checked that the tests are not exercising , at the InsetOutput method the control flow when a output is not verifiable

This PR is deprecated with the release of the multi-dapp repository #511.


how to reload the jsgrid outside

there are three controls in my page.  a tree ,jsgrid1,jsgrid2,when i click tree node then jsgrid1 load data ,click row of jsgrid1 then jsgrid2 load data. in general there are two relations : tree and jsgrid1.jsgrid1 and jsgrid2.i wanna konw when i click tree node how to reload the jsgrid2

If you'd like to reload data call loadData method on the grid $("#grid").jsGrid("loadData");.


cl-basic.owl has no annotations at all

I just noticed this when updating GO's CL import. The cl-basic OWL format has lost all labels, definitions, etc.

@balhoff @dosumis is working on this! Let me know if you need any help here David!

FIxed in latest release.


proposal: cmd/vet: add declarative support for identifying functions for printf check

Goals
Add support for printf (and errorf) for function pointers and interfaces:
func Infof(string, any...)
func Errorf(string, any...)

func NewLogger() func(string, any...) {}
func SetLogger(func(string, any...))

type Logger interface {
  Infof(string, any...)
}

var infof func(string, any...)

Why change is needed
Currently the implementation does work by (a) having either functions mapping a specified list (which can be provided to vet via commandline argument) or by (b) calling the fmt.Printf or fmt.Print function.
a) Providing a specific function mapping does not work with modules that are not imported within the source file. Also there is no config file which could be use provide this list project-wide or inherit it from imported modules. For the full mapping list, see here.
b) Calling the fmt.Printf or fmt.Print function directly does not work for arguments, return values, and interfaces.
c) Also IDEs like VS Code and Goland add support for vet-based rules. Adding this feature to vet will likely also trigger changes in the IDE support.
For more details on the implementation, see here.
Solutions
There are different ways to solve this issue. I would like to brainstorm different ways, so please feel free to add proposals in the comments.
I) Named Arguments and Return Values
Use named arguments and return values by either using printfFormat or errorfFormat as argument name:
func Infof(printfFormat string, any...)
func Errorf(errorfFormat string, any...)

func NewLogger() func(printfFormat string, any...) {}
func SetLogger(func(printfFormat string, any...))

type Logger interface {
  Infof(printfFormat string, any...)
}

var infof func(printfFormat string, any...)

Pros: Easy to use, unlikely to cause side effects with existing code, clean upgrade path for existing modules, does not increase required Go version
Cons: Bloated code, argument names where non should be required
II) Add new fmt.FormatString and errors.FormatString
Add new fmt.FormatString and errors.FormatString types (which point to string) to declare the functions/methods as formatted:
func Infof(fmt.FormatString, any...)
func Errorf(errors.FormatString, any...)

func NewLogger() func(fmt.FormatString, any...) {}
func SetLogger(func(fmt.FormatString, any...))

type Logger interface {
  Infof(fmt.FormatString, any...)
}

var infof func(fmt.FormatString, any...)

Pros: Safe from side effects with existing code
Cons: Impact on reflection, requires build tag on upgrading code, requires addition to core packages, requires upgrade to higer Go version
III) Add declaration list to go.mod
Allow additional printf-like functions to be declared within the go.mod file and have those settings inherited from imported modules. Package names are resolved relative to the module root.
module hello/world

go 1.21

vet printf logging.Infof
vet errorf logging.Errorf

vet printf logging.InfofFunc

Examples:
package logging

func Infof(string, any...)
func Errorf(string, any...)

type InfofFunc func(string, any...)

func NewLogger() InfofFunc {}
func SetLogger(InfofFunc)

type Logger interface {
  Infof(string, any...)
}

var infof InfofFunc

Pros: no side effects on existing code
Cons: requires upgrade to higher Go version
IV) Add new go.vet config file
Allow additional printf-like functions to be declared within a new go.vet file and have those settings inherited from imported modules. Package names are resolved relative to the module root. (Similar to III but with less issues.)
The file should always be backward compatible and unknown and illegal entries should be ignored with a warning.
printf (
  logging.Infof
  logging.InfofFunc
)

errorf logging.Errorf

Pros: no side effects on existing code, clean upgrade path for existing modules, does not increase required Go version, could be used for additional go tool vet settings
Cons: new file added to Go universe
Please let me know what you think.
Best Regards, Felix

I just want to note that I am aware that for Go v2 other proposals are available, like https://github.com/golang/go/issues/50554 . The focus of this proposal is Go v1.

CC @golang/tools-team

This is closely related to https://github.com/golang/go/issues/52445. (A duplicate in spirit if not the same collection of suggestions.)

Perhaps this issue and the linked one could both be solved by letting go vet recognize pragmas of the form
// govet: printf
// govet: stdmethod
To turn on the matching vet check for the function defined just after this pragma?

There are already simple ways of marking a function as a printf wrapper when the analysis cannot infer this:
func f(format string args ...any) {
     if false {
        _ = fmt.Sprintf(format, args) // causes vet to treat f as a printf wrapper
     }
     ...rest of function body...
}

and to do the reverse, to hide from vet the fact that a function should not be treated like a printf wrapper even though it does delegate to printf:
func f(format string, args ...any) {
    format += "" // hide from vet that this function is a printf wrapper
    ...rest of function body...
}

Since this proposal is about the specific case of printf, I think we should reject it. There are other analyzers for which the idea of a configuration file or annotation mechanism is more compelling, but this proposal is not about them.

I agree that this printf check issue alone is not strong enough to justify introduction of new configuration mechanism.
I want to note that Alan's suggestion https://github.com/golang/go/issues/58340#issuecomment-1419144620 is clever, but it is hard to discover. Can we eventually provide a method or handy utility to do this? One may still argue that this pollutes code as much as annotations would do.
And It looks to me this workaround depends a lot on the current implementation details of the printf check. If this is the recommended official way, we need to make it future-proof (e.g. add testing in the printf check and ensure we don't accidentally break it while optimizing or tuning the check).

hard to discover

The first of my two code examples above is documented:
$ go help vet
usage: go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]

Vet runs the Go vet command on the packages named by the import paths.
...
For details of a specific checker such as 'printf', see 'go tool vet help printf'.

$ go tool vet help printf
...
A function that wants to avail itself of printf checking but is not
found by this analyzer's heuristics (for example, due to use of
dynamic calls) can insert a bogus call:
if false {
	_ = fmt.Sprintf(format, args...) // enable printf checking
}

...
There's also a web version here:
https://github.com/golang/tools/blob/master/gopls/doc/analyzers.md#printf

We could add the other example here if that would help, but I think it's pretty rarely wanted.

I don't think it is currently clear what the goal of the proposal is (or what the problem is). I am guessing that all four suggestions are trying to do the equivalent of adding a new entry to x/tools/go/analysis/passes/printf.isPrint. Can you explain in more detail which functions you intend on being able to annotate, where you would like the annotations to live, and what the annotations are supposed to mean?

The printf case is a weak justification for analysis annotations because it is already well served by simple and unobjectionable code changes that are (at least partly) documented by the analyzer. Other analyzers may provide more a compelling motive for a richer annotation or configuration mechanism. I suggest we either broaden the proposal to exampletypical patterns across a range of analyzers, or reject the proposal.

Re-reading this thread I realized my first comment was addressing only a narrow part of the original proposal, which is more broadly about how to indicate in the type of a function that it is a printf wrapper, so that dynamic calls to func values and interface methods are checked. Apologies for not reading more carefully.
Let's reconsider the four ideas in the first note:

Named arguments and return values (e.g. func(printfFormat string, any...))
Add new fmt.FormatString and errors.FormatString (e.g. func(fmt.FormatString, any...))
Add declaration list to go.mod
Add new go.vet config file

In reverse order, my reactions are:

that (4), a vet config file,  is the wrong place to write this information. It's a property of a particular declaration in the source, so the annotation (whatever form it takes) belongs in the source, where it can be easily found, and can evolve with the code. Generally I don't think any of the analysis flags for indicating sets of special functions have really enjoyed much success, and they represent an approach that predates the idea of modular analysis using facts to record lemmas (or types) discovered from analyzing previous units.

that (3), the go.mod file, is also the wrong place for this information, since it's not really related to modules.

that (2), a format string type, is better, but we don't really want to have to change the type of a function to enable vet checking, as this would break existing code, and even for new code it's inconvenient and surprising. However, one could define fmt.FormatString as a type alias for string with added intent. That would of course require a change to the standard library. A type alias for string isn't distinguishable from string in the type-checker's representation, so the information would not be available to other packages through the type system, but I think it would be possible for the printf checker to export an analysis fact about the parameter variable that would then be accessible from other packages. Still, users would probably prefer to read string in the source than a type alias.

that (1), a format parameter name, is even better, as it doesn't require changes to the type, or to the standard library, but only to the analyzer.

For completeness, let's not forget the implicit zero approach, which is some comment-based syntax as @beoran (and many others in the past) have suggested. We may eventually need a more powerful and general notation to express analysis facts in the source code, but I'd rather not design it until we have seen a handful of analyzers that need it.
I think approach 1 is worth prototyping in the printf checker.

IIUC the annotations that are being requested are 2 slightly different cases:

This function in my package should belong to x/tools/go/analysis/passes/printf.isPrint.
This function is another package I imported should belong to x/tools/go/analysis/passes/printf.isPrint.

@adonovan We should be able to solve both with approach (1) in https://github.com/golang/go/issues/58340#issuecomment-1482797981.
We can annotate functions using a special argument name like this:
var _ func(printfFormat string, any...) = MyPrintf                        // same package function
var _ func(printfFormat string, any...) = MyLogger.MyPrintf      // same package method
var _ func(printfFormat string, any...) = logger.Printf                 // imported function
var _ func(printfFormat string, any...) = (logger.Logger).Printf // imported method

This is reusing the parameter name from the func type to pick up the annotation. I am not sure if the sketch https://go.dev/cl/479175 supports it.
This annotation only needs to be done once per package. We can also forward added isPrint annotations for reverse dependencies via Facts. So the # of annotations could be as low as the # of leaf packages in a module. Scaling arguments are all theoretical though as the number of printf wrappers one needs to label in order to do proper printf inference is likely very small. Given that this is not a bigger pain point, my hunch is the number of annotations in the wild would be quite small. So I think (1) would be a reasonable solution solution for printf.
A limitation I can see from a user's perspective is that this does not allow for the following: MyPackage imports OtherPackage which imports YetAnotherPackage. We cannot influence isPrint inference during OtherPackage by adding a label for YetAnotherPackage.Printf in MyPackage, i.e. "injecting" annotations for analysis. A config file can do this by being a root dependency. IMO I think it is okay for MyPackage to just do more labeling for all of the inferred isPrint functions it is potentially missing from OtherPackage. So IMO this is not a compelling case for config files yet.
There is a minor implementation issue that an added isPrint annotation from another package should be a package Fact instead of an object Fact.

On the question of "injecting" annotations into a lower package, the answer has to be a clear no: the framework allows information to flow only upwards, from p's imports to p itself. I'm not sure it's practical even to support the restricted version of injection in which, given A->B->C, package B expresses an retroactive annotation on a declaration in C so that A benefits, because, as you say, object facts can only be exported by the declaring package. If one of your dependencies forgot to add an annotation, your best choice remains to send them a PR.
On the question of the notation of annotations, one approach we should consider is for each analyzer to provide a subpackage of declarations with no run-time effect--just types, constants, and empty function bodies--which the client code imports and uses to express annotations. For example:
import printfannot "golang.org/x/tools/go/analysis/passes/printf/annot"

// (FormatString is defined as a type alias for string, with intentionality.)
func MyPrintf(format printfannot.FormatString, args ...any) { ... }

// or perhaps:

var _() {
    // The existence of this call tells the printf checker to export a fact about MyPrintf.
    printfannot.Check(MyPrintf)
    ...
}

Using Go syntax for annotations has a number of benefits: unlike comments, they stay up to date as the code evolves, they can be navigated like ordinary references, documentation is instantly available.

I'm not sure it's practical even to support the restricted version of injection in which, given A->B->C, package B expresses a retroactive annotation on a declaration in C so that A benefits, because, as you say, object facts can only be exported by the declaring package.

You can do this with package facts where {C.Printf} is added as a package fact on B. The major downside is that A's package facts are expected to be a superset of B's package facts (for A's reverse dependencies). This might all be too much for too little benefit for this checker.

var _() {
// The existence of this call tells the printf checker to export a fact about MyPrintf.
printfannot.Check(MyPrintf)
...
}

I've been thinking about this kind of annotations for a while. I definitely like these as a high level idea. It feels like we just need more use cases before pursuing this though (guarded by checking would be a good candidate). But this is kinda getting off topic.
For the printf checker though, maybe it is good enough to using the name of the first function argument? That was my understanding of (1) https://github.com/golang/go/issues/58340#issuecomment-1482797981. The name might be a magic constant, but we do accept magic constants for things like //go: directives/comments.

You can do this with package facts where {C.Printf} is added as a package fact on B. The major downside is that A's package facts are expected to be a superset of B's package facts (for A's reverse dependencies). This might all be too much for too little benefit for this checker.

I agree. At the risk of stating the obvious, package facts are for facts about packages, and objects facts are for objects. (The superset property is not essential, BTW. "Package P has package doc comment C" would be a totally valid package fact.)

I definitely like these as a high level idea. It feels like we just need more use cases before pursuing this though (guarded by checking would be a good candidate).

Glad we're on the same page wrt Go syntax for annotations; and, yes, there are many details still to work out.

For the printf checker though, maybe it is good enough to using the name of the first function argument?

I'd be happy with that approach (specifically: bullet point 1, sketched in CL 479175, not the var _ func... = MyPrintf approach in the later note). It seems unobtrusive enough that if we later add a more general notion of annotations we won't regret this step.


Add 'Zettelkasten.app' as zettelkasten cask

Didn’t you get a PR template when submitting this? Because it has things you need to complete that would fix the erros this has. Please try again.

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


DeviceId on Android

The current deviceId is a hardware dependant deviceId. This is incorrect for 2 reasons:

as explained here:
http://stackoverflow.com/questions/16869482/how-to-get-unique-device-hardware-id-in-android

it requires a dangerous right at install time (read phone number of callers)

Correct code as stated in the stackoverflow answer should be:
var androidId = Android.Provider.Settings.Secure.GetString(Context.ContentResolver,
Secure.AndroidId);

This is a bit opinionated of a request.  When I originally wrote this library, it was the imei that I was after.  I'll look into making this configurable in a future release.


Build breaks after cloning class and not changing attributes

The issue, when cloning a class, the output DVR reference of the object attributes does not change to the new class. This has no influence when running your code in the Development environment, but when building LabVIEW cannot save the blockdiagram, and the error is not very easy to understand when you don't know where this is coming from.
As you can see in this image, we've create the class TestFirst.lvclass with a simple property method vi named GetAttribute1.vi and after that we cloned the class as TestSecond.lvclass. when you open the GetAttribute1.vi of the cloned class and put your mouse cursor over the dvr output of the get_attributes you can see in the context help that the data on this wire is still from the original class.

To remedy this, we've altered the cloneclass.vi of the GDS by searching for the first cluster and dropping the string constant in that cluster. and we've added some applies to just to be sure. I've added a screenshot and the fixed vi, which is made in LV2020. The only thing I changed in this vi is the case you're seeing in the screenshot.

CloneClass.zip

Done


Investigate what would be needed to run our own tile server

The Vector Atlas needs to be able to serve GeoJSON for the outlines of countries in Africa as well as raster layers of maps. We should investigate what we need to do if we were to run our own tile server that serves these items. How much resource does it require to run a tile server and would it work with a low speed connection? There is potentially an acceptance of poorer performance if someone is trying to view maps over a poor connection.
Acceptance Criteria

[ ] Outputs of the investigation are documented here
[ ] New stories from the outputs have been added to the backlog.

I've started looking at possibilities for running a tile server for our maps as well as having layers on top. I've been using tileserver-gl as a docker image and converting our various geojson or geotiff files to the mbtiles format - this seems to be much smaller (it's essentially a self-contained sqlite database) and the tile server generates the png tiles on the fly. I haven't yet worked out if this interfaces with leaflet or not, I would hope so as the tile server provides a standard /{z}/{x}/{y} route.
These are the commands I used:
gdaldem color-relief an_gambiae_map.tif colormap.txt an_gambiae_colorized.tif -alpha
gdal_translate -of MBTiles -ot Byte an_gambiae_colorized.tif an_gambiae_map2.mbtiles
gdaladdo -r nearest an_gambiae_map2.mbtiles 2 4 8 16 32
docker run --rm -it -v $(pwd):/data -p 8080:80 maptiler/tileserver-gl

and it gave the result attached.

original_files.zip
Here's the original tif and the resulting mbtiles files if you want to have a go at running the container (the config will need to be updated to remove the countries-raster.mbtiles file)

Leaflet didn't render the geoJSON that was converted to an mbtiles format because it didn't know how to render vector layers - we need to work out how to either render vector layers or convert to a png layer that leaflet can handle.

After experimenting with OpenLayers I was able to get it to render vector layers easily as well as applying styling to the vector components.
Data was gathered from Natural Earth. Instructions for building the geoJSON from Natural Earth data:

Go to natural earth and look for the layers you want, e.g. https://www.naturalearthdata.com/downloads/10m-physical-vectors/ has the land and ocean maps I used
Download the zip and extract it
From within the folder run ogr2ogr -f GeoJSON oceans.json ne_10m_ocean.shp and it will use the other files in the folder for metadata. (You need to install gdal to have these tools)
Copy all the json files you want in the map in to a single folder
From that folder run tippecanoe -zg -o world.mbtiles --coalesce-densest-as-needed --extend-zooms-if-still-dropping --force *.json to generate the combined mbtiles file
Update the tileserver-gl config to reference this file
This should now come through as different layers in the OpenLayers VectorTileSource and you can tweak the styles based on the name of the layer (note the name of the layer is the name of the geoJSON file that went in)

A knowledge sharing session with the Malaria Atlas Project showed that they were using a similar stack but instead of tileserver-gl they were using geoserver https://geoserver.org/ - the main reason for this is that it provides a much richer interface and integration capabilities with external GIS software. This is possibly too heavy-weight for our requirements but we may need to revisit this decision later. For the moment we will use tileserver-gl as it's lighter weight and still servers both vector and raster data as tiles.
One major difference is that geoserver natively supports caching of tiles rather than rendering them on every request. Depending on performance we may want to look to introduce a proxy cache for the tile server in our reverse proxy https://www.nginx.com/blog/nginx-caching-guide/

New stories raised in #52 , #53 and #54

Reviewed and approved

Closing as complete.


Added Diamond Casino & Resort/1.47 to AltV.Net.Enums.PedModel

Please target dev branch not master for pull request creation.


Theme compile results in entire new folder

PHP Version: -   | Shopware Version: <IP_ADDRESS>  | Affected area / extension: Platform(Default)

Expected behaviour:
Theme:compile should use the same folder as before.
For CacheBuster, it should add a hash of the filecontent.
Actual behaviour:
Theme:compile creates new folder. It adds a cacheBuster onto main JS, but not on the async loaded assets.
This makes caching nonsense, while regularly updating own javascripts.
It could be a feature, but I also need a Ticket number xD
How to reproduce:
theme:compile, see folder changed

[public] Shopware automated response: This issue is linked to the internal issue: NEXT-39156
[created from NEXT-39156, comment 505328]

@tinect for the first problem (theme:compile always creating a new folder) you can use the following config in your z-shopware.yaml
storefront:
    theme:
        theme_path_builder_id: Shopware\Storefront\Theme\MD5ThemePathBuilder

But I also have the problem regarding cache buster of the async assets. I also see this as a main problem, because in our case we need to flush cloudflare completely after deploys, which also flushes image transformations etc. which is super unneccessary :(


Support writing one rule in mutiple lines

For example:
rule
       ::= 'A'
         | 'B'
         | 'C'

This syntax should be supported.
It throw errors now.

To write multi line rules you should use parentheses and avoid the newline after the name of the rule
rule   ::= ( 'A'
           | 'B'
           | 'C' )

Here is an example https://github.com/lys-lang/node-ebnf/blob/7f6df026be606ff0439979d23039a7d3b0547f2c/test/NewLang.spec.ts#L102-L112
It should work

OK, thank you!

Last time that page was updated was in 2016.. https://github.com/menduz/ebnf-highlighter

Last time that page was updated was in 2016.. https://github.com/menduz/ebnf-highlighter

I cloned and built the repo with new version of node-ebnf. It works as expect now.
Thank you!


Improvement of installation instructions

Hi,
I'm performing the review of your submission to JOSS, and have a few concerns that I think need improvement, in this particular case, on the installation instructions.
In general, written installation instructions seem a bit limited and should be improved. Specific areas that should be reviewed are:

I suspect the all instructions are somewhat outdated, not mentioning the simplest installation method using pip install bifacial_radiance, given that bifacial_radiance is available in PyPI and installs all dependencies (except RADIANCE itself, which is clearly stated in STEP 0 - Prerequisites).
Will the software work on all platforms? STEP 2 seems to suggest that it will not, talking about moving to a specific location a .exe file, which is a Windows only file. What does it happen if you use another platform? Is that functionality still available? Will the software work at all? Is there any alternative to those Windows-only tools? It is absolutely fine if bifacial_radiance is a Windows-only software, of course, but if that is the case, it should be clearly stated.
STEP 3 is obscure on what “scene” files are or why they need to be in a separate directory. Probably it will become clearer after improving the Package Overview part.
The Youtube video instructions (good initiative!) are clearly only for Windows, but seem outdated too, for example installing PVlib manually using pip while it is now one of the dependencies listed in “requirements.txt”.

Best wishes,
Diego

Hello @dalonsoa ,
I have updates to the sphinx documentation and the JOSS journal as requested on this and other threads. Am I supposed to wait until all the review process is finished to push this commits/changes or do it now/alongside the comments to start answering those?
Thank you
Silvana

Hi Silvana,
I think the best option will be to open a pull request with the changes, indicating which issues are solved by that PR and how. This way, it is much easier to see the changes compared to the original version. Tag me and @wholmgren as reviewers and when we accept it, that means we are happy with the corrections. Would that work for you?
Best wishes,
Diego

Sounds good! I'll proceed that way. Thank you.

resolved in commits / PR


Subquery support for alert rules

Proposal
Use case. Why is this important?
It is useful in the scenarios where only sending alert to alert manager is not enough it also needs some background information about the alert or to help to decide root cause of the alert.
“Nice to have” is not a good use case. :)
Lets consider a case where we are generating alert for a node under high memory utilization from last 10 minutes. In this case when we send alert manager that this particular node is under high memory utilization in Swarm.
But with this feature in place we can send alert manager extra information like what are the services and their actual memory consumption on that node. In this way the alert manager can send useful information to user which can help him understand that this particular service is consuming more memory on the node.

You can already do this via templating in alert annotations.
It makes more sense to ask questions like this on the prometheus-users mailing list rather than in a GitHub issue. On the mailing list, more people are available to potentially respond to your question, and the whole community can benefit from the answers provided.