gridsome build hangs after Compile assets

Description
Upon creating a new, OOTB project and running gridsome build, it hangs after Compile assets and never creates any HTML files.
Steps to reproduce

Install the gridsome cli: sudo npm install --global @gridsome/cli
Create the project: gridsome create ttoo
cd ttoo
Build with gridsome build

Expected result
A /dist folder with HTML, JS and CSS etc.
Actual result
gridsome build
Gridsome v0.5.7

Initialize - 0.45s
Load sources - 0.03s
Create GraphQL schema - 0.03s
Set up routes - 0s
Generate code - 0.02s
Bootstrap finish - 0.54s
Run GraphQL (0 queries) - 0s
Compile assets - 3.15s

A /dist folder with:
/assets/css/*styles..css
/assets/js/app|component|page*.js
/assets/manifest/client|server.json
Environment

Libs:
- gridsome version: 0.5.7
- @gridsome/cli version: 0.0.9

For Tooling issues:
- Node version: 10.15.3
- Platform:  Mac 10.14.4

Others:
- Yarn version: 1.15.2

@stowball
I'm getting this same issue. It says it compiles assets within 13.65s, and then has been hanging for the last 20 minutes,

Same here. The problem appeared after upgrading running npm install --save which upgraded Gridsome. But I downgraded to 0.5.4 and the issue is still there.

@jd-fillmore @stowball did you manage to downgrade and make building work? I didn't.

I also experienced this and tried to do some debugging. It works when downgrading vue-router. Can anyone else confirm this? Try adding this to package.json and reinstall dependencies with Yarn:
"resolutions": {
  "gridsome/vue-router": "3.0.2"
}

@hjvedvik this helped, thanks!

Thanks for the help @hjvedvik - I'm running into this issue too.  Unfortunately downgrading vue-router to 3.0.2 hasn't helped me?  Is there something I'm possibly missing?
My setup is:
Gridsome:

@gridsome/cli v0.0.9
gridsome v0.5.7

Tooling:

Node version: 11.14.0
Platform:  Mac 10.14.4
Yarn version: 1.15.2

@timcreatewell could you share your code please?

"resolutions": {
"gridsome/vue-router": "3.0.2"
}

This did not solve it for me.  Mine problem project is just a clone of https://github.com/gridsome/gridsome-starter-markdown-blog.git

Hi @sergeyfilimonov , thanks for reaching out!  Unfortunately the code is in a private repo so I'm unable to share it :(
I've done some debugging though and can confirm that a brand new project (with the vue-router change applied) does build on my system.
Additionally, I think I have narrowed down the cause of the build error in my current project.  I have added Vuex and some route guards in gridsome.client.js.  Where I believe things are failing are when I use route guards that reference getters in my Vuex store, for example:
import store from './src/store/index'

export default function (Vue, options, context) {
  context.appOptions.store = store

  context.router.beforeEach((to, from, next) => {
    // store getters simply return a boolean value
    if (to.name === "finalise" &&
            (!store.getters['contact/hasContact'] ||
             !store.getters['product/hasProduct'])) {
      next({ name: 'foo' });
      return
    }

    ...

    next();
  });
}

The example getters contact/hasContact and product/hasProduct listed above simply return a boolean value.
If I comment route guards like the example listed above out, the build passes.
Interestingly, the route guards all work when I run gridsome develop.
Am I perhaps mis-configuring this, that is, I shouldn't be referring to the store in this manner?
Thanks!

I have the same problem.
On clean system I installed brand new gridsome project, and without adding any code, gridsome build hangs after Compile assets.
Issue persists on both MacOS (Mojave 10.14.4) and Windows 10.

Got the same issue. However, downgrading vue-router seems to fix it for me.

I'm using NPM so I'm unable to use the resolutions fix. This issue is blocking me from launching my website unless I completely refactor the way I use SVGs on the website (which would take a lot of my time). Truly infuriating.
I'm considering not using Gridsome at all as it seems to be too unstable.

@vandelay87 your SVGs are somehow dependent on using NPM instead of Yarn?

Using the npm package 'npm-force-resolutions' to downgrade vue router without yarn, I can confirm that my site now builds.  I put the following in my resolutions:
"@gridsome/vue-router": "3.0.2", "ridsome/vue-router": "3.0.2", "vue-router": "3.0.2"

"resolutions": {
  "gridsome/vue-router": "3.0.2"
}

This seems to fix the issue for me (a hang on build). To anyone else who, like me, was new to resolutions in their package.json, here's an overview.

@sergeyfilimonov Thanks for the condescending reply. I understand that SVGs are not dependant on NPM. I sometimes develop on Windows (yeah, I know) and I have had problems with Yarn in the past, so I'm somewhat timid to switch and debug.
@stuible Thanks, I will try that tomorrow.

@hjvedvik @sergeyfilimonov @timcreatewell @apertureless @allanwhite
Pasted the below code into package.json:
"resolutions": {
  "gridsome/vue-router": "3.0.2"
}

Here's a codesandbox of my site.
Tried uninstalling node modules, used ''npm-force-resolutions' package to downgrade as well, reinstalled node_modules, tried gridsome build and still hangs.
Any other suggestions guys? Driving me nuts.

Same problem over here. Everything was just fine a week ago, also using 0.5.7. Tried all the recommended things here and none work 🤔 . Wondering what the problem could be.

I've done some further debugging... By the looks of things things are breaking for me when I try to route to a different path in a route guard within gridsome.client.js
e.g.
...
context.router.beforeEach((to, from, next) => {
    if (to.name === "foo") {
        next({ path: '/bar' });
        return;
    }
    ...

My hunch is that the build process knows nothing of the /bar page at the time that it's processing the gridsome.client.js file and therefore hangs?
Is anyone else using route guards like this?

@vandelay87 Your SVGs should be fine. This bug is caused by a change in the latest version of vue-router. I'll publish a fix later today :)

Looks like the vue-router team has been busy. This issue was fixed in 3.0.4 but reintroduced in 3.0.5 and then fixed again in 3.0.6. So just make sure your lock files use the latest vue-router.

Looks like the vue-router team has been busy. This issue was fixed in 3.0.4 but reintroduced in 3.0.5 and then fixed again in 3.0.6. So just make sure your lock files use the latest vue-router.

Updated vue-router to 3.0.6 and I can confirm this is working. My project is building now. Thank you very much! 😄

I can confirm after adding the vue-router resolution my project now builds. Thanks for the useful thread and responses.

Hi guys,
I've updated my vue-router to 3.0.6 (via npm-force-resolutions) and in my case it's still hanging. I've checked what version of the vue-router is being used by /node_modules/gridsome/node_modules/vue-router/package.json is "_from"<EMAIL_ADDRESS> "_id"<EMAIL_ADDRESS>So I assume gridsome is using the 3.0.6 version.
I've tried few things and in my case it depends on the amount of pages I'm building. From certain amount of pages it just simply hangs. If I shuffle the pages, those which caused for the build to hang, compile fine.
I've encountered issues previously when building up the graphQl. Some resources were not to available as if the pagination was applied (I had 25 of them exactly). I'm wondering if this could be the case here as well.

I'm having the same issue as described,  and I am on 3.0.6 vue-router version.
When I comment out the context.router.beforeEach block the build doesn't hang

Yeah, I'm getting this and it doesn't seem to have anything to do with the router.


⚠ ClamAV has degraded performance

In d2c8ae5, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 201 ms

Resolved: ClamAV performance has improved in 1e6e1bd.


Overriding media acquisition is too hard

Is your feature request related to a problem? Please describe.
Maintainers of SIP.js have made clear in several instances (#588, #602, #696) that using a custom MediaStream as a source instead of getUserMedia() should be done through the implementation of a custom SessionDescriptionHandler. I'm fine with that.
In 0.14 however, the library has been rewritten in typescript, and most of the methods of Web.SessionDescriptionHandler are now private. This means that, to implement the rather small change from #588, one is required to reimplement the whole getDescription() method, while previously overwriting acquire() was enough.
Duplicating everything adds to the maintenance burden, as it forces to track every change to the upstream class. Bugs can easily slip through. It also means duplicating the whole class including modifier handling, ICE, etc., which are already solved problems.
Describe the solution you'd like
Because of that, would it be possible to devise a way to only override the acquisition part of Web.SessionDescriptionHandler (ideally, only the actual stream creation part)?
I can imagine two ways this could be implemented, depending on what fits the library style best, while not adding much maintenance burden to SIP.js itself:

through inheritance, using a protected getMediaStreams(constraints: any): Promise<MediaStream[]> method,
through inheritance, by splitting getDescription() into individually overridable parts,
though some sort of callback in the SessionDescriptionHandlerOptions interface or in events.

Also, due to the way the library uses different options in different contexts (in this case, UA sessionDescriptionHandlerFactoryOptions at creation time but constructor options at INVITE time) it might be useful to pass the options along to whatever solution is chosen.
Describe alternatives you've considered
I tried implementing a modifier that would add mediastream tracks and call createOffer() again, but this fails due to Firefox complaining that you cannot call createOffer() twice.
I could not find any other hook or overridable methods that could make this feature available easily.
Additional context
I need to create a session without requesting user device access.

For reference, my first proposal would look something like this;
diff --git a/src/Web/SessionDescriptionHandler.ts b/src/Web/SessionDescriptionHandler.ts
index 831abbc..190b0e9 100644
--- a/src/Web/SessionDescriptionHandler.ts
+++ b/src/Web/SessionDescriptionHandler.ts
@@ -589,10 +589,7 @@ export class SessionDescriptionHandler extends EventEmitter implements SessionDe
     };
   }

-  private acquire(constraints: any): any {
-    // Default audio & video to true
-    constraints = this.checkAndDefaultConstraints(constraints);
-
+  protected getMediaStreams(constraints: any): Promise<MediaStream[]> {
     return new Promise((resolve, reject) => {
       /*
        * Make the call asynchronous, so that ICCs have a chance
@@ -624,7 +621,14 @@ export class SessionDescriptionHandler extends EventEmitter implements SessionDe
         this.logger.error(error.error);
       }
       throw error;
-    }).then((streams) => {
+    });
+  }
+
+  private acquire(constraints: any): any {
+    // Default audio & video to true
+    constraints = this.checkAndDefaultConstraints(constraints);
+
+    return this.getMediaStreams(constraints).then((streams) => {
       this.logger.log("acquired local media streams");
       try {
         // Remove old tracks

@nud I was fighting with this, too. I agree there should be a hook to override only media acquisition.
However, in the meantime, you could try this hack, seems to work for me:
class MySDH extends Web.SessionDescriptionHandler {
  constructor(...) {
    this["acquire"] = this.myAcquire;
  }
  private myAcquire(...) { ... }
}

After all TS is just JS when you need to get work done ;)

@grischa that looks indeed like a solution, but I am afraid that the typescript compiler could benefit from the "privateness" of the method to optimize it out / change its name.
IMO an officially supported way is desirable, especially as the need seems to be pretty common.

@grischa that looks indeed like a solution, but I am afraid that the typescript compiler could benefit from the "privateness" of the method to optimize it out / change its name.
IMO an officially supported way is desirable, especially as the need seems to be pretty common.

For reference, here is my current not-pretty-at-all implementation:
import {
  SessionDescriptionHandler as WebSessionDescriptionHandler,
  SessionDescriptionHandlerModifiers,
  InviteClientContext,
  InviteServerContext,
} from "sip.js";

// FIXME: we need pretty intimate imports to be able to inherit from
// SIP.Web.SessionDescriptionHandler.
import { SessionDescriptionHandlerObserver } from "sip.js/lib/Web/SessionDescriptionHandlerObserver";
import { WebSessionDescriptionHandlerOptions } from "sip.js/lib/Web/SessionDescriptionHandler";
import { BodyObj } from "sip.js/lib/session-description-handler";
import { Logger as SIPLogger } from "sip.js/lib/core/log";

export interface SessionDescriptionHandlerOptions
  extends WebSessionDescriptionHandlerOptions {
  mediaStream?: Promise<MediaStream>;
}

/*
 * This SessionDescriptionHandler implements a way to provide a media stream
 * as an audio source instead of a media device.
 *
 * See https://github.com/onsip/SIP.js/pull/588
 */
