Testing routes is undocumented

Feature Request
Is your feature request related to a problem? Please describe.
It would be nice to have an exemple on how to test the routes
Describe the solution you'd like
https://github.com/probot/probot/blob/686232d13dce67ab144efb97413fc60aa9e78cc1/test/index.test.js#L90

I totally agree! We have some larger improvements for the testing docs planned: https://github.com/probot/probot/issues/684, and I'd love to address this as a part of those improvements.
Feel free to open a PR to https://github.com/probot/probot/blob/master/docs/testing.md if you're interested!

would love to.
So IIUC exposing probot.server is not accidental and can be documented as part of the API?

When I run something like this I get  TypeError: Cannot read property 'address' of undefined and a bunch of unhandled promise rejection warnings: (node:65995) UnhandledPromiseRejectionWarning: HttpError: {"message":"A JSON web token could not bedecoded","documentation_url":"https://developer.github.com/v3"}. My actual work on testing my route is here:
https://github.com/bcgov/repo-mountie/blob/fix/monitoring/__tests__/monitor.ts
I think some better docs on how to test would be amazing.

Was there a solution to this PR?

No, I fear the maintainers didn’t have the resources to work on it, we are all volunteering and can only do so much. If you’d like to pick it up yourself, that’d be great.

Understood!
I was able to get the tests described in the comments here working, like:
    test('GET /favicon.ico should return image/x-icon header', async () => {
      await request(probot.server)
        .get('/favicon.ico')
        .expect('Content-Type', 'image/x-icon')
        .expect(200);
    });

so I was trying to understand if the issue is with the way we write code or is it just that documentation needs updating or something else.
https://probot.github.io/docs/testing/ also describes something very similar so I was wondering if there's anything more to this issue.
I can send a doc update PR if that is all there is to it.

Might be that there were some changes without updating the docs, too. If your tests works than let’s document it :) Make sure it works with the latest version in the beta branch. Could you start a PR?

I'm using the latest but not the beta. My tests are here: https://github.com/ewolfe/prlint/blob/feat/probot-app/test/index.test.js
Are there significant changes in beta? If so, then I'll hold off (I can get to it but that'll take some time).


Update mongodb.md

Updated correct end of life date for Mongo 4.4 as per the confirmation we received from Mongo team.

Updated correct end of life date for Mongo 4.4 as per the confirmation we received from Mongo team.

The current rule is to use the start of the month based on information on https://www.mongodb.com/support-policy/lifecycles. I am OK to change this based on the information you provided, but for all releases, not only for 4.4. Could you update other release cycles too ?


Make this available in Maven Central

We try to avoid custom repos as much as possible (company policy)

What's the lowest friction way to get onto Maven Central these days?

The process to publish on MC is absolutely painful :smile:

Is there a shortcut through Bintray/JFrog? We need to move our artifacts over at Snowplow too...

http://blog.bintray.com/2014/02/11/bintray-as-pain-free-gateway-to-maven-central/


Transformations are not clear on documentation

I'm not sure if I'm the only one, but the documentation on transformations is not very clear. I'm not exactly sure how to apply them or where the class is being housed in the assembly. Am I missing something or am I just blind?

Apologies I figured it out. I was just blind and I wasn't following the tutorial correctly. I forgot to install the  package. I had only installed the Xamarin.FFImageLoading.Forms and Xamarin.FFImageLoading.Transformations packages without Xamarin.FFImageLoading package. Thanks for the your hard work guys!

@titonton @daniel-luberda Can this be closed?

@adrianknight89 yes it can. Sorry for the late reply

BTW: anyone can edit wiki (feel free to update it). Cheers.


Make better documentation - Including README.md (Bounty: 2000 SOLO)

Summary
It's important for clients to jump-start and be able to use this library. Therefore it's essential we have good documentation.
This documentation comes from:
npm run doc "Generate HTML API documentation and open it in a browser"
npm run doc:json "Generate API documentation in typedoc JSON format"
README.md should also cover examples and a complete documentation.

See PR #17


[Relay] Fix dataflow_pattern.rewrite() hang if Match in IR

rewrite() quits only if graph stop changing, but ExprMutator
always creates new Match node. This patch fixes this.
@icemelon9 @jroesch @mbrookhart  Please review, thanks

cc @masahi  Could you please review and merge this?

Thanks @lixiaoquan @mbrookhart


Literature pipeline is mis-identifying gastric cancer-associated genes as aging-associated genes ("AGS" confusion)

Describe the bug
A user reported on the Open Targets Community that some gastric cancer genes are coming up as aging-related genes, likely due to a confusion on the term "AGS".
Observed behaviour
Certain genes such as CDH1 are flagged as associated with aging based on literature-mining evidence (text mining score of 0.73). However, the matches are between CDH1 and "AGS". The Community user suggested that the confusion may arise from the term AGs being recognised as "Aging Genes", whereas in this case the text-mining evidence refers to the AGS cell line, which is used to study gastric cancer.
Expected behaviour
Such genes should not be associated with aging. The pipeline should disambiguate between AGs as an abbreviation for Aging Genes, and AGS, the name of a cell line.
To Reproduce
Steps to reproduce the behaviour:

Go to 'https://platform.opentargets.org/evidence/ENSG00000039068/GO_0007568'
Scroll down to the Europe PMC widget
Check the matches for a paper, for example: E-cadherin expression increases cell proliferation by regulating energy metabolism through nuclear factor-κB in AGS cells.
See that the matches are for AGS-cells rather than Aging Genes.

There might be a combination of accidents happening here.

AGS cell line accidentally recognised as a trait or phenotype.
AGE - adenocarcinoma of the gastroesophageal junction confused with (AGE)ING
Stemming of aging -> ag and plurals ag-> ags creating artificial matches

A lot of the issues here could be resolved by improving our disambiguation logic. It's not about getting the exact result in one shot, but learning about the best possible hit from the broader context of the publication

A user has highlighted a similar issue with the TRFC protein (transferrin receptor) being confused with "Tfr cells". This may be due to the fact that Tfr is a synonym of TRFC.
The following paper is therefore not evidence for the association of TRFC and Parkinson disease.

Another issue with Down Syndrome/Dravet Syndrome, where the DS abbreviation is being mis-identified as Dravet Syndrome when the paper is about Down Syndrome.
See: https://platform.opentargets.org/evidence/ENSG00000163703/Orphanet_33069

We are not in a position to improve the NER models at the moment. We made notes that there are some issues there


Merge cli informant and telemetry

We just do telemetry! and it posts both on telemetry endpoints (if any activated) and cherry-picks some data for the cli informant at the same time.

Hmm, why?

@bkchr just an idea
In the view of
#4209, #830
and existing cli notifications
As I see it, there will be same data with the same purpose, prepared and posted for two destinations. This can be generalised, maybe not worth the effort though.

In general sounds good, but I think it should be the other way around. We send the telemetry data when we print the informant.
Filtering the telemetry data sounds false to me. The telemetry is not any structured data. This would require us to parse the data again and print only the stuff we want. I don't see the benefit. Just makes stuff more complicated.

The benefit is to make informant a sort of poor man telemetry client right in the cli, when you don't have anything else
Then also later you can enrich the informant output in a configurable way, it will just start to catch and show more of the telemetry events.
But I understand that it maybe little benefit, so I will keep this issue to myself and think about it while implementing those mentioned metrics

One important thing to note is that the informant is specific to the CLI. Substrate itself is a library and doesn't necessarily have a CLI. The telemetry, however, is always present. I don't really see why they should be coupled.


[hedgedoc] oidc configuration

Helm chart name:
hedgedoc
Describe the solution you'd like:
That there are configuration options for setting up oidc authentication.

I will look into this. Thanks for the request!

I haven't tried this myself, but have you tried setting the environmental variables?


for-each statement is faster than forEach method

See https://dart-review.googlesource.com/c/sdk/+/330983 for context.
It is probably known, and this is why we have the corresponding lint.

It's fairly well known. The lack of overheard of a method call, probably polymorphic if forEach is not inlined, makes for-in usually be faster.
It's not guaranteed. If the loop compilation doesn't recognize the Iterable, and cannot inline the iterator, then it's possible, at least hypothetically, that the forEach can do the iteration more efficiently.

Yeah, I see that the performance is quite different in different cases.
Specifically this code is not important to me at all, I just wanted to see what happens, how much it is not guarantee.
There are surprises.
At least for-each statement is reliably 2x slower in AOT :-)

Code is here
// ignore: unused_import
import 'dart:typed_data';

void main() {
  const repeatCount = 1000;
  final values = Int64List(1000000);
  // final values = List.filled(1000000, 0);
  {
    final timer = Stopwatch()..start();
    for (var i = 0; i < repeatCount; i++) {
      doForEachStatement(values);
    }
    print('doForEachStatement: ${timer.elapsedMilliseconds} ms');
  }
  {
    final timer = Stopwatch()..start();
    for (var i = 0; i < repeatCount; i++) {
      doForEachMethod(values);
    }
    print('doForEachMethod: ${timer.elapsedMilliseconds} ms');
  }
}

