text:
[Feature Request] Controller delegation

It would be useful to be able to delegate control of a DID to another DID. (full control over the DID doc + keys)

So allow specification of the top-level controller property.

As a sample, this would allow the simple parent-child use-case where a parent holds control over a child’s DID but the child can still hold control over its authentication etc keys. In case the child loses access to their keys, the parent can rotate them.
This is different from:

Parent holding the private key associated with the child's MASTER_KEY - delegation should point to a DID to allow a separate rotation of keys on the parent's side.
This is also different from capabilityDelegation as that is not for DID control.

This might also be useful in some specific IoT scenarios.

this is also an interesting one, and we had reviewed this in the past.
I remember this first conversation. If I am not mistaken, the conclusion at the time from conversations in DIF (Decentralized Identity Foundation) was that, beyond what the spec allows syntactically, for interoperability reasons, it was recommended to have did.id == did.controller and for each verification method respect did.verificationMethod[i].controller == did.controller. I cannot find a written reference :/, so I welcome to be corrected is this was/is wrong. Furthermore, the spec may have changed since last time I reviewed this topic, so I welcome news on this too.
At a quick glance, I can see this issue and this other one to clarify semantics about the controllers properties. It may be good to see that settle. We can of course, discuss here use cases and thoughts that we could bring to those W3C issues.
On this line, I unfortunately didn't understand this sentence:

Parent holding the private key associated with the child's MASTER_KEY - delegation should point to a DID to allow a separate rotation of keys on the parent's side.

could you elaborate a bit more? I didn't follow the part of "delegation should point to a DID to allow a separate rotation of keys on the parent's side."
Once again, thank you for opening issues and exchanging thoughts!

Hmm, did.verificationMethod[i].controller == did.controller perhaps but I'm not so sure on did.id == did.controller. did.id is the identifier itself of the DID subject, and did.controller is the controller of the DID document.
DID subject and DID controller aren't the same, but they can be (and often are). I would say each DID (so did.id) has a MASTER_KEY (though the spec seems to allow for multiple, 1-of-n signature, not sure if that's intended), and that MASTER_KEY allows you to control any DID where did.controller = <did.id of controller with MASTER_KEY>.
This would allow you to delegate control of a DID document, and doesn't involve anything to do with the verificationMethods which is most of the discussion in those linked issues.

could you elaborate a bit more? I didn't follow the part of "delegation should point to a DID to allow a separate rotation of keys on the parent's side."
Here I meant that we are using did.controller in a DID document of the child, to point to the parent's DID. A worse alternative is to keep the spec as it is today, and the parent just happens to hold the MASTER_KEY of the child - this is kind of delegation, but not at the DID level but rather the key level.

You could very simply get n-of-n or 1-of-n multi-sig by allowing an array for did.controller, for example like cheqd do (they are n-of-n multi-sig). This is still in line with the did:core spec.
I need to review the issues you linked (and others that I can find) in more detail when I have the time though, as I might be missing something! :)

apologies for the delay here too

DID subject and DID controller aren't the same, but they can be (and often are). I would say each DID (so did.id) has a MASTER_KEY (though the spec seems to allow for multiple, 1-of-n signature, not sure if that's intended), and that MASTER_KEY allows you to control any DID where did.controller = <did.id of controller with MASTER_KEY>.
This would allow you to delegate control of a DID document, and doesn't involve anything to do with the verificationMethods which is most of the discussion in those linked issues.

so, if I understood correctly, the logic you are describing is:
The keys allowed to update a DID A, are the MASTER_KEYs of the DID in the A.controller field, correct? (and possibly A MASTER_KEYs too)
And, the difference you refer to is mostly at the point of displaying the delegation at the DID document, compared to just having the control without announcement (using the private key of the MASTER_KEY of the DID A)

A worse alternative is to keep the spec as it is today, and the parent just happens to hold the MASTER_KEY of the child - this is kind of delegation, but not at the DID level but rather the key level. That allows the parent to update their MASTER_KEY irrespective of the child's DID document - so a parent of 6 children could use their 1 MASTER_KEY to control 6 DIDs (+their own) instead of holding 6 or 7 MASTER_KEYs.