export class SessionDescriptionHandler extends WebSessionDescriptionHandler {
  public static factory(
    session: InviteClientContext | InviteServerContext,
    options: any,
  ): SessionDescriptionHandler {
    const logger = session.ua.getLogger(
      "sip.invitecontext.sessionDescriptionHandler",
      session.id,
    );
    const observer = new SessionDescriptionHandlerObserver(session, options);
    return new SessionDescriptionHandler(
      logger,
      observer,
      options as SessionDescriptionHandlerOptions,
    );
  }

  private defaultAcquire: (constraints: any) => any;
  private mediaStream?: Promise<MediaStream>;

  constructor(
    logger: SIPLogger,
    observer: SessionDescriptionHandlerObserver,
    options: SessionDescriptionHandlerOptions,
  ) {
    super(logger, observer, options);
    // If we have the "mediaStream" option, then we override the "acquire" method.
    // FIXME: use proper inheritance/overriding.
    // See https://github.com/onsip/SIP.js/issues/709

    this.defaultAcquire = this["acquire"];
    this["acquire"] = this.realAcquire;
  }

  private realAcquire(constaints: any) {
    if (this.mediaStream) {
      return this.acquireMediaStream(this.mediaStream);
    } else {
      return this.defaultAcquire.apply(this, constaints);
    }
  }

  private acquireMediaStream(mediaStream: Promise<MediaStream>) {
    return mediaStream.then(stream => {
      try {
        // Remove old tracks
        if (this.peerConnection.removeTrack) {
          this.peerConnection.getSenders().forEach(sender => {
            this.peerConnection.removeTrack(sender);
          });
        }

        // Add new tracks
        stream.getTracks().forEach(track => {
          this.peerConnection.addTrack(track, stream);
        });

        return Promise.resolve();
      } catch (e) {
        return Promise.reject(e);
      }
    });
  }

  public getDescription(
    options: WebSessionDescriptionHandlerOptions = {},
    modifiers: SessionDescriptionHandlerModifiers = [],
  ): Promise<BodyObj> {
    this.mediaStream = (options as SessionDescriptionHandlerOptions).mediaStream;
    return super.getDescription(options, modifiers);
  }

