Internal Imagenet normalisation for pretrained resnet models

Consistent with inceptionV3 and googleNet pytorch implementation.

Codecov Report

Merging #784 into master will decrease coverage by 0.07%.
The diff coverage is 14.28%.

@@            Coverage Diff             @@
##           master     #784      +/-   ##
==========================================
- Coverage   38.13%   38.05%   -0.08%
==========================================
  Files          32       32
  Lines        3126     3132       +6
  Branches      487      488       +1
==========================================
  Hits         1192     1192
- Misses       1855     1861       +6
  Partials       79       79

Impacted Files
Coverage Δ

torchvision/models/resnet.py
16.54% <14.28%> (-0.75%)
:arrow_down:

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 9d9f48a...23e0618. Read the comment docs.

Same comment from https://github.com/pytorch/vision/pull/782#issuecomment-471199627 applies


Getting undefined reference to `printf_' when compiling as CMake library with -Os

I'm out of ideas, really...

cmake is order-sensitive, compiled printf last and it works


Compounds not included in the Sink

Hello,
I was trying to extract sink from different sbml models. When I compared the sink extracted by rptools and the compounds with MNXM IDs I extracted from the model manually, I noticed that some cytosolic compounds are not included in the sink by rptools. This might be due to there is no flux for these compounds. And, --remove_dead_end option is True as default. However, I could not make it work assigning it to any form of false.
python -m rptools.rpextractsink iJO1366.xml iJO1366_rmdeadends_false.csv --remove_dead_end False
python -m rptools.rpextractsink iJO1366.xml iJO1366_rmdeadends_false.csv --remove_dead_end FALSE
python -m rptools.rpextractsink iJO1366.xml iJO1366_rmdeadends_false.csv --remove_dead_end F
python -m rptools.rpextractsink iJO1366.xml iJO1366_rmdeadends_false.csv --remove_dead_end false
python -m rptools.rpextractsink iJO1366.xml iJO1366_rmdeadends_false.csv --remove_dead_end f

The response was always this depending on the "false" argument:
usage: rpextractsink [-h] [--log ARG] [--log_file LOG_FILE] [--silent] [--version] [--compartment_id COMPARTMENT_ID]
                     [--remove_dead_end]
                     input_sbml output_sink
rpextractsink: error: unrecognized arguments: f

How can I try it without removing dead ends?
I have another related question: I thought the compounds that are not included in the sink might be deprecated. RetroRules uses MNXref v3.0. The current release of MetaNetX is MNXref 4.4. Does rptools also use MNXref v3.0? There are many deprecation incidents with each new release. When I go to the MetaNetX page of a compound in the pathway resulting from RetroPath2.0, it is highly probable to see the compound is deprecated. I thought that I could update the compounds to their newest MNXM IDs. But the deprecations with each new release cause paths of IDs for the same compound.

The mappings are "one-to-one, many-to-one (merge) and one-to-many (split)" as described in the Search/Download MNXref namespace page, and also can be seen below.

Sometimes I observe that a compound deprecates into something very different (in my opinion). I asked about this issue to MetaNetX with an e-mail. But what do you think about the deprecations and how does it affect the pathway predictions? Does it have a relation with the reason that some compounds are not included in the sink formed by rptools.extractsink?

Hello @niraito,
To include dead-end metabolites, one needs to not write the option --remove_dead_end in the command line call. Taking the example you provide, it would be:
python -m rptools.rpextractsink iJO1366.xml iJO1366_rmdeadends_false.csv

Regarding the second part of your question, the sink extraction (as well as the dead end detection) is independant of MetaNetX. Basically, the sink extraction relies only on the SBML model, by listing the metabolites belonging to a given compartment (by defaut, the 'c' compartment, which corresponds to the cytosol in E. coli). For the dead-end detection, Flux Balance Analysis are used.
The MetaNetX deprecated relationships does not affect the pathway predictions, in the sens that, for a given set of reaction rules and sink, the predicted reactions and pathways remain the same than 3 years before (this is because we are using chemical structures to work, not IDs).
However, it's true that a lot of deprecated warnings now popup when browsing the MNX IDs, and make more difficult to explore results... (Releasing a new datasets is something plan in the future).
Regards,
Thomas

Hello again, dear @tduigou,
Thank you for helping me with the --remove_dead_end argument :)
However, I still have another question:
python -m rptools.rpextractsink iJO1366.xml iJO1366_sink_20221018.csv --compartment_id c
# number of cytosolic compounds: 808 (without header)
wc -l iJO1366_sink_20221018.csv

809 iJO1366_sink_20221018.csv

python -m rptools.rpextractsink iJO1366.xml iJO1366_sink_20221018_rmde.csv --compartment_id c --remove_dead_end
# number of cytosolic compounds, dead ends removed: 705 (without header)
wc -l iJO1366_sink_20221018_rmde.csv

706 iJO1366_sink_20221018_rmde.csv

From the sbml file, I can extract cytosolic compounds (by MNXM ids, not according to their chemical structures) manually:
# to extract list of species section:
cat iJO1366.xml | sed '/listOfSpecies/,$!d' > iJO1366_listOfSpecies_sed_intro.tmp
tac iJO1366_listOfSpecies_sed_intro.tmp | sed '/\/listOfSpecies/,$!d' | tac > iJO1366_listOfSpecies_sed_outro.tmp

cat iJO1366_listOfSpecies_sed_outro.tmp | grep 'MNXM' | sort -u | wc -l

1136

There are 1136 unique compounds or MNXM ids.
cat iJO1366_listOfSpecies_sed_outro.tmp | grep 'compartment="c"' | wc -l

1039

1039 compounds (or MNXM ids) out of 1136 are cytosolic.
But in the sink, there were 808 cytosolic compounds (or MNXM ids) (or 705, when dead ends are removed). Why do you think there is this difference? Could you help me find the reason I got them different in number?
Thank you for your time and patience!
Best regards,
Nilay

Hello again, dear @tduigou,
I checked the InChI columns of the sinks both extracted by rptools and the one that I retrieved from the sbml file (all MNXM IDs). And I saw that some of the MNXM compounds that I retrieved from the sbml file do not have InChI structures while all compounds in the sink extracted by rptools have InChI structures. Thank you for the explanation.
Also, I would like to use the output scopes of RetroPath2.0 in further steps of my research. What would you suggest to do about the deprecated compounds for now?
Thank you for your time and patience!
Best regards,
Nilay

Hi @niraito,
I would say it all depends of what will be done after RP2. Of course, if only chemical structure provided by the inchi matters, not the MNX IDs, then the status of deprecated are not important. If the MNX IDs are needed to establish crosslinks with other databases, then playing with the chem_xref files provided by MNX might be usefull find the links between deprecated and today's IDs.
Best wishes,
Thomas

Dear @tduigou,
Thank you for your time, patience, and guidance! I will need the crosslink information. Therefore, I will work on the chem_xref and other files from MNX.
Best regards,
Nilay


Add ability to send events via Resque/Sidekiq

Similar to the Celery/Redis support in the Python Tracker

Rescheduling for 0.6.0

This is no longer aligned with our roadmap. It's overkill for this tracker; we're looking into alternative solutions for version 1.0.0. Closing.


How to run in multi-gpus?

I use 4 gpus to train DDAIG, but the error happens "CUDA OUT OF MEMORY".
It seems the code only supports single-gpu training.

to allow multi-gpu training, you have to manually add nn.DataParellel to the model


New patter type not showed in the default 'ALL' page

Since in our team we have chosen to go for a different nomenclature, I added a new type of pattern, called elements.
PatternLab loads it correctly in the menu, and I can see the single subpattern. But they are not loaded together with the atoms/molecules/etc..
Is is there a way to add new patterns (with name different from the default) to the ALL section?
Thanks

My mistake.
I just realized I was not using the subtype level. Everything is working fine.


Detect & Warn Top Level Await Brick

The following code will potentially brick Vue component as the await won't be resolved until the script loads and the script can't load until the trigger is fired (which relies on the component being mounted in most cases).
<script setup>
const { $script } = useScript('..')

await $script.load()
// or await $script
</script>

Could we implement this as an eslint rule? (cc: @antfu)

I don't have the context, but is that saying that users should not await for $script coming from useScript? Should we provide auto-fix/suggestions as well?


Updates for Compatibility with Latest OpenAI API

Hi @alvesvaren,
First, thank you for creating this library. It helped me a lot when I switched from the Chat Completion API to the Assistants API using zod for tool validation. I couldn't have done it without your library.
I had to make a few changes to src/index.ts to work with the latest API version. The retrieval tool was replaced with file_search, and there were some type changes. I am currently using this modified file in my final thesis project. I thought it would be a good idea to contribute these changes back to your project. If accepted, I can use this library as an npm package.
Here are the changes:

Updated the OpenAI GPT model in the examples to gpt-4o-mini.
Updated the handling of messages.data[0].content[0] in the examples/openai-assistants.ts example to account for a new third type.
Changes to src/index.ts:

Updated type OpenAI.Beta.AssistantCreateParams.AssistantToolsFunction to OpenAI.Beta.FunctionTool openai-node link
Updated type OpenAI.Beta.Assistant.Retrieval to OpenAI.Beta.FileSearchTool openai-node link
Updated type OpenAI.Beta.Assistant.CodeInterpreter to OpenAI.Beta.CodeInterpreterTool openai-node link
Fixed and updated the aliases for the variable/const t and changed retrieval: { type: "retrieval" } to fileSearch: { type: "file_search" }.
Updated src/index.test.ts: type: "retrieval" to type: "file_search".

Thanks again for your work on this library.

I worked with Yarn locally and didn't realize that the openai dependency needs an upgrade, as does the zod peer dependency.

Nice! Thank you, I will have a look at it later.
I can update the dependencies and add a  changeset file :)
dependabot is just for automating new updates, you can update them manually too if you want

Wasn't able to update your branch for some reason, so moved this to #189

Now released as part of v0.12.0 :D, thanks again @aleksa-codes

@alvesvaren Nice! 😄 Thank you again for this package.


ips-pro: fix and improve model

fix dps value for the boost mode, it's "booster" here.
handle temperature dynamically
add cool and auto mode

Merged

Merged

even with hvac_action :heart_eyes:, thank you!


Please add support for Angular 17 New Control Flow

Angular 17 now offers new control flow, and there's already an extension available for VS Code https://github.com/angular/vscode-ng-language-service .
Here's a request to pelase add support for Angular new control flow in Visual Studio as well.

The current version of the extension appears to support the control flow syntax, so maybe this issue might be closed?


Item "id" in return dictionary of getFriendGamePlayed missing from documentation; queryPort should be query_port

Another documentation bug to fix:
According to the documentation at https://gramps.github.io/GodotSteam/functions-module.html, the return dictionary for the getFriendGamePlayed method has four items:

getFriendGamePlayed( int steamID )
Gets the details of a friend playing a joinable game.
Returns a dictionary:
ip (string)
gamePort (int)
queryPort (int)
lobby (int)

However, the actual return dictionary also has a fifth item, "id", which indicates the game id for the game the friend is playing:

id (int)

Additionally, the "queryPort" key (as documented) is "query_port" in the actual return dictionary (though for whatever reason gamePort is still in camelCase)

Yeah, that got changed since the last doc update.  If you find other things, please append them to this issue or your previous one instead of making multiple.  Thanks for checking up on them though!

Got it; sorry, didn't mean to spam issues

It's all good!  Just makes it easier for me if there is one big list instead of it spread out.
Currently re-writing the functions section with corrections that you mentioned, others I am finding, and links to the official Steamworks SDK documentation for reference.  It should be very helpful overall for everyone.

Both of these are now fixed in the next update!  Thanks again!


DO NOT MERGE: Update name/tag embedded into schema1 manifests (blocked on #332)

This vendors in https://github.com/containers/image/pull/88 , updates tests to pass now that schema1 manifests are being modified by the upload, and enables several tests which were previously broken by our incorrect schema1 support.  Fixes #290 .
Similarly to https://github.com/containers/image/pull/88, depends on, and includes, #336. I will rebase as necessary.
See the individual commit messages for more details.

@runcom PTAL as well, merging https://github.com/containers/image/pull/88 without this would break CI.

seems ok to me, we'll see what tests say on CI


Version change to 0.11.1

This change is

r? @Viv-Rajkumar

r? @vinipsmaker
(maidsafe_highfive has picked a reviewer for you, use r? to override)


Added go vet in test folder.

Added go vet in test folder
Fix test vet issues.

Fix #5788
Signed-off-by: Eloy Coto<EMAIL_ADDRESS>

This change is

test-me-please


Actions not triggering

I have a Gimbal Series 10.
This device rotates the bluetooth mac address every X minutes.
It seems that the app uses the bluetooth mac address as a key to identify the beacon.
This means that when the mac address changes the actions are not triggering anymore. The app thinks that it is a new device.
If I perform a new scan, I find my beacon there but with a new mac address.
When I tap on the beacon it is added to the list as a different beacon.
Maybe this should be changed. The UUID should be the only key that identifies the device.
I will try to take a screenshot and add it here to make it more clear.

yes, you are right.
currently identifier is build as
return getUUID() + ";" + getMajor() + ";" + getMinor() + ";" + getBluetoothAddress();
so i can remove bluetooth address, but i need to think/check how to avoid breaking existing users databases or old version of the app

Thanks for your fast reply vitas :)
By the way, apart from that, the app is really good, the best I found on Play Store for notifications.
It would be great if the issue can be fixed.
Thanks!

Hello,
Have you tried to solve it? I changed the identifier to be
return getUUID() + ";" + getMajor() + ";" + getMinor() + ";FF:FF:FF:FF:FF:FF";
However, it doesn't recognise the beacon as the same as before but as a new one. And without the MAC address it crashes.
Could you please help me find the part of your code that compares two beacons? I'm kind of confused, because I don't know the library you are using and it seems that equal() methods you created are not being used anywhere.
Thanks.

Hello vitas, I have the same problem with my gigaset g-tag. However this tag also changes it's major and minor.

Hello,
the app it's very fine but I don't understand why it's not possible, for me, into the app, test the action. I insert the action type and the action parameter then Execute but nothing. The action is enabled for the beacon.
Thanks

@theScrabi , @vakabus

I have tried to change to use only some GUID but then i  have a problem to identify already stored
beacon, it is always insert as new and will give duplicates in management view. I do not understand what purpose to have always changing major, minor or mac address, that is not correct.

@paperoga
for test action does not matter if the action is enabled..probably parameter is not correct. What type of action do you test? what parameters do you enter?

I enter:
Action type = Open Url
Action parameter = http://www.corriere.it
I've traced the source and in UrlAction.java, in public String execute(Context context) seems don't execute new CallUrl<>(param).start().

Hi,
Have you some news for me ?

@vitas I don't know why my tag is doing that but it does. However I found out that my G-Tag does not have a common beacon protocol, so that does not matter. I'll buy a iBeacon compatible device in the next few day, and check if that works.

@paperoga
i have uploaded new version on google play, have added new action what is similar to open url but opens url in web browser, looks like that is what you want. "Open Url" action just makes request to url in background without browser, for example you need to trigger something on your own service

Now it's ok.
Thanks


dns.RecordSetsClient#CreateOrUpdate fails with "The location property is required for this definition."

I try to create a DNS record following the example here https://github.com/Azure/azure-sdk-for-go/pull/600/files (@xtophs) and I get this error:
FATA[0003] dns.RecordSetsClient#CreateOrUpdate: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="LocationRequired" Message="The location property is required for this definition."

(Here the code: https://github.com/symbiont-io/external-dns/blob/4f2c85e30da9edcdf73a9effac45943ae6d17a93/provider/azure.go#L175-L197)

You may want to connect with @peterhuene, who's also working on an external DNS provider: https://github.com/peterhuene/external-dns
I haven't see this error when creating a RecordSet, only creating zones. What parameters are you passing to the CreateOrUpdateCall?

We're about to submit the work from the azure branch as a PR once I finish up a few more unit tests.  Ideally the PR will go up this afternoon.
I also have not seen this error when creating records sets, only zones (which have a location property).

For reference, the PR is up at https://github.com/kubernetes-incubator/external-dns/pull/214

@peterhuene great !! Will try to test your branch today. Only me get the error so closing the issue for now. Will re-open if happen again with the @peterhuene branch.


Weather-App

Add weather app using HTML,CSS ,JS
Assign me under GSSOC'22
@abhijeet007rocks8

Hey @Atif0604 , You can work on this issue. I'll be assigning it to you.

@Atif0604 while creating PR please follow all the Contribution Rules which are mentioned in the issue #43 .

Okay


OpenSSL 1.0.x is dead

OpenSSL project has deleted 1.0 tarballs

All of them? Just yesterday I was fighting with something that was not working right, and just switched the letter.

The website doesn't list any 1.0 versions, even in historical snapshots. I presume that they're so unmaintained, it'd be unwise to even try to find them.


Update Go version to 1.20

Feature Request
Update Go version to 1.20.
Refer to TiDB, PD:

https://github.com/pingcap/tidb/blob/v7.2.0/go.mod#L3
https://github.com/tikv/pd/blob/v7.2.0/go.mod#L3

close as https://github.com/pingcap/tidb-dashboard/pull/1709 merged


[Jisho] Add Search History

Description
PR for #4120
I refactored the search command with new Raycast utils and then added a Search History command.
The Search History command is pretty simple, it shows the previous searches by the user. Previous searches are saved when the user runs an action (copy/open in browser) on a search result and also when the search bar is cleared (this can be toggled off in the extension preferences).
Saved search results will be shown with as much info as they have. For search results, we show the result directly. For saved search queries, only the query is shown. Search entries are deduplicated such that any entry that gets re-added will only be moved up to the top of the history (not added twice).
I also changed the search command to allow for initial search queries. This is used when a user selects a previous search query to launch the search command with the initial query set.
Just realized that there is no delete functionality and no manual add, I'll add these two things before pushing for a merge.
Screencast

Checklist

[ x ] I read the extension guidelines
[ x ] I read the documentation about publishing
[ x ] I ran npm run build and tested this distribution build in Raycast
[ x ] I checked that files in the assets folder are used by the extension itself
[ x ] I checked that assets used by the README are placed outside of the metadata folder

@dmacdermott this should be ready for merge, let me know if you have any questions. I don't really know the procedure for review here at Raycast.

I moved from launchCommand to Action.Push since that provides a way for the user to navigate back to the search history and continue from there. I'm not sure which one is preferred.

Done 👍

@dmacdermott is this ready for merge?

@mmtftr Yeh looks good ok to me 👍
@pernielsentikaer Is it possible if this pr can get merged? Cheers


Fatal error with > 255 translation strings

According to the JVM spec:

The number of method parameters is limited to 255 by the definition of a method descriptor.

Because of this, it seems impossible to have more than 255 translation strings defined with lyricist:
Strings.kt:
package com.example.translations

data class Strings(
  val s1: String,
  val s2: String,
  val s3: String,
  // ...
  val s256: String,
)

EnUSStrings.kt:
package com.example.translations

import cafe.adriel.lyricist.LyricistStrings

@LyricistStrings(languageTag = Locales.EN_US, default = true)
val EnUSStrings = Strings(
    s1 = "1"
    s2 = "2"
    s3 = "3"
    // ...
    s256 = "256" // starts throwing obscure error at this point
)

The project builds fine, but I get the following obscure error at launch time:
FATAL EXCEPTION: main
    Process: com.example.app, PID: 3919
    java.lang.VerifyError: Verifier rejected class com.example.translations.EnUSStringsKt: void com.example.translations.EnUSStringsKt.<clinit>() failed to verify: void com.example.translations.EnUSStringsKt.<clinit>(): [0x1B5D] Rejecting invocation, expected 32 argument registers, method signature has 33 or more (declaration of 'com.example.translations.EnUSStringsKt' appears in /data/app/~~om5MwkBVj9HGhO0i8RIbKQ==/com.example.app-9CsHVxFyi-qyH5k4yNO6ZQ==/base.apk)
        at com.example.translations.EnUSStringsKt.getEnUSStrings(EnUSStrings.kt:6)
        ...

And after doing some research about this error it leads me to the aforementioned JVM limit, which makes sense in my case.
Is there a work around to get around this limitation? Or am I missing something?

Solved it by using an interface and regular class instead. It's unfortunate, but I suppose I'll just have to accept the limitations of Kotlin and JVM :man_shrugging:
Example:
Strings.kt:
package com.example.translations

interface Strings {
  val s1: String
  val s2: String
  val s3: String
  // ...
  val s256: String
}

EnUSStrings.kt:
package com.example.translations

import cafe.adriel.lyricist.LyricistStrings

class EnUSStringsClass : Strings {
    override val s1 = "1"
    override val s2 = "2"
    override val s3 = "3"
    // ...
    override val s256 = "256" // no longer throws at this point
}

@LyricistStrings(languageTag = Locales.EN_US, default = true)
val EnUSStrings = EnUSStringsClass()


External tool user

In my role as....
An external tool user
I need to be able to...
Use a single tool (index calculation, bias correction, etc. )
in order to...
Apply it to an independent dataset

Need to define early in process - do we "allow" cherry picking of part of the processing chain.


Made a better example for easy understanding

Hi Kemal,
I changed the example a little bit so people can understand what the current screen is actually comparing with. I changed the example site to example.com just like in puppeteer docs.
Thank you for this tool. Super useful!

Than you i will review your comments.


Add incidence rate to Table 3 transitions popultation statistics

Add incidence rate in brackets after prevalence:
Cancer Prevalence (Incidence) - 9.7% (1.5%)
Could also add few more rows for other important chronic diseases - Lung disease, stroke, hypertension etc.

Incidence rate included, script to calculate incidence is in FEM_R/


CDN missing recent v3.24.1

Today was released Raven.js v3.24.1 https://github.com/getsentry/raven-js/releases/tag/3.24.1, but it still isn't found in CDN https://cdn.ravenjs.com/3.24.1/raven.min.js

Also https://ravenjs.com shows outdated v3.20.0

FYI https://cdn.ravenjs.com/3.24.0/raven.min.js is found.

Purged CDN cache. https://cdn.ravenjs.com/3.24.1/raven.min.js should work just fine now. Can you re-verify please?

@kamilogorek, https://cdn.ravenjs.com/3.24.1/raven.min.js is fine now, thanks! But what with https://ravenjs.com - mustn't it show v3.24.1?

@laukstein it should, I always forget about it and should probably automate it at one point :P
Fixed :)


Why 'Graph' tab is not exist during visualization ?

Name: graph-notebook
Version: 3.1.1
Summary: jupyter notebook extension to connect to graph databases
Home-page: https://github.com/aws/graph-notebook
Author: amazon-neptune
Author-email<EMAIL_ADDRESS>License: UNKNOWN
Location: /Users/lidongze/Library/Python/3.9/lib/python/site-packages
Requires: boto3, botocore, gremlinpython, ipykernel, ipython, ipywidgets, jedi, Jinja2, jupyter, jupyter-contrib-nbextensions, nbconvert, neo4j, networkx, notebook, rdflib, requests, requests-aws4auth, SPARQLWrapper, widgetsnbextension
Required-by:

Could someone can tell me how to visualize the graph during gremlin magic function like this ? thanks.

Hi @lidongze0629, for the graph tab to be rendered, the Gremlin query and the %%gremlin line arguments must satisfy certain conditions.
I'll start with the second query, as it's more straightforward. For a Gremlin query result to be visualized, it must be a path. As the query g.V() only returns vertices, the graph tab is not displayed.
For the first query, the visualizer fails because the provided path pattern -p v,oute,inv,oute,inv,oute,inv expects paths containing four vertices connected by explicitly returned edges. Your query returns paths following a different sequence, three vertices with no explicit edges returned.
If we amend the path pattern to -p v,inv,inv to match the query results, the graph will be displayed as intended:

Please do take a look at our tutorial notebooks, which provide excellent walkthroughs of how to use visualize queries. These notebooks are included with the graph-notebook package, you can install and launch them from a local directory by running:
# copy premade starter notebooks
python -m graph_notebook.notebooks.install --destination ~/notebook/destination/dir

# start jupyter
python -m graph_notebook.start_notebook --notebooks-dir ~/notebook/destination/dir

@michaelnchin Thanks very much for your detailed reply, it's helpful for me.


Migrate does not recognize changes made to a field of type String to ENUM

Bug description
Prisma migrate has some weird behavior when it comes to ENUMs. I made a change to a model consisting of making a field of type String required and also changing the type of another field from String to ENUM like NewEnumType. When running migrate dev command, the generated migration included the first change only. I then manually altered the table and introspected again, it could see the ENUM, but all other ENUM fields that I added to the datamodel were gone. So I basically have to manually alter multiple models instead of achieving that through migrate.
How to reproduce

Migrating from<EMAIL_ADDRESS>to the latest version.
the upgrade cli had an issue of recognizing ENUMs, it just branded them as of type MEDIUMTEXT

1- Change a field name in a model.
2- Change another field type in the same model to an ENUM type; like ItemType.
3- Defined enum ItemType at the bottom of the datamodel file.
4- Ran migration dev.
5- Generated migration included the name change only.
Expected behavior
The generated migration should have recognized that there has been a change to a field of type String to ENUM.
Prisma information
Using the latest Prisma 2.17
Environment & setup

OS: Ubuntu 18
Database: MySQL hosted on RDS
Node.js version: 14.15.1
Prisma version:

prisma               : 2.17.0
@prisma/client       : 2.17.0
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine 3c463ebd78b1d21d8fdacdd27899e280cf686223 (at<EMAIL_ADDRESS>Migration Engine     : migration-engine-cli 3c463ebd78b1d21d8fdacdd27899e280cf686223 (at<EMAIL_ADDRESS>Introspection Engine : introspection-core 3c463ebd78b1d21d8fdacdd27899e280cf686223 (at<EMAIL_ADDRESS>Format Binary        : prisma-fmt 3c463ebd78b1d21d8fdacdd27899e280cf686223 (at<EMAIL_ADDRESS>Studio               : 0.353.0

I can confirm this. The steps are correct for a reproduction.


Add new filter/transform, fix issue #12 exploitable js4_dq_fp

#12 should be fixed, the resulting source from
http://<IP_ADDRESS>:8088/xss/reflect/js4_dq_fp?in="};alert%281574%29;%20f%20=%20{// is:

CLA is valid!


Refactor stub extension generator

This PR refactors the implementation of the grpc stub extension generator. It also adds support for generating stub extensions based on method signature annotations.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@89b1188). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #75   +/-   ##
=========================================
  Coverage          ?   84.96%
  Complexity        ?       19
=========================================
  Files             ?       15
  Lines             ?      306
  Branches          ?       49
=========================================
  Hits              ?      260
  Misses            ?       16
  Partials          ?       30

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 89b1188...ff87fb8. Read the comment docs.


Card image card-img-top bad antialiasing in Safari / MacOS

Hello guys,
I just noticed that images put inside card element with class card-img-top have a problem with antialiasing with Safari. Basically depending on the size of the windows of browser a sort of semi transparent border of 1px is put at the left or the right of the image.
I suppose it's due to the antialiasing. This issue happens just with Safari.

As you can see from the file attached (it's the right part of a card element with an image) there's a sort of 1px border on the right. Magnifying the border you can notice that's a semi-transparent part of the image.
Is there any work-around? It's very annoying mostly when you change the background of the card in case of :hover like I do.
Thanks
S

You're likely to encounter that in nearly any browser when they render half pixels. Not anything we can do about that unfortunately.


Use ESBuild instead of Webpack

Hello, as webpack is no longer what the cool kids use, I'm wondering if you would be open to swapping it for esbuild?

I'm not opposed in theory, but my experience with js build systems is rooted in much pain and so I wonder how much effort it would be to make the change.

Yeah, it's just an effort question to me. The current setup has worked for a while and it's the part of the codebase I'm least-comfortable with, so I'm change-averse.

I might give it a try this weekend, one can know if it'll work under a couple of hours so if I face anything weird I'll report back

Nice! Would be great if we could get a fable and esbuild watch kind of thing going on.

hot reload?! https://blog.hediet.de/post/hot_reload_for_vs_code_extension_development

I went out and checked (with  vite as opposed to raw esbuild) and after some inspection and looking after the code I have a few questions:

What is the main reason webpack is/was being used?
Do we even want webpack/esbuild/vite at all?

I can only think webpack was there to transpile back early fable code where electron didn't support esm, and perhaps even some ES201X features, this is no longer the case the recent node/electron versions support all of the features that fable transpile as far as I'm aware, we could ditch it entirely to be honest.
The only reason I can think to have an extra build/bundling tool would be if extensions need to have bundled javascript files rather than transpiled and minified source code.
I think we should be able to just run fable in watch mode in the back and then just launch the extension with the direct output of fable there would be some work to be done in regards imported members without extensions but I think over all it could be worth exploring
thoughts?

That's an interesting idea for sure. I don't think we do anything special - as long as we can emit source maps that should be all we need. The VSCode docs highly suggest bundling for a perf benefit, but realistically our extension isn't really that large at all. Perhaps shipping an unbundled version would be better for debugging?

I would still bundle for production as the docs say, you don't know upfront what target (desktop/browser) you are dealing with so you want maximum coverage.
It would be super cool if while developing you would only need Fable (in watch mode) and can have that extension reload working. That would really be the sweet spot I think.

Hey Sorry I forgot to report back here
I just committed my attempt on my fork I know it worked but I didn't test it too much (hence why no PR) in case anyone wants to check it out
https://github.com/ionide/ionide-vscode-fsharp/compare/main...AngelMunoz:main


feat: ui updates

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


Feat/sdk 25r1

Updating Pytwin TwinRuntime SDK with 2025R1 version

Codecov Report
Attention: Patch coverage is 7.59494% with 73 lines in your changes missing coverage. Please review.

Project coverage is 84.95%. Comparing base (8fc0270) to head (bc87957).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #223      +/-   ##
==========================================
- Coverage   87.74%   84.95%   -2.80%
==========================================
  Files          11       12       +1
  Lines        2555     2638      +83
==========================================
- Hits         2242     2241       -1
- Misses        313      397      +84

@chrpetre it would be good to add a coverage of the src/ansys/pytwin/twin_runtime/constants.py.


Hotfix/issue#134

This change is

Details of fix
When no search phrase is typed, 'browse all services' page is displayed.

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

Comments from Reviewable


Don't call API#setup twice

Self-descriptive. No need to call #setup because #initialize already calls it.

@hubert ?

hi @marshall-lee, i know you didn't introduce this issue, but how do you feel about removing the 'self' part from the initialize method. at a glance it's misleading when you're tracing the code from setup to initialize.
otherwise G2G.

@hubert done!

beautiful @marshall-lee
thanks!


[$100 bounty] mapsd: switch to static render mode

Now that we're on MapLibre (https://github.com/commaai/openpilot/pull/31185), hopefully we can use the static rendering mode here: https://github.com/commaai/openpilot/blob/03c183cb052ff1d9da5c7a927f0abbb37434fe2a/selfdrive/navd/map_renderer.cc#L117.
Currently, the map renderer abuses the Qt event loop and forces it to process the full event queue to achieve behavior that we'd expect from the static rendering. The goal is to replace that janky logic with the proper static rendering mode.

Hello, I am new to Open Pilot, and I would like to work on this issue, for starters I have simply removed the for loop, just kept the update function and if (rendered()) condition in map_renderer.cc. However while testing the files and running "mapsd", I get these errors (I have created the Mapbox api token and added it to environment variable ), can you please tell me if I am going in right direction, thank you.

Starting listener for: navd
: [ ERROR ]  "{unknown}[General]: The resource https://api.mapbox.com/styles/v1/commaai/ckvmksrpd4n0a14pfdo5heqzr/bkx9h9tjdf3xedbnjvfo5xnbv/sprite.json not found"
: [ ERROR ]  "{unknown}[General]: The resource https://api.mapbox.com/styles/v1/commaai/ckvmksrpd4n0a14pfdo5heqzr/bkx9h9tjdf3xedbnjvfo5xnbv/sprite.png not found"
: [ ERROR ]  "{unknown}[Style]: Failed to load sprite: HTTP status code 404"
: [ ERROR ]  "{unknown}[Style]: Failed to load sprite: HTTP status code 404"


Create codeql-analysis.yml

@eddynaka Merged within 5 minutes with no description and no review?

SDL compliance task.
Adding to all repos that we are missing.

I think it's important note that (SDL compliance) initially in the PR (or the YAML). Not all contributors may be aware of that.
How does this overlap or not overlap with the existing LGTM integration?

Both LGTM and CodeQL uses the same queries.
CodeQL is more integrated with the Security tabs and we can run based on crons.
LGTM is more integrated with PRs. So, you will see the issues once you create a PR.
IF your project gets stale, for example, and a vulnerability starts to exist, LGTM would not notify you, since it only works based on PRs.
Now, CodeQL works on crons and PRs (merged), when that happens, we would receive the notifications.

LGTM is more integrated with PRs. So, you will see the issues once you create a PR.

I'm seeing the equivalent functionality with the CodeQL action. Can you quantify the "more integrated" part? If the CodeQL action is a superset, then do we need both?

LGTM is more integrated with PRs. So, you will see the issues once you create a PR.

I'm seeing the equivalent functionality with the CodeQL action. Can you quantify the "more integrated" part? If the CodeQL action is a superset, then do we need both?

If we have an issue during PR, for example, an unused variable. During PR, LGTM would say: 'you have an unused variable, you can remove'. Since CodeQL can take time to execute, it's not advisable to run during PR.
Below, all the rules that it ran:

https://github.com/microsoft/sarif-vscode-extension/pull/391/checks?check_run_id=2998930639
https://lgtm.com/projects/g/microsoft/sarif-vscode-extension/logs/languages/lang:javascript

"more integrated": once it finds an issue, it will post results here: https://github.com/microsoft/sarif-vscode-extension/security/code-scanning.
About the rules, per CodeQL repository, they share the same set of rules:
This open source repository contains the standard CodeQL libraries and queries that power LGTM and the other CodeQL products that GitHub makes available to its customers worldwide.

references:

https://github.com/github/codeql


Data redaction before sending to server

Describe the feature or enhancement
I am trying to integrate Umami on a Next.js (pages router) website hosted on Vercel.
I am switching over from Vercel Analytics, however, there is one big feature that missing: the option to redact/modify data, before it is sent to the analytics server.
Vercel Analytics has a beforeSend function, which exposes the 'event' data object that you can then modify or even return null to completely avoid sending certain analytics. Docs
This allows us to not report usage on certain private routes (e.g. /private/*) and to redact sensitive data from others (e.g. /password-reset/[SENSITIVE_HASH_TOKEN]).
Looking at the Umami docs, there seem to be Tracker Functions available if your turn-off data-auto-track.
The following would allow you to redact data:
umami.track(props => ({ ...props, url: '/home', title: 'Home page' }));

however, it would require you to pretty much rewrite all the tracking logic to account for all the initial page-loads, direct navigations, reloads, client-side navigations, etc.
I still want to "auto-magically" collect all the page-view data, I just want to redact some of it.
I believe the above could be most easily accomplished with some kind of an init function or even better an easily integrable npm package: #2776

This makes sense to add.


Images aren't drawing

None of the methods for drawing images are working for me, i'd provide stack trace if there was one. It just completely skips over the process or at least that's what it seems like
Example: .addCircularImage(avatar, 20, 26, 64)

I need more context, what version of canvas and canvas-constructor are you using? What's the full code for this?

canvas: ^2.5.0
canvas-constructor: ^3.0.1,
const fetched = await fetch(msg.member.user.displayAvatarURL());
if(!fetched.status !== 200) return this.client.utils.error('Failed To Get Avatar')
const targetAvatar = await result.buffer();
console.log(targetAvatar)
return new Canvas(400, 180)
.addCircularImage(targetAvatar, 20, 26, 64)
.toBufferAsync()
```i wish i could provide more but it just shows no signs of an error or a problem.