I should point that for the 7 DIDs (the parent's and the 6 children'), you could still use a single key by using the same key material in all the DIDs. Nothing forbids a key to be present in multiple DID documents.
Even though W3C mentions this type of behaviors, it is not that common to see in DID method implementations. The rules to control a DID are defined by each method, and the proposed logic may restrict some methods. For example, Sidetree.based DID methods, or KERI they tend to use key commitments, and not keys. And commitments are used only once in the system (not per DID), making a controller-like feature hard to implement (and I think Sidetree doesn't implement it).
Let me know if I understood the difference of using the key vs using controller field, what I am missing is a use case where the difference is needed.
I could also point out some issues:

At first glance, it damages a bit privacy by adding correlation between DIDs
More importantly, this "controller"'s semantics would create transitive relations that cannot easily be avoided. If A controls B, and B controls C, then A can add a MASTER_KEY to B's document and update C. In contrast, if A controls a private key of a MASTER_KEY in B's DID document, and B does the same with a MASTER_KEY in C's DID document, then A has no control over C unless B or C do something to allow it explicitly.
The above type of logic would be even more complex with lists of controllers

A priori, I think the topic needs further refinement before updating the spec.
Do you think we should keep this issue open @iFergal? or should I close this and we can re-open it in the future if the topic gets new points?
As always, thank you for the comments and my apologies for the delay

I am closing the issue to keep a clean view of active ones
Feel free to re-open if needed

authors: EzequielPostan iFergal

repo: input-output-hk/prism-did-method-spec


text:
Search highlight bug

Great theme thanks for creating
Related to https://github.com/insanum/obsidian_nord/issues/21 there remains a bug with highlighting of find results.
Control-F Find and then F3 to go through search results in file.

Hits in plain text are highlighted just fine.
Hits within code blocks are also fine.
Hits within inline code like this are virtually impossible to see  (there is an almost invisible fine line)

I using Dark Theme

Theme has been rewritten for Obsidian 0.16.

source: gharchive/issue

authors: aubreyz insanum

license: MIT

license_type: permissive

license_source: github-api


text:
Can TrueTime allow me to have the same time for all users? (question)

I implemented trueTime into my swift project and found that when the time was changed in the settings it did not affect the trueTime time, which is exactly what I want. However, when I closed the app and changed the time manually then went back in the trueTime time had changed. Am I implementing it incorrectly? Currently, I am starting the connection in view did load and checking for the time on a one-second timer?

@JoshLorDeveloper: This should work as expected (backgrounding the app and changing the system clock should have no affect on TrueTime). Can you post your example project here?

authors: JoshLorDeveloper msanders

license_source: bigquery


text:
'login_required' after calling IGClient.deserialize(clientFile, cookieFile, OkHttpClient.Builder);

Issue Template Requirements
Issue must be of the specified template and follow these requirements or it will be ignored.

Please do not post screenshots of code output
Wrap code in a codeblock
exhibiting spam behavior or "evil" behavior will have the issue ignored
Please make sure your issue hasn't been asked before
Please complete the checklist below (mark boxes [ ] with [x])

Pre-Checklist
I made sure...

[X] I read the README.md
[X] I looked over the examples and wiki
[X] my issue hasn't been asked or solved before

Question
Login works fine, I get the IGClient and serialize it. I do not store the client in variable right away. Instead, I get/deserialize the client from the cookie and client files and then assign it to variable. But I get 'login_required' error after deserializing the client.
My code for login:
//login
    @NonNull
    public Callable<IGClient> login(String username, String password, @Nullable Callable<String> inputCode) {
        if (this.shouldCancelRequest) {
            return () -> null;
        }
        return () -> {
            try {
                IGClient.Builder builder = IGClient.builder()
                        .client(cachingHttpClient().build())
                        .device(DeviceUtils.getIGDevice())
                        .username(username)
                        .password(password)
                        .onLogin((client, loginResponse) -> {
                            if (loginResponse.getStatusCode() == 200 && StringUtils.equals(loginResponse.getStatus(), "ok")) {
                                //serialize client
                                serializeClient(client);
                            }
                        });
                if (inputCode != null) {
                    IGClient.Builder.LoginHandler challengeHandler = (client, loginResponse) -> {
                        // included utility to resolve challenges
                        // may specify retries. default is 3
                        return IGChallengeUtils.resolveChallenge(client, loginResponse, inputCode);
                    };
                    builder.onChallenge(challengeHandler);
                }
                updateRequestCount();
                return builder.login();
            } catch (Exception e) {
                handleException(context, e, false).printStackTrace();
                return null;
            }
        };
    }

    private void serializeClient(IGClient client) {
        try {
            File clientPath = new File(Common.IGCLIENT.CLIENT_PATH, String.valueOf(client.getSelfProfile().getPk()));
            if (!clientPath.exists()) {
                clientPath.mkdirs();
            }

            File clientFile = new File(clientPath, Common.IGCLIENT.CLIENT_FILE);
            File cookieFile = new File(clientPath, Common.IGCLIENT.COOKIE_FILE);
            clientFile.delete();
            cookieFile.delete();

            client.serialize(clientFile, cookieFile);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

And the response I get:
--> POST https://i.instagram.com/api/v1/accounts/login/
Content-Length: 855
Connection: close
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Language: en-US
X-IG-Capabilities: 3brTvw==
X-IG-App-ID: 567067343352427
User-Agent: Instagram 255.1.0.17.102 Android (33/13; 320dpi; 1080x2400; Xiaomi; Redmi Note 9 Pro; joyeuse; qcom; en_US)
X-IG-Connection-Type: WIFI
X-Ads-Opt-Out: 0
X-CM-Bandwidth-KBPS: -1.000
X-CM-Latency: -1.000
X-IG-App-Locale: en_US
X-IG-Device-Locale: en_US
X-Pigeon-Session-Id: 4e7bfb39-616c-4808-b878-b2fd5edf9a93
X-Pigeon-Rawclienttime: 1665928217396
X-IG-Connection-Speed: 2733kbps
X-IG-Bandwidth-Speed-KBPS: -1.000
X-IG-Bandwidth-TotalBytes-B: 0
X-IG-Bandwidth-TotalTime-MS: 0
X-IG-Extended-CDN-Thumbnail-Cache-Busting-Value: 1000
X-IG-Device-ID: 94a05e81-cd13-48e0-ad66-cc9d71fcb66e
X-IG-Android-ID: android-f26e85ca914e5ed5
X-FB-HTTP-engine: Liger
signed_body=SIGNATURE.%7B%7D
--> END POST (855-byte body)

<-- 200 https://i.instagram.com/api/v1/accounts/login/ (3664ms)
content-type: application/json; charset=utf-8
ig-set-password-encryption-key-id: 128
ig-set-password-encryption-pub-key: pub_key
vary: Cookie, Accept-Language, Accept-Encoding
date: Sun, 16 Oct 2022 13:50:20 GMT
strict-transport-security: max-age=31536000
content-language: en
cache-control: private, no-cache, no-store, must-revalidate
pragma: no-cache
expires: Sat, 01 Jan 2000 00:00:00 GMT
x-frame-options: SAMEORIGIN
content-security-policy: report-uri https://www.instagram.com/security/csp_report/; default-src 'self' https://www.instagram.com; img-src data: blob: https://*.fbcdn.net https://*.instagram.com https://*.cdninstagram.com https://*.facebook.com https://*.fbsbx.com https://*.giphy.com; font-src data: https://*.fbcdn.net https://*.instagram.com https://*.cdninstagram.com; media-src 'self' blob: https://www.instagram.com https://*.cdninstagram.com https://*.fbcdn.net; manifest-src 'self' https://www.instagram.com; script-src 'self' https://instagram.com https://www.instagram.com https://*.www.instagram.com https://*.cdninstagram.com wss://www.instagram.com https://*.facebook.com https://*.fbcdn.net https://*.facebook.net 'unsafe-inline' 'unsafe-eval' blob:; style-src 'self' https://*.www.instagram.com https://www.instagram.com 'unsafe-inline'; connect-src 'self' https://instagram.com https://www.instagram.com https://*.www.instagram.com https://graph.instagram.com https://*.graph.instagram.com https://i.instagram.com/graphql_www https://graphql.instagram.com https://*.cdninstagram.com https://api.instagram.com https://i.instagram.com https://*.i.instagram.com https://*.od.instagram.com wss://www.instagram.com wss://edge-chat.instagram.com https://*.facebook.com https://*.fbcdn.net https://*.facebook.net chrome-extension://boadgeojelhgndaghljhdicfkmllpafd blob:; worker-src 'self' blob: https://www.instagram.com; frame-src 'self' https://instagram.com https://www.instagram.com https://*.instagram.com https://staticxx.facebook.com https://www.facebook.com https://web.facebook.com https://connect.facebook.net https://m.facebook.com https://*.fbsbx.com; object-src 'none'; upgrade-insecure-requests
cross-origin-embedder-policy-report-only: require-corp;report-to="coep"
report-to: {"group": "coep", "max_age": 86400, "endpoints": [{"url": "/security/coep_report/"}]},{"group": "coop", "max_age": 86400, "endpoints": [{"url": "/security/coop_report/"}]}
origin-trial: AuqWincgAuXeuu3KypEMnrrFEJHySaesyJS3EaIH40zvafzrU0Irhb7+5QwZpOqMZrPTjgvFl7Z5jJgy1dNAcQMAAAB6eyJvcmlnaW4iOiJodHRwczovL2luc3RhZ3JhbS5jb206NDQzIiwiZmVhdHVyZSI6IkNyb3NzT3JpZ2luT3BlbmVyUG9saWN5UmVwb3J0aW5nIiwiZXhwaXJ5IjoxNjEzNDExNjYyLCJpc1N1YmRvbWFpbiI6dHJ1ZX0=
cross-origin-opener-policy: same-origin-allow-popups;report-to="coop"
x-content-type-options: nosniff
x-xss-protection: 0
x-ig-push-state: c2
x-aed: 72
access-control-expose-headers: X-IG-Set-WWW-Claim
x-ig-request-elapsed-time-ms: 2255
x-ig-peak-time: 1
ig-set-authorization: Bearer IGT:2:eyJkc191c2VyX2lkIjoiMTE4NDc4OTM4MyIsInNlc3Npb25pZCI6IjExODQ3ODkzODMlM0FzNTdPWmtkNlNVcFh5VSUzQTI0JTNBQVlmenJYYXhpWW1yb1Fwb0FaLWlMaWNQUm9uU0kwbENCWjB4dmhVTU5BIn0=
ig-set-use-auth-header-for-sso: True
ig-set-x-mid: Y0wMGgABAAFPcbUyCGNmNugJuWDt
ig-set-ig-u-ig-direct-region-hint:
ig-set-ig-u-shbid:
ig-set-ig-u-shbts:
ig-set-ig-u-rur: RVA,1184789383,1697464220:01f7f4e032e39b522565bca1f9605a0f6270375cf8b3480e583f7ebb23f11db8f44c8c3e
ig-set-ig-u-ds-user-id: _user_id_
x-ig-origin-region: rva
x-fb-trip-id: 1512268381
alt-svc: h3=":443"; ma=86400,h3-29=":443"; ma=86400
{"logged_in_user":{_user_}
<-- END HTTP (2244-byte body)

Now is the time I get the client to make my first request:
public static IGClient getClient() {
        int tries = 5;

        while (App.client == null && tries > 0) {
            File clientPath = Common.CURRENT_CLIENT_PATH();
            File clientFile = new File(clientPath, Common.IGCLIENT.CLIENT_FILE);
            File cookieFile = new File(clientPath, Common.IGCLIENT.COOKIE_FILE);
            if (clientFile.exists() && cookieFile.exists()) {
                try {
                    App.client = IGClient.deserialize(clientFile, cookieFile, cachingHttpClient());
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
            tries--;
        }

        return App.client;
    }

Then I get this error message:
--> POST https://i.instagram.com/api/v1/feed/timeline/
Content-Length: 429
Connection: close
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Language: en-US
X-IG-Capabilities: 3brTvw==
X-IG-App-ID: 567067343352427
User-Agent: Instagram 255.1.0.17.102 Android (33/13; 320dpi; 1080x2400; Xiaomi; Redmi Note 9 Pro; joyeuse; qcom; en_US)
X-IG-Connection-Type: WIFI
X-Ads-Opt-Out: 0
X-CM-Bandwidth-KBPS: -1.000
X-CM-Latency: -1.000
X-IG-App-Locale: en_US
X-IG-Device-Locale: en_US
X-Pigeon-Session-Id: 315721ba-8640-4541-bf5b-8a54344496c1
X-Pigeon-Rawclienttime: 1665928222226
X-IG-Connection-Speed: 3521kbps
X-IG-Bandwidth-Speed-KBPS: -1.000
X-IG-Bandwidth-TotalBytes-B: 0
X-IG-Bandwidth-TotalTime-MS: 0
X-IG-Extended-CDN-Thumbnail-Cache-Busting-Value: 1000
X-IG-Device-ID: c1e73f03-639a-46df-ad31-90f6481ab52f
X-IG-Android-ID: android-f26e85ca914e5ed5
X-FB-HTTP-engine: Liger

signed_body=SIGNATURE.%7B%7D
--> END POST (429-byte body)

<-- 403 https://i.instagram.com/api/v1/feed/timeline/ (1398ms)
content-type: application/json; charset=utf-8
vary: Cookie, Accept-Language
date: Sun, 16 Oct 2022 13:50:23 GMT
strict-transport-security: max-age=31536000
content-language: en
cache-control: private, no-cache, no-store, must-revalidate
pragma: no-cache
expires: Sat, 01 Jan 2000 00:00:00 GMT
x-frame-options: SAMEORIGIN
content-security-policy: report-uri https://www.instagram.com/security/csp_report/; default-src 'self' https://www.instagram.com; img-src data: blob: https://*.fbcdn.net https://*.instagram.com https://*.cdninstagram.com https://*.facebook.com https://*.fbsbx.com https://*.giphy.com; font-src data: https://*.fbcdn.net https://*.instagram.com https://*.cdninstagram.com; media-src 'self' blob: https://www.instagram.com https://*.cdninstagram.com https://*.fbcdn.net; manifest-src 'self' https://www.instagram.com; script-src 'self' https://instagram.com https://www.instagram.com https://*.www.instagram.com https://*.cdninstagram.com wss://www.instagram.com https://*.facebook.com https://*.fbcdn.net https://*.facebook.net 'unsafe-inline' 'unsafe-eval' blob:; style-src 'self' https://*.www.instagram.com https://www.instagram.com 'unsafe-inline'; connect-src 'self' https://instagram.com https://www.instagram.com https://*.www.instagram.com https://graph.instagram.com https://*.graph.instagram.com https://i.instagram.com/graphql_www https://graphql.instagram.com https://*.cdninstagram.com https://api.instagram.com https://i.instagram.com https://*.i.instagram.com https://*.od.instagram.com wss://www.instagram.com wss://edge-chat.instagram.com https://*.facebook.com https://*.fbcdn.net https://*.facebook.net chrome-extension://boadgeojelhgndaghljhdicfkmllpafd blob:; worker-src 'self' blob: https://www.instagram.com; frame-src 'self' https://instagram.com https://www.instagram.com https://*.instagram.com https://staticxx.facebook.com https://www.facebook.com https://web.facebook.com https://connect.facebook.net https://m.facebook.com https://*.fbsbx.com; object-src 'none'; upgrade-insecure-requests
cross-origin-embedder-policy-report-only: require-corp;report-to="coep"
report-to: {"group": "coep", "max_age": 86400, "endpoints": [{"url": "/security/coep_report/"}]},{"group": "coop", "max_age": 86400, "endpoints": [{"url": "/security/coop_report/"}]}
cross-origin-resource-policy: cross-origin
origin-trial: AuqWincgAuXeuu3KypEMnrrFEJHySaesyJS3EaIH40zvafzrU0Irhb7+5QwZpOqMZrPTjgvFl7Z5jJgy1dNAcQMAAAB6eyJvcmlnaW4iOiJodHRwczovL2luc3RhZ3JhbS5jb206NDQzIiwiZmVhdHVyZSI6IkNyb3NzT3JpZ2luT3BlbmVyUG9saWN5UmVwb3J0aW5nIiwiZXhwaXJ5IjoxNjEzNDExNjYyLCJpc1N1YmRvbWFpbiI6dHJ1ZX0=
cross-origin-opener-policy: same-origin-allow-popups;report-to="coop"
x-content-type-options: nosniff
x-xss-protection: 0
x-ig-push-state: c2
x-aed: 72
access-control-expose-headers: X-IG-Set-WWW-Claim
x-ig-request-elapsed-time-ms: 239
x-ig-peak-time: 0
ig-set-x-mid: Y0wMHwABAAFwTqNA6B25Zr85tqNs
ig-set-ig-u-ig-direct-region-hint:
ig-set-ig-u-shbid:
ig-set-ig-u-shbts:
ig-set-ig-u-rur:
ig-set-ig-u-ds-user-id:
content-length: 136
x-ig-origin-region: rva
x-fb-trip-id: 1512268381
alt-svc: h3=":443"; ma=86400,h3-29=":443"; ma=86400

{"message":"login_required","error_title":"You've Been Logged Out","error_body":"Please log back in.","logout_reason":2,"status":"fail"}
<-- END HTTP (136-byte body)

Seems like this.httpClient.cookieJar() size is 0

This is the IGClient after loging in:
IGClient(encryptionId=107, encryptionKey=_encryptionKey_, authorization=_authorization_, httpClient=okhttp3.OkHttpClient@ec63a46, sessionId=_sessionId_, actions=com.github.instagram4j.instagram4j.actions.IGClientActions@84c5407, exceptionallyHandler=com.github.instagram4j.instagram4j.IGClient$1@e841934, deviceId=_deviceId_, guid=_guid_, phoneId=_phoneId_, loggedIn=true, selfProfile=User(super=Profile(super=com.github.instagram4j.instagram4j.models.user.User@6a072524, pk=_pk_, username=_username_, full_name=_full_name_, is_private=false, profile_pic_url=_profile_pic_url_, is_verified=false, has_anonymous_profile_picture=false), is_business=true, media_count=0, follower_count=0, following_count=0, biography=null, external_url=null, hd_profile_pic_versions=null, hd_profile_pic_url_info=null, account_type=2), device=IGAndroidDevice(super=IGDevice(userAgent=Instagram 255.1.0.17.102 Android (33/13; 320dpi; 1080x2400; Xiaomi; Redmi Note 9 Pro; joyeuse; qcom; en_US), capabilities=3brTvw==, deviceMap=null), androidVersion=33, androidRelease=13, dpi=320dpi, displayResolution=1080x2400, manufacturer=Xiaomi, model=Redmi Note 9 Pro, device=joyeuse, cpu=qcom))

And the IGClient after deserialization
IGClient(encryptionId=null, encryptionKey=null, authorization=null, httpClient=okhttp3.OkHttpClient@c4c5a6f, sessionId=sessionId actions=com.github.instagram4j.instagram4j.actions.IGClientActions@ea837c, exceptionallyHandler=com.github.instagram4j.instagram4j.IGClient$1@5d1f405, deviceId=deviceId, guid=guid, phoneId=phoneId, loggedIn=true, selfProfile=User(super=Profile(super=com.github.instagram4j.instagram4j.models.user.User@6a072524, pk=pk, username=username, full_name=full_name, is_private=false, profile_pic_url=profile_pic_url, profile_pic_id=profile_pic_id, is_verified=false, has_anonymous_profile_picture=false), is_business=true, media_count=0, follower_count=0, following_count=0, biography=null, external_url=null, hd_profile_pic_versions=null, hd_profile_pic_url_info=null, account_type=2), device=IGAndroidDevice(super=IGDevice(userAgent=Instagram 255.1.0.17.102 Android (33/13; 320dpi; 1080x2400; Xiaomi; Redmi Note 9 Pro; joyeuse; qcom; en_US), capabilities=3brTvw==, deviceMap=null), androidVersion=33, androidRelease=13, dpi=320dpi, displayResolution=1080x2400, manufacturer=Xiaomi, model=Redmi Note 9 Pro, device=joyeuse, cpu=qcom))

I have fixed the problem. I don't know how I got it in the first place. The problem is that after deserializing the client and cookie files, I got strike with "login_required" which will happen everytime I open the app. So the user would have to re-login everytime (which is not a good thing). I noticed that some fields are set to null in the client after I deserialize it. So I thought that I could get those fields' value and save them somewhere.
If anyone encounter that particular problem, here's how I fixed it:
I basically used reflection to get the transient variables right after loging in.
private void serializeClient(IGClient client) {
        try {
            Log.d(TAG, "serializeClient: " + client.toString());
            String path = String.valueOf(client.getSelfProfile().getPk());

            //save client's path in shared preferences
            settingsPrefs().edit().putString(Common.IGCLIENT.CLIENT_KEY, path).apply();

            File clientPath = new File(Common.IGCLIENT.CLIENT_PATH, path);
            if (!clientPath.exists()) {
                clientPath.mkdirs();
            }

            File clientFile = new File(clientPath, Common.IGCLIENT.CLIENT_FILE);
            File cookieFile = new File(clientPath, Common.IGCLIENT.COOKIE_FILE);
            File mapFile = new File(clientPath, Common.IGCLIENT.MAP_FILE);
            clientFile.delete();
            cookieFile.delete();
            mapFile.delete();

            //save client fields to hashmap
            //this is where I read the transient fields
            HashMap<String, String> mapField = new HashMap<>();
            Field[] fields = client.getClass().getDeclaredFields();
            for (Field field : fields) {
                if (Modifier.isTransient(field.getModifiers())) {
                    if (!field.getName().equals("httpClient") && !field.getName().equals("exceptionallyHandler")) {
                        field.setAccessible(true);
                        if (field.getType() == String.class) {
                            mapField.put(field.getName(), (String) field.get(client));
                        } else {
                            mapField.put(field.getName(), new Gson().toJson(field.get(client)));
                        }
                        field.setAccessible(false);
                    }
                }
            }

            SerializeUtil.serialize(mapField, mapFile);

            client.serialize(clientFile, cookieFile);

//            App.setClient(client);
        } catch (Exception e) {
            e.printStackTrace();
        }

//        IGClientSerializeUtils.serialize(client);
    }

And when I want to get the client back:
public static IGClient getClient() {
        int tries = 5;

        while (App.client == null && tries > 0) {
            File clientPath = Common.CURRENT_CLIENT_PATH();
            File clientFile = new File(clientPath, Common.IGCLIENT.CLIENT_FILE);
            File cookieFile = new File(clientPath, Common.IGCLIENT.COOKIE_FILE);
            File mapFile = new File(clientPath, Common.IGCLIENT.MAP_FILE);
            if (clientFile.exists() && cookieFile.exists() && mapFile.exists()) {
                try {
                    HashMap<String, String> mapFields = (HashMap<String, String>) SerializeUtil.deserialize(mapFile, HashMap.class);
                    App.client = IGClient.deserialize(clientFile, cookieFile, cachingHttpClient());

                    for (Map.Entry<String, String> entry : mapFields.entrySet()) {
                        Field[] fields = client.getClass().getDeclaredFields();
                        for (Field field : fields) {
                            if (field.getName().equals(entry.getKey())) {
                                field.setAccessible(true);
                                if (field.getType() == String.class) {
                                    field.set(App.client, entry.getValue());
                                } else {
                                    field.set(App.client, new Gson().fromJson(entry.getValue(), field.getType()));
                                }
                                field.setAccessible(false);
                            }
                        }
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
            tries--;
        }

//        if (App.client == null) {
//            App.client = IGClientSerializeUtils.deserialize();
//        }

        Log.d(TAG, "getClient: " + client.toString());
        return App.client;
    }

all serialization is good! But when i try deserialize, i have null IGClientActions

#709

have you resolve your problem ?

have you resolve your problem ?

I never encountered this problem when I used EasyInsta library. You can try as well.
That lib internally handle all the serialization/deserialization part and directly provide you with the instagram instance

authors: ErrorxCode bloworlf noirtier-villefort


text:
Welcome Menssage does not work

Hi
When I try to run Welcome Menssage I log into the account and it throws me the following error
"{'user_info': {'id': xxxx, 'username': 'xxxx', 'is_private': True, 'profile_pic_url': 'https://scontent-eze1-1.cdninstagram.com/v/t51. 2885-19 / s150x150 / 72406449_1247276762119025_5060125306149404672_n.jpg? _Nc_ht = scontent-eze1-1.cdninstagram.com & oh = b6a91591e5b439fef6dbac777499beb4 & oe} 5 '70se: 5 '70se:
None "
Please help me

"{'user_info': {'id': xxxx, 'username': 'xxxx', 'is_private': True, 'profile_pic_url': 'https://scontent-eze1-1.cdninstagram.com/v/t51. 2885-19 / s150x150 / 72406449_1247276762119025_5060125306149404672_n.jpg? _Nc_ht = scontent-eze1-1.cdninstagram.com & oh = b6a91591e5b439fef6dbac777499beb4 & oe} 5 '70se: 5 '70se:"
I don't get the above part but I get the last line that you wrote None.
I also wrote a comment on in the pull request which involved this welcome message feature.
See this

repo: instagrambot/instabot


text:
DEVELOPERS: add location (geo tag) to a post

Related php code: https://github.com/mgp25/Instagram-API/issues/34 (klawdyo commented on Apr 17, 2016)
Trying to change configurePhoto in api_photo.py by adding:
'location'      : {         'external_source': 'facebook_places',          'facebook_places_id': 115213835158481,          'lng': 108.1,          'lat': 10.9333,          'name': 'Phan Thiet',          'city': '',          'address': '',          'pk': 216918627     },
but got the following error:

<Response [500]>
{'status': 'fail', 'message': "Other media configure error: b'E3v4zLVnwi'"}

I found it on other bot, i hope it help: https://github.com/LopesX/instabot.py/blob/master/src/instabot.py
def get_media_id_by_tag(self, tag):
""" Get media ID set, by your hashtag or location """
    if self.login_status:
        if tag.startswith('l:'):
            tag = tag.replace('l:', '')
            self.by_location = True
            log_string = "Get Media by location: %s" % (tag)
            self.write_log(log_string)
            if self.login_status == 1:
                url_location = self.url_location % (tag)
                try:
                    r = self.s.get(url_location)
                    all_data = json.loads(r.text)
                    self.media_by_tag = list(all_data['graphql']['location']['edge_location_to_media']['edges'])
                except:
                    self.media_by_tag = []
                    self.write_log("Except on get_media!")
                    logging.exception("get_media_id_by_tag")
            else:
                return 0

        else:
            log_string = "Get Media by tag: %s" % (tag)
            self.by_location = False
            self.write_log(log_string)
            if self.login_status == 1:
                url_tag = self.url_tag % (tag)
                try:
                    r = self.s.get(url_tag)
                    all_data = json.loads(r.text)
                    self.media_by_tag = list(all_data['graphql']['hashtag']['edge_hashtag_to_media']['edges'])
                except:
                    self.media_by_tag = []
                    self.write_log("Except on get_media!")
                    logging.exception("get_media_id_by_tag")
            else:
                return 0

Nice. Can you please implement it in our bot? Let's make a Pull Request.

authors: LopesX ohld ppleskov


text:
Proxy

Add proxy param to login session

@ob1vanq are you planning the complete this PR? if you don't have to time, I can do it.

I would really appreciate if the suitable proxy support would be added, Thanks :+1:

i use
export HTTPS_PROXY="https://113.53.60.178:8080"
i get
Session file does not exist yet - Logging in.
Traceback (most recent call last):
  File "/usr/local/bin/instaloader", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.9/dist-packages/instaloader/__main__.py", line 471, in main
    _main(loader,
  File "/usr/local/lib/python3.9/dist-packages/instaloader/__main__.py", line 110, in _main
    instaloader.login(username, password)
  File "/usr/local/lib/python3.9/dist-packages/instaloader/instaloader.py", line 634, in login
    self.context.login(user, passwd)
  File "/usr/local/lib/python3.9/dist-packages/instaloader/instaloadercontext.py", line 214, in login
    csrf_json = self.get_json('accounts/login/', {}, session=session)
  File "/usr/local/lib/python3.9/dist-packages/instaloader/instaloadercontext.py", line 325, in get_json
    resp = sess.get('https://{0}/{1}'.format(host, path), params=params, allow_redirects=False)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 555, in get
    return self.request('GET', url, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 696, in urlopen
    self._prepare_proxy(conn)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 966, in _prepare_proxy
    conn.connect()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 359, in connect
    conn = self._connect_tls_proxy(hostname, conn)
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 500, in _connect_tls_proxy
    return ssl_wrap_socket(
  File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 453, in ssl_wrap_socket
    ssl_sock = _ssl_wrap_socket_impl(sock, context, tls_in_tls)
  File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 495, in _ssl_wrap_socket_impl
    return ssl_context.wrap_socket(sock)
  File "/usr/lib/python3.9/ssl.py", line 500, in wrap_socket
    return self.sslsocket_class._create(
  File "/usr/lib/python3.9/ssl.py", line 997, in _create
    raise ValueError("check_hostname requires server_hostname")
ValueError: check_hostname requires server_hostname

source: gharchive/pull-request

authors: LuckyCoders Natgho ainyava ob1vanq

repo: instaloader/instaloader


text:
Proposal: Adopting Conventional Commit Messages

I propose adopting conventional commit messages in our repository to standardize our commit history and improve code review processes. At least I would like to enforce it since most of the contributors are doing it, but this would be helpful for newcomers. By using a concise prefix indicating the type of change followed by a brief description, we can enhance readability, facilitate automated changelog generation, and promote better collaboration among contributors. We will integrate Commitlint as a CI job to enforce the conventional commit message format and update documentation. This initiative aims to streamline release management and maintain high-quality code throughout the project lifecycle.
To start, I'm proposing the following commitlint.json:
{
  "extends": [
    "@commitlint/config-conventional"
  ],
  "rules": {
    "type-enum": [
      2,
      "always",
      [
        "bot",
        "build",
        "ci",
        "chat",
        "containers",
        "core",
        "docs",
        "doc",
        "generate",
        "server",
        "test",
        "tests",
        "train"
      ]
    ],
    "body-leading-blank": [
      2,
      "always"
    ],
    "footer-leading-blank": [
      2,
      "always"
    ],
    "body-max-line-length": [
      0,
      "always"
    ]
  }
}

I can work on this, once the proposal has been approved.
Your feedback is appreciated.

Closing, for context see https://github.com/instructlab/instructlab/pull/1098

repo: instructlab/instructlab


text:
🛑 Dropzone is down

In 4b4ba90, Dropzone ($DZ_URL) was down:

HTTP code: 502
Response time: 335 ms

Resolved: Dropzone is back up in b1eb3b9.

repo: instruxmedia/webserver-uptime


text:
28 line typo edit softmas => softmax

28
00:02:30,686 --> 00:02:37,927
여러분은 또한 몇 가지 선형 분류기를 구현할 것인데 SVM과
Softmas 뿐만 아니라 2-layer 신경망도 구현할 것입니다.
여기에서 softmas => softmax로 수정했습니다 이슈보다 이게 빠를거 같아서 PR보내요

@Sihan-Son 감사합니다.


text:
🛑 Shopintake is down

In 3f56ac6, Shopintake (https://www.shopintake.com) was down:

HTTP code: 403
Response time: 318 ms

Resolved: Shopintake is back up in 1889923 after 20 minutes.


text:
🛑 Shopintake is down

In 9436dda, Shopintake (https://www.shopintake.com) was down:

HTTP code: 403
Response time: 341 ms

Resolved: Shopintake is back up in c38f833 after 8 minutes.


text:
replace RSA shielding key with NaCl/salt/sodium asymmetric crypto

Needs to first be researched in depth
RSA should be deprecated as it should no longer be considered secure
NaCl is scheme enabling asymmetric encryption and authentication at the same time, based on ed25519. We would still need a shared secret among all enclaves operating the same shard, but it could be an ed25519 secret key instead of an RSA one. We may even want to use that shared ed25519 key as a "per shard" account on Integritee Network.
Good docs come with the python lib:
https://pynacl.readthedocs.io/en/latest/public/
The rust lib seems unmaintained: https://crates.io/crates/nacl

That will be a great improvement.
Also Rsa3072KeyPair in rust-sdk doesn't seem that stable, sometimes it works with only certain Intel-SDK version (e.g. 2.19, but not 2.21+). In rust SDK 2.0.0 - the ucrypto feature doesn't work reliably either, see  https://github.com/apache/incubator-teaclave-sgx-sdk/issues/456

authors: Kailai-Wang brenzi

repo: integritee-network/worker


text:
squid:S1118 - Utility classes should not have public constructors

This pull request is focused on resolving occurrences of Sonar rule
squid:S1118 - Utility classes should not have public constructors.
You can find more information about the issue here:
https://dev.eclipse.org/sonar/rules/show/squid:S1118
Please let me know if you have any questions.
George Kankava

+1

Thank @georgekankava for your contribution.

authors: georgekankava sundapeng

repo: intel-hadoop/chimera


text:
cmake error on latest RASPBIAN STRETCH LITE

Hi
Can someone help me here. I try to build mraa for a raspberry pi 1 but I get this error. Hm should I update cmake?
pi@raspberrypi ~/python/libs/mraa/build $ cmake ..
-- INFO - libmraa Version v1.9.0
-- INFO - cmake Version 2.8.9
-- INFO - Target arch is armv6
-- INFO - Adding onewire backend support
-- INFO - Adding support for platform ALL
-- INFO - Adding support for all platforms
INFO - Adding ARM platforms
CMake Warning at src/CMakeLists.txt:203 (message):
  Enabled JSONPLAT but JSON-C library not found: Ignoring JSONPLAT

-- PYTHON2 attempting to build!
CMake Error at src/python/python2/CMakeLists.txt:13 (target_include_directories):
  Unknown CMake command "target_include_directories".

-- Configuring incomplete, errors occurred!

many thanks

yeah if you don't have target_include_directories cmake is too old or disable python bindings, though does show a bug, we should change minimum version to 2.9.

okay many thanks.

authors: arfoll mgiaco

repo: intel-iot-devkit/mraa

license: mit


text:
Error launching gmapping with R200 camera

System Configuration
Please complete Your Configuration detail below. Refer to the BKC at Configuration.

Version
Your Configuration

Operating System
Ubuntu 14..04 LTS

Kernel
4.2.0-42-generic

Backend
video4linux

ROS
indigo

ROS RealSense
1.30

librealsense
1.9.7-blue

Camera Type-Firmware
R200 1.0.72.06

How to collect Configuration Data
This section can be deleted before submission.

Version
Method

Operating System
grep DISTRIB_DESCRIPTION /etc/*elease*

Kernel
uname -r

Backend
`ls /sys/class

ROS
rosversion -d

ROS RealSense
rosversion realsense_camera

librealsense
`cat /librealsense/readme.md

Camera Type-Firmware
View the ROS log from running nodelet

Expected Behavior
I'm trying to initialize gmapping using a Realsense R200 camera. I've followed all the installation steps as posted on the Readme.md files. All R200 nodelet launch files work perfectly and I get pretty good data from the camera which I can easily visualize in Rviz. However, I'm unable to run gmapping and I think it has to do with some naming issues.
Actual Behavior
These are screenshots from terminals running:
roslaunch realsense_camera r200_nodelet_navigation.launch (left)
roslaunch realsense_navigation gmapping.launch (right)

As you can see an extra /camera is being appended to all params for gmapping.launch. I'm guessing this results on two different nodelet manager names or some other naming issues and so things aren’t loaded correctly? I also noted in issue #37 that the prefix is RealsenseNodelet which seems to be correct from looking at the launch files on the realsense camera package, but it is different from what I have.
Steps to Reproduce
roslaunch turtlebot_bringup minimal.launch
roslaunch realsense_camera r200_nodelet_navigation.launch
roslaunch realsense_navigation gmapping.launch
I can't figure out how to solve this problem

These instructions are now deprecated and in the process of being removed as we are in the process of adding r200 support to the turtlebot navigation package. These changes are almost complete and the r200 navigation package will be removed shortly.

Yes I noticed when I saw the turtlebot navigation while installing from source. I didn’t substitute the  r200.launch.xml for the one in realsense navigation and so another r200 nodelet was being launched when starting gmapping. I used the r200.launch.xml from realsense navigation and all is working great now.
Is this fixed now since r200 is being added to the turtlebot navigation package?:

I suppose we wont need to start the nodelets separately once r200 is integrated completely
Totally unrelated, but would I be able to run the turtlebot follower by launching the r200 rgbd nodelet and then the follower since rgb_processing seems to be required?

Using the new source I was able to run gmapper-demo as described in the turtlebot_navigation tutorial on the wiki[1] and did not encounter the errors described in the report.
[1] - http://wiki.ros.org/turtlebot_navigation/Tutorials/indigo/Build a map with SLAM

@betaupsx86, have you been able to retry this with the default turtlebot packages now that they have native R200 support?  Please keep in mind that you need to be pulling from source, as these commits are not yet in the released packages yet.

I was able to get it all working back then; acml, gmapping and the turtlebot follower example. The problem was that an extra camera nodelet was being started along the launch chain which conflicted with the already running r200 nodelet from the instructions. I modified some xml files and the issue was resolved. I will download the turtlebot sources again to see if everythings runs smoothly now that they integrated the r200. Thanks

Totally unrelated, but has anyone successfully used any person tracking packages with the r200.

@betaupsx86 I don't believe we have anyone focusing on using the R200 with any of the existent person tracking packages out there at this time, though we have some internal solutions in the pipeline. If you end up having any issues getting them to work, please file a new issue -- we'd love the feedback.

authors: anelliot betaupsx86 kevincwells tripzero

repo: intel-ros/realsense


text:
An issue about Multi-Socket sample code

Issue descript:
Multi-Socket sample code default set socket number = 4 , running on different config/SKU has some different results
#define SOCKET_COUNT 4u
Config 1:
CPU:  Intel(R) Xeon(R) Platinum 8490H
Socket :  2
DSA device per Socket:  4
Enable 1 device:  dsa0  (on socket0)
Both SOCKET_COUNT equal to 1~4 can running successful.
Config 2:
CPU:  Intel(R) Xeon(R) Platinum 8470
Socket :  2
DSA device per Socket:  1
setup1:  // error failed to submit to node0
Enable 1 device:  dsa0  (on socket0)
SOCKET_COUNT=4
setup2:  // error failed to submit to node1
Enable 1 device:  dsa0  (on socket0)
Enable 1 device:  dsa1  (on socket1)
SOCKET_COUNT=4
setup3:  // successful
Enable 1 device:  dsa0  (on socket0)
Enable 1 device:  dsa1  (on socket1)
SOCKET_COUNT=2
setup4:  // successful
Enable 1 device:  dsa0  (on socket0)
SOCKET_COUNT=4
Commented out code： current_job->numa_id  = i
for (uint32_t i = 0; i < SOCKET_COUNT; ++i)
   {
       const uint32_t chunk_size = transfer_size / SOCKET_COUNT;

       dml_job_t* current_job = (dml_job_t*)((uint8_t*)jobs + (job_size * i));

       current_job->operation             = DML_OP_MEM_MOVE;
       current_job->source_first_ptr      = src + (chunk_size * i);
       current_job->destination_first_ptr = dst + (chunk_size * i);
       current_job->source_length         = chunk_size;
       current_job->flags                 = DML_FLAG_PREFETCH_CACHE;
       //current_job->numa_id               = i;
   }

Why has these different results , does any logic issue about numa node check of DML？

Hi @Sean58238, could you please clarify, have you commented out this portion of the code for all of setup1-4 runs with Config 2?

While we're waiting for the clarification, I'll try to provide some guidance, maybe this would help to resolve misunderstanding.
Here is the documentation chapter w.r.t NUMA support in DML. It says:

If a user needs to use a device from a specific node, it can be done in two ways:

Pin thread which performs submissions to the specific NUMA, the library will use devices only from this node.
Set NUMA id parameter of the job to the specific node id, then devices will be selected only from this node.

In the example, by default, SOCKET_COUNT is set to 4, and then a job assigned to every NUMA node via setting current_job->numa_id = i (where i is from 0 to SOCKET_COUNT).
Therefore, the example should be expected to succeed if (a) 4 sockets are available on the system (otherwise you need to adjust SOCKET_COUNT) and (b) on each socket, there is a DSA instance present. This would be in accordance with "Set NUMA id parameter of the job to the specific node id, then devices will be selected only from this node".
If current_job->numa_id is not set, DML would use the information about the NUMA node of the calling thread for the job submission (meaning, your thread/process is tied to CPU core from NUMA node N and only devices from N would be used during execution). You could pin the process to a specific node via numactl --cpunodebind=<node_id> for instance.
Hope this helps, let me know.

hi @Sean58238 does this clarifies things for you?

yes,  setup1-4 runs with Config 2, this issue happened on this config

repo: intel/DML


text:
vector.shape_cast not properly lowered to LLVM

If a workload involves tensor.expand_shape and vector passes at the same time, the final lowered llvm IR contains unrealized_conversion_cast op, which cannot be interpreted.
One of the minimum reproducible case is as follows.
module {
  func.func @main_entry(%arg0: tensor<2x32x16xf32>, %arg1: tensor<32x16xf32>) -> tensor<32x16xf32> attributes {llvm.emit_c_interface} {
    %expanded_1 = tensor.expand_shape %arg1 [[0, 1], [2]] output_shape [2, 16, 16] : tensor<32x16xf32> into tensor<2x16x16xf32>
    %1 = tensor.empty() : tensor<32x16xf32>
    %6 = linalg.batch_reduce_matmul ins(%arg0, %expanded_1 : tensor<2x32x16xf32>, tensor<2x16x16xf32>) outs(%1 : tensor<32x16xf32>) -> tensor<32x16xf32>
    return %6 : tensor<32x16xf32>
  }
}

Is it because we don't contain -convert-vector-to-llvm in our pipeline?

Is it because we don't contain -convert-vector-to-llvm in our pipeline?

Partially, adding -convert-vector-to-llvm can resolve the issue under a certain cases. We also have other issues.

Is it because we don't contain -convert-vector-to-llvm in our pipeline?

Partially, adding -convert-vector-to-llvm can resolve the issue under a certain cases. We also have other issues.

-convert-vector-to-llvm can resolve unrealized_conversion_cast, but it also causes explosion in the number of IRs. The compile time is too long to be bearable after the number of MLP layers >=2

We can run simple plain-in-plain-out MLP by adding the following 2 passes
pm.addPass(createConvertVectorToSCFPass());
pm.addPass(createConvertVectorToLLVMPass());

However, the compilation time is too long:
{
    "args": {
        "type": "bench",
        "driver": "mlp",
        "batch_size": 128,
        "hidden_size_list": "512x256x128",
        "has_bias": "256x128",
        "act_type": "relu",
        "dtype": "f32",
        "bench_kind": "py",
        "print_ir": false,
        "disable_results_to_params": false,
        "warm_up": 100,
        "repeat": 100
    },
    "compile_cost(ms)": 147815.80170989037,
    "execute_cost(ms)": 0.25182072073221207
}

Let me explain something. The vector lower pass is in this PR #252.
At the same time, it is best not to use this pass alone if the tiling tensor is large, because the mlir default lower pipeline of vector operation is to full unroll all instructions, resulting in a very long IR. Of course the final result is that the compilation will take a long time and compiled binary file is huge.
Therefore, this pass is usually used with the physical register pass. We will use a for loop to handle the full unroll instructions.

repo: intel/graph-compiler


text:
Restructuring codebase

DISCLAIMER: These are quite deep changes to the repository, we should probably make sure everyone agrees in the proposed changes down to the finest detail.
Goal is simply make the platform-specific changes consistent with each other, and keeping the root-level and source folders clean of platform-specific files.
This builds correctly under Windows+VS2017 and macOS+Xcode. Testing on Windows+EWDK is pending.
There's no functionality changes, so there should be no run-time regressions.
Changes
Generic changes:

Combined platform-specific folders. Moved {darwin,windows}/ to platforms/{darwin,windows}/, to avoid polluting the root folder. This is meant to reduce root-folder pollution, specially if support for more platforms (e.g. Linux) is added.
Combined documentation: Moved API.md to docs/api.md, and added platform-specific usage instructions in docs/manual-{darwin,windows}.md to avoid polluting README.md, specially if support for more platforms (e.g. Linux) is added.
Reorganized .gitignore files: One root-level .gitignore file with general rules that affect the entire source tree (e.g.: .DS_Store for macOS), and platform/compiler-specific rules at platforms/*/.gitignore to deal with build-related files (e.g.: *.vcxproj.user for Visual Studio, build/ for Xcode).
Improved consistency across platforms: Before, each platform acted,

Renamed darwin/hax_driver/com_intel_hax to darwin (consistent folder depth).
Renamed Windows build directory from obj to build (consistent naming with macOS).

Changes on Windows:

Modified solution filters: Updated solution filters/folders to match the layout of the repository {core, platforms, tests}.
Removed WDK 7.1 makefiles: According to https://github.com/intel/haxm/pull/108#issuecomment-431271607, these were part of the legacy WDK 7.1 build system used in earlier HAXM releases and no longer consumed. This was replaced with WDK 10, whose Nmake2MsBuild tool generated the necessary .props files.
Removed WDK 10 makefiles: There's no need of having one extra layer of indirection in our build systems: both VS and EWDK consume only .sln/.vcxproj files which are already checked in the repository. The additions to .vcxproj's are not significantly more verbose (and redundancy could still be reduced by removing duplicated statements if necessary).
Explicitly disabled JustMyCode: Debug configurations enable JustMyCode which causes a known bug in driver projects under Visual Studio 15.8.

Changes on macOS:

Removed readme: Previously at darwin\hax_driver\com_intel_hax\readme, since its description of the codebase no longer matched the state of the codebase.

Thanks, the new source tree layout looks so neat and clean!
nit: In platforms/windows/, there are 3 .c files where some of the #include paths are not "canonical", although that doesn't break the build:

hax_win.h
hax_host_mem.c
hax_wrapper.c

We have started testing this PR, and have found one issue so far: the tests project fails the Win32 build (both Debug and Release).
  test_emulator.obj : error LNK2019: unresolved external symbol _em_decode_insn referenced in function "protected: void __thiscall EmulatorTest::assemble_decode(char c
onst *,unsigned __int64,unsigned int *,unsigned int *,enum em_status_t *)" (?assemble_decode@EmulatorTest@@IAEXPBD_KPAI2PAW4em_status_t@@@Z) [\path\to\haxm\platforms\wi
ndows\haxm-tests.vcxproj]
  test_emulator.obj : error LNK2019: unresolved external symbol _em_emulate_insn referenced in function "protected: void __thiscall EmulatorTest::run(char const *,stru
ct test_cpu_t const &,struct test_cpu_t const &)" (?run@EmulatorTest@@IAEXPBDABUtest_cpu_t@@1@Z) [\path\to\haxm\platforms\windows\haxm-tests.vcxproj]
  \path\to\haxm\platforms\windows\build\tests\Win32\\haxm-tests.exe : fatal error LNK1120: 2 unresolved externals [\path\to\haxm\platforms\windows\haxm-tests.vcxproj]

By canonical you mean they are not relative to the current file? If so, I've just fixed it. The reason it worked is that the project (and the source.props file before), has several added include directories.

Right. I noticed that you had updated most relative #include paths, so I just thought you had missed a few.

This was seemingly caused my the last PR, since the emulator tests include emulate.h, which relies on HAX_ARCH* macros, which are included from include/hax_types.h if HAX_TESTS is not defined, which it is.

I see. I thought we had tested the Win32 build before merging #110, but perhaps we overlooked the tests build failure.

In the future we probably should make a clear cut between kernel and userspace: maybe by defining macros HAX_KERNEL and HAX_USER (instead of HAX_TESTS) that lets us separate code better.

I agree. Maybe this can help us solve another problem (#9): that hax_interface.h is actually not shared between HAXM (kernel) and QEMU (user space). There are a few issues to fix, but making hax_types.h portable would be a key step.

Maybe this can help us solve another problem (#9): that hax_interface.h is actually not shared between HAXM (kernel) and QEMU (user space).

Yes, my thoughts exactly. :-)

authors: AlexAltea raphaelning

repo: intel/haxm


text:
build: move to Go 1.19

Signed-off-by: Mikko Ylinen mikko.ylinen@intel.com

Codecov Report

Merging #1093 (bb33a0d) into main (8f2d10c) will not change coverage.
The diff coverage is n/a.

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

@@           Coverage Diff           @@
##             main    #1093   +/-   ##
=======================================
  Coverage   53.01%   53.01%
=======================================
  Files          40       40
  Lines        4350     4350
=======================================
  Hits         2306     2306
  Misses       1917     1917
  Partials      127      127

Impacted Files
Coverage Δ

cmd/gpu_plugin/rm/gpu_plugin_resource_manager.go
83.42% <ø> (ø)

cmd/qat_plugin/dpdkdrv/dpdkdrv.go
84.48% <ø> (ø)

pkg/controllers/reconciler.go
4.25% <ø> (ø)

pkg/fpga/dfl_linux.go
0.00% <ø> (ø)

pkg/fpga/intel_fpga_linux.go
0.00% <ø> (ø)

pkg/fpgacontroller/patcher/patcher.go
98.40% <ø> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@uniemimu @kad @tkatila @hj-johannes-lee please review and merge. I don't have enough rights to merge it.

authors: bart0sh codecov-commenter mythi