int doForEachMethod(List<int> values) {
  var result = 0;
  values.forEach((value) {
    result = (result + value) & 0xFFFF;
  });
  return result;
}

int doForEachStatement(List<int> values) {
  var result = 0;
  for (final value in values) {
    result = (result + value) & 0xFFFF;
  }
  return result;
}

JIT, Int64List, doForEachStatement: 1212 ms
JIT, Int64List, doForEachMethod: 4791 ms
AOT, Int64List, doForEachStatement: 2448 ms
AOT, Int64List, doForEachMethod: 2999 ms
JIT, List<int>, doForEachStatement: 649 ms
JIT, List<int>, doForEachMethod: 4884 ms
AOT, List<int>, doForEachStatement: 1266 ms
AOT, List<int>, doForEachMethod: 390 ms

For forEach, it's necessary to say which forEach it is. Each Iterable can have its own forEach, with widely different implementation and performance.
That's one reason it's harder to optimize, you don't always know which function is being called. And when you do, unless it's a platform type, the best the compiler can do is to inline.
For platform types, it's possible to optimize the iteration just as much as for-in. It's probably just not done.

AOT, List, doForEachStatement: 1266 ms
AOT, List, doForEachMethod: 390 ms

In AOT both of these are fully inlined into main and specialised, but in for-in benchmark we have the following piece left over from the list iterator implementation:
148:     v325 <- LoadIndexed(v84, v287 T{int}) T{*?}
...
152:     Branch if StrictCompare:16(===, v325 T{X0??}, v0 T{Null?}) goto (34, 35)
154: B34[target]:20
...
156:     t0 <- AssertAssignable:22(v325 T{X0??}, v290, ' in type cast', instantiator_type_args(v0 T{Null}), function_type_args(v0 T{Null?})) [-9223372036854775808,<PHONE_NUMBER>854775807] T{int}
158:     ParallelMove  goto:28 B36
160: B35[target]:24
162:     ParallelMove  goto:30 B36
164: B36[join]:26 pred(B34, B35) ParallelMove rcx <- C

These are remnants of _current as E - transformed into _current == null ? _current as E : _current.
Compiler failed to eliminate them because it failed to figure out the type of LoadIndexed(...). This in turn happened because CreateArray instruction is missing proper type arguments inference rule. Changing it like this fixes it:
CompileType CreateArrayInstr::ComputeType() const {
  if (type_arguments()->BindsToConstant() &&
      type_arguments()->BoundConstant().IsTypeArguments()) {
    const auto& type_args =
        TypeArguments::Cast(type_arguments()->BoundConstant());
    return CompileType(
        /*can_be_null=*/false, /*can_be_sentinel=*/false, kArrayCid,
        &AbstractType::ZoneHandle(Type::New(
            Class::Handle(
                IsolateGroup::Current()->object_store()->array_class()),
            type_args, Nullability::kNonNullable)));
  }
  return CompileType::FromCid(kArrayCid);
}

After this change both loop become the same, however on my box we still see a performance difference:
doForEachMethod: 558 ms
doForEachStatement: 861 ms

Note that both loops are empty at this point (DCE eliminated loading from array and arithmetic operations because their results are never used).
The code placement (loop alignment) is to blame for the remaining difference between two empty loops. If we align all loop headers in the program the difference disappears:
doForEachMethod: 560 ms
doForEachStatement: 551 ms

In Int64List compiler does not inline _TypedListBase.get iterator. Putting @pragma('vm:prefer-inline') on get iterator gets us to:
doForEachMethod: 3417 ms
doForEachStatement: 552 ms

Final remark: it'd caution against making choices between forEach and for-in if your loop is making any significant amount of work. If it is not just summing elements of the array - the difference between forEach and for-in might not matter.

Thank you for the analysis, it is always so enlightening to me.
Yeah, I know that benchmark results should be viewed with some caution.
FWIW, it was motivated by a change in the actual code where switching to for-in produced nice performance benefits.

FWIW, it was motivated by a change in the actual code where switching to for-in produced nice performance benefits.

The AOT can do a good job in this case, because it's easy to infer the iterable to be always an IntSet. In cases where we cannot infer the concrete type a .forEach() may often be faster in AOT (as 2 non-inlinable .moveNext() / .current calls may be slower than a single closure call) - but of course if one does a lot of work per-element the overhead of iteration doesn't matter.

In the benchmark below forEach() is always slower than for-in.
JIT, always-inline, doForEachStatement, Int64List: 1234 ms
JIT, always-inline, doForEachStatement, Int32List: 996 ms
JIT, always-inline, doForEachMethod, Int64List: 5001 ms
JIT, always-inline, doForEachMethod, Int32List: 4968 ms
AOT, always-inline, doForEachStatement, Int64List: 1377 ms
AOT, always-inline, doForEachStatement, Int32List: 2614 ms
AOT, always-inline, doForEachMethod, Int64List: 3143 ms
AOT, always-inline, doForEachMethod, Int32List: 3136 ms
JIT, never-inline, doForEachStatement, Int64List: 1230 ms
JIT, never-inline, doForEachStatement, Int32List: 991 ms
JIT, never-inline, doForEachMethod, Int64List: 4990 ms
JIT, never-inline, doForEachMethod, Int32List: 4988 ms
AOT, never-inline, doForEachStatement, Int64List: 2611 ms
AOT, never-inline, doForEachStatement, Int32List: 2616 ms
AOT, never-inline, doForEachMethod, Int64List: 3142 ms
AOT, never-inline, doForEachMethod, Int32List: 3151 ms
And I'm really glad that AOT can do good job inlining, in my outside opinion all variants of writing iterations: forEach(), for-in and for-index - if inlinable, over a List with known length, should produce the identical code.

Code is here
// ignore: unused_import
import 'dart:typed_data';

void main() {
  const repeatCount = 1000;
  final values1 = Int64List(1000000);
  final values2 = Int32List(1000000);
  int result = 0;
  {
    final timer = Stopwatch()..start();
    for (var i = 0; i < repeatCount; i++) {
      result = (result + doForEachStatement(values1)) & 0xFF;
    }
    print('doForEachStatement, Int64List: ${timer.elapsedMilliseconds} ms');
  }
  {
    final timer = Stopwatch()..start();
    for (var i = 0; i < repeatCount; i++) {
      result = (result + doForEachStatement(values2)) & 0xFF;
    }
    print('doForEachStatement, Int32List: ${timer.elapsedMilliseconds} ms');
  }
  {
    final timer = Stopwatch()..start();
    for (var i = 0; i < repeatCount; i++) {
      result = (result + doForEachMethod(values1)) & 0xFF;
    }
    print('doForEachMethod, Int64List: ${timer.elapsedMilliseconds} ms');
  }
  {
    final timer = Stopwatch()..start();
    for (var i = 0; i < repeatCount; i++) {
      result = (result + doForEachMethod(values2)) & 0xFF;
    }
    print('doForEachMethod, Int32List: ${timer.elapsedMilliseconds} ms');
  }
  print('result: $result');
}

@pragma('vm:always-inline')
// @pragma('vm:never-inline')
int doForEachMethod(List<int> values) {
  var result = 0;
  values.forEach((value) {
    result = (result + value) & 0xFFFF;
  });
  return result;
}

@pragma('vm:always-inline')
// @pragma('vm:never-inline')
int doForEachStatement(List<int> values) {
  var result = 0;
  for (final value in values) {
    result = (result + value) & 0xFFFF;
  }
  return result;
}


Fixes #30634: Add default divisor for GOMEMLIMIT

Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] If your commit description contains a Fixes: <commit-id> tag, then
please add the commit author[s] as reviewer[s] to this issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.

Fixes: #30634
This PR adds a divisor value for GOMEMLIMIT to prevent Argo CD from flagging the application as out of sync.
Add default divisor for GOMEMLIMIT to satisfy Argo CD diff

Anything that can be done to move this forward?  This unfortunately breaks the ArgoCD ProgressiveSync feature since the daemonset is never able to get synchronized with the expected state.

/test

/test


use gh-hosted svg

externally hosted svgs stopped working. Using the internal location of the same svg.
(additionally linter added empty lines after the headings)

it is now working again, but I think it is still better to use the SVG contained within the repo, to prevent future breaks with externally linked graphics


[ENG][Bug]: Refreshing Wish History with Web Cache provides wish history from a different account and server

Checklist

[X] I have read FAQ page and Exception page in Snap Hutao document, and my issue is not answered
[X] I and tried search feature in Snap Hutao document site, and no associated article
[X] My issue is not a finished issue, and it's not a duplicated issue