Try this:
  const fetched = await fetch(msg.member.user.displayAvatarURL());
- if(!fetched.status !== 200) return this.client.utils.error('Failed To Get Avatar')
+ if (!fetched.ok) return this.client.utils.error('Failed To Get Avatar');
  const targetAvatar = await fetched.buffer();
  console.log(targetAvatar);
  return new Canvas(400, 180)
    .addCircularImage(targetAvatar, 20, 26, 64)
    .toBufferAsync()

And I think it doesn't work because displayAvatarURL will either give a webp, or a gif, both unsupported in Canvas, you need a jpg or a png:
- const fetched = await fetch(msg.member.user.displayAvatarURL());
+ const fetched = await fetch(msg.member.user.displayAvatarURL({ format: 'png' }));

With those changes, this should work.

That did the trick, thank you very much!


BUG: uint (i.e. uint32) compared to 1 << 62

I came across this when v0.0.15 wouldn't compile with gopherjs
This check
I've filed an issue with gopherjs since technically it compiles in go but not gopherjs.
But, it seems like an oversight in the cue impl since i is a uint uint from the received context will never be greater than 1<<32 and branch based on the conditional would never be executed.  I believe it's akin to an  if false branch...
Perhaps I am mistaken through and it does serve the intended purpose, if that is the case could we adjust the impl from
1850: if i > 1<<62 {

to
1850: if uint64(i) > uint64(1)<<62 {

to work around the bug in gopherjs and help support the npm cuelang package

Could you try if changing the return type for uint() from uint to uint64?  (And similarly that for int()frominttoint64`)? That should fix it.

@mpvl If I'm understanding you correctly

(And similarly that for int()frominttoint64`)?

Is referring to the argument passed to Bit here
Which results in an error:
$ gopherjs build -o ./build/__CUE__.js ./src/cue.go
../../../.golang/src/cuelang.org/go/cue/builtins.go:1853:20: cannot use int64(i) (value of type int64) as int value in argument to x.Bit

https://golang.org/pkg/math/big/#Int.Bit

This issue has been migrated to https://github.com/cue-lang/cue/issues/227.
For more details about CUE's migration to a new home, please see https://github.com/cue-lang/cue/issues/1078.


meaning of SAMPLE_GROUPS parameter for ground truth sampling's config file

Hi,
does anyone know what's the meaning of SAMPLE_GROUPS in the config file waymo.yaml?
DATA_AUGMENTOR:
    DISABLE_AUG_LIST: [ ]
    AUG_CONFIG_LIST:
        - NAME: gt_sampling_T
          USE_ROAD_PLANE: False
          DB_INFO_PATH: [gt_datainfo]
          PREPARE: {
              filter_by_min_points: [ 'Car:10', 'Pedestrian:5', 'Cyclist:5', 'Van:20' ],
              filter_by_ranges: [-50.0, -50.0, -2, 50.0, 50.0, 4]
          }
          SAMPLE_GROUPS: [ 'Car:40','Pedestrian:30', 'Cyclist:30', 'Van:10' ]
          NUM_POINT_FEATURES: 4
          DATABASE_WITH_FAKELIDAR: False
          REMOVE_EXTRA_WIDTH: [ 0.2, 0.2, 0.2 ]
          LIMIT_WHOLE_SCENE: True

It's set to           SAMPLE_GROUPS: [ 'Car:40','Pedestrian:30', 'Cyclist:30', 'Van:10' ] in my config but I am not sure about the meaning.

I guess it's the target number of objects in each frame, judging from this line from database_sampler:
sample_group['sample_num'] = str(int(self.sample_class_num[class_name]) - num_gt)

It seems that sample_group parameter was set to balance the sample numbers for different categories and to eliminate the long tail.  Right?

It is there to balance the imbalance of foreground (belonging to objects we want to predict) vs. background points (not belonging to any object). Without augmenting additional objects, this imbalance would be much bigger. Still, after this augmentation, there are typically way more background than foreground points in a scene.


Added support for mount points

added AddMountPoint() together with support for st_ino and st_dev
adapted GetDiskUsage() and ChangeDiskUsage() to use the file system given by path, added SetDiskUsage() convenience function
added FakeOsModule.ismount() implementation
moved rename implementation to FakeFilesystem.RenameObject(), adapted
it and shutil.move() to correctly behave with same and different file systems
added auto-mount for Windows drives and UNC paths and some related fixes
adapted/added tests
Fixes #25

Forgive me, I forgot to mention that this is TOTALLY AWESOME!


Stuck at JNI boundary?

Background
A Java application has ties to a C/C++ program via the JNI.
Problem
ORT did not complete processing the build.gradle file, yet gave no indication as to an error.
  ~/dev/ort/bin/ort --info analyze -f JSON -i . -o ./ort/analyzer
  12:34:06.484 [DefaultDispatcher-worker-1] INFO  org.ossreviewtoolkit.analyzer.PackageManager - Resolving Gradle dependencies for path 'conformance/build.gradle'...

Expected
ORT shows an error to indicate that it encountered an issue resolving licensing information or the hanging loop prints a progress report to the user to indicate what's happening.
Actual
ORT hangs. After 30 minutes, no progress made, I stopped ORT.
Work around

Comment out the references to JNI projects in conformance/build.gradle.
Re-run ORT.

This allowed ORT to proceed without hanging. (At least until the troublesome JNI project was referenced from another project, which resulted in another hang, but it appears to be the same issue.)

Comment out the references to JNI projects in conformance/build.gradle.

Are you able to share the source code to the project?
Also, do you get more details when running with --debug?

Are you able to share the source code to the project?

Proprietary, sorry. I'll see about running with --debug (aside, it'd be nice to add that option to the README.md file in the debugging section).

Ran using:
~/dev/ort/bin/ort --debug --info analyze -f JSON -i . -o ./ort/analyzer

No additional processing information was written to the console.
Perhaps the first task in tracking this down would be to add more logging into the system around the resolver?
13:13:20.211 [DefaultDispatcher-worker-1] INFO  org.ossreviewtoolkit.analyzer.PackageManager - Resolving Gradle dependencies for path 'project.name'...

No additional processing information was written to the console.

That's probably because you use both --debug and --info, and the latter overrides the former. Please use --debug instead of --info (or put --debug last).

Hangs here:
14:32:37.186 [DefaultDispatcher-worker-1] DEBUG org.gradle.tooling.GradleConnector - Connecting from tooling API consumer version 7.5.1

Comment out the references to JNI projects in conformance/build.gradle.

Are you able to share the source code to the project?
Also, do you get more details when running with --debug?

Comment out the references to JNI projects in conformance/build.gradle.

Are you able to share the source code to the project?
Also, do you get more details when running with --debug?

We are having the same issue, but without any JNI dependency whatsoever. Unfortunately the --debug flag is not offering more information than the one already mentioned in this issue. So how to proceed?

So how to proceed?

Are you maybe in a position to debug this yourself? Eventually, adding more logger.debug statements to init.gradle could also give a clue where it's hanging.

Do you see the "Gradle may use a maximum of XXXX MiB of memory" message somewhere in the log output?
Alternatively, can you share the project you're analyzing?

Unfortunately I cannot share. But I can provide the relevant logs (even though I have to cut any company information, replaced with XXX):
`17:35:13.899 [main] INFO  org.ossreviewtoolkit.utils.ort.OrtAuthenticator - Authenticator was successfully installed.
17:35:13.913 [main] INFO  org.ossreviewtoolkit.utils.ort.OrtProxySelector - Proxy selector was successfully installed.
Found 3 Gradle definition file(s) at:
build.gradle
app/build.gradle
demo/build.gradle
Found 3 definition file(s) from 1 package manager(s) in total.
17:35:13.974 [main] INFO  org.ossreviewtoolkit.analyzer.Analyzer - Starting Gradle analysis.
17:35:13.985 [DefaultDispatcher-worker-1] INFO  org.ossreviewtoolkit.analyzer.PackageManager - Resolving Gradle dependencies for path 'build.gradle'...
17:35:14.017 [DefaultDispatcher-worker-1] DEBUG org.gradle.tooling.GradleConnector - Connecting from tooling API consumer version 7.5.1
17:35:14.087 [Connection worker] DEBUG org.gradle.tooling.internal.consumer.loader.DefaultToolingImplementationLoader - Using tooling provider from Gradle distribution 'XXX/gradle-7.5.1-all.zip'
17:35:14.087 [Connection worker] DEBUG org.gradle.tooling.internal.consumer.loader.DefaultToolingImplementationLoader - Using tooling provider classpath: [XXX]
17:35:27.356 [DefaultDispatcher-worker-1] DEBUG org.ossreviewtoolkit.analyzer.managers.Gradle - Analyzing the project in 'XXX-app' produced the following standard output:
Gradle may use a maximum of 8192 MiB of memory.
> Configure project :
XXX

> Configure project :app
XXX

> Configure project :demo
XXX

CONFIGURE SUCCESSFUL in 13s

17:35:27.361 [DefaultDispatcher-worker-1] DEBUG org.ossreviewtoolkit.analyzer.managers.Gradle - The Gradle project 'XXX-app' uses the following Maven repositories: [XXX]
17:35:27.538 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - readpipe [/usr/bin/git, --version],/usr/bin
17:35:27.540 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - readpipe may return 'git version 2.34.1'
17:35:27.540 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - remaining output:
17:35:27.541 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - readpipe [/usr/bin/git, config, --system, --show-origin, --list, -z],/usr/bin
17:35:27.544 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - readpipe may return 'file:/etc/gitconfigfilter.lfs.clean'
17:35:27.544 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - remaining output:
17:35:27.544 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - git-lfs clean -- %ffile:/etc/gitconfigfilter.lfs.smudge
17:35:27.544 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - git-lfs smudge -- %ffile:/etc/gitconfigfilter.lfs.process
17:35:27.544 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - git-lfs filter-processfile:/etc/gitconfigfilter.lfs.required
17:35:27.544 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.FS - true
17:35:27.545 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.SystemReader - loading config FileBasedConfig[/etc/gitconfig]
17:35:27.546 [DefaultDispatcher-worker-1] DEBUG org.eclipse.jgit.util.SystemReader - loading config FileBasedConfig[XXX/.gitconfig]
17:35:27.595 [DefaultDispatcher-worker-1] WARN  org.ossreviewtoolkit.analyzer.managers.Gradle - Project uses an Ivy repository which is not supported by the analyzer. Dependencies from this repository will be ignored: XXX
17:35:27.601 [DefaultDispatcher-worker-1] INFO  org.ossreviewtoolkit.analyzer.PackageManager - Resolving Gradle dependencies for path 'build.gradle' took 13.607519556s.
17:35:27.601 [DefaultDispatcher-worker-1] INFO  org.ossreviewtoolkit.analyzer.PackageManager - Resolving Gradle dependencies for path 'app/build.gradle'...
17:35:27.601 [DefaultDispatcher-worker-1] DEBUG org.gradle.tooling.GradleConnector - Connecting from tooling API consumer version 7.5.1`
It is an Android project. As you can see we have three build.gradle files in it. The root file contains variables containing the version numbers we are adding as implementation dependencies to the app and demo module, e.g.
implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:$kotlinx_coroutines_version" Could this lead to a problem? Other teams in our project do it the same way and aren't experiencing the current issue, so I guess it should work.
Thanks for taking a look and helping!

Could this lead to a problem?

I don't think so.
Could you maybe try to minimize your project to that it still reproduces the issue, but does not contain any private information, and then share it? Or alternatively, try to modify our existing Android test project so that it reproduces the issue?

Unfortunately I cannot strip down the project to publish it (too much effort), so I took your example and adapted it step by step. I found three dependencies responsible for ORT hanging at the Connecting from tooling... message in combination with a setting in our gradle.properties file. Project is uploaded here: https://github.com/mpbecker/OSS_debug
Further information how to reproduce are found here: https://github.com/mpbecker/OSS_debug/blob/c00626e9b178acfcdfb8f7adb03707bfda431c21/app/build.gradle#L63
All tested with the latest Android Studio version on a Ubuntu machine. Please let me know if you can reproduce, so maybe we can do some further investigations. Thanks!

I just tried an older version for Hilt: going back from 2.44 to 2.43.2 seems to solve the issue. No clue what they changed there, but maybe that could give a hint what could cause the problem.

I just tried an older version for Hilt: going back from 2.44 to 2.43.2 seems to solve the issue.

I can reproduce the issue, that's great, thanks for that! However, I also see it hanging with Hilt 2.43.2.

Changing the lines
https://github.com/oss-review-toolkit/ort/blob/63b2b2d3e29b822ff75af42772682f35bf5e3a31/analyzer/src/main/kotlin/managers/Gradle.kt#L204-L205
to read
.setStandardOutput(System.out)
.setStandardError(System.err)

yields on-the-fly output that shows that analysis is actually not hanging, but extremely slow, and this message shows up for every Gradle configuration:
Configuration 'amazonDemoDebugAndroidTestAnnotationProcessorClasspath' was resolved during configuration time.
This is a build performance and scalability issue.
See https://github.com/gradle/gradle/issues/2298

Oh wow, thanks for revealing what's going on here! Well that's somehow annoying since I left ORT running for our Project for about 7 hours hanging at this message and then finally canceled the task :D And the machine was quite powerful. So it seems we are stuck here or have to live with the fact that it could take hours to run ORT or do you have any idea how to tackle this? I must admit, I am not that familiar with Gradle config, etc.

Here's a stacktrace:
at com.android.build.gradle.internal.DependencyResolutionChecks$registerDependencyCheck$4$1.execute(DependencyResolutionChecks.kt:84)
at com.android.build.gradle.internal.DependencyResolutionChecks$registerDependencyCheck$4$1.execute(DependencyResolutionChecks.kt:62)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:95)
at org.gradle.internal.event.BroadcastDispatch$ActionInvocationHandler.dispatch(BroadcastDispatch.java:83)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:43)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:245)
at org.gradle.internal.event.BroadcastDispatch$SingletonDispatch.dispatch(BroadcastDispatch.java:157)
at org.gradle.internal.event.AbstractBroadcastDispatch.dispatch(AbstractBroadcastDispatch.java:61)
at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:346)
at org.gradle.internal.event.BroadcastDispatch$CompositeDispatch.dispatch(BroadcastDispatch.java:249)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:141)
at org.gradle.internal.event.ListenerBroadcast.dispatch(ListenerBroadcast.java:37)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
at com.sun.proxy.$Proxy48.beforeResolve(Unknown Source)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.performPreResolveActions(DefaultConfiguration.java:811)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$400(DefaultConfiguration.java:159)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$1.call(DefaultConfiguration.java:654)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$1.call(DefaultConfiguration.java:647)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:204)
at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:199)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:66)
at org.gradle.internal.operations.DefaultBuildOperationRunner$2.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:157)
at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:59)
at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:53)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:73)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveGraphIfRequired(DefaultConfiguration.java:647)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.lambda$resolveExclusively$4(DefaultConfiguration.java:627)
at org.gradle.api.internal.project.DefaultProjectStateRegistry$CalculatedModelValueImpl.update(DefaultProjectStateRegistry.java:444)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveExclusively(DefaultConfiguration.java:624)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.resolveToStateOrLater(DefaultConfiguration.java:611)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getResolvedConfiguration(DefaultConfiguration.java:586)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getResolvedConfiguration(Unknown Source)
at jdk.internal.reflect.GeneratedMethodAccessor65.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
at groovy.lang.MetaBeanProperty.getProperty(MetaBeanProperty.java:59)
at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.getProperty(BeanDynamicObject.java:233)
at org.gradle.internal.metaobject.BeanDynamicObject.tryGetProperty(BeanDynamicObject.java:176)
at org.gradle.internal.metaobject.CompositeDynamicObject.tryGetProperty(CompositeDynamicObject.java:55)
at org.gradle.internal.metaobject.AbstractDynamicObject.getProperty(AbstractDynamicObject.java:60)
at org.gradle.api.internal.artifacts.configurations.DefaultConfiguration_Decorated.getProperty(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:329)
at AbstractDependencyTreePlugin$DependencyTreeModelBuilder$_buildAll_closure1.doCall(/tmp/ort-Gradle16581747034260241197/init4185485621798155021.gradle:176)
at jdk.internal.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:274)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1035)
at groovy.lang.Closure.call(Closure.java:412)
at groovy.lang.Closure.call(Closure.java:428)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.findResults(DefaultGroovyMethods.java:4761)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.findResults(DefaultGroovyMethods.java:4745)
at org.codehaus.groovy.runtime.dgm$285.invoke(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoMetaMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:226)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:73)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:139)
at AbstractDependencyTreePlugin$DependencyTreeModelBuilder.buildAll(/tmp/ort-Gradle16581747034260241197/init4185485621798155021.gradle:170)