  public setDescription(
    sessionDescription: string,
    options: WebSessionDescriptionHandlerOptions = {},
    modifiers: SessionDescriptionHandlerModifiers = [],
  ): Promise<void> {
    this.mediaStream = (options as SessionDescriptionHandlerOptions).mediaStream;
    return super.setDescription(sessionDescription, options, modifiers);
  }
}

It is worth noting that:

we pass the media stream at invite time (not at UA initialization time) so it forces us to do some additional moving-around operations that could be avoided by passing the options to the hypothetic getMedia handler.
we need to import a bunch of semi-private stuff from SIP.js to be able to inhertit from the handler.

IMO any improvement in these areas is worth taking, especially since I don't think this is such an uncommon case.
Just off the top of my head, what about having some MediaStreamFactory class, whose default implementation would be to get the browser's user media? IT would not feel foreign to the current design and would be very flexible without requiring users to reimplement the whole SDP handling part.

We just finished discussing this internally. We think that making the acquire function (and potentially others) protected is a great idea. The big issue is, once we do that, we are essentially supporting that interface moving forward. We want to take a bit of time and review these functions to make sure we like the headers and return types and then we will push an update to make them protected.

@egreenmachine glad to hear it! :+1:
Alternatively, providing some "mediastream" promise as a parameter might be a simpler and easier solution to maintain on your side, or splitting parts out as i suggested in my previous comments. I get that supporting inheritance is a big maintenance burden (composition is usually easier) but at the same time the Session Description Handler does way more than just "media management" at this point...

I pushed 7caeb88f4071902ad4a5c357d5f286bc602921a2 as a first pass at this. Let me know if it covers what you were looking for. We plan to do a bit more work here after the next release is settled.

@egreenmachine at first sight it looks nice. It certainly does the job for my own current use case. The improved typing is good. The small improvements I could suggest are:

passing the configuration object so that whoever implements that subclass can act according to the (maybe custom) options. Basically it could replace the constraints, as these are part of the options object.
export the types that are required to implement one's own factory, or make the actual class a factory option (I guess there is no need to override the constructor most of the time if you can pass extra options to getMediaStream())

export the types that are required to implement one's own factory, or make the actual class a factory option (I guess there is no need to override the constructor most of the time if you can pass extra options to getMediaStream())

We already export the types needed to make your own factory... https://github.com/onsip/SIP.js/blob/master/src/session-description-handler-factory.ts. I am not sure what else you are asking for here.

@egreenmachine what I mean is this:
if you want to inherit from Web.SessionDescriptionHandler, you will need at some point to call the constructor. It means you need access to the following types (from the code sample above):
import { SessionDescriptionHandlerObserver } from "sip.js/lib/Web/SessionDescriptionHandlerObserver";
import { WebSessionDescriptionHandlerOptions } from "sip.js/lib/Web/SessionDescriptionHandler";
import { Logger } from "sip.js/lib/core/log";

Otherwise you cannot write this:
  public static customFactory(
    session: InviteClientContext | InviteServerContext,
    options: any,
  ): SessionDescriptionHandler {
    const logger: Logger = session.ua.getLogger(
      "sip.invitecontext.sessionDescriptionHandler",
      session.id,
    );
    const observer = new SessionDescriptionHandlerObserver(session, options);
    return new MyOwnSessionDescriptionHandler(logger, observer, options);
  }

If you want to create a new SessionDescriptionHandler subclass from scratch, you need to be able to override getDescription() and setDescription() so you need the following type:
import { BodyObj } from "sip.js/lib/session-description-handler";

These can be used already, but it involves looking into the library and importing the right private files.
Most probably any type that is part of the prototype of a function that one is supposed to override should be part of the exported API.

I see. You are absolutely correct that they are not exported. I do not want to export the Observer as we are moving towards a standard approach for the library with delegates. I will try and find some time to make the necessary changes and get the required interfaces public.

@egreenmachine if this is part of the legacy API that is going to die in 0.16 I would not spend too much time on this. Since many changes will be required anyway, importing private stuff, while bad practice, is not too bad :-)
Thank you very much for the time you spent on this issue.

Hi,
#815 is a new implementation which I believe/hope addresses this issue.
Media Acquisition
The function which returns a new default SessionDescriptionHandlerFactory....
export function defaultSessionDescriptionHandlerFactory(
  mediaStreamFactory?: (
    constraints: MediaStreamConstraints,
    sessionDescriptionHandler: SessionDescriptionHandler
  ) => Promise<MediaStream>
): SessionDescriptionHandlerFactory {

now takes a MediaStreamFactory as a parameter...
/**
 * Interface of factory function which produces a MediaStream.
 * @public
 */
export type MediaStreamFactory = (
  constraints: MediaStreamConstraints,
  sessionDescriptionHandler: SessionDescriptionHandler
) => Promise<MediaStream>;

So you may provide whatever implementation you wish to acquire a local MediaStream.
If a MediaStreamFactory is not specified, a default which uses getUserMedia() is provided.
This can be set via the existing UserAgentOption.sessionDescriptionHandlerFactory.
Extending SessionDescription Handler
I've attempt to make the new implementation extensible enough to be useful but without going so far as creating a maintenance headache. But I'm interested in feedback - particularly if it ends up resulting a "less is more" outcome.

@john-e-riordan here is what my current (0.16) implementation looks like:
import { Session, Web } from "sip.js";

export interface CustomMediaStreamConstraints extends MediaStreamConstraints {
  stream?: boolean;
}

export class SessionDescriptionHandler extends Web.SessionDescriptionHandler {
  public static factory(
    session: Session,
    options: any,
  ): SessionDescriptionHandler {
    const logger = session.userAgent.getLogger(
      "sip.SessionDescriptionHandler",
      session.id,
    );
    return new SessionDescriptionHandler(logger, options);
  }

  private createStream(): Promise<MediaStream> {
    // ...
  }

  protected getMediaStream(
    constraints: MediaStreamConstraints,
  ): Promise<MediaStream> {
    const c = constraints as CustomMediaStreamConstraints;

    return c.stream
      ? this.createStream()
      : super.getMediaStream(constraints);
  }
}

I suppose the 0.16 API already removed a bunch of obstacles. But the MediaStreamFactory sure looks nice as long as it can be set in the Invite options or receive parameters from there.

With your MR I suppose the code above will become something like this:
import { MediaStreamFactory, Web } from "sip.js";

function createStream(): Promise<MediaStream> {
   // ...
}

function customFactory(constraints: MediaStreamConstraints): Promise<MediaStream> => {
    const c = constraints as CustomMediaStreamConstraints;

    return c.stream ? createStream() : Web.defaultMediaStreamFactory()(constraints);
}

Then in the UA options:
const options: UserAgentOptions = {
   // ...
   mediaStreamFactory: customFactory;
   // replaces sessionDescriptionHandlerFactory: SessionDescriptionHandler.factory
}

Is that correct? I couldn't find the place where you set the stream factory in the MR.

Hey,
import { UserAgent, UserAgentOptions, Web } from "sip.js";

// My custom media stream factory...
const mediaStreamFactory: Web.MediaStreamFactory = (constraints: MediaStreamConstraints, sessionDescriptionHandler: Web.SessionDescriptionHandler): Promise<MediaStream> => {
  const mediaStream = new MediaStream();
  return Promise.resolve(mediaStream);
}

const options: UserAgentOptions = {
  sessionDescriptionHandlerFactory: Web.defaultSessionDescriptionHandlerFactory(mediaStreamFactory)
}

const myUA = new UserAgent(options);

So you mentioned "as long as it can be set in the Invite options or receive parameters from there."
From my prior comment above, you can see that the current constraints (from the invite options) and the sessionDescriptionHandler itself get passed to the custom mediaStreamFactory. I'd like to understand what else, if anything, you might need to pass and why?

@john-e-riordan no it's fine, currently I pass everything using the constraints object, the typing of which got related in the 0.16 API.
I just provided the code samples so that you get the use case, but I think your API proposal is fine.

Closing this as the proposal was released in 0.17.0.


Update README.md and fix readPackageAsync

Fix SyntaxError: The requested module 'read-pkg' does not provide an export named 'readPackageAsync'
Add install instructions, npm package name is different from github and it's not trivial to find the package

Thanks, I totally forgot that these things are named different!


Preference window too tall to fit on screen

From<EMAIL_ADDRESS>on 2011-03-12T10:06:30Z
What steps will reproduce the problem?

Launch spyder
Entern prefereneces
Window too tall so Apply, Cancel, OK not reachable

(workaround: maximize window) What version of the product are you using? On what operating system? Spyderlib from rep. Mac OSX 10.6, Python 2.7
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=583

From pierre.raybaut on 2011-03-13T01:04:24Z
Status: Duplicate
Mergedinto: 419


Nan::New should almost always return MaybeLocal

Only a handful of New<T> overloads return MaybeLocal<T> at the moment.
In practice, everything that's not a singleton primitive (anything that's not true, false, undefined or null) can fail under OOM conditions.
If nothing else, the current MaybeLocal/Local dichotomy is kind of ad hoc and inconsistent.  For example, the overloads for v8::Date and v8::RegExp return a MaybeLocal, the ones for v8::Array and v8::Object return das Ding an sich, even though they're all heap objects.