Windows Version
22H2
Snap Hutao Version
<IP_ADDRESS>
Device ID
No response
Issue Category
Wish Export
What Happened?
Previously all of my wishes were imported from a UIGF file and accurate. The first time I tried Refreshing with Web Cache in 1.10.1, instead of taking the wish history from my current open account on the Europe server, it took the wish history from a different account (which I have opened the previous day) on the Asia server. I have restarted Genshin since opening the Asia account.
What is expected?
No response
Last Step

[X] I believe the description above is detail enough to allow developers to reproduce the issue

Close the game
In Hutao: delete the web cache in settings page
Launch the game, open the wish history web page
In Hutao: refresh by web cache


Admin Consent is not working in Cloud Shell

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az ad app permission admin-consent
Errors:
400 Client Error: Bad Request for url: http://localhost:50342/oauth2/token
Traceback (most recent call last):
python3.6/site-packages/knack/cli.py, ln 215, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 654, in execute
    raise ex
cli/core/commands/__init__.py, ln 718, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
cli/core/commands/__init__.py, ln 709, in _run_job
    cmd_copy.exception_handler(ex)
...
python3.6/site-packages/msrestazure/azure_active_directory.py, ln 486, in get_msi_token
    result.raise_for_status()
python3.6/site-packages/requests/models.py, ln 940, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: http://localhost:50342/oauth2/token

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Use Cloud Shell to run az cli
az ad app permission admin-consent --id {}

Expected Behavior
It works as locally
Environment Summary
Linux-4.15.0-1089-azure-x86_64-with-debian-stretch-sid
Python 3.6.10
Installer: DEB

azure-cli 2.8.0

Additional Context

Looks like MSI doesn't like this GUID: https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/azure/cli/command_modules/role/custom.py#L907

Cloud Shell

It is a known issue that resource='74658136-14ec-4630-ad9b-26e160ff0fc6' or https://main.iam.ad.ext.azure.com/ is not accepted by Cloud Shell's managed identity. You will need to manually run az login before using this command.
For more information, you could check https://github.com/Azure/azure-cli/issues/9942#issuecomment-650669473.

This should be fixed now.  I cannot repro, please close.

Hi $ az ad app permission admin-consent --id b9df9246-f8c2-4505-8556-814b7ecc95a9
The command failed with an unexpected error. Here is the traceback:
400 Client Error: Bad Request for url: http://localhost:50342/oauth2/token
Traceback (most recent call last):
File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 215, in invoke
cmd_result = self.invocation.execute(args)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 654, in execute
raise ex
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 718, in _run_jobs_serially
results.append(self._run_job(expanded_arg, cmd_copy))
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 709, in _run_job
cmd_copy.exception_handler(ex)
File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/role/commands.py", line 69, in graph_err_handler
raise ex
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 688, in _run_job
result = cmd_copy(params)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/init.py", line 325, in call
return self.handler(*args, **kwargs)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/init.py", line 776, in default_command_handler
return op(**command_args)
File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/role/custom.py", line 907, in admin_consent
send_raw_request(cmd.cli_ctx, 'post', url, resource='74658136-14ec-4630-ad9b-26e160ff0fc6')
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/util.py", line 775, in send_raw_request
token_info, _, _ = profile.get_raw_token(resource)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/_profile.py", line 643, in get_raw_token
creds = self._get_token_from_cloud_shell(resource)
File "/opt/az/lib/python3.6/site-packages/azure/cli/core/_profile.py", line 391, in _get_token_from_cloud_shell
auth = MSIAuthenticationWrapper(resource=resource)
File "/opt/az/lib/python3.6/site-packages/msrestazure/azure_active_directory.py", line 592, in init
self.set_token()
File "/opt/az/lib/python3.6/site-packages/msrestazure/azure_active_directory.py", line 598, in set_token
self.scheme, _, self.token = get_msi_token(self.resource, self.port, self.msi_conf)
File "/opt/az/lib/python3.6/site-packages/msrestazure/azure_active_directory.py", line 486, in get_msi_token
result.raise_for_status()
File "/opt/az/lib/python3.6/site-packages/requests/models.py", line 940, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: http://localhost:50342/oauth2/token

Can we close this as a dupe of https://github.com/Azure/azure-cli/issues/11749 ?

Duplicate of #8912


Update settings of favonia/cloudflare-ddns

Thanks for using my DDNS updater. Since version 1.13.0 released on 16 July, the updater has stopped dropping superuser privileges by itself, instead relying on Docker's built-in mechanism to drop those privileges. The new way is safer and more reliable, but it made the old Docker template (which grants SETUID and SETGID) potentially less secure. I am on a mission to eliminate the old template from the internet. Please help me promote security best practices!
For more information about this design change, please read the CHANGELOG. If copyright ever matters, this PR itself is licensed under CC0, which should allow you to do whatever you want. Thank you again for your interest in my DDNS updater.

Wow this is such a nice thing to do @favonia! Thank you! And thank you for a super solid DDNS updater!
Related: #555


Euclidean distance along dimension broken

        INDArray arr = Nd4j.linspace(1,100,100).reshape('f', 10, 10).dup('c');
        INDArray arr2 = Nd4j.linspace(1,100,100).reshape('c', 10, 10);
        INDArray out = Nd4j.getExecutioner().exec(new EuclideanDistance(arr, arr2), 1);
        System.out.println(out);

0.9.1:
[151.94,  128.86,  108.37,  92.22,  82.98,  82.98,  92.22,  108.37,  128.86,  151.94]

Master:
[460.00,  470.00,  480.00,  490.00,  500.00,  510.00,  520.00,  530.00,  540.00,  550.00]

See also DL4J failing tests:
TestGraphNodes.testL2Node
GradientCheckTestsComputationGraph.testBasicL2, .testBasicIrisTripletStackingL2Loss

Original issue fixed. Please confirm it works fine for other related stuff.

Can confirm that it is fixed, along with the referenced DL4J unit tests.


Add additional units

Area, flux, wt%, vol%, permeability and absorbance units added.

@nneskildsf There were a few issues that I was very close to not discover. The area tests were incorrect (1m2 is 100dm2, not 10dm2) but the tests were green because of the float equality problem (which also affected pint quantities). I fixed the equality comparisons using a delta. This caused the area tests to (correctly) fail. It seems necessary to define cm2 and cmd in the ureg for conversions to work correctly). Doing this made the tests pass.
But this leaves the question - why did pint not complain about cm2 and dm2 but instead just treated them as cm and dm in conversions? Are we sure we have all the required ureg definitions? At least we know what to look for if conversions are incorrect.

Great work! I have looked at the code and it looks good to me.


Install Voxel SDK 0.6.0 on Windows 10

Hi, I try to install Voxel SDK 0.6.0 on WIndows 10.
I have installed Python 2.7.11(64bit), PCL-1.7.2(win64) and Qt 5.4.2 in advance.
The Voxel SDK is successfully installed.
After running Simple Voxel Viewer program, some error messages pop up like "pcl_common_release.dll", "pcl_visualization_release.dll", "vtkRenderingFreeTypeOpenGL-6.1.dll", "vtkRenderingOpenGL-6.1.dll" are lost in my PC.
After install/uninstall voxel sdk many times, I finally try to copy all the PCL 1.7.2 DLL files to the Voxel SDK /bin directory. It works though many warning messages appears.
For example,
WARNING: CameraSystem: Ignoring Voxel library pcl_common_release.dll with ABI version = 0. Expected ABI version = 34
Suppose the pre-built binaries can not locate the DLL files in PCL library, please help check what's going on.
After running Simple VoxelViewer, an error message shows no device attached. Program is terminated and command window is closed.
As a result, I can not confirm the error message exactly. Does Simple VoxelViewer need an optical sensor CDK device to execute normally?

Most tools included in the SDK require a connected CDK or supported 3DTOF camera.
SimpleVoxelViewer attempts to connect to a supported 3DTOF camera at startup and start a frame stream.
Another tool in the SDK (CameraSystemReadStreamTest.exe) can read a pre-captured .vxl files and extract data from it.
To debug your installation problem, please check your PATH and VOXEL_SDK_PATH environment variables.
https://github.com/3dtof/voxelsdk/wiki/Build-from-source-on-Windows#running-sdk-programs

Yes, it works after adding the path environment. Should take care of some version numer and path name in practical directory. Please add the environment setting notification in the Wiki Installation on Windows page. Thank you for your help.

Thanks.
Will update the wiki page. I realize it's only on the Build Instructions page.


[FIX] Fixed the performance issues caused by re-rendering

Closes #17

Changes proposed in this pull request:

Memoized ResultCard component and updateDownload call back function
~Implemented virtualization solution for rendering the an array of ResultCard components~

Checklist