So it seems ORT's way of resolving dependencies at Gradle configuration time is inherently incompatible with the Android plugin's check not to do that.
We have several ideas how to change the Gradle analysis in the context of another issue, but until then I don't have an idea for a work-around right now.
All in all, your issue @mpbecker more looks like #5622 than this issue, as @DaveJarvis does not seem to be using an Android project.

Alright! Big shout outs for helping on such short notice. Really appreciate it, thanks!

Correct, we're not using Android. And it could be that ORT isn't hanging but merely taking a long time to run.
In either case, having tonnes of information about what's going on would be quite helpful. Information such as:

What project is being analyzed?
What files are being downloaded (e.g., URLs)?
What actions are being taken (uncompressing jar file, scanning for pom.xml files, searching for authors, etc.)?
What commands are being run?
What exceptions are encountered?
What information for the project was gleaned (project name, version, authors, license)?
Was the license information indeterminate?

We're running ORT through a rather picky firewall, so it could be getting stuck on downloads.

@DaveJarvis, do you happen to know whether there's a BOM artifact in your dependency tree? If so, #5964 might fix your issue, too.

@DaveJarvis could you give the new GradleInspector a try?

new GradleInspector a try?

Sorry, I won't be back this way. We now hand-maintain our XML files that contain the licensing information. ORT was instrumental in getting us 80% of the way there.