That's the way it is in V8.

Okay, but I'll bet you a beer it's not going to stay that way.

Perhaps it won't stay, but there have been no concrete indications of an oncoming change yet. The code will adapt if it has to. I beg you not to inquire about the state of this from the V8 devs, lest you stir up a new set of changes.

I beg you not to inquire about the state of this from the V8 devs, lest you stir up a new set of changes.

you've made my day, nearly spat out my coffee while reading that

I think that https://code.google.com/p/v8/issues/detail?id=3929 indicates, that MaybeLocal<> is da future. Whenever there is exception now, empty handle will be returned.

That issue is several months old. It seems resolved, since the last two commits are
https://chromium.googlesource.com/v8/v8.git/+/7f38011a04ca27e8f88b300713c8dc05ba8d61d7
convert last api functions which try to handle exceptions to maybes
and
https://chromium.googlesource.com/v8/v8.git/+/5d8e3bfaffd1c0edac4f03b41767b101dd75c482
Clarify what APIs return Maybe and MaybeLocal values


H/S Pre-run set up flow: Module Set Up Step Copy Updates

Overview
For protocols that use h/s, there is a dynamic step copy change that guides users to "Follow software instructions on how to set up the Heater Shaker module"
Implementation Details

This feature is located in the App's Devices tab
If h/s is present in a protocol, the step 2 accordion copy will update to read "Follow software instructions on how to set up the Heater Shaker module" as specified in design.

Design

https://www.figma.com/file/695ogls23YsQYImRcGYDE1/Heater-Shaker?node-id=752%3A31579

Acceptance Criteria

Module set up Step 2 copy dynamically changes if H/S is present in the protocol. Added copy reads: "The Heater Shaker module will require set up"
Module set up Step 2 copy reverts to default if H/S is not present or detected in protocol ("Plug in and turn on the required modules via the OT-2 USB ports. Place the modules as shown in the deck map")

this ticket has changed and is n/a with latest designs. closing


Help with error