[x] PR has an interpretable title with a prefix ([ENH], [FIX], [REF], [TST], [CI], [MNT], [INF], [MODEL], [DOC]) (see https://neurobagel.org/contributing/pull_requests for more info)
[x] PR links to GitHub issue with mention Closes #XXXX
[x] Tests pass
[x] Checks pass

For new features:

[ ] Tests have been added

For bug fixes:

[ ] There is at least one test that would fail under the original bug conditions.

:rocket: PR was released in v0.1.0 :rocket:


Remove app dir

Step 2:

remove /app directory
move migration to /src/Migrations directory
update doctrine/migrations lib to 2.0

to simplify the code review you could review each commit independently

Bon travail!


Implement init command

Before running ceph-bootstrap we need to make sure that the salt pillar is correctly configured to find the ceph-salt.sls file created by ceph-bootstrap. This should be done automatically by the ceph-bootstrap init command.
Currently these are the steps we run manually before running ceph-bootstrap config:
cat <<EOF > /srv/pillar/top.sls
base:
  '*':
    - ceph-salt
EOF
touch /srv/pillar/ceph-salt.sls
chown -R salt:salt /srv/pillar
salt \* saltutil.pillar_refresh

We will not implement an explicit init command, but we will automatically initialize the salt pillar on ceph-bootstrap config command if the salt pillar is not already correctly configured.


Only include certmanager if it's enabled & parameterise ingress class

Hi there 👋🏻 I think this may be a copy/paste mistake in the requirements.yaml, but if it's intentionally set to ingress.enabled, apologies for taking your bandwidth!
Also parameterises ingress.class to allow the easy use of different ingress types

Hey @ashleydavies - thanks for the pull request! I'd initially lumped ingress and certmanager together intentionally to allow enabling SSL easily with a single value change.
In hindsight - it totally makes sense that you'd want to enable an ingress without certmanager (if you have your own certs, already have certmanager installed, etc).
I'd be happy to merge this PR if you could bump the chart version as well!

Cheers again @siggisim! Made those changes I mentioned and bumped the version to 0.0.20

Thanks for the contribution @ashleydavies!

Ditto for the prompt turnaround, much appreciated! 🚀


Docs for pose2d usage

Closes https://github.com/PhotonVision/photonvision-docs/issues/112 with some generic statements. Could possibly also point to the simposeest example for context, but right now that's java only.

Everything here looks good.
Re: Could possibly also point to the simposeest example for context, but right now that's java only.
One of the original concerns was I've heard is that people want to see how to use the current Pose2D for a robot to generate a trajectory to the pose 2D of a target.
Would you mind adding in a final step to the simposeest example page doing just that in this PR? I guess that would involve a photonvision PR as well for the code. Let me know what you think

Edited comment to include keyword to tie to the issue, here is the keyword list:

Everything here looks good.
Re: Could possibly also point to the simposeest example for context, but right now that's java only. One of the original concerns was I've heard is that people want to see how to use the current Pose2D for a robot to generate a trajectory to the pose 2D of a target. Would you mind adding in a final step to the simposeest example page doing just that in this PR? I guess that would involve a photonvision PR as well for the code. Let me know what you think

yes...ish. So here's my $0.02 on the topic. We should have a canonical, "all bells and whistles" example. Sim Pose Est is close to that, but as you pointed out lacks trajectory generation and autonomous.
However, I worry that gets a bit outside the scope of vision processing itself. The key is to present the potential, without being so prescriptive as to invite folks to reference the photonvision example as "necessarily correct for their situation". It move photonvision's docs out of "explaining how to use photonvision", and into a "educate users on how to do vision processing well" space. This isn't bad, just a change to be cognizant of.
W're already down that path by having any examples. I think the best path forward is to add a new example that builds on sim pose estimation and shows how to do pathplanning/ramsete, all with wpi stuff.
In terms of mechanics.... I'd say two new issues, one for photon and one for docs here?

yes...ish. So here's my $0.02 on the topic. We should have a canonical, "all bells and whistles" example. Sim Pose Est is close to that, but as you pointed out lacks trajectory generation and autonomous.
However, I worry that gets a bit outside the scope of vision processing itself. The key is to present the potential, without being so prescriptive as to invite folks to reference the photonvision example as "necessarily correct for their situation". It move photonvision's docs out of "explaining how to use photonvision", and into a "educate users on how to do vision processing well" space. This isn't bad, just a change to be cognizant of.
W're already down that path by having any examples. I think the best path forward is to add a new example that builds on sim pose estimation and shows how to do pathplanning/ramsete, all with wpi stuff.
In terms of mechanics.... I'd say two new issues, one for photon and one for docs here?

This all makes sense, I agree. I think a good middle ground (for now, while other examples potentially get written) would be to drop a line at the end of the example that says, hey, now that you have all of this set up you can do things like generate trajectories from anywhere on the field, (something), and (something else) without explicitly writing out those examples there.
Thoughts?

I think that works by me.
To clarify, after re-reading all the posts, I think that there are at least two possible things one could do with a Pose2D that photonlib returns:

Incorporate vision into a pose estimate in a field-global reference frame, and path plan based on known position of the target.
Path-plan in a reference frame centered on the target itself

Adding statements on this docs page to describe these both should be just fine.
Does this cover the expected use cases?

Yea, those two should cover it.

#132 supersedes this.


Remove Moshi from cache layer

Update RecordFieldAdapter to use direct json api instead of moshi lib.
Final step to rid off Moshi lib from runtime module.
Closes #572

@sav007 Can we remove it from Apollo completely?

@jaredsburrows we can't as it used internally for our apollo-compiler but it's not used at runtime

@sav007 Ok, thank you so much. That is what I meant!


Add create accessor factory constructor

Use case in code:
ReactiveTextField<Duration>(
  suffix: const Icon(PIcons.outline_time_circle),
  // here
  valueAccessor:
      ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) =>  prettyDuration(modelValue!),
  ),
  /////
  onTap: () async {
    var resultingDuration = await showDurationPicker(
      context: context,
      initialTime: const Duration(minutes: 30),
    );
    if (resultingDuration != null) {
      provider.controls.duration
          .updateValue(resultingDuration);
    }
  },
  readOnly: true,
  formControl: provider.controls.duration,
  labelText: 'Preparation time',
),

@Husssam12 sounds reasonable. Maybe the doubling of accessor in ControlValueAccessor.stringAccessor is redundant and ControlValueAccessor.string is more elegant.
Let's wait for @joanpablo response.
Maybe it will make sense to add accessors for all dart basic types like int, double, and so on)

@Husssam12 sounds reasonable. Maybe the doubling of accessor in ControlValueAccessor.stringAccessor is redundant and ControlValueAccessor.string is more elegant. Let's wait for @joanpablo response. Maybe it will make sense to add accessors for all dart basic types like int, double, and so on)

Thanks for replying, I made it more generic

Hi @Husssam12,
Thanks a lot for the issue and for supporting Reactive Forms.
This is quite interesting, and an attractive idea. But I have some questions.
First, why would you create an inline ControlValueAccesor instead of a separate class with single responsibility in another file (separated from the widget file)? In your example, you have the prettyDuration method that is supposed to be implemented in the same Widget class. Why not create a separated class with this single responsibility (i.e. the value accessor)?
I mean, don't make me wrong. I think it is an exemplary implementation of inline ControlValueAccessor, but I would like to understand an actual use case that a separated class doesn't solve.
As you may know, adding this feature implies more code to the package to maintain and more tests to add, so I want to make sure it is because of a good reason and that solves a real use case.
looking forward to hearing from you.

Hi @Husssam12,
Thanks a lot for the issue and for supporting Reactive Forms.
This is quite interesting, and an attractive idea. But I have some questions.
First, why would you create an inline ControlValueAccesor instead of a separate class with single responsibility in another file (separated from the widget file)? In your example, you have the prettyDuration method that is supposed to be implemented in the same Widget class. Why not create a separated class with this single responsibility (i.e. the value accessor)?
I mean, don't make me wrong. I think it is an exemplary implementation of inline ControlValueAccessor, but I would like to understand an actual use case that a separated class doesn't solve.
As you may know, adding this feature implies more code to the package to maintain and more tests to add, so I want to make sure it is because of a good reason and that solves a real use case.
looking forward to hearing from you.

The first reason is that I am a bit lazy :crying_cat_face: , but actually I have two reasons:

the implemention of modelToViewValue is in another utils package so i have separate responsibility for that, in my example the package is duration,
In most cases (maybe in my project)  I don't need to implement viewToModelValue.

So I think it's a slightly faster way to create ControlValueAccessor with less code.
I hope I have clarified my use case.

Hi @Husssam12
What about the "viewModel" method? In your example you are defining a callback for the "modelToView", but you have not defined one for the "viewToModel":
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) =>  prettyDuration(modelValue!),
)

Don't you suppose to update the FormControl value from the Widget (the View) value?
Don't the modelToView and viewToModel callbacks (arguments) should be mandatory instead of optional?
Thanks in advance.

Hi again @Husssam12,
In your example (use case) you are calling the method prettyDuration() from the duration package passing as an argument the modelValue, but you are not checking if the modelValue is null or not.
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) =>  prettyDuration(modelValue!),
)