I found three dependencies responsible for ORT hanging at the Connecting from tooling... message in combination with a setting in our gradle.properties file. Project is uploaded here: https://github.com/mpbecker/OSS_debug

I just verified that the current version of ORT's Gradle analyzer also does not hang anymore for @mpbecker's case, see the analyzer-result.
So I'm closing this as the issue is not reproducible anymore.


Primary navigation: Items missing when viewing specific pages

Hi,
This is a known issue, but I'm not sure if you've seen it happen here specifically. Feel free to disregard if you have.
When viewing these pages from Ecosystem Catalog, the primary navigation breaks:
JDBC
PHP DBAL
PHP PDO
Python
SQLAlchemy
.NET Npgsql

Yeah, I can remember this anomaly is coming from an intentional hack. Thank you for raising it. The rule is »As soon as you are in the "drivers" projects, show it like that.« It is clearly confusing, and will need to be improved on the course of all modernizations we are working on. Please keep the ticket open until it has been resolved.


Url messages

Url messages are now received as unsupported format because they appear are now being formatted to fetch content preview

fixed on this release


small_world calculations

This is a follow-up issue after discussing #131
Right now plotting function calculates the small coefficient of "real_graph" relative to random graphs whenever called. That's why it takes a while and that is not ok for plotting functions.
Our discussions led to the 2 ways how to solve it:

Calculate small_world once and save values as a property of GraphBundle, which means adding a field to class GraphBundle. When plotting small coefficient values, we could check if these values already exist, and do not need to calculate every time small_world.

Reduce the time needed for calculating small_world values
@KirstieJane asked to show which step takes the most time. Here it is:

Code under the hood

%%time
# Calculate the small coefficient of `gname` relative to each other graph in GraphBundle
bundleGraphs.report_small_world("real_graph")

What report_small_world does is the following:
%%time
global_dict = {}
for name, graph in bundleGraphs.items():
    global_dict[name] = small_coefficient(bundleGraphs["real_graph"], graph)

# Calculate the small coefficient of G relative to R
def small_coefficient(G, R):
    return small_world_sigma((nx.average_clustering(G),
                              nx.average_shortest_path_length(G)),
                             (nx.average_clustering(R),
                              nx.average_shortest_path_length(R)))

# Compute small world sigma from tuples
def small_world_sigma(tupleG, tupleR):
    Cg, Lg = tupleG
    Cr, Lr = tupleR
    return ((Cg/Cr)/(Lg/Lr))

Time to execute code:

After looking at what report_small_world essentially does, it is easy to notice that for each graph in pair ("real_graph", "random[i]_graph") we are calculating measures average_clustering and average_shortest_path_length again and again.