Issue Description:
I've assigned an array and am trying to iterate through it to print an array of block ids.
What happens:
I get an error in the log and it does not print.
What you expected to happen:
I expected it to print the array to the log.
Script used (Please Pastebin or gist your script, posting an unpasted or ungist'd script will automatically close this issue): https://pastebin.com/51kHbrAc
Minetweaker.log file (Please Pastebin or gist your file, posting an unpasted or ungist'd file will automatically close this issue): https://pastebin.com/E3fBDEyq

Affected Versions (Do not use "latest"):

Minecraft: 1.12.2
Forge: <IP_ADDRESS>1
Crafttweaker: 4.0.7

Your most recent log file where the issue was present:
Which log goes here exactly?
fml_client_latest

You need to define what the array is.

wow I feel dumb now, thank you


No support for creating virtual networks

There is no support for creating virtual networks on azure using the SDK

This issue is still open #155


Update Set-SPEnterpriseSearchTopology.md

Updated example.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-server/Set-SPEnterpriseSearchTopology.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Relative paths in path settings

Would it be possible to support relative paths in path settings? (Currently just game directory and FGDs.)
Reason: I have a portable GoldSrc development folder at "some portable location" with some sub folders:

compile
decompile
fgd
maps
resources
sources
textures
tools
... and more

I put "bspguy.exe" in "decompile" because that's what it's for, so in my case it would be neat if the FGD paths could be relative, such as ../fgd/Sven Co-op 5.23.fgd or ..\fgd\Sven Co-op 5.23.fgd instead of an absolute (and sometimes changing) path.
This may require use of an $AppDir placeholder to insert the current path name of the directory the application resides in.

Sure, I didn't think of using it this way.

@wootguy is this issue still there?

#26 fixes this.
"Asset paths" (for finding WADs) and "FGDs" can be relative to the working directory or "Game Directory". Relative paths currently need to start with a slash.

@wootguy but global settings path anyway non portable. May be for window user need save settings in same folder(where bspguy.exe located)?

That's a different issue, but I can see a local settings file being useful (at least for game-related settings).

Thank you kindly for that update @2020karaulov2020


Avoid confusion of inplace LM masking

Fix confusion of LM masking that happens inplace. Discussed in https://github.com/huggingface/pytorch-pretrained-BERT/issues/243 and https://github.com/huggingface/pytorch-pretrained-BERT/issues/226

Great, thanks @tholor!


Iterative BitSizeL implementation

This PR fixes #403 by replacing the recursive implementation with an iterative one. However, reading @vadym-kl's issue description I wonder whether it is better to implement it as a Q# intrinsic and calling directly into C#'s method to retrieve the bit size.

It looks like the build failure is transient, so maybe let's kick off another one?
/azp run
With respect to the other point, I think especially for QIR emission, it would make sense to keep this backed by your  Q# implementation so as to not introduce another intrinsic that target packages need to implement.

With respect to the other point, I think especially for QIR emission, it would make sense to keep this backed by your Q# implementation so as to not introduce another intrinsic that target packages need to implement.

Can we do both? Provide a Q# implementation but also have a C# implementation for when we run Q# applications inside C#? I think such an approach would be generally helpful.

Can we do both? Provide a Q# implementation but also have a C# implementation for when we run Q# applications inside C#? I think such an approach would be generally helpful.

Good question, yeah. @swernli, I know you've raised that some of the behavior around that has changed recently with the  move to targeting packages; how would be best to have the best of both worlds here?

Thanks for drawing my attention to this, Chris! The good news is that the target package work (which merged to qsharp-runtime/main as of https://github.com/microsoft/qsharp-runtime/pull/476) was able to accomplish its goals in a (mostly) non-breaking way. So the behavior I raised before that changed actually didn't change and can still work as it did before. For clarity, here's a list of the current behaviors you can use:

If you provide a Q# implementation for a callable and a C# implementation, the C# implementation will override the Q# as it does today, using the existing mechanisms for discovering child classes in the C# and registering them as overrides their parent (this behavior was going to change but now has not).
If you define a Q# callable as body intrinsic then by default it will be generated into an abstract C# class, so failing to provide a C# child class with implementation will result in a runtime failure because the infrastructure won't find any overrides and will try to instantiate the abstract class (also matches current behavior).
If you define a Q# callable as body intrinsic and opt-in to the the new behavior it will be generated as a concrete C# class that calls into an interface to invoke the desired implementation. You must then define the interface implement it on your desired simulator or other runtime environment to get the right functionality, and will get compile time errors if the interface definition is missing and runtime errors if the chosen simulator doesn't implement that interface (this is the new behavior and is entirely optional).

So it sounds like in this case you want to use that first option, which will still work as it does today. That way the Q# implementation will be used when generating code (such as for QIR) but the C# implementation will take precedence with our default simulator.

Thanks for the help, @swernli!

If you provide a Q# implementation for a callable and a C# implementation, the C# implementation will override the Q# as it does today, using the existing mechanisms for discovering child classes in the C# and registering them as overrides their parent (this behavior was going to change but now has not).

So it sounds like in this case you want to use that first option, which will still work as it does today. That way the Q# implementation will be used when generating code (such as for QIR) but the C# implementation will take precedence with our default simulator.

Agreed, I think this meets both usecases fairly nicely. It's good to have the version that relies on the nicely optimized code from the C# standard libraries while still being able to use the pure Q# version in QIR. My only concern at that point would be testing to make sure that the Q# version is correct when the C# implementation is missing; I think that isn't quite covered by @Test(...) at the moment, such that we may need a bit more there...

Thanks for the help and feedback @swernli and @cgranade. I am also not clear at the moment, how we can test both implementations. I will merge this PR for now and eventually open another one, adding a C# native implementation when we sorted out the test questions.


Pin SonarQube version for each release

Currently, the SonarQube image is always the "latest" version of SonarQube, thus there is no guarantee that any given release of this project will have the same version of SonarQube.

closed for https://github.com/redhat-cop/containers-quickstarts/issues/186


Allow any members to trigger /merge if a PR which targets to a release branch is approved.

Feature Request

[ ] I have searched the issues of this repository and believe that this is not a duplicate.

Is your feature request related to a Issue or PR(Optional)

Which project:

PR or Issue Link:

Describe the feature you'd like:
If a PR which targets to a release branch is approved by an authorized member. Any other members but not only authorized members can trigger /merge.
Do you have any ideas on how to implement it?(Optional)

@zhouqiang-cl


Inconsistent error "Invalid HMAC"

I have a server that opens 3 connections to 3 different clients and runs a command. Randomly the server will throw the following error:
ERROR Error: Invalid HMAC
  at SSH2Stream._transform (.../node_modules/ssh2-streams/lib/ssh.js:543:25)
  at SSH2Stream.Transform._read (_stream_transform.js:167:10)
  at SSH2Stream._read (.../node_modules/ssh2-streams/lib/ssh.js:236:15)
  at SSH2Stream.Transform._write (_stream_transform.js:155:12)
  at doWrite (_stream_writable.js:307:12)
  at writeOrBuffer (_stream_writable.js:293:5)
  at SSH2Stream.Writable.write (_stream_writable.js:220:11)
  at Socket.ondata (_stream_readable.js:556:20)
  at emitOne (events.js:96:13)
  at Socket.emit (events.js:188:7)
  at readableAddChunk (_stream_readable.js:177:18)
  at Socket.Readable.push (_stream_readable.js:135:10)
  at TCP.onread (net.js:542:20)

It doesn't happen every time it's run and it doesn't happen on all servers at the same time (sometimes 0, 1, 2, or all 3). The command is long running (5-10 mins) with a lot of output (thousands of lines), and logging shows it happens to stop randomly in time/code for that command.
Server:
# node --version
v6.4.0
# ssh -V
OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014
# npm ls ssh2-streams
...
└─┬<EMAIL_ADDRESS>  └──<EMAIL_ADDRESS>
Clients:
# ssh -V
OpenSSH_5.3p1, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
# ssh -V
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
# ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013

As some background, this library/process had been working flawlessly up to a couple weeks ago. I updated all the associated libraries on both server/client to no avail. It is possibly correlated to updating node from v0.10 to v6, but that may be a red herring.

Can you set debug: console.log in the connection config and post the handshaking info (where the ciphers, hmacs, etc. are exchanged) for each of the problematic endpoints?

We have a giant log that doesn't separate the output on the server (internal tool, logging not normally needed to be separate), so apologies for that. Here is all 3:
Local ident: 'SSH-2.0-ssh2js0.1.6'
Client: Trying build5.dev.teralogics.com on port 22 ...
Local ident: 'SSH-2.0-ssh2js0.1.6'
Client: Trying build6.dev.teralogics.com on port 22 ...
Local ident: 'SSH-2.0-ssh2js0.1.6'
Client: Trying build7.dev.teralogics.com on port 22 ...

Client: Connected
Remote ident: 'SSH-2.0-OpenSSH_5.3'
Outgoing: Writing KEXINIT
Comparing KEXINITs ...
(local) KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
(remote) KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
KEX algorithm: diffie-hellman-group-exchange-sha256
(local) Host key formats: ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
(remote) Host key formats: ssh-rsa,ssh-dss
Host key format: ssh-rsa
(local) Client->Server ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes128-gcm<EMAIL_ADDRESS>(remote) Client->Server ciphers<EMAIL_ADDRESS>Client->Server Cipher: aes128-ctr
(local) Server->Client ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes128-gcm<EMAIL_ADDRESS>(remote) Server->Client ciphers<EMAIL_ADDRESS>Server->Client Cipher: aes128-ctr
(local) Client->Server HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1
(remote) Client->Server HMAC algorithms: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
Client->Server HMAC algorithm: hmac-sha1
(local) Server->Client HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1
(remote) Server->Client HMAC algorithms: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
Server->Client HMAC algorithm: hmac-sha1
(local) Client->Server compression algorithms: none,zlib@openssh.com,zlib
(remote) Client->Server compression algorithms<EMAIL_ADDRESS>Client->Server compression algorithm: none
(local) Server->Client compression algorithms: none,zlib@openssh.com,zlib
(remote) Server->Client compression algorithms<EMAIL_ADDRESS>Server->Client compression algorithm: none
Outgoing: Writing KEXDH_GEX_REQUEST
Outgoing: Writing KEXDH_GEX_INIT
Checking host key format
Checking signature format
Verifying host fingerprint
Host accepted by default (no verification)
Verifying signature
Outgoing: Writing NEWKEYS
Outgoing: Writing SERVICE_REQUEST (ssh-userauth)
Outgoing: Writing USERAUTH_REQUEST (password)
Outgoing: Writing CHANNEL_OPEN (0, session)
Outgoing: Writing CHANNEL_REQUEST (0, exec)

Client 2:
Local ident: 'SSH-2.0-ssh2js0.1.6'
Client: Trying ... on port 22 ...
Client: Connected
Remote ident: 'SSH-2.0-OpenSSH_5.3'
Outgoing: Writing KEXINIT
Comparing KEXINITs ...
(local) KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
(remote) KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
KEX algorithm: diffie-hellman-group-exchange-sha256
(local) Host key formats: ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
(remote) Host key formats: ssh-rsa,ssh-dss
Host key format: ssh-rsa
(local) Client->Server ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes128-gcm<EMAIL_ADDRESS>(remote) Client->Server ciphers<EMAIL_ADDRESS>Client->Server Cipher: aes128-ctr
(local) Server->Client ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes128-gcm<EMAIL_ADDRESS>(remote) Server->Client ciphers<EMAIL_ADDRESS>Server->Client Cipher: aes128-ctr
(local) Client->Server HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1
(remote) Client->Server HMAC algorithms: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
Client->Server HMAC algorithm: hmac-sha2-256
(local) Server->Client HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1
(remote) Server->Client HMAC algorithms: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
Server->Client HMAC algorithm: hmac-sha2-256
(local) Client->Server compression algorithms: none,zlib@openssh.com,zlib
(remote) Client->Server compression algorithms<EMAIL_ADDRESS>Client->Server compression algorithm: none
(local) Server->Client compression algorithms: none,zlib@openssh.com,zlib
(remote) Server->Client compression algorithms<EMAIL_ADDRESS>Server->Client compression algorithm: none
Outgoing: Writing KEXDH_GEX_REQUEST
Outgoing: Writing KEXDH_GEX_INIT
Checking host key format
Checking signature format
Verifying host fingerprint
Host accepted by default (no verification)
Verifying signature
Outgoing: Writing NEWKEYS
Outgoing: Writing SERVICE_REQUEST (ssh-userauth)
Outgoing: Writing USERAUTH_REQUEST (password)
Outgoing: Writing CHANNEL_OPEN (0, session)
Outgoing: Writing CHANNEL_REQUEST (0, exec)

Client 3:
Local ident: 'SSH-2.0-ssh2js0.1.6'
Client: Trying ... on port 22 ...
Client: Connected
Remote ident: 'SSH-2.0-OpenSSH_6.6.1'
Outgoing: Writing KEXINIT
Comparing KEXINITs ...
(local) KEX algorithms: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
(remote) KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
KEX algorithm: ecdh-sha2-nistp256
(local) Host key formats: ssh-rsa,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
(remote) Host key formats: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519
Host key format: ssh-rsa
(local) Client->Server ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes128-gcm<EMAIL_ADDRESS>(remote) Client->Server ciphers: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305<EMAIL_ADDRESS>Client->Server Cipher: aes128-ctr
(local) Server->Client ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes128-gcm<EMAIL_ADDRESS>(remote) Server->Client ciphers: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305<EMAIL_ADDRESS>Server->Client Cipher: aes128-ctr
(local) Client->Server HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1
(remote) Client->Server HMAC algorithms: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
Client->Server HMAC algorithm: hmac-sha2-256
(local) Server->Client HMAC algorithms: hmac-sha2-256,hmac-sha2-512,hmac-sha1
(remote) Server->Client HMAC algorithms: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
Server->Client HMAC algorithm: hmac-sha2-256
(local) Client->Server compression algorithms: none,zlib@openssh.com,zlib
(remote) Client->Server compression algorithms<EMAIL_ADDRESS>Client->Server compression algorithm: none
(local) Server->Client compression algorithms: none,zlib@openssh.com,zlib
(remote) Server->Client compression algorithms<EMAIL_ADDRESS>Server->Client compression algorithm: none
Outgoing: Writing KEXECDH_INIT
Checking host key format
Checking signature format
Verifying host fingerprint
Host accepted by default (no verification)
Verifying signature
Outgoing: Writing NEWKEYS
Outgoing: Writing SERVICE_REQUEST (ssh-userauth)
Outgoing: Writing USERAUTH_REQUEST (password)
Outgoing: Writing CHANNEL_OPEN (0, session)
Outgoing: Writing CHANNEL_REQUEST (0, exec)

@mscdex Anything else I can try to help debug?

Is there some example code you could give to reproduce this? I cannot reproduce it on my end by generating lots of lines of text remotely.

Unfortunately I can't give you specific examples (my company is against it), but essentially we had a bot responding to irc commands that then connected using this library to different servers that ran a grunt script which ran commands to build an rpm on different OSes (which generated a lot of output). We have since switched our build process to be completely different and use integrated CI tools so I can be of little help in debugging further.


differences in struct ifaddrs

Currently, there are two variants of struct ifaddrs in libc: one matching Linux with an ifa_ifu field and an OS X variant with only ifa_dstaddr. However, some other BSD derivates define ifa_broadaddr as well, which isn't currently covered (and I guess the fields would be misaligned on systems having ifa_broadaddr as a separate field in the struct).
Googling for getifaddr man pages, I found these different definitions:
Variant 1: union:
http://man7.org/linux/man-pages/man3/getifaddrs.3.html (Linux)
https://docs.oracle.com/cd/E26502_01/html/E29035/getifaddrs-3socket.html (Solaris 11)
Variant 2: only ifa_dstaddr, no ifa_broadaddr (or possibly a macro on ifa_dstaddr):
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/getifaddrs.3.html (OS X)
Variant 3: separate fields ifa_dstraddr and ifa_broadaddr:
http://netbsd.gw.com/cgi-bin/man-cgi?getifaddrs+3+NetBSD-current (NetBSD)
https://www.freebsd.org/cgi/man.cgi?getifaddrs (FreeBSD)
https://man.openbsd.org/getifaddrs.3 (OpenBSD)
Based on these findings, I suppose struct ifaddr in src/unix/bsd/mod.rs would have to move down to the variant-specific fiels under apple, freebsdlike and netbsdlike to adjust for this difference. And the Solaris variant should probably simply be changed to use ifa_ifu. Any other platform that needs to be supported and checked?

Platforms like Solaris and some BSD platforms aren't verified automatically today, so feel free to change the definition on those paltforms!

Can Travis test BSD/Solaris?

Only with QEMU currently, they don't offer native hosts running BSD/Solaris

Oh note that we've already got QEMU emulation of FreeBSD, is that sufficient for libc?

Yeah, QEMU is probably good enough for libc, as long as its fast enough.

Actually, things aren't as bad as @mwanner thinks.  The man pages make it look like the BSDs have an extra ifa_broadaddr field, but it's actually a macro for ifa_dstaddr.  AFAICT, the only problem is on NetBSD, which adds an extra ifa_addrflags field at the end.
Here are links to the structure definitions, as opposed to man pages
https://github.com/illumos/illumos-gate/blob/master/usr/src/head/ifaddrs.h
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/include/ifaddrs.h?rev=1.4&content-type=text/x-cvsweb-markup
http://cvsweb.netbsd.org/bsdweb.cgi/src/include/ifaddrs.h?rev=1.8&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
https://svnweb.freebsd.org/base/head/include/ifaddrs.h?revision=250887&view=markup

The NetBSD situation with ifa_addrflags is complicated.  The still-supported NetBSD 7.x release series does not have the ifa_addrflags field, while the NetBSD 8.x release series and -current do.
I've not looked closely as to what this particular difference means for compatibility of binaries. The lack of OS-level ABI/API breaking-change handling in the libc crate leaves a lot to be desired…

It seems that a lot of work has happened here already. What exactly remains to be done here?

I agree, ifa_broadaddr has vanished, it seems.


[HOLD #12603][Image][Performance] Avatar images in a report are re-fetched when we hover on the message

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

What performance issue do we need to solve?
We need to figure out why the component re-renders even though nothing changes in the state. This could possibly be due to a parent component re-rendering which makes the child component Avatar re-render as well.
https://user-images.githubusercontent.com/9680864/192889584-6ccdd960-f04c-4a25-8654-940afb1cd232.mov
What is the impact of this on end-users?
TBD.
List any benchmarks that show the severity of the issue
TBD.
Proposed solution (if any)
TBD.
List any benchmarks after implementing the changes to show impacts of the proposed solution (if any)
TBD.
Platform:
Where is this issue occurring?

[x] Web
[x] iOS
[x] Android
[x] Desktop App
[x] Mobile Web

👋 @youssef-lr - is this one held on a plan for Image-related feature request and improvements or does it need a volunteer to work on it? CC: @roryabraham

Good question, I'd be willing to help look into this if it's not on hold

I think this should be on hold for https://github.com/Expensify/App/issues/10894, but that one's up-for-grabs @Beamanator 😉

Go on, @Beamanator. You know you want to.. 😏
Alrighty, I've popped a hold in the title here for now.

You da man! 🏊♂

Still on hold, making progress on image improvements, see tracking issue

Still on hold, will get to this soon hopefully

Coming from this thread, I'm going to assign this to @thomas-coldwell as a follow-up to the caching PR.

Hi, yes I'll square this off once the image caching PR is merged 🙌

👋 Are we still held here as the image caching PR was reverted?

We're still on hold here for the caching PR.

Still on hold for the caching PRs.

Still held on the web caching PR.

No change. Web caching PR is close though!

Still held. Fork PR is merged, and the App PR is in review. Latest on the held issue is here: https://github.com/Expensify/App/issues/12603#issuecomment-1410057871

Still held on the linked App PR above.

No change. Blocked by resolving CORS issues to unblock web caching.

Still on hold

Same, caching is still blocking this one.

Still held

Commented on #12603 to update that issue's hold to the correct place, as the issue it's pointing to as being held on has merged.

Same, Melv.

Melv, same.

No change yet!

same

No change, server migration comes first then image cashing Melv.

still held

Still working on web image caching!

same ^

In light of https://github.com/Expensify/App/issues/32703 being fixed, the https://github.com/Expensify/App/pull/34505 is in review.

New PRs are in the works and a bit of a wider plan. :)

@youssef-lr @thomas-coldwell @Beamanator with all the performance improvements as of late, I think we took care of this one. I just tried to reproduce on a chat I have with a bunch of attachments/preview components and hovering over them doesn't re-fetch anything in the Network tab.
Going to close this out, but if anyone disagrees, feel free to reopen!


Add Jessica to team page

@jkwok91

:+1:
@jkwok91: can you comment with a profile and bio to this issue?
On Tue, Apr 5, 2016 at 5:15 PM, Max Wofford<EMAIL_ADDRESS>wrote:

@jkwok91 https://github.com/jkwok91
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/hackclub/website/issues/222

--
Zach Latta
Hack Club |<EMAIL_ADDRESS>

Closed by #232.


[alarm] Fix a bug in alarm.c discovered when OPENTHREAD_CONFIG_UPTIME_ENABLE is enabled

@jwhui could you review this please?

Sorry, I actually have one more change to make.

@jwhui I finished making the change. Please review when able


1.10: Pdf Issues

No ministry value in some of the pdfs generated
This issue will be handled in a separate ticket #827

https://app.zenhub.com/files/439477060/f5ce76be-001f-4742-80f0-71199887879d/download

Name of the pdf should be the same as the name of the draft. Currently the name is "Complaint-Intake-Form-Artical-1.10" There is also a typo "artical"

The information section should be removed in the pdf

The title says "ullying" instead of "Bullying"
@bhumin-fw


Updated with link to geo regions

@dilukose,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

azureps-cmdlets-docs/ResourceManager/AzureRM.TrafficManager/v3.1.0/Add-AzureRmTrafficManagerEndpointConfig.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Kanban styling - Notion like Kanban board CSS still working with Kanban Plugin 2.0.51 in Obsidian 1.6.7?

Hi there,
thanks for providing this CSS snippet.
I tried to get it work in the combo Obsidian 1.6.7 , Default Theme and Kanban Plugin 2.0.51 . Unfortunately without luck . May I ask if this works for you or where I have to make some adjustments?
Thanks in advance for a hint.

It is working on my end
What is your Obsidian installer version?

Thanks for getting back to my issue. My installer version is 1.6.7 and my Obsidian version is also 1.6.7. I would like to work with this CSS snippet: Kanban styling - Notion like Kanban board.

Could you explain a bit more about the issue? It'll help me understand better since my English isn't that great

Hello again,
sure, I will try to explain it a bit better.
Setup: Obsidian installer version 1.6.7; Obsidian version:1.6.7. ; Kanban Plugin version 2.0.51; Obsidian default theme.
A: situation without any CSS snippet:

B: situation with CSS snippet: Kanban styling - Notion like Kanban board

C: situation with CSS snippet: KanbanPlugin.css

So I think in B: there is colour missing in the lanes  and the whole Kanban board seems to be shrunk a bit. Does this have to look this way?

Thanks for explaining! I'm not that great with CSS, but I think if you remove everything below this line in the Notion-like Kanban board snippet, you should get the result you're after.
If you run into more questions, you can ask on the Obsidian discord server. There are CSS wizards there who might be able to help you more!


Define tempest-all image

Tempest image should contain only tempest while tempest-all image
should contain tempest with all relevant plugins.
Depends-On: https://github.com/openstack-k8s-operators/tcib/pull/97

Firstly, no idea why I can't see the tempest-all container build, I see tempest and tempest-extra, not the new one - tempest-all :/
Secondly, maybe we don't need tempest-all - I'd like to compare the size of the image with all the plugins with the one where only tempest is and if the difference isn't significant we can have just one image with all the plugins and not distinguish between tempest and tempest-all

recheck

Firstly, no idea why I can't see the tempest-all container build, I see tempest and tempest-extra, not the new one - tempest-all :/ Secondly, maybe we don't need tempest-all - I'd like to compare the size of the image with all the plugins with the one where only tempest is and if the difference isn't significant we can have just one image with all the plugins and not distinguish between tempest and tempest-all

@kopecmartin I have added the depends-on in this pr, now tempest-all image will be built soon.

recheck

Firstly, no idea why I can't see the tempest-all container build, I see tempest and tempest-extra, not the new one - tempest-all :/ Secondly, maybe we don't need tempest-all - I'd like to compare the size of the image with all the plugins with the one where only tempest is and if the difference isn't significant we can have just one image with all the plugins and not distinguish between tempest and tempest-all

@kopecmartin I have added the depends-on in this pr, now tempest-all image will be built soon.

oh, right, I forgot about that, thanks Chandan!

@kopecmartin https://logserver.rdoproject.org/98/98/7d75e833dc34ca4d83f7f758be3091cae0150256/github-check/tcib-build-containers/103afd0/ci-framework-data/logs/containers-built.log
<IP_ADDRESS>:5001/podified-antelope-centos9/openstack-tempest-all                 7875d401b14a7e53d94789026df40798  d2c77d5a99bf  54 seconds ago      1.07 GB
<IP_ADDRESS>:5001/podified-antelope-centos9/openstack-tempest-extras              7875d401b14a7e53d94789026df40798  bad37edde185  About a minute ago  595 MB
<IP_ADDRESS>:5001/podified-antelope-centos9/openstack-tempest                     7875d401b14a7e53d94789026df40798  406f5f52dd52  14 minutes ago      533 MB

@kopecmartin https://logserver.rdoproject.org/98/98/7d75e833dc34ca4d83f7f758be3091cae0150256/github-check/tcib-build-containers/103afd0/ci-framework-data/logs/containers-built.log
<IP_ADDRESS>:5001/podified-antelope-centos9/openstack-tempest-all                 7875d401b14a7e53d94789026df40798  d2c77d5a99bf  54 seconds ago      1.07 GB
<IP_ADDRESS>:5001/podified-antelope-centos9/openstack-tempest-extras              7875d401b14a7e53d94789026df40798  bad37edde185  About a minute ago  595 MB
<IP_ADDRESS>:5001/podified-antelope-centos9/openstack-tempest                     7875d401b14a7e53d94789026df40798  406f5f52dd52  14 minutes ago      533 MB

amazing, now, I am open for feedback and thoughts on this - tempest without plugins has half the size of the one with plugins, considering our upstream/downstream pipeline, is it worth it to save 500MB per one image download?

recheck

recheck

recheck


pull request for e2e test at 12/25/2016 00:15:11

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


check-html-links add an option to ignore certain folders/references

As mentioned on Twitter, some URLs might not be resolvable "statically". For instance, some URLs might be served by Netlify proxy or by another subsystem.
To accommodate this use case, we should provide an option to ignore certain folders/references.
In addition, we could pass a "filter function" to the resolveLinks function to decide if we should process or ignore a given link. That might be useful, when check-html-links will be able to check external links as some users will probably want to disable this feature. Using a filter function this will be straightforward:
import {validateFolder} from 'check-html-links'

validateFolder('_site', {
  options: {
    // ignore external url
    ignoreLink: (hrefObj) => value.startsWith('//') || value.startsWith('http')
  }
})

We could also introduce a "resolver function" if we want to emulate a proxy (i.e., when files exist on the local file system but on another path). But that's probably out-of-scope for now.
And now the tough question, how should we name this option :sweat_smile:
$ npx check-html-links _site --ignore="/speedlify/**,**debug**,{app,docs,tests}/**/*.html"

We might need to add link or url to make it clear (otherwise, one might think that it will ignore files).
We could also add pattern if we want to support glob expressions:

--ignore
--ignore-pattern
--ignore-link-pattern
--ignore-link-patterns
--skip

I think that patterns should be plural if we can define multiple patterns using a comma-separated list or singular if we can use the option multiple times:
$ npx check-html-links _site \
  --ignore-link-pattern="/speedlify/**" \
  --ignore-link-pattern="**debug**" \
  --ignore-link-pattern="{app,docs,tests}/**/*.html"

And last question, should we add https://www.npmjs.com/package/yargs-parser to parse process.argv? For reference, https://github.com/yargs/yargs has 7 dependencies so not great.
I'm not familiar with https://www.npmjs.com/package/commander but it has 0 dependency... so it might be a potential solution.

Really like that, thanks for the thorough preleminary work @Mogztter ! I have had the same (but simpler) use case last week when trying to run a website with a javadoc folder. Creates huge amounts of links that will be valid by definition.
I 'll look deeper into this!

Really like that, thanks for the thorough preleminary work @Mogztter ! I have had the same (but simpler) use case last week when trying to run a website with a javadoc folder. Creates huge amounts of links that will be valid by definition.
I 'll look deeper into this!

we probably need 2 separate flags 🤔
e.g. on pattern to not check links for files that do get checked... and one pattern to not even analyze/check for
$ npx check-html-links _site \
  --ignore-link-pattern="/speedify/*" \
  --skip-checking-pattern="./folder-to-ignore/*"

for a lib to parse process.argv... it will probably be command-line-args as it's also used in all the other repos we have... it's probably not perfect with a deps tree of 5... but it's at least knowledge we can reuse across multiple projects
PS: the node API is probably going to change 😅

we probably need 2 separate flags 🤔
e.g. on pattern to not check links for files that do get checked... and one pattern to not even analyze/check for
$ npx check-html-links _site \
  --ignore-link-pattern="/speedify/*" \
  --skip-checking-pattern="./folder-to-ignore/*"

for a lib to parse process.argv... it will probably be command-line-args as it's also used in all the other repos we have... it's probably not perfect with a deps tree of 5... but it's at least knowledge we can reuse across multiple projects
PS: the node API is probably going to change 😅

command-line-args seems like a deal.
Right, I indeed see now that we have two use cases indeed. Interesting. The skip seems rather easy to implement, but I wonder if the skip will not increase the processing complexity? Will have a look at the current implementation

command-line-args seems like a deal.
Right, I indeed see now that we have two use cases indeed. Interesting. The skip seems rather easy to implement, but I wonder if the skip will not increase the processing complexity? Will have a look at the current implementation

Thanks for your replies!
Should I go forward and implement --ignore-link-pattern using command-line-args?
Any thoughts on the Node API? Should we introduce an "options object" as a second argument of the validateFolder function?

Thanks for your replies!
Should I go forward and implement --ignore-link-pattern using command-line-args?
Any thoughts on the Node API? Should we introduce an "options object" as a second argument of the validateFolder function?

Go for it. I started looking at it yesterday but didn't get on the actual implementation yet.

Go for it. I started looking at it yesterday but didn't get on the actual implementation yet.

thanks again for implementing 🙇♂


chore: update json dependency

Summary
Update json dependency to the latest version with the most adoption.

Checklist

[ ] Does your PR title have the correct title format?
Does your PR have a breaking change?:

I guess no breaking changes?

@qingzhuozhen  the JSON depdency using the date as a version. But I checked in here https://github.com/stleary/JSON-java/releases, and I didn't see there has a breaking change.


updating viewpoint to use center/scale

@lsmallwood can you please merge? Switching from extent to center/scale viewpoint to better accommodate differing form factors

just the 1 comment


OCM-1733 | feat: list instance-types by region

@gdbranco How do you wish to proceed on this? I cannot retrieve the regions without WithAWS() to validate that it exists (happy to be corrected here). If the region doesn't exist (or cannot be logged into) the command will hang.

/lgtm

/approve


fix(types): duration is not optional anymore

Duration is not optional anymore and not limited to iOS. This PR fixes the types.

@mrousavy it also needs the size type, right? It's neither in the extension and not inside TemporaryFile. Can we assume that this value is ALWAYS present? You know the native codebase better. If true, I would also add size

Hey thanks for the PR!
Yes, size is also always present

What does size represent exactly? On iOS, I don't have size in my onMediaCaptured. Android does have a value

Ah then we need a separate PR to add it for iOS native