Because the argument of the  * _ModelToViewValueCallback* is a nullable type you should not trust you will receive a not null argument. A safe implementation would be:
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) => modelValue != null ? prettyDuration(modelValue) : null,
)

Hi @Husssam12
What about the "viewToModel" method? In your example you are defining a callback for the "modelToView", but you have not defined one for the "viewToModel":
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) =>  prettyDuration(modelValue!),
)

Don't you suppose to update the FormControl value from the Widget (the View) value? Shouldn't be the arguments modelToView and viewToModel mandatory instead of optional?
Thanks in advance.

Hi again @Husssam12,
In your example (use case) you are calling the method prettyDuration() from the duration package passing as an argument the modelValue, but you are not checking if the modelValue is null or not.
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) =>  prettyDuration(modelValue!),
)

Because the argument of the _ModelToViewValueCallback is a nullable type you should not trust you will receive a not null argument. A safe implementation would be:
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) => modelValue != null ? prettyDuration(modelValue) : '',
)

Hi again @Husssam12,
In your example (use case) you are calling the method prettyDuration() from the duration package passing as an argument the modelValue, but you are not checking if the modelValue is null or not.
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) =>  prettyDuration(modelValue!),
)

Because the argument of the _ModelToViewValueCallback is a nullable type you should not trust you will receive a not null argument. A safe implementation would be:
ControlValueAccessor<Duration, String>.create(
    modelToView: (modelValue) => modelValue != null ? prettyDuration(modelValue) : '',
)

Sorry for the late reply
That's what I missed, this didn't happen in my case because the field is read only, I will make changes for this and update the pull request.

Hi @mr7ssam @vasilich6107,
Let me recap:
at this point we have something like this:
typedef ModelToViewCallback<ModelDataType, ViewDataType> = ViewDataType?
    Function(ModelDataType? modelValue);

typedef ViewToModelCallback<ModelDataType, ViewDataType> = ModelDataType?
    Function(ViewDataType? modelValue);

class InlineValueAccessor<ModelDataType, ViewDataType>
    extends ControlValueAccessor<ModelDataType, ViewDataType> {
  final ModelToViewCallback<ModelDataType, ViewDataType> _modelToView;
  final ViewToModelCallback<ModelDataType, ViewDataType> _viewToModel;

  InlineValueAccessor({
    required ModelToViewCallback<ModelDataType, ViewDataType> modelToView,
    required ViewToModelCallback<ModelDataType, ViewDataType> viewToModel,
  })  : _modelToView = modelToView,
        _viewToModel = viewToModel;

  @override
  ViewDataType? modelToViewValue(ModelDataType? modelValue) =>
      _modelToView(modelValue);

  @override
  ModelDataType? viewToModelValue(ViewDataType? viewValue) =>
      _viewToModel(viewValue);
}

And @mr7ssam based on your use case you will use it like this:
ReactiveTextField<Duration>(
  valueAccessor: InlineValueAccessor<Duration, String>(
    modelToView: (modelValue) =>  prettyDuration(modelValue!),
    viewToModel(viewValue) => null,
  ),
  readOnly: true,
  formControl: provider.controls.duration,
),

Do you still thinking that it is better than the following solution?
ReactiveTextField<Duration>(
  readOnly: true,
  valueAccessor: DurationValueAccessor(),
  formControl: provider.controls.duration,
)

class DurationValueAccessor extends ControlValueAccessor<Duration, String> {
  @override
  String? modelToViewValue(Duration modelValue) => prettyDuration(modelValue!);

  @override
  Duration? viewToModelValue(String viewValue) => null;
}

looking forward to hearing from you.


Create Web Page for CSV Uploader Guide

Problem Statement
As the Experience Team, we need to make the CSV Uploader guide publicly accessible so that prospective Senders can easily access it.
Recommendation

@sean-usds @BerniXiongA6 Rachel has recommended that we put out the CSV Uploader Guide as a web page in ReportStream this week and have it deployed to production by 1/5. This takes priority over anything else you are working on at the moment. I don't think that it needs to be navigable (yet) but we should be able to provide a link to the page in production that we can provide to our prospective senders. Please work together to get this guide out and let me know what blockers you may have. Thanks!
cc: @rachelhanster

@loripusey already have a working branch for this and will be working with @BerniXiongA6 today to flow our current content into it.

Content is up on staging and have iterated through a couple PRs as of Fri 1/7.

Doing last checks today based on what's on staging. Have put up a couple PRs (#3729 and #3732) and have one last draft PR up at #3754.


Connection with Key Authentication and SSH proxy server.

Hi. Thanks for the excellent work.   I have two feature requests for the vfsjfilechooser2:
It is strongly desired that the remote host can be connected via SSH Key Authentication. Also, support for SSH proxy server is also grateful.

I'm not actually the author of the library, I merely resurrected it, so I don't really know how the file name resolution works in practice (another Apache library does that). Also, I haven't used the library myself for years. Only a recent PR breathed some life into it again.


Don't mount efivarfs if it's already been mounted