That's not nice, cause we already have these measure values stored as properties of a Graph. No need to calculate over and over.
bundleGraphs["<graph-name>"].graph["global_measures"]

So, changing the small_coefficient() to access already available values rather than calculating them again, makes small_world calculations really fast!
    return small_world_sigma((G.graph["global_measures"]["average_clustering"],
                              G.graph["global_measures"]["average_shortest_path_length"]),  # noqa
                             (R.graph["global_measures"]["average_clustering"],
                              R.graph["global_measures"]["average_shortest_path_length"]))  # noqa

Thanks for reading till the end :)
ps. The issue is so long because my initial goal was to document which part of code takes the most time.

Addressed in PR #121


HTML is not getting stamped on page the second time when page loads?

In my app I have a link from main page to an FAQ page; all routing is done using app-router. Upon clicking faq it works perfect! However when I go back to main page and then click again for FAQ link the page renders nothing. But if i refresh the page then its fine.
To recreate do the following:

Open https://sizzling-fire-7471.firebaseapp.com/dev/#/ and click the FAQ page link at bottom . You will see a list of Q & A
Then click left arrow on top to go back to main page
Now click FAQ link again and you will not see anything,but in the console you will see it fetching data.

Also, refreshing the page makes it okay.
Let me know if you need more information.

This issue has now been resolved. It was due to a bug in firebase-collection. It was fixed at https://github.com/GoogleWebComponents/firebase-element/pull/42/files and will soon be merged.


Update pleaseRemoveMe()

Hello,
Do you plan to update the main script to remove all activity ?
I just try this day with English Language and old interface, detect only 8 activities, and when the script start facebook put a model that say 'Content already deleted'. Maybe much easier to update to new UI ? No confirmation need, but you need to have mouse on the activity to view action button, i tried to force hover status but not work on chrome debug console.
Thanks

Hi, thanks for the feedback, unfortunately the new change of layout requires rewriting the scripts, I will try to rewrite them one by one, and at the same time the old layout seems to be needing some review as well.
New layout: no need to simulate the hover, you could try this selector, and you would see all of the items open 👍
[...document.querySelectorAll('div[aria-label="Action options"][role="button"]')].forEach( (a) => { a.style.border = "thick solid red"; a.click(); });

If you are in the mood, you could try to update the script or better, create a new one for the new layout for easier maintenance.
NB: this will send a click on all of the three dots, but it does not click on Delete so it is safe :)


tests/e2e: Generalize GetEnv

Addressing comment from previous PR https://github.com/openservicemesh/osm/pull/1828#discussion_r505042224
Affected area:

Tests                  [X]

CI System              [X]

Does this change contain code from or inspired by another project? If so, did you notify the maintainers and provide attribution?
No

Codecov Report

Merging #1844 into main will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1844      +/-   ##
==========================================
- Coverage   59.21%   59.19%   -0.02%
==========================================
  Files         125      125
  Lines        5171     5171
==========================================
- Hits         3062     3061       -1
- Misses       2106     2107       +1
  Partials        3        3

Impacted Files
Coverage Δ

pkg/envoy/route/config.go
95.00% <0.00%> (-0.84%)
:arrow_down:

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 814c2c7...189227d. Read the comment docs.


Drop Node.js 0.10.x & 0.12.x support and update code accordingly

Node.js 0.10.x & 0.12.x is obsolete and its support can be dropped (its maintenance ends in Oct/Dec 2016, see also the Twitter poll). This allows us to modernize the code a bit — mainly use some ES6 features.
Should be done after #441.
Tasks:

[x] Drop Node 0.10.x & 0.12.x support

[x] Update package.json
[x] Update the “Compatibility” section in README.md
[x] Don’t test Node 0.10.x & 0.12.x in Travis CI

[x] Babelify all code that can be seen by the browser

[x] Pass the browser version through Babel
[x] Pass spec code through Babel before serving it to the browser
[x] Pass benchmark code through Babel before serving it to the browser

[x] Update code

[x] Replace var with let & const
[x] Replace some functions with arrow functions
[x] Replace classes.subclass with native classes
[x] Replace suitable for loops with for-of
[x] Replace Array.prototype.forEach with for-of
[x] Replace remaining functions in utils with native ones where possible

This is done now, but I’ll add two comments (both as notes-to-self and as an explanation for anyone interested):

I decided to use Array.prototype.forEach in instead of for-of in the codebase. Originally, I intended to use for-of because it seems more universal and more deeply integrated into the language (via iteration protocols). Then I prototyped the change and discovered that:

Array.prototype.forEach composes better with the rest of the code. For example, it is possible to pass it a reference to a function which is used elsewhere. There is no need to spell out the actual call.

In at least one instance I needed an index associated with the iterated item. This is trivial with Array.prototype.forEach but impossible with for-of.

I don’t have much need to break from loops, which is the most significant practical advantage of for-of over Array.prototype.forEach. I actually think that in most cases, break inside a loop is a signal that your algorithm could be improved (e.g. by expressing it in functional terms).

A simple for-of loop is transpiled into quite large body of code by Babel.

Overall, these discoveries convinced me to go the forEach route.
See also this Twitter conversation.

I decided to get rid of utils/arrays and utils/objects modules. Once it became possible to use Object.keys and array extras (enabled by dropping IE8 compatibility), the utility functions contained in these modules became less useful. PEG.js code also became somewhat inconsistent as regular JavaScript features and the utility functions started to be used next to each other. Beside, I don’t think PEG.js should be in the business of reinventing Underscore.js/Lodash.

This change sometimes required rewriting code which used the utility functions in more low-level fashion and it introduced some small duplications, but I ended up liking the result for its simplicity and consistency.
In the future, I may decide to adopt Lodash, but introducing it as dependency would complicate running PEG.js in the browser, which I’m not willing to do now.

Since this issue was resolved, I've also dropped Node 4 support, as well as non-LTS versions of Node, which makes Node 6 the lowest version of Node that PEG.js is tested on.
The browser bundle is generated using Rollup and Babel, with the babel-env plugin's target set to IE11 now, although tbh I think I will drop IE altogether after 0.11

Sounds good, that's current best practices after all. Thanks @futagoza!


libc++_link_static.cpp: remove the grep quiet option

To help with the debug of #71

the problem is a network issue


[SPARK-30785][SQL] Create table like should keep tracksPartitionsInCatalog same with source table

What changes were proposed in this pull request?
Table generated by CREATE TABLE LIKE a partitioned table is a partitioned table. But when run ALTER TABLE ADD PARTITION, it will throw AnalysisException: ALTER TABLE ADD PARTITION is not allowed. That's because the default value of tracksPartitionsInCatalog from CREATE TABLE LIKE always is false.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Add a unit test.

Test build #118210 has started for PR 27538 at commit eae0731.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/22970/
Test PASSed.

Test build #118210 has finished for PR 27538 at commit eae0731.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118210/
Test FAILed.

Test build #118277 has started for PR 27538 at commit 87ce3aa.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23037/
Test PASSed.

Test build #118277 has finished for PR 27538 at commit 87ce3aa.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118277/
Test FAILed.

Retest this please.

Test build #118292 has started for PR 27538 at commit 87ce3aa.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23050/
Test PASSed.

Test build #118292 has finished for PR 27538 at commit 87ce3aa.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118292/
Test PASSed.

Test build #118333 has started for PR 27538 at commit 15cb3a3.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23090/
Test PASSed.

Test build #118333 has finished for PR 27538 at commit 15cb3a3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118333/
Test PASSed.

cc @cloud-fan @HyukjinKwon @dongjoon-hyun

please use CREATE TABLE LIKE instead of CTL in PR description. CTL is not a common shortcut.

Test build #118637 has started for PR 27538 at commit cf28b07.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/23390/
Test PASSed.

Test build #118637 has finished for PR 27538 at commit cf28b07.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/118637/
Test PASSed.

thanks, merging to master/3.0!


Not working

Logs not working

Are you, by any chance, using Gshade?  did you install Gshade first, and then Alexander?

Yeah I did do that, however I uninstalled gshade, didnt like it. Then reinstalled alexander, still didnt work. (I deleted all of the files).
Then I also reinstalled the game, then reinstalled alexendar, still didnt work. Other than the stuff in the game folder, is there another location with files? Maybe the appdata folder?

"Not working" => What's not working?
"Logs not working" => How is logs not working?
Screencap => Unloading feature is provided as "if possible". It may not be possible at all at times.

What's not working?/How is logs not working?
The first couple connection lines appear in the logs, after that nothing. So when I hit a button, nothing appears, hence Alexander not working.
I have unloaded several times in several different cases.
I should mention this though, if I use the option "load into game once" it works. However once I close the game, the game freezes and I need to force shutdown the game, after that I get a different error from Alexander.

Exit related problems should be fixed in the next release.
For no logs being recorded when you use actions, first, check if you do have Use Logging for Networking > Latency and Timing Helper ticked.
Do you use a VPN? In that case, try ticking everything in Networking > Troubleshooting.

I do use a VPN, however I did try without VPN as well. I also tried Networking>Troubleshooting tip, lines do appear for a while.
For the Networking>Latency and timing helper tip, its ticked.  I would be able to feel it in the gameplay if Alexander was working anyway.

Now that stuff show up in log after ticking stuff in troubleshooting, save the logs from the log window and post it.

XivAlexander_20220117_174718_057.log
Thanks for your help btw.

You will have to extract everything in the zip then Install or Load Once, or the program will not work. Try again after downloading and extracting everything.

Thats what I tried, it was a fresh copy of the program, just downloaded before.

Oh, I think I get what's going on. Open G:\Steam Games\steamapps\common\FINAL FANTASY XIV Online\game\, delete config.init.json, and then try again. It should definitely work when you do that and restart the game.

Thanks a lot!
Deleting the .json file didnt work, however pasting the opcode worked.

Also looking forward to the update to address the close issue. Feel free to close issue.

The problem is, how did you get into the situation you were in to begin with? Can you take a screencap of %APPDATA%\XivAlexander and %LOCALAPPDATA%\XivAlexander? Just type Windows+R, and paste one, and press enter.

Couple of weeks ago, I played around with Gshade, it messed up something with the game so I uninstalled. However I didn't know it was Gshade at the start. I uninstalled and reinstalled both gshade and Alexander multiple times. I think I broke something then.

You can and should delete everything except XivAlexander32/64/Loader32/Loader64 in the latter folder. I'll change the installer to make sure there does not exist config.xivalexinit.json in the latter folder too.

Done, thanks for your help again.


Guards not reacting correctly in Air Base

In the original game, you don't get instantly detected after dealing with the first guard or even the patrolling one if you're quick enough. In the port, it seems like they detect their dying friends through walls and from their back.
Here's the port vs 1964 GEPD:
https://github.com/fgsfdsfgs/perfect_dark/assets/34986384/c32e11fe-2e41-4e52-97c5-cd534ed86d75

Hey @Graslu, let me know if #134 feels right to you.

Good to hear! This also affects Chicago's first few moments, previously the FBI agent would be alerted way too soon, but that seems to be fixed now too. Any instance where neutralizing a guard behind another one not looking should not alert them anymore though, but I'm not sure what other levels that could change behaviors.

I suppose this should be reopened.

I spent a while testing out a maybe solution. Though it still seems slightly inconsistent of the original behavior, it's better than the current behavior. I did a lot of testing and recorded a little bit of it so there's something to reference it against, though I want to test and make sure there's no other regressions elsewhere.
perfect_dark_pc_guard_sight.patch
GE1964 guard behavior:

PC patch guard behavior:

I'm really curious what is going behind the scenes to make it vary so differently with the original issue compared to the N64 version.