With a newer u-root, something like the following could be a solution. The New() and DefaultVarFS were added in 47260416a.
Might want to do the mounting only when efivarfs is not mounted and not in the other error case, where something else is being mounted on the default mount point. That would require some better error reporting from package efivarfs though, AFAICT.
@@ -175,14 +175,15 @@ func main() {

 	switch hostCfg.location {
 	case hostCfgEfivar:
-		_, err := mount.Mount("efivarfs", "/sys/firmware/efi/efivars", "efivarfs", "", 0)
-		if err != nil {
-			stlog.Error("mounting efivarfs: %v", err)
-			host.Recover()
+		if _, err := efivarfs.New(); err != nil {
+			_, err := mount.Mount("efivarfs", efivarfs.DefaultVarFS, "efivarfs", "", 0)
+			if err != nil {
+				stlog.Error("mounting efivarfs: %v", err)
+				host.Recover()
+			}
+			stlog.Info("mounted efivarfs at /sys/firmware/efi/efivars")
 		}

-		stlog.Info("mounted efivarfs at /sys/firmware/efi/efivars")
-
 		_, efiReader, err := efivarfs.SimpleReadVariable(hostCfg.name)
 		if err != nil {
 			stlog.Error("reading efivar %q: %v", hostCfg.name, err)

https://git.glasklar.is/system-transparency/core/stboot/-/tree/main/


Define Output

Description
Before diving into the development phase, it's crucial to define what the final outputs of the project will be and how they will be presented. This will guide the development process and ensure that the team is aligned in terms of objectives.
Tasks

[ ] Identify the key deliverables for this project.
[ ] Decide on the format of presentation (e.g., Jupyter Notebook, slide deck, blog post, etc.).
[ ] Determine the KPIs or success metrics for each deliverable.
[ ] Outline the data visualization strategies for showcasing the analysis.
[ ] Create a roadmap or timeline for the project based on the defined outputs.

Acceptance Criteria

A document outlining the project's key deliverables and presentation strategy is available.
The team has a clear understanding of what needs to be developed and presented.

Identify the key deliverables for this project.

Utilize PySpark, MLFlow, and DeltaLake technologies and develop a recommender system.

Decide on the format of the presentation (e.g., Jupyter Notebook, slide deck, blog post, etc.).

Document the project overview and objectives in a README file, and use Jupyter Notebook to detail the data analysis and modeling steps.


feat: add get game data and timeline

Add support for getting v4 and v5 PostGame data and timeline JSONs from leaguepedia

TO DO

Add riot_transmute to dependencies
Use riot_transmute to merge the data and timeline into a single LolGame
Merge leagupedia_parser's LolGame with riot_transmute's merged LolGame to create a single LolGame instance with leagupedia source/metadata as well as timeline frame data

Honestly this repo is mostly abandonned since River, my main contact at Leaguepedia, got fired.
I'd advise creating your own fork or just rewriting it with pydantic like it should be!


Importing executable files with auto-detected format exports corrupted binaries

Describe the bug
If you import an ELF binary with the format as Executable and Linking Format (ELF) and then export that binary, it creates a corrupted binary that segfaults.
However, if you import it as "Raw binary" and manually select the language, then the exported file works as expected.
To Reproduce
Steps to reproduce the behavior:

Import the cp ELF binary into your project (default settings).
Right-Click it and click Export...
Select Binary as the format.
Export it.
Make the exported binary executable.
Run the exported binary.

Expected behavior
The exported binary should work instead of segfaulting (happens with multiple binaries that I've tested).
Screenshots
Default:

Import as Raw binary:

Environment (please complete the following information):

OS: Kubuntu 18.10
Ghira Version 9.0

Additional context
Happens with both i386 and x86_64 binaries.

Just tested it on Windows and it's the same story with PE executables. They also need to be imported raw, else you can't run them.

Can confirm. The exported ls becomes ~3kb larger than the original.
Some binaries also end up with missing headers.

Note: Loading as Raw Binary does not seem to produce the same analysis/disassembly output at all.
The disassembly after analysis is missing various things ranging from functions not being disassembled to missing Xrefs.
It also appears to analyze the binary much faster than when imported as ELF indicating it is either unable to analyze is as thoroughly when loaded as a Raw Binary or just skips a bunch of analysis options which are enabled/supported only under ELF.
Thus, loading as Raw Binary should not be considered a workaround for this as the output differs.

The binary export is not intended to create a valid executable.  It simply dumps the memory blocks that exist within Ghidra void of any address placement information.

@gnooby22 Would be nice if there was a way to imitate the behavior when loading a binary as Raw Binary (which when exported creates a valid verbatim copy of the loaded program) but retaining all the analysis options when loading it as ELF.
One would expect that Export Program as Binary would create a valid executable when loaded as ELF as well.
This means that executables as of now can't be nicely patched like in IDA.

Yeah,
Working exported binaries is a very important feature for many workflows.

Once I imported as Raw Binary what can I do to produce the same binary analysis of an ELF? At least to automatically show assembly code.

@Corallo It currently sadly does not seem to be possible

Also have this issue.
When I make patches to apps, I can't export a binary without seg fault, nor does it make the change to the underlying binary referenced by the project.

Same issue here with every binary I have tested.

Does 9.0.1 fix this?

@johnalanwoods Don't worry, it won't be long. Imagine all these poor agents at the NSA who can't work because their hacking toy is broken. They won't let this linger long. LOL

@najamelan it does not appear to be a bug
One of the devs (whose account is now deleted) mentioned this:

The binary export is not intended to create a valid executable - there is no export for doing this. It simply dumps the memory blocks that exist within Ghidra void of any address placement information.

I doubt this will be "fixed"

@Ristovski interesting. To me this would seem like a basic feature. The ability to edit the binary and run that binary independently of Ghidra. I’m shocked this is seen as normal behaviour. Even IDA does this.

@johnalanwoods I agree. I don't see why the binaries loaded as ELF should not export the same way they do when loaded as Raw Binary. I haven't looked into the bundled source code yet, but maybe this could be trivial to fix.

A few things to add:

This was not addressed in 9.0.1.  The effort is most likely too large to appear in a patch release.
I'm changing this from a bug to an enhancement because while the feature isn't working as requested, it's working as documented (see help page for exporting files).
#154 is related, because the file offset to memory address mapping is lost during import.  Keeping track of that mapping would be required to properly go back to file-form.

Thank you for the clarification @ryanmkurtz.
It seems unusual to me that, as sophisticated as Ghidra is, it doesn't include this feature.
How much utility can there be without being able to generate an edited executable?
Anyway, not to worry.
Regards,
John

Same problem.

So what are people supposed to do without the ability to export a working binary for windows? Re-write the program or?

I agree with @bernky, there are things which can be done without export. Such as exfiltration of data and there is python scripting etc, but still the ability to export is very important.

alright then, i can't finish my root-me assignments using ghidra, what i should do without export, use other tools, what is the point, this is high priority bug.

Great find, almost lost my mind trying to figure it out.

alright then, i can't finish my root-me assignments using ghidra, what i should do without export, use other tools, what is the point, this is high priority bug.

I think they are considering this as an "Enhancement feature"

I just went back to IDA, at least I can export from it easily and I don’t have to run it inside 4 nested VMs to avoid myself being backdoored ;)

As others have said export works fine when you import as Raw Binary.

As others have said export works fine when you import as Raw Binary.

Raw badly affects the quality of the disassembly. It makes it really hard to work in.

On 15 May 2019, at 1:53 p.m., benjaminkoffel<EMAIL_ADDRESS>wrote:
As others have said export works fine when you import as Raw Binary.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/NationalSecurityAgency/ghidra/issues/19?email_source=notifications&email_token=ABHLP4VVQ5LRUIFZCQVIBHDPVQBUDA5CNFSM4G4ADAC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVOR2FA#issuecomment-492641556, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHLP4Q5YOBDBPDQ6X5IGCLPVQBUDANCNFSM4G4ADACQ.

Does 9.0.4 fix this?

No, 9.0.4 is mostly a bug fix release.

The problem still persists, are you gonna solve it?

Ghidra 9.1 will add the ability to retain and access the original imported program bytes.  This was a key requirement for this type of exporter to be written properly.  However, Ghidra 9.1 will not introduce any new exporters.  Writing an exporter to take a loaded memory image back to a runnable binary is a pretty sizeable task (to do it correctly and completely), and it is specific to each loader (there is no generic solution).  However, now that the infrastructure is in place, you might start seeing the community take a stab at it for the more popular file formats (PE, ELF).

Will it be possible to put a header on top of a raw binary file? Use case:
$ qemu-system-tricore -M tricore_testboard -kernel firmware.bin
firmware.bin won't work, but if you slap an ELF header on the raw instructions, they will parse.

I have written a python script to write back small patches to a copy of the original PE/ELF binary:
https://github.com/schlafwandler/ghidra_SavePatch
It's still experimental and far away from a complete export feature; but if you are only dealing with few and small modified locations it might be a good enough workaround.

Note that the Binary export is not broken, it is simply misunderstood.  This exporter simply dumps the initialized memory blocks defined within Ghidra in binary form.  The blocks are appended sequentially.  It was never intended to recreate a loadable/executable binary.  While this is certainly a desirable feature, it does not yet exist within Ghidra.
The binary exporter can provide a means of exporting a selected memory region as binary such that it can be subsequently added to another Ghidra program.  This can be useful if a specific section needs to be unpacked and loaded to a specific memory address within Ghidra.

@ghidra1 understood thanks.
However this means Ghidra can’t be used to patch a binary. Which is the primary reason I use IDA.
Otherwise the use is restricted to inspecting methods and watching output.

The request is a reasonable improvement, although as an analysis tool re-writing binaries has not been a high priority.
I am closing this ticket and deferring the issue to #1505 as an enhancement/improvement.

Does this issue cover the following bug as well? (see first instruction after LAB_*)
I made changes to a PE64 dll, but did not save the project for try&error patching. However, the unsaved changes are still exported after they were reverted in Ghidra.

#1505 was merged in, so there are now PE and ELF exporters that behave how you thought the Binary exporter should have behaved.  No changes were made to the Binary exporter...that one still just dumps the memory image to a file as-is. The PE and ELF exporters can be used to save basic byte modifications back to a new runnable PE/ELF file.
Here is the help for the PE exporter:


Remove graphviz to speed up the dot files generation

Signed-off-by: Rodolfo Olivieri<EMAIL_ADDRESS>

Codecov Report

Merging #11 (b276a49) into main (a039b65) will not change coverage.
The diff coverage is 100.00%.

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

@@            Coverage Diff            @@
##              main       #11   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            5         5
  Lines          135       142    +7
  Branches        23        24    +1
=========================================
+ Hits           135       142    +7

Impacted Files
Coverage Δ

dismod/dot.py
100.00% <100.00%> (ø)

dismod/main.py
100.00% <100.00%> (ø)

dismod/utils.py
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

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


Updating Vagrantfile to install Docker-Compose rather than fig

@projectweekend Good call. For some reason it wasn't working for me initially but that's since I was trying through the SSH session and not as root. Updated + updated the docker image pointers since that wasn't working for me. Cheers

:+1: Thanks for catching this!


EDA viz tab:  Export plot button does not export the legend

When you export a plot with an overlay, the legend should be included in the exported plot. Currently it is not, making the exported plot useless

This came up in our ui-infra scrum and we decided this needs further discussion.

@steve-fischer-200 and @bobular suggest that ONE file is likely too much work
user will be editing the SVG anyway
So we provide two files: plot and legend
This assumes we can get SVG from our legend div relatively easily. (can we @dmfalke ?)


0.9.10

Merge for next release

Pull Request Test Coverage Report for Build 523

289 of 289 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 477:
0.0%

Covered Lines:
6137

Relevant Lines:
6137

💛  - Coveralls

Pull Request Test Coverage Report for Build 523

289 of 289 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 477:
0.0%

Covered Lines:
6137

Relevant Lines:
6137

💛  - Coveralls


Does the gap of QPS between offline and server mode make sense?

I observed that the offline and server QPS are not at same level, my understanding is that it's due to the poisson distribution by server scenario, is it correct?
And if yes, how much does the gap make sense?  30%? 40%, etc.
@briandersn @tjablin @guschmue @christ1ne @delock

@tejasprabhune had a WIP patch in #437 to make the server scenario's effective QPS equal to the requested QPS, but he hasn't been able to compile and test it. The logic of the patch I think is mostly right though, if someone wants to pick that up.
Not sure if that's what this bug is referring to.

Thank you @briandersn for looking at this. The #437 is for scheduled QPS and requested QPS, Mine is about server and offline QPS, e.g.,
With same data set and settings, the offline QPS is 1000, and the server QPS within latency bound is 800, is this 20% gap a reasonable result?

Ah, I see. I'm not sure what a reasonable discrepancy is, but you are right. Server should be slower since some periods of time will have a burst of queries with a much higher "instantaneous QPS".

Unless there's a specific complaint that the discrepancy between server and offline doesn't make sense, I propose closing this for now.


Blueprint Port

This ought to be "fun"
TODO

[x] GroupRow
[x] PasswordDialog
[x] TransactionRow
[x] AccountSettingsDialog
[x] AccountView

The constructor is 429 lines :cold_sweat:

[x] GroupDialog
[x] MainWindow
[x] PreferencesDialog
[x] ShortcutsDialog
[x] TransactionDialog
[x] TransferDialog

Fixes #335

Considering how much more there is to the Denaro UI vs. Tube Converter, we might want to dedicate a beta release to making sure nothing broke

@fsobolev How does it look to you?

There is this weird line when scrolled to the top of the transactions list under the Transactions label:

That line should appear when hitting the "top" when scrolling upwards, I believe that comes from libadwaita. It matches the stable release, at least for me  :sweat_smile:

That line should appear when hitting the top when scrolling upwards, I believe that comes from libadwaita. It matches the stable release, at least for me  :sweat_smile:

Yes, but the problem is it doesn't go away and stays there constantly. Could just be a WSL artifact render issue

It could be. For me, it only stays for as long as I hold the scroll up touchpad gesture

https://user-images.githubusercontent.com/17648453/223803317-070fec4f-fbe0-4860-ab27-7e3b03f41ff1.mp4
Yeah definitely probably a weird WSL GPU thing

https://github.com/nlogozzo/NickvisionMoney/releases/tag/2023.3.0-beta1


Please Tag a Stable Release for Composer

Hi There,
I have just integrated your package into my Asset Building Pipeline.
https://github.com/phpgearbox/asset
Would be awesome if you could tag a stable release so users of my package do not have to specifically require the development build of your package.
Cheers Brad

Done.


Fixed: Migrating alternate names

This fixes the institution alternate names migration to only add unique and non-null entries to the list of alternate names.

Is it ok to be merged?

Actually -- one sec! I have one more thing I can add here..

OK! Done -- I just added "Sweden" to the list of country sigla


CMake warnings about cycle with release archive underlay

I'm trying to compile rosbag2_bag_v2 in an overlay on a release archive and getting cmake warnings about cycles.
I'm on Ubuntu 18.04 with a ROS Eloquent installation. I can also reproduce with a pre-Foxy nightly archive.
To reproduce,

Download and extract a release archive (e.g. Eloquent)

Source Melodic installation
 source /opt/ros/melodic/setup.bash

Source Eloquent installation
 source ros2-eloquent/setup.bash

Checkout this repository and try to build
 mkdir -p rosbag2_bag_v2_ws/src && cd rosbag2_bag_v2_ws/src
 git clone https://github.com/ros2/rosbag2_bag_v2.git -b eloquent
 cd ..
 colcon build

Example output:
Starting >>> ros1_rosbag_storage_vendor
Finished <<< ros1_rosbag_storage_vendor [29.9s]
Starting >>> rosbag2_bag_v2_plugins
[Processing: rosbag2_bag_v2_plugins]
--- stderr: rosbag2_bag_v2_plugins
CMake Warning at /home/jacob/ws/ros/ros2-eloquent/share/actionlib_msgs/cmake/actionlib_msgsConfig.cmake:29 (message):
  Package 'actionlib_msgs' is deprecated (This package will be removed in a
  future ROS distro, once the ROS 1 bridge supports actions.)
Call Stack (most recent call first):
  CMakeLists.txt:72 (find_package)

CMake Warning at /home/jacob/ws/ros/ros2-eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
  Cannot generate a safe runtime search path for target
  test_rosbag_v2_storage because there is a cycle in the constraint graph:

    dir 0 is [/home/jacob/ws/ros/rosbag2_bag_v2/build/rosbag2_bag_v2_plugins]
    dir 1 is [/home/jacob/ws/ros/ros2-eloquent/lib]
      dir 4 must precede it due to runtime library [libclass_loader.so]
    dir 2 is [/home/jacob/ws/ros/rosbag2_bag_v2/install/ros1_rosbag_storage_vendor/lib]
    dir 3 is [/home/jacob/ws/ros/ros2-eloquent/opt/yaml_cpp_vendor/lib]
    dir 4 is [/opt/ros/melodic/lib]
      dir 1 must precede it due to runtime library [libclass_loader.so]

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  /home/jacob/ws/ros/ros2-eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
  CMakeLists.txt:137 (ament_add_gmock)

CMake Warning at /home/jacob/ws/ros/ros2-eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
  Cannot generate a safe runtime search path for target
  test_rosbag_output_stream because there is a cycle in the constraint graph:

    dir 0 is [/home/jacob/ws/ros/rosbag2_bag_v2/build/rosbag2_bag_v2_plugins]
    dir 1 is [/home/jacob/ws/ros/ros2-eloquent/lib]
      dir 4 must precede it due to runtime library [libclass_loader.so]
    dir 2 is [/home/jacob/ws/ros/rosbag2_bag_v2/install/ros1_rosbag_storage_vendor/lib]
    dir 3 is [/home/jacob/ws/ros/ros2-eloquent/opt/yaml_cpp_vendor/lib]
    dir 4 is [/opt/ros/melodic/lib]
      dir 1 must precede it due to runtime library [libclass_loader.so]

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  /home/jacob/ws/ros/ros2-eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
  CMakeLists.txt:149 (ament_add_gmock)

CMake Warning at CMakeLists.txt:76 (add_library):
  Cannot generate a safe runtime search path for target
  rosbag2_bag_v2_plugins because there is a cycle in the constraint graph:

    dir 0 is [/home/jacob/ws/ros/rosbag2_bag_v2/install/ros1_rosbag_storage_vendor/lib]
    dir 1 is [/home/jacob/ws/ros/ros2-eloquent/lib]
      dir 3 must precede it due to runtime library [libclass_loader.so]
    dir 2 is [/home/jacob/ws/ros/ros2-eloquent/opt/yaml_cpp_vendor/lib]
    dir 3 is [/opt/ros/melodic/lib]
      dir 1 must precede it due to runtime library [libclass_loader.so]

  Some of these libraries may not be found correctly.

---
Finished <<< rosbag2_bag_v2_plugins [52.0s]

Summary: 2 packages finished [1min 23s]
  1 package had stderr output: rosbag2_bag_v2_plugins

@Karsten1987 Do you know if this use-case was ever tried?

can you try inverting the source order? basically swap step 2 and 3
The problem did arise in the past, and I remember there isn't really much we can do about it except taking care what is being sourced and in which order

This is the documented order in the readme, and reversing the order fails compilation at ros1_rosbag_storage_vendor.

I am also running into almost the same issue.
I'm running ros melodic and eloquent.
When trying to build the rosbag2_bag_v2 package i get the following error output:
`Starting >>> rosbag2_bag_v2_plugins
--- stderr: rosbag2_bag_v2_plugins
CMake Warning at /opt/ros/eloquent/share/actionlib_msgs/cmake/actionlib_msgsConfig.cmake:29 (message):
Package 'actionlib_msgs' is deprecated (This package will be removed in a
future ROS distro, once the ROS 1 bridge supports actions.)
Call Stack (most recent call first):
CMakeLists.txt:72 (find_package)
CMake Warning at /opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Cannot generate a safe runtime search path for target
test_rosbag_v2_storage because files in some directories may conflict with
libraries in implicit directories:
runtime library [liburdfdom_sensor.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_model_state.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_model.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_world.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [libconsole_bridge.so.0.4] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
/opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:137 (ament_add_gmock)
CMake Warning at /opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Cannot generate a safe runtime search path for target
test_rosbag_v2_storage because there is a cycle in the constraint graph:
dir 0 is [/home/mh/rosbag2_bag_v2_ws/build/rosbag2_bag_v2_plugins]
dir 1 is [/opt/ros/eloquent/lib]
  dir 0 must precede it due to runtime library [librosbag2_bag_v2_plugins.so]
  dir 2 must precede it due to runtime library [libros1_rosbag_storage.so]
  dir 4 must precede it due to runtime library [libimage_transport.so]
dir 2 is [/home/mh/rosbag2_bag_v2_ws/install/ros1_rosbag_storage_vendor/lib]
dir 3 is [/opt/ros/eloquent/opt/yaml_cpp_vendor/lib]
dir 4 is [/opt/ros/melodic/lib]
  dir 1 must precede it due to runtime library [libclass_loader.so]

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
/opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:137 (ament_add_gmock)
CMake Warning at /opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Cannot generate a safe runtime search path for target
test_rosbag_output_stream because files in some directories may conflict
with libraries in implicit directories:
runtime library [liburdfdom_sensor.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_model_state.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_model.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_world.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [libconsole_bridge.so.0.4] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
/opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:149 (ament_add_gmock)
CMake Warning at /opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:69 (add_executable):
Cannot generate a safe runtime search path for target
test_rosbag_output_stream because there is a cycle in the constraint graph:
dir 0 is [/home/mh/rosbag2_bag_v2_ws/build/rosbag2_bag_v2_plugins]
dir 1 is [/opt/ros/eloquent/lib]
  dir 0 must precede it due to runtime library [librosbag2_bag_v2_plugins.so]
  dir 2 must precede it due to runtime library [libros1_rosbag_storage.so]
  dir 4 must precede it due to runtime library [libimage_transport.so]
dir 2 is [/home/mh/rosbag2_bag_v2_ws/install/ros1_rosbag_storage_vendor/lib]
dir 3 is [/opt/ros/eloquent/opt/yaml_cpp_vendor/lib]
dir 4 is [/opt/ros/melodic/lib]
  dir 1 must precede it due to runtime library [libclass_loader.so]

Some of these libraries may not be found correctly.
Call Stack (most recent call first):
/opt/ros/eloquent/share/ament_cmake_gmock/cmake/ament_add_gmock.cmake:52 (_ament_add_gmock)
CMakeLists.txt:149 (ament_add_gmock)
CMake Warning at CMakeLists.txt:76 (add_library):
Cannot generate a safe runtime search path for target
rosbag2_bag_v2_plugins because files in some directories may conflict with
libraries in implicit directories:
runtime library [liburdfdom_sensor.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_model_state.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_model.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [liburdfdom_world.so.1.0] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib
runtime library [libconsole_bridge.so.0.4] in /usr/lib/x86_64-linux-gnu may be hidden by files in:
  /opt/ros/eloquent/lib

Some of these libraries may not be found correctly.
CMake Warning at CMakeLists.txt:76 (add_library):
Cannot generate a safe runtime search path for target
rosbag2_bag_v2_plugins because there is a cycle in the constraint graph:
dir 0 is [/home/mh/rosbag2_bag_v2_ws/install/ros1_rosbag_storage_vendor/lib]
dir 1 is [/opt/ros/eloquent/lib]
  dir 0 must precede it due to runtime library [libros1_rosbag_storage.so]
  dir 3 must precede it due to runtime library [libimage_transport.so]
dir 2 is [/opt/ros/eloquent/opt/yaml_cpp_vendor/lib]
dir 3 is [/opt/ros/melodic/lib]
  dir 1 must precede it due to runtime library [libclass_loader.so]

Some of these libraries may not be found correctly.
/opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::MultiLibraryClassLoader::getAllAvailableClassLoaders()' /opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::impl::AbstractMetaObjectBase::isOwnedBy(class_loader::ClassLoader const*)'
/opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::MultiLibraryClassLoader::getRegisteredLibraries[abi:cxx11]()' /opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::ClassLoader::isLibraryLoaded()'
collect2: error: ld returned 1 exit status
make[2]: *** [test_rosbag_output_stream] Error 1
make[1]: *** [CMakeFiles/test_rosbag_output_stream.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::MultiLibraryClassLoader::getAllAvailableClassLoaders()' /opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::impl::AbstractMetaObjectBase::isOwnedBy(class_loader::ClassLoader const*)'
/opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::MultiLibraryClassLoader::getRegisteredLibraries[abi:cxx11]()' /opt/ros/melodic/lib/librviz.so: undefined reference to class_loader::ClassLoader::isLibraryLoaded()'
collect2: error: ld returned 1 exit status
make[2]: *** [test_rosbag_v2_storage] Error 1
make[1]: *** [CMakeFiles/test_rosbag_v2_storage.dir/all] Error 2
make: *** [all] Error 2
Failed   <<< rosbag2_bag_v2_plugins [10.2s, exited with code 2]
Summary: 1 package finished [10.9s]
1 package failed: rosbag2_bag_v2_plugins
1 package had stderr output: rosbag2_bag_v2_plugins
`
@Karsten1987 any update on this issue?

Same problem as @Mavahu but with foxy and noetic.

@Mavahu I have fixed that problem - see #32


NumberFormat documentation is referring to non-existent decimalFormat, percentFormat, etc

The documentation mentions decimalFormat, percentFormat, scientificFormat, and currencyFormat, none of which exist. I suppose these should be decimalPattern, percentPattern, scientificPattern, and currency, respectively.
https://github.com/dart-lang/intl/blob/5e0817412a746f5329d18ff3eba9c2b46104f935/lib/src/intl/number_format.dart#L36-L45

Thanks. There are also several more constructors than when that was written. Update pending.


Cleanup command fails to drop pglogical role due to privileges on view pg_stat_statements

Describe the bug
PgBelt fails to drop the pglogical role when running belt teardown --full with the following error:
ERROR:  role "pglogical" cannot be dropped because some objects depend on it
DETAIL:  privileges for view pg_stat_statements

Expected behavior
The teardown command runs without errors and doesn't stop in the middle.
Additional context
This happened with a Postgres 12 RDS database.

Solution - just gotta run an extra REVOKE to get rid of the blocker:
REVOKE ALL ON pg_stat_statements FROM pglogical;


Added Cormorant Aeronology, moved USI Sounding rockets

I have Moved USI Sounding rocket parts - Nosecone, and few others from start to Model rockets node, as it makes more sense
Also i have added

Cormorant Aeronology: http://forum.kerbalspaceprogram.com/index.php?/topic/119951-cormorant-aeronology-dev-thread/&page=1

BoxSat:  http://forum.kerbalspaceprogram.com/index.php?/topic/82643-104-boxsat-va02f-updated-09162015/

USI Alcubierre Warp Drive: http://forum.kerbalspaceprogram.com/index.php?/topic/90899-11-alcubierre-warp-drive-stand-alone-v040/

Canadarm: http://forum.kerbalspaceprogram.com/index.php?/topic/118906-11x-canadarm-v171-5-june-2016/

fixed 1 part for Mk2 Extension - Added to Experimental Aerodynamics

Looks like you used the release version as a master instead of the dev version here on the Github.:)
Changes look good otherwise. Made a note for the Airlock.

This is the first time i am using github so honestly i have no idea what i am doing, just hoping i dont mess stuff up

Can you write me few lines how to do it properly. I will wait till you integrate changes before i download new version so we dont overlap. Assume the following when writing stuff.

I used to work with SVE, however GIT is confusing for me
Please specify exact page i need to be to get latest version, and how to do it.

I plan to add around 10-15 mods more, so just fyi, and i need to do it sometime during this weekend, but definitely before wednesday.


Added the icon and title to the site

Related Issue

Closes: #5
#19

Description

How Has This Been Tested?

Screenshots (if applicable)

Type of Change

[ ] Bug fix
[ ] New feature
[ ] Code style update
[ ] Breaking change
[ ] Documentation update

@parassareen4 : use a proper commit message.

for sure, my bad

signup is on /signup route and login on /login

any changes needed here?

@parassareen4 good all changes look fine to me, @mehul-m-prajapati please look into this PR. I think it's good enough to be merged now.

@mehul-m-prajapati Kindly merge this PR

@yashksaini-coder : okay, I will test and merge today.

@yashksaini-coder : okay, I will test and merge today.

the tests went fine?

@yashksaini-coder : okay, I will test and merge today.

@mehul-m-prajapati i think this can be merged


esimp fails to unfold recursive definition

In the last line, esimp [rep] fails. Also, the tactic esimp [add_add] would fail in the same position.
-- HoTT
import types.nat

open nat eq

definition add_add (n l k : ℕ) : n + l + k = n + (k + l) :=
begin
  induction l with l IH,
    reflexivity,
    exact succ_add (n + l) k ⬝ ap succ IH
end

variables {A : ℕ → Type} (f : Π⦃n⦄, A n → A (succ n))
variables {n : ℕ} (a : A n)
include f

definition rep [reducible] (k : ℕ) (a : A n) : A (n + k) :=
by induction k;exact a;exact f v_0

definition rep_rep_succ (k l : ℕ) (a : A n) :
   rep f k (rep f (succ l) a) =[add_add n (succ l) k] rep f (k + (succ l)) a :=
begin
  esimp [rep],
end

@fpvandoorn In the current implementation, esimp fails whenever it cannot fold the recursive application.
The motivation for this heuristic is that we are not really creating something simpler.
If we really want to unfold rep we should use the tactic unfold rep. Same for add_add.

I do understand that the general case of folding recursive definitions back is very complicated, so if you don't want to spend time on refining the code to see whether terms can be folded back, that's also fine, and then you can just close this issue. I can work around it, if necessary.


IGAPP-xx: Go live chatbot munich

This pull request belongs to an issue on our bugtracker.
You can find it there by looking for an issue with the key which is mentioned in the title of this pull request.
It starts with the keyword IGAPP.

Why closed? And is the branch still needed?

Sorry closed by mistake.