So unrelated to Air Base but I assume it's a similar issue. The Blonde guards at the end of Deep Sea will target Caroll. Don't think they can damage him, but after you alert then by killing one he'll try to slap him.
Also on Chicago, similar issue to Air Base where they see you from behind. Noticeable on PA after you slap the first FBI Agent.

This sure seems like the LOS check sometimes goes through solid collision geometry, or maybe through seams in it or something.
If that is the case, then the FOV check on the guards is then unrelated to this issue and fixing it just happens to fix the guards in Air Base because I guess they're looking away from the bodies of the guards you kill outside.
I don't know why it would fail, but that would explain a lot of LOS-related issues.

An explanation from Ryan Dwyer:

There's two factors at play:

On N64, it takes longer to draw your crossbow due to lag, thus it takes longer to kill the guard around the corner, which means the patrolling guard genuinely is out of sight and fails the LOS check.
On N64, notifychrindex is -1, which makes it read garbage data while the guard is in his dying animation. The garbage value is > the chr count, so the notify loop doesn't execute while he's dying. On the final frame of death, it sets his notifychrindex to 0, and it finds the patrolling guard. But he's out of sight by that point.

The biggest issue is the second one, as the N64 has to wait for the guard to finish his anim before the notify is done, and that takes a second or two

Point (2) was changed as the result of the crash fix mentioned above, so the death animation starts alerting immediately and not upon completion. I pushed a different fix that should match the original behavior now, so maybe now it'll be a bit closer to that.
Not much can be done about (1).
As it turns out, there never really was a working FOV check for this particular case, so the guards should see you with their backs even on N64, it will just take them a few seconds longer to react. Whether #179 should be merged to fix the FOV check I don't know, since that will make it different from the OG behavior in that there actually will be a working FOV check.

The FOV check might be cool as an additional gameplay option. Like "More realistic guard vision" or something. It would be a shame to let that work go to waste.


WIP: Eureka integration tests

What this PR does / why we need it:
Eureka integration tests.
Which issue this PR fixes: contributes to https://github.com/istio/pilot/issues/1232
Special notes for your reviewer:
I'm looking for quick feedback on the overall approach. When bin/e2e.sh -registry Eureka is called, I spin up an Eureka server and an accompanying mirroring process that listens for k8s endpoints and registers them with the Eureka server. Then e2e tests proceed mostly as normal. This approach has the advantage requiring very minimal changes to the e2e tests.
TODO:

[ ] improve synchronization logic in the Eureka mirror.
[ ] remove Eureka client duplication (switch to hudl/fargo or another 3rd party Eureka library?)
[ ] ingress/egress support (perhaps a follow-on PR)
[ ] enable automated the Eureka tests (follow-on PR)

Note that normal e2e tests will be unaffected by this PR.
Release note:

@rshriram: ingress/egress are currently broken. I'm trying to figure out the cause.

Nice work! Can you add some comments for the purpose of eurekamirror?

@kyessenov, @ayj: PTAL


How to get real lanelines from the lane segment annotation?

Hi, as is illustrated in the paper, OpenLane-V2 subset A is built basd on Argoverse 2. Then how to get real lanelines in argoverse 2 from the lane segment annotation in OpenLane-V2?
I found that some left lanelines and right lanelines in lane segments are virtual lanelines. How to distinguish the real lanelines from the virtual ones?

Hi, @wenjie710, you can use the laneline_type to distinguish the virtual lane. The category 'none' refers to virtual lanelines.
For more details, please move to here.

Thanks a lot.


Enable stacktrace support in gitian builds

This PR enables stacktrace support in the release builds done by Gitian.
It expects debug information to be present in dashd.debug (linux) and dashd.exe.dbg (windows). These debug files are split/stripped as part of the Gitian build already. If debug information is not present, a serialized crash info is printed which can then be used later to extract the stacktrace. This allows easier debugging and support when users report unexpected crashes. They can now provide us with the serialized crash info and we are able to extract the stacktraces even when the user did not run with debug info. We might consider releasing debug files as well in the future.
With the debug file present, it looks like:
2019-06-26 20:18:37 Windows Exception: EXCEPTION_INT_DIVIDE_BY_ZERO
   0#: (0x007BD0B4) wallet.cpp:5147 - CWallet::InitAutoBackup()
   1#: (0x0041F929) init.cpp:1558   - AppInitMain(boost::thread_group&, CScheduler&)

Without the debug file present, it looks like:
2019-06-26 20:19:41 No debug information available for stacktrace. You should download debug information from Github and then run:
dashd.exe -printcrashinfo=bvcgc43iinzgc43ijfxgm3ybaaewiyltnbsc4zlymuxvo2lomrxxo4zaiv4ggzlqoruw63r2ebcvqq2fkbkest2ol5eu4vc7irevmskeivpuewk7ljcvetycwtihwaaaaaaaakpzieaaaaaaaaaa====

This can then be used to extract the stacktrace with the same executable but with the debug file present:
$ wine ./dashcore-0.14.1/bin/dashd.exe -printcrashinfo=bvcgc43iinzgc43ijfxgm3ybaaewiyltnbsc4zlymuxvo2lomrxxo4zaiv4ggzlqoruw63r2ebcvqq2fkbkest2ol5eu4vc7irevmskeivpuewk7ljcvetycwtihwaaaaaaaakpzieaaaaaaaaaa====
Windows Exception: EXCEPTION_INT_DIVIDE_BY_ZERO
   0#: (0x007BD0B4) wallet.cpp:5147 - CWallet::InitAutoBackup()
   1#: (0x0041F929) init.cpp:1558   - AppInitMain(boost::thread_group&, CScheduler&)

As you can see, this was invoked with wine. Serialized stacktraces can be taken from native Windows and then be extracted with wine, and vice versa.

Latest commits changes how stacktrace support is compiled. From now on, basic stacktrace and crash info support is compiled in unconditionally on all platforms. The only thing that is conditionally now is the hooking into exception/assert handling.

Also added experimental support for MacOS, but as always, I'm unable to verify if it actually works. My hope here is that by manually loading the .debug file instead of the actual binary when initializing libbacktrace, we're able to get debug info to work. This worked fine for Windows builds, so lets hope it works here as well.
@UdjinM6 maybe you find some time to test this again? I can also provide you with pre-built binaries from a Gitian run. As an alternative, you could do your own Gitian build (./dash/contrib/gitian-build.py -u https://github.com/codablock/dash -c -n -Vdocker -j6 -b -om <signer> pr_gitian_stacktraces). It should also be possible to generate the .debug files in a local build by running make -C src osx_debug. I added a temporary commit that allows to provoke a crash by adding -crash=1 to dashd/dash-qt.
When debug info has not been generated yet and dashd is run with -crash=1, it should give no stacktrace but a -printcrashinfo line. When debug info has been generated, it should print the stacktrace. At that time, the -printcrashinfo option should also start to work.

Rebased on develop, handled review comments, and also added printing of crash description in the case where no debug info is present.
@UdjinM6 did you also try the case where the .debug files were already present when the crash happened?

Yep. I also tried to specify the exact path to dash-qt.debug (thought that maybe it fails due to /./ in the path) - doesn't help either.

Hmm ok, looks like I have no other choice but to actually look into the dSYM bundle structure and make generating that thing part of the build process...

After some discussion in Slack and some more testing done by @UdjinM6, we figured out that using a dSYM bundle works. I've added some commits so that the osx_debug make target creates a dSYM bundle instead.

Removed https://github.com/dashpay/dash/commit/f89c24bc49c1c1a57c76ee4591671d0336d87b06


Results on SemanticKITTI test set

Hi,
thank you for the work and publication. I have a question regarding to the results you show in the paper. Do you use any trick like test-time augmentation or model ensembling to further boost the performance?
Best,
Bin

I don't use any tricks. I simply select the best result from multiple training runs.


'Map is not defined'

Attach (recommended) or Link to PDF file here:
Configuration:

Web browser and its version:
Opera Mini for Android (V 27.0.2254.118423)
Operating system and its version:
Android 5.0.1
PDF.js version:
Latest build
Is a browser extension:
No

Steps to reproduce the problem:

When I tried to open mozilla.github.io/pdf.js/web/viewer.html it can't show pdf. There was a notification 'An error occured while loading the PDF.'
I tried to click 'More information' button and said 'PDF.js v2.1.70 (build: 6ebdbb24) Message: Map is not defined)

What is the expected behavior? (add screenshot)
What went wrong? (add screenshot)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Opera Mini for Android (V 27.0.2254.118423)

Looking at https://en.wikipedia.org/wiki/Opera_Mini, that version doesn't look very up-to-date.

It looks like we need a core-js polyfill for Opera Mini then :(

Looking at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#Browser_compatibility, basically every remotely modern browser[1] has at least basic support for Map.
Hence it seems, at least to me, that the most appropriate resolution is to WONTFIX this issue.

[1] That even includes IE11.

Oh, the current version is 37 according to Wikipedia, not 27; I misread that. Indeed, then we can close this as won't-fix.


[Performance] Reduce allocations on HNSW hot paths

There are a lot of heap allocations happening on the HNSW hot path which can become a bottleneck and increase the amount of GC required
Some structures that are allocated often could be managed by a pool (e.g. sync.Pool or custom like for the visited list)
Some heap escapes are due to coding inefficiencies, e.g. passing around pointer types where a non-pointer type would have led to a stack-only allocation, etc.
A disproportionate amount of allocs are happening on import-specific parts, e.g. connecting neighbors / running the heuristic, so the biggest gains to be expected are on importing, but it could have a nice effect on querying as well.

Cleanups required before this can be merged

[ ] There are multiple copies of the non-interface bufio.Writer
[ ] Check how the license of the modified go source code needs to be displayed/included
[ ] Memory condensor 2: can we remove the old one?

Not tied to a specific release date, explicitly excluded from the v1.5.0 timeline.

Unmark stale.
Under active development and the plan is to include the first version in the v1.8.0 release.