Add Search functionality to Blog

As the content grows, it would be good to have an internal search function for the blog like we do on the docs.

I think this is doable! Are we planning to mimic the design of the doc's search input? Also, where do we want this input to be placed on the blog? The search input for the docs is in the sidebar, but the blog doesn't have a sidebar 🤔

It means that we need some design input here. Let's put it in the list of things for the design team.

Do we have a deadline or priority level for this issue?

Tomorrow?  Just kidding.  To me this should have always been there.  Now that we have more content, it's much more important.  I know you've got other things to tend to and I don't know how time consuming this is.  If it helps this is how I would rank the issues I have, in importance from greatest to least, but all accomplished by end of quarter. 😬

Landing page release video positioning - Due Nov 17th or at time of release if it gets extended
Testimonial.to - ASAP per Dmitry, but he'd put release above it too.
Search function for blog -
Add YouTube to Learn line up on the Community Page
Educational Course Connection - this is last only because it will not come out until the end of the year.

If you told me, "there's no way we can do all that by the end of the year with everything else," I'd say cut out 2 and 3 and put them in Q1 '22. The rest need to get done.

@DavidGOrtega also mentioned using faceted search!

What does that mean?

@DavidGOrtega also mentioned using faceted search!

What does that mean?

What does that mean?

Faceted search is a way of searching by applying filters to your search (like how you can narrow down your search on Amazon by selected the color or size you want). We already have tags on our blog posts. Maybe we can show the available tags below wherever we place the search bar, allowing users to select them 🤔

Yes!  I like this idea.  It will send them to more content they didn't even know they were looking for! Please yes!

@yathomasi please take a look at the review.


AWS X-Ray implementation of opencensus

Would you be interested in accepting an opencensus implementation for aws x-ray?  I've written one for opentracing, but after reading through opencensus, I like your approach better.

Yes please!!!

Also please feel free to take a look at https://github.com/census-instrumentation/opencensus-go/issues/314.

Sweet.  I'll have a look this weekend.

This has been moved to: https://github.com/census-instrumentation/opencensus-go-exporter-aws/


Where is the "BatchNormReimpl"?

sync_batchnorm/batchnorm_reimpl.py
all = ['BatchNormReimpl']
There is no BatchNormReimpl in batchnorm_reimpl.py.
Maybe BatchNorm2dReimpl instead?

Fixed by 0d261dd. Thanks for reporting.


WronG expiryDate

I am working with xamarin, When I set TimeSpan.FromHours(1) the expiration date is minus 2 hours. I know that is because difference between utcNow and Now time is 2 hours. Lets fix it

The time is stored in UTC Time.

Right. Closed


Remove title and timestamp?

Is it possible to remove the dashboard title and time range from the exported pdf as seen in the photo below?

You could achieve this using a custom latex template. See the query parameters section of the readme.

From: Gareth Lynskey<EMAIL_ADDRESS>Sent: Tuesday, 17 December 2019 18:04
To: IzakMarais/reporter
Cc: Subscribed
Subject: [IzakMarais/reporter] Remove title and timestamp? (#177)
Is it possible to remove the dashboard title and time range from the exported pdf as seen in the photo below?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi,
I have tried using the custom latex template example and looking at older issues related to this but i still can't seem to get it to work. I have created the /templates directory in the /bin dir. I have also added my newCustomTexFile.tex to that directory and ran my grafana-reporter command but it still seems to use the default template. I have tried running the grafana-reporter command with and without the '-template' flag, both of which don't seem to do anything. I have also tried to manually change the 'texTemplate.go' and 'texGridTemplate.go' files, but changes to these files still returns the default tex template. Is there anything I have to do to initialize changes to grafana-reporter before running it? Or Would you have any idea as to why none of the changes are registering?
Thanks for your time.

In addition to creating the /templates directory in the /bin directory you also need to supply the file name as an html query parameter named 'template' as part of the GET request.
If you can't get that working you can modify the source code as you suggest, but you would need to recompile the reporter binary for that to take effect.

From: Gareth Lynskey<EMAIL_ADDRESS>Sent: Thursday, 02 January 2020 18:42
To: IzakMarais/reporter
Cc: Izak Marais; Comment
Subject: Re: [IzakMarais/reporter] Remove title and timestamp? (#177)
Hi,
I have tried using the custom latex template example and looking at older issues related to this but i still can't seem to get it to work. I have created the /templates directory in the /bin dir. I have also added my newCustomTexFile.tex to that directory and ran my grafana-reporter command but it still seems to use the default template. I have tried running the grafana-reporter command with and without the '-template' flag, both of which don't seem to do anything. I have also tried to manually change the 'texTemplate.go' and 'texGridTemplate.go' files, but changes to these files still returns the default tex template. Is there anything I have to do to initialize changes to grafana-reporter before running it? Or Would you have any idea as to why none of the changes are registering?
Thanks for your time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

That's after working for me now. I wasn't able to get the /templates directory to function correctly but I was able to get it to work by modifying the code and recompiling the reporter binary. Thank you very much.

Glad you found a solution.


WXLogLevel 名字和微信SDK 冲突

WXLogLevel 这个枚举 和 微信SDK WXLogLevel 冲突了

This issue is outdated for a long time and will be closed now. You can create a new one if you still have questions.


drawArrays: no buffer is bound to enabled attribute

Hello!
I'm having an issue when trying to use a custom shader with Createjs.
When running the attached code it gives the following warning:
WebGL: INVALID_OPERATION: drawArrays: no buffer is bound to enabled attribute
after executing gl.drawArrays(gl.TRIANGLES, 0, 6). However, this does not happen when I comment the following lines:
var stage = new createjs.StageGL("demoCanvas");
stage.update();
I don't see anything wrong with my code.
index.html.zip

Ok, it seems I found the problem. I had to add this before setting up the shader program to draw:
for(var i = 0; i<8; i++)
gl.disableVertexAttribArray(i);
Createjs is not disabling every attribute it enables
Is this intended?

Glad you fixed your issue.
Currently StageGL is pretty tuned to drawing exactly the way it's intended to draw. I totally get that this stops your ability to do some cool things for yourself like per object tinting or mesh rendering but they weren't phase 1 goals.
I have it on my roadmap to add a proper API for doing what you want, a custom shader to render all the DisplayObjects, but it's not going to be quick. I wont commit to a timeline right now sorry, but feel free to share the results of any experiments you do. It might speed up my process if I know some gotchas.
In the meantime I recommend anyone who has very custom drawing demands to consider making a new Filter. Filters are expected and designed to have swapable shaders, while they are expected to process a single element covering the scene the shaderParamSetup call on them is the window and reference you need to do all sorts of customization, so long as you set it back afterwards.


Warnings when using an exported interface in a class

1. OS
Arch Linux
Linux maistho-laptop 4.7.2-1-ARCH #1 SMP PREEMPT Sat Aug 20 23:02:56 CEST 2016 x86_64 GNU/Linux

2. Versions
angular-cli: 1.0.0-beta.11-webpack.8
node: 6.5.0
os: linux x64

3. Repro steps
I started a new repository, and added a new empty service, with an exported interface.
Complete changes, and a repo to pull and see the issue, can be found here:
https://github.com/Maistho/angular-cli-input-issue/commit/e5c483081bfd7af3dafd0db074179b3090668e27
After running ng build, I get two warnings in the Terminal
4. The log given by the failure
Hash: 354e709ba2cf588db59a
Version: webpack 2.1.0-beta.21
Time: 11161ms
            Asset       Size  Chunks             Chunk Names
   main.bundle.js    2.51 MB    0, 2  [emitted]  main
 styles.bundle.js    10.2 kB    1, 2  [emitted]  styles
        inline.js    5.53 kB       2  [emitted]  inline
         main.map     3.1 MB    0, 2  [emitted]  main
       styles.map    14.1 kB    1, 2  [emitted]  styles
       inline.map    5.59 kB       2  [emitted]  inline
       index.html  489 bytes          [emitted]
assets/.npmignore    0 bytes          [emitted]
chunk    {0} main.bundle.js, main.map (main) 2.46 MB {1} [initial] [rendered]
chunk    {1} styles.bundle.js, styles.map (styles) 9.96 kB {2} [initial] [rendered]
chunk    {2} inline.js, inline.map (inline) 0 bytes [entry] [rendered]

WARNING in ./src/app/app.component.ts
18:55 export 'TestInterface' was not found in './test.service'

WARNING in ./src/app/app.component.ts
18:88 export 'TestInterface' was not found in './test.service'
Child html-webpack-plugin for "index.html":
         Asset     Size  Chunks       Chunk Names
    index.html  2.82 kB       0
    chunk    {0} index.html 357 bytes [entry] [rendered]

5. Mention any other details that might be useful.
I could not reproduce the issue without adding the @Input() to the class member.
Compiling with tsc does not produce any warnings.

I get same issue when following the the dependency injection token example given in the angular docs - https://angular.io/docs/ts/latest/guide/dependency-injection.html#dependency-injection-tokens
Haven't checked if perhaps the docs have been updated but implemented in my app based on documentation as of maybe 2 months ago I get the following warning:
export 'AppConfig' was not found in '../app.config'
Whenever I import the interface.
Works fine despite warning so I've just been waiting for it to go away eventually as things mature

@TheLarkInn can you weight in?

Seeing the very same error as well.

This is a bug we identified but I need to find it in our webpack repo to link to this one.

having the same issue. (Works fine despite warning)
are you exporting more than one interface/class/const from the file?
issue stopped for me after i exported each interface from its own dedicated file.
meaning if i had one file with multiple exports - i got warnings in build (export 'MyInterface1' was not found in '../file')

file.ts

export interface MyInterface1 {}
export interface MyInterface2 {}

after refactor - no warning

file1.ts

export interface MyInterface1 {}

file2.ts

export interface MyInterface2 {}

Usually (and coming from the Java world), I'd consider it good style to split such multiple definitions into separate files anyway.
But given how Angular recommends injecting interfaces (with an OpaqueToken), it seems obvious to define the interface and its related token in the same file, triggering this error.

This issue is fixed for me after upgrading to angular-cli 1.0.0-beta.17 and angular 2.1.0

@teledemic interesting, I still have the same problem on those versions.

Huh! I recently upgraded all my packages. Not sure what it could have been other than those two. FWIW:
  "dependencies": {
    "@angular/common": "2.1.0",
    "@angular/compiler": "2.1.0",
    "@angular/core": "2.1.0",
    "@angular/forms": "2.1.0",
    "@angular/http": "2.1.0",
    "@angular/platform-browser": "2.1.0",
    "@angular/platform-browser-dynamic": "2.1.0",
    "@angular/router": "3.1.0",
    "angular2-highcharts": "^0.3.4",
    "bootstrap": "4.0.0-alpha.4",
    "core-js": "^2.4.1",
    "jwt-decode": "2.1.0",
    "ng2-bootstrap": "^1.1.14",
    "rxjs": "5.0.0-rc.1",
    "ts-helpers": "^1.1.1",
    "zone.js": "^0.6.25"
  },
  "devDependencies": {
    "@types/jasmine": "^2.5.35",
    "@types/jwt-decode": "1.4.28",
    "angular-cli": "^1.0.0-beta.17",
    "codelyzer": "~1.0.0-beta.1",
    "jasmine-core": "2.5.2",
    "jasmine-spec-reporter": "2.7.0",
    "karma": "1.3.0",
    "karma-chrome-launcher": "^2.0.0",
    "karma-cli": "^1.0.1",
    "karma-jasmine": "^1.0.2",
    "karma-remap-istanbul": "^0.2.1",
    "protractor": "4.0.9",
    "ts-node": "1.4.3",
    "tslint": "3.15.1",
    "typescript": "^2.0.3"
  }

I'm on Angular 2.1.0 and CLI beta 17. I have a structure looking like this:
import { OpaqueToken } from '@angular/core';

export const APP_CONFIG = new OpaqueToken('app.config');

export interface AppConfig {
  geoserverUrl: string;
  ...
}

which triggers a Warning:
export 'AppConfig' was not found in '../../app.config'
whenever I try to inject the named token, e.g.
constructor(private http: Http, @Inject(APP_CONFIG) private appConfig: AppConfig) {
  ...
}

If I make the AppConfig a class, it works without warnings. (Though of course it then has to be instantiated differently).
I makes me wonder if something in the build sequence just throws away the interfaces (too early), since they don't actually exist in the final JavaScript.

Same issue with @Input property decorator. Found workaround:
@Input() myProp = <MyInterface1>null

instead of
@Input() myProp: MyInterface1

now no warnings

Can anybody update on the status of this?. I'm at v1.0.0-beta.21, and still getting the warnings.

I get an error in CLI: Cannot find name 'HERO_DI_CONFIG'. (followed complete example on angular documentation). Despite the error, all is working fine an chrome console doesn't log any errors.

Just to add what knowledge I can, if you are using the APP_CONFIG example and getting the harmony warning, I moved the interface declaration (and just the interface file) into another file (iapp.config.ts), imported IAppConfig into app.config.ts, and did the imports in the components separately, e.g:
import { APP_CONFIG } from '../app.config';
import { IAppConfig } from '../iapp-config';
Everything else remained the same (didn't have to convert it to a class etc). The extra file/imports are bulky, but no warnings and works as expected.

Recently trying to create a service provider (yup, also following the DI guide at https://angular.io/docs/ts/latest/guide/dependency-injection.html#!#injector-providers) and I copied the code into the hero.service.provider.ts file. It seems that it demands the file to export CamelCase instead of camelCase.

Took @Maistho's repo for a spin.
The issue is still present, with ng
Did an ng init, overwrote most files except for app.component.{spec,}.ts.
Here's the log of ng build:
Hash: 9d7d11aa2c4280a08ba2
Time: 10909ms
chunk    {0} main.bundle.js, main.bundle.map (main) 5.23 kB {2} [initial] [rendered]
chunk    {1} styles.bundle.css, styles.bundle.map, styles.bundle.map (styles) 1.77 kB {3} [initial] [rendered]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.61 MB [initial] [rendered]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry] [rendered]

WARNING in ./src/app/app.component.ts
18:55-68 "export 'TestInterface' was not found in './test.service'

WARNING in ./src/app/app.component.ts
18:88-101 "export 'TestInterface' was not found in './test.service'

What is the meaning of the pseudo time-stamps look-a-like "18:55-68" and "18:88-101" ??

Took @Maistho repo for a spin.
After ng init, overwriting most files except for app.component.*.ts.
ng build still gives the warning:
Hash: cad6eef25bd1670f6646
Time: 10163ms
chunk    {0} main.bundle.js, main.bundle.map (main) 5.23 kB {2} [initial] [rendered]
chunk    {1} styles.bundle.css, styles.bundle.map, styles.bundle.map (styles) 1.77 kB {3} [initial] [rendered]
chunk    {2} vendor.bundle.js, vendor.bundle.map (vendor) 2.61 MB [initial] [rendered]
chunk    {3} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry] [rendered]

WARNING in ./src/app/app.component.ts
18:55-68 "export 'TestInterface' was not found in './test.service'

WARNING in ./src/app/app.component.ts
18:88-101 "export 'TestInterface' was not found in './test.service'

ng version is
                         _                           _  _

__ _  _ __    __ _  _   _ | |  __ _  _ __         ___ | |()
/  || '_ \  / _ || | | || | / ` || '|_  / __|| || |
| (| || | | || (| || || || || (| || |  |___|| ( | || |
_,||| || _, | _,||| _,|||          _|||||
|_/
angular-cli: 1.0.0-beta.26
node: 7.4.0
os: darwin x64
@angular/common: 2.4.4
@angular/compiler: 2.4.4
@angular/core: 2.4.4
@angular/forms: 2.4.4
@angular/http: 2.4.4
@angular/platform-browser: 2.4.4
@angular/platform-browser-dynamic: 2.4.4
@angular/router: 3.4.4
@angular/compiler-cli: 2.4.4

I still have this warning, as @catull reported.
The current workaround that @Iverson suggested works for me.
But I didn't understand what it meant at first.
It's a typescript type cast, it says "in myProp there is a null value (initially), but it WILL be of type MyInterface1
It can also be written as:
@Input myprop = null as MyInterface1;

I'd really like to see this resolved

I am still experiencing exactly the issue described by @wulfsberg.
import { OpaqueToken } from '@angular/core';

export let SKYPE_CONFIG_TOKEN = new OpaqueToken('skype.config');

export interface SkypeConfig {
    ...
}

Everything works, but I get this warning:
105:93-104 "export 'SkypeConfig' was not found in './skype.config'
As this seems to be legal (and recommended) code, it would be better if it did not throw a warning.

There is simpler & better solution: move all interfaces in a relevant `myfunctionality.interfaces.ts' with normal
export interface MyFunctionality {
   foo: string;
}

and it works like a charm, with no warnings. And it separates your interfaces into their own files, which is nice.

This issue is very annoying.
Could you please fix it?

Also waiting this issue to be fixed since a long time..

If you extend an interface the warning remains when you split the interfaces in files

This is getting more attention from users than it should, and less attention from maintainers as I see the dates. Anyway, I come here not to complain (since I know the problem is hard), but to provide a valid workaround.
Our team uses a lot of interfaces. But also a lot of barrels (those index files where you simply re-export public stuff). A workaround that is working perfectly for us is using explicit re-exports, i.e:
Instead of using export * from './file-with-interfaces'; in that index.ts, we do export { SomeClass, SomeType, AnInterface1, AnInterface2 } from './file-with-interfaces';
Later using import { SomeClass, AnInterface1, OtherClass } from './the-folder-with-barrel'; works in the app and shows no warnings. I expect this may help some sorrowful souls ;).
PS: we have 62 interfaces and 0 warnings with this method ;)

I made the same suggestion as @ShadowManu just above and got 3 negative votes - it 'd be nice if you explained your reasons :+1:

@anodynos Fragmenting your code into double the number of files to use an Angular-ideomatic OpaqueToken is sub-optimal. As I mentioned, I come from the Java world and am fairly used to the "one file, one interface" style, but in this case it really feels like the wrong thing to do. (And from a language perspective, it should just work).

Vanilla ES6/ES7 rules!!!
** ducks **

@anodynos there's a couple of differences though. 1) you're not forced to put interfaces aside. Just put them where you deem necessary. 2) The barrel with explicit re-exports is somehow (yeah, I don't get the particular reason) the one making the warnings go away.

@anodynos @ShadowManu
The solutions you suggest don't solve the problem, they are just workarounds:

@anodynos I do want to keep the OpaqueToken and interface in the same file;
@ShadowManu I do not want to be forced to use barrels.
As it was stated by @wulfsberg , it should just work from a language perspective and I think this is the main reason why you are getting thumbs down. Personally, I prefer getting the warning messages than adopting any of those two workarounds.

Thanks @JulienBroi - some some comments:

You dont need the OpaqueToken  & IOpaqueToken or whatever in the same file - you can have an opaque-token-interfaces.ts or opaque-token-types.ts and stick all the interface & type related stuff in there.

What wrong with barrels?

I don't need it, but I want it, the language allows it, and Angular recommends it. Insisting that I have to do it in another way because of a bug is not a good solution.

It is a workaround and shouldn't be needed. But for those desperate, there's something that can be done in the meantime. Reverting is later as simple as deleting the files and following the broken imports.

Could a maintainer lock this issue? I'm getting my inbox spammed and none of these comments are helpful.

Another work around:
@Input() myProp:any;
Of course, I hope the team can fix this bug.

@MazeChaZer All you need to do is to clock on the "Unsubscribe" button above on the side.

@catull I would like to get notified when this issue is resolved

For the record, the corresponding issue in webpack is webpack/webpack#2977.
As @hccampos explains there, it touches classes with decorators (annotations):

classes that contain decorators and are using an interface imported from another file trigger the warning. While everything works normally, it would be nice to get rid of the warnings.

Personally I can say it is actually only for the class of a class member annotated with @Input that I see the problem, it is not because of the class itself:
@Input() component: IComponentRow;

will trigger:
WARNING in ./src/app/features/cockpit/workspaces/petals-content/petals-component-view/petals-component-overview/petals-component-overview.component.ts
46:50-63 "export 'IComponentRow' was not found in '../../../state/components/component.interface'

The problem is not because of webpack but most certainly because of something typescript/decorators related (as explained by @sokra: https://github.com/webpack/webpack/issues/2977#issuecomment-245887841). The interface is referenced in the javascript code generated by typescript and thus webpack can't find it (since they have no real existence in the javascript realm).
@filipesilva so I think the problem is coming from typescript itself.

I have a similar situation. I have multiple interfaces in the same file, all exported. From other files I import those and get a warning that it cannot find them. If I split each interface to its own file, the warning goes away.
Sometimes I have interfaces and classes in the same file, same result when importing the interfaces.
368:57-64 "export 'IConfig' was not found in '../models/app-insights'

export interface IAppInsights {
 // ...
}

import { IConfig } from '../models/app-insights';
// ...

Things that worked:

split each interface to its own file
make them abstract classes

VS Code is happy with this. VS Code can find the import, can navigate to the definition. So it seems to be OK using TypeScript ... but the compiler is not.
cc @alexeagle as an FYI
Ths appears to be a TypeScript thing. ?

we changed our tsconfig.js module from es6 to commonjs and warnings were gone, based on generated code I'm not sure whats different.
Input decorator code with es6:
__decorate([
webpack_require.i(WEBPACK_IMPORTED_MODULE_0__angular_core["Input"])(),
__metadata('design:type', (typeof (_a = typeof WEBPACK_IMPORTED_MODULE_1__models_user_info["UserInfo"] !== 'undefined' && WEBPACK_IMPORTED_MODULE_1__models_user_info["UserInfo"]) === 'function' && _a) || Object)
], HeaderComponent.prototype, "user", void 0);
Input decorator code with commonjs:
__decorate([
core_1.Input(),
__metadata('design:type', (typeof (_a = typeof user_info_1.UserInfo !== 'undefined' && user_info_1.UserInfo) === 'function' && _a) || Object)
], HeaderComponent.prototype, "user", void 0);

We need a better way to isolate which layer is causing the problem - it seems like angular CLI magic is making this difficult. Perhaps a minimal repro without the CLI would help?

@alexeagle I dont have a minimal repro, though I will try to find a better one.
In the meantime, if you clone this repo and branch, run npm i, then run ng b you will see the issues I mentioned.
https://github.com/projectkudu/AzureFunctionsPortal/tree/upgrade-angular-v4

Sorry, I won't have time to dig in today. The warning does come from webpack, right? Could it be that TypeScript has erased the interface from the output .js file, but some other code still references it? (try pasting the .ts content in the TypeScript playground to see what it emits)

No worries, no rush. It's a warning, not an error.
The typescript compiler outputs an empty file. But there are other interfaces in that file which are fine.
Another interesting observation is that if I move each interface to its own file, the warning goes away

I am also experiencing the same thing, but it also happens with type aliases export type MyTypeAlias = .... as well, not just interfaces.

I used to just be able to ignore this warning, but now after upgrading to @angular/cli 1.0.1 it will give an error in the browser saying "Failed to compile" along with the error about my interface not being found in the source file.  Why is a warning stopping it from running?

In @angular/cli: 1.0.1 I have not warning, but error:

Should I put every single interface or type in a separate file? Even very small? For example:
export type SelectorDataMapperFn<T> = (term?: string) => Observable<T[]>;
export type SelectorListItemMapperFn<T> = (value: T) => SelectorSelectItem<T>;
export type SelectorCompareWithFn<T> = (value1: T, value2: T) => boolean;
export type SelectorCreateNewItemFn<T> = (value: string) => void;

In separate file each? Is it all right?

@manofearth At the moment it is the only possibility to get around the error.

Yeah, updating from 1.0.0 to 1.0.1 prevents the UI from loading at all now. The errors displayed (like in @manofearth 's picture) are still displayed in the console logs as "WARNING"s though.

I found that error disappears if I switch imports from  import { X } from './x' to import * as ModuleX from './x'. But it's not very convinient to prepend all X usages in code with module alias: ModuleX.X.

Hi,
`
// test.ts
export interface test {}
// app.ts
import { test } from './test'
`
I don't get any warning but the import resulting undefined

same issue

If you put all the interfaces alone in a single type (say a types.ts file) and then import them from there, you should get no errors.
The problem happens when there is some non-type-related code in a file mixed with some types and interfaces. In that case, webpack tries to import a file and look for a symbol in it but it doesn't exist. If the interfaces are all in a separate file, they are only used by TS for type checking and webpack doesn't care about it.

Hmm, I did separate it; yes no error, but by the time i import the file, i
could not reference the interface which i exported.. It's declared as
undefined thus produce errors at later codes; am I missing something?
On Thu, Apr 27, 2017 at 6:39 PM Hugo Campos<EMAIL_ADDRESS>wrote:

If you put all the interfaces alone in a single type (say a types.ts file)
and then import them from there, you should get no errors.
The problem happens when there is some non-type-related code in a file
mixed with some types and interfaces. In that case, webpack tries to import
a file and look for a symbol in it but it doesn't exist. If the interfaces
are all in a separate file, they are only used by TS for type checking and
webpack doesn't care about it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/angular/angular-cli/issues/2034#issuecomment-297689689,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACmP2QobYmOgxcKUOLSh9fbt6xgsdfljks5r0H5mgaJpZM4J5QId
.

thanks  but can't we fix it, it works with workaround but can't move all my interfaces in each module to one file. need fix
@hccampos

@istiti to be honest, I don't see this getting fixed soon. It is not really an Angular CLI problem, and it is not really a Webpack problem. It is not a Typescript problem either... it is sort of in-between everything, and no one party can easily fix it, I think.

I'm curious if the CLI is using Rollup. I've experienced the same kind of issue on an Ionic 2+ project when I used Rollup instead of Webpack to bundle. So if the CLI uses Rollup, I think it might be where the source of this issue resides.

Just FYI for everyone here, the errors don't block the UI on 1.0.2 or 1.1.0-beta.0, so you can upgrade past 1.0.1 if you need to.

Hi everyone, I'm having the same issue. I was following angular's styleguide by using classes instead of interfaces for type definitions, but decided to refactor and use interfaces instead and discovered the warning message.
However, now that I see that this hasn't been solved yet, I changed back to classes.
My question is, why use interfaces instead of classes? What's the real difference?

The difference between a class and an interface is this. The class says something about how the thing is constructed. What kind of code it has running behind it. Which may contain methods and so on. The interface only talks about the shape of data. So in terms of communicating to fellow developers the meaning of the code, and interface is the most clear way to talk about data your application does not construct and knows nothing about the construction of. For example, some data arriving over the wire as JSON then deserialized - it won't ever really be an instance of any class other than Object. But it may structurally match an interface.
TypeScript has an interesting "hack" around classes. If you define the class which only has fields, you can then treat it much as an interface. It will even pretended that an object is an instance of a class of which it is clearly not, the class only has fields (and therefore works like an interface). I think that is a horrible idea, I don't think it is a good feature, and should be removed. But no one asked me :-)
The difference becomes stark as soon as there is a method added. Once a class or interface has even a single method, the ability to pretend they are the same evaporates.

Agreed @kylecordes, this statement is probably misusing context: "I was following angular's styleguide by using classes instead of interfaces for type definitions".
A class and an interface serve two very different purposes. One is about concrete implementation, the other abstracted behavior. I'm confident the Angular style guide would not equate the two as interchangeable.

@tcoz @kylecordes Thank you, I understand the difference in languages like Java or PHP, but if Typescript allows to use a class like if it's an interface, why not embrace that hack?
Also, you are right @tcoz. I misinterpreted the angular guideline. This is what it says about interfaces:

Do name an interface using upper camel case.
Consider naming an interface without an I prefix.
Consider using a class instead of an interface.
Why? TypeScript guidelines discourage the I prefix.
Why? A class alone is less code than a class-plus-interface.
Why? A class can act as an interface (use implements instead of extends).
Why? An interface-class can be a provider lookup token in Angular dependency injection.

It just says to consider using a class instead of an interface because it can be implemented instead of extended and because it can be a provider lookup token for dependency injection in Angular (I have no idea what that is)

I would say for the very reason your language reveals: it's a hack. I'm not sure language is a determining factor. An interface is an interface.
Now, if TypeScript has underlying technical reasons for not using interfaces the way everything else does because the language itself can't support it properly, that's a different matter. But they should make it clear that this is the case. And increasingly, it does seem interfaces can be problematic in TS.
Also the whole "without the I" thing is silly to me. The C# style guide, very first example of Interface, shows:
interface IEquatable
So it seems contradictory to me that TS would say "no" but C# clearly says "yes", unless the point was to be able to tell a C# interface from a TS one...which again, would be a questionable practice IMHO.
Also, say you're iterating a collection a filtering on some types. Are they interfaces, or class types? How do you know just by looking at the code? In a review (like a GitHub side-by-side), where's there's no hover tooling and so on, that could be very annoying.

I've had a read of the styleguide, and I think it's simply poorly worded. What I believe it means is instead of doing this:
interface IItemService {}
class ItemService implements IItemService {}
class OtherService {
  constructor(itemService: IItemService) {}
}

to do this:
class ItemService {}
class OtherService {
  constructor(itemService: ItemService) {}
}

This is because in the latter case, the class itself can be injected by-reference (this is what the "provider lookup token" bit means - the class constructor is used as the thing to identify what we're trying to inject here.)
The style guide is simply advising against a pattern that is quite common e.g. in Java with Spring, where every dependency should be an interface and then the DI framework figures out which implementation to use. It states that in Typescript that creates unnecessary overhead, and in 99% of cases your interface would only have one implementation anyway so it's unnecessary to prematurely optimise this by leveraging polymorphism.
I don't believe the style guide is actually stating "use classes instead of interfaces always" - I think it's stating "use just classes instead of class-plus-interface for injectable classes."
Regardless, I believe this is quite off-topic and is just making a long thread longer, so we should probably stop discussing the style guide.

@tcoz

Also the whole "without the I" thing is dubious. The C# style guide, very first example of Interface, shows:
interface IEquatable
(Note also the name implies a behavior, not a concrete "thing").

If you go by that logic, You need need to pretend I to Equatable to know that its a behaviour. The able sufix of Equatable clearly implies this is a interface.

Some pretty easy examples where that doesn't work. Example: "IComponent", "IProvider".  That would have to be "Compentable", "Providerable". That'd just be odd. Those btw are again from C#.
I really can't see a reason to differentiate it from other languages that way. Some poor guy from C# or Java starts using TS.

I'm sorry to have brought this up, but continuing this discussion it's completely off-topic xD.
For now, just so I don't see the warning export 'TestInterface' was not found in './test.service' I preferred to use classes instead of Interfaces, because I don't want to split every Interface into separate files.
And thanks to typescript's "hack" that allows you to use classes like if they were interfaces, whenever this bug is fixed, I could change the classes to interfaces and everything should continue working without issues.

Just to obscure this weird error a bit more... I have the same warning for:
// Warning: "export 'BillState' was not found in '../../state/reducers/bills'
@Input() bill: BillModel;

However, if I change the type to be an array of BillModel the error is gone.... :sheep:
// No warning :-)
@Input() bill: BillModel[];

@gionkunz I have the same behavior as you, except that it's crashing my entire site. It's only in certain files, when I import the interface and assign it as a type, I get the error datatypes_1 is not defined. datatypes is the folder that my interface sits in. It does not matter if I import the interface from the index file in datatypes or straight from the file where it is exported. But, if I cast the object as an array, I can build the project.

I'm experiencing the same issue when referencing interfaces from third-party modules.

Heya all, I've been looking at this problem and wanted to give you an update.
There's two parts to the issue:

interfaces don't really exist after TS compilation.
Webpack tries to follow imports on ES modules.

So for things that need to exist and be imported after compilation, like a decorated type (e.g. @Input() test: TestInterface), you will get a warning that the import cannot be found by webpack. It simply does not exist anymore after compilation. Also, AOT does not suffer from this problem.
A couple of workarounds have been proposed, like keeping files that only have interfaces, or declaring the interface in the same class that uses it. These address the problem in different ways.
When you have a file composed only of interfaces, it is empty after compilation. So Webpack thinks it's a CommonJS module (instead of a ES module) and doesn't try to figure out it's exports, assuming whatever we're importing is there at runtime. See https://github.com/webpack/webpack/issues/2977#issuecomment-245898520 for more details.
Declaring the interface in the same module where you use it means there's no export to follow, so no warning.
I checked with the TypeScript folks (@mhegazy, @DanielRosenwasser) and @alexeagle, and this is indeed an unfortunate situation for which there is no clear fix.
The recommendation is to use a value that exists after compilation for decorated properties. For instance, a class or variable instead of an interface.
I know this is frustrating because you are encouraged to fully make use of TypeScript, but it is a current limitation.
I'll communicate this to docs to make sure guidance is provided.
Thanks to all that have been following this, providing context, reproductions and workarounds. I'm sorry I don't have a real fix that just makes it go away.

+1

@filipesilva So the best practice is to use class instead?

@wilsoncook yes.

I just got this error for the first time, because I had a file that exported a const and an interface. The weird thing is I had already been using the interface elsewhere (within Providers and within other models) for a while without problems. The warning didn't crop up until I tried to use the interface from a component. Just FYI.

@mischkl same concern

So the best practice is to use class instead?

@filipesilva But as I understand it adds extra unused source code to the resulting bundle or do I miss something?

IMHO, this seems like a much better approach than telling people to switching to using classes everywhere

The thing is you can't completely split interfaces and the real code in some situations.
Here is one of them:
import {SomeComponent} from './some.component';

export interface SomeInterface {
  ref: ComponentRef<SomeComponent>;
}

In this case you have to import the real component to describe an interface and resulting file won't be empty after compilation.

@th0r the example you mention should not be a problem. The problem only comes when you export a mixture of compile-time and run-time stuff in one file, e.g.:
export class SomeClass {
  foo: string;
}

export interface SomeInterface {
  bar: string;
}

@mischkl I mean your solution (extracting all compile-time stuff into a separate file) won't work for my example.

@th0r I guess I didn't specify what I meant exactly enough. You can mix and match compile-time stuff with non-compile-time stuff as much as you want AFAIK, the only problems come when you export both from one file.

So the solution is to separate out all interface and type exports into extra files, which can then be imported elsewhere and used freely.

This won't work for my example because of this (quote from this comment):

When you have a file composed only of interfaces, it is empty after compilation. So Webpack thinks it's a CommonJS module (instead of a ES module) and doesn't try to figure out it's exports, assuming whatever we're importing is there at runtime.

In my example this file with interfaces won't be empty because you imported SomeComponent into it that is needed to describe SomeInterface.

@th0r why don't you try it out? I think you'll find that the result is empty, despite your expectations,

@mischkl I'm sorry! You're right - just tried to extract them into separate files again and warnings disappeared.
Seems like I did something wrong the first time.

@filipesilva is there a typescript issue for this that can be referenced by this issue for future tracking if it gets fixed?

@zakhenry not that I know of, no.

Is there a reason why these warnings fail execution in the browser when its just warnings and not errors? As mentioned by someone in<EMAIL_ADDRESS>it seemed no showstopper for development but as of<EMAIL_ADDRESS>it halts development completely when it happens. My team is in the progress of migrating an app with 150+ components and suddenly this issue appeared for us. I'm still goofing around trying to find workarounds. It seems to have appeared completely random after having migrated roughly 30 components..
So far I've found that any kind of union type on affected decorated properties will remove the warning, e.g.
@Input() someProp:MyMagicalInterface

will result in a warning while
@Input() someProp:MyMagicalInterface | undefined

will work. And to get completely funky
@Input() someProp:MyMagicalInterface | MyMagicalInterface

does work also.  ¯_(ツ)_/¯

for whatever it's worth ... when you change the module in the tsconfig to "commonjs" the error goes away. This may not work for most situations, in mine it does because I am using a core module that is compiled outside of the cli project (with ngc) and later linked into it.

// ./src/app/wx.d.ts
export declare function config(): void;

// ./src/app/app.component.ts
import * as wx from './wx.d';

// using
wx.config();

ng serve throw Module build failed: Error: Debug Failure. False expression: Output generation failed.

Changing tsconfig module to "commonjs" fixed the warnings for me. Previously it was set to "es2015"

is there a way to just silence that warning?

@remmeier see the comment a few above - you can suppress the warning simply by making the type a union of itself. The same type safety is achieved, and the warning goes away. It is by no means a fix, but at least you can continue developing

The issue still exists, why is this closed?

@RenaldasK there is long explanation (shortly - it is the limitation which currently cannot be solved) https://github.com/angular/angular-cli/issues/2034#issuecomment-302666897
Try to rewrite interfaces to classes if possible (this works for me).
Or one of the proposed solutions above (i did not try any of them).

Aside from the console warnings, is there any actual reason to avoid this issue?

All of the solutions above fell like a hacks, and putting a single line interface in its own file seems like a waste of time...

Having the same issue with a scenario like this:
export class Something { ... }
export type SomethingKey = Pick<Something , 'keyPropertyName'>;

in one file.  However when I add another interface, class or type to that file, the interface is resolved perfectly fine. This seem to be only the issue with the Pick<..> type.

@filipesilva
Thanks for looking into the problem in detail. Easiest workaround I have found is to declare a local alias type in the component file for the imported type when needed in an @Input().
So for your example, rather than:
import {TestInterface} from ...
...
@Input() test: TestInterface

do a
import {TestInterface} from ...
type TestInterfaceAliasHack = TestInterface;
...
@Input() test: TestInterfaceAliasHack

This is really annoying. Is there a real fix and not simply temporary workarounds?

This issue's very Annoying !

For the time being just a flag to silence the warnings would be great as everything works perfectly fine regardless of the warnings.

They said working on it, i have the same issue just have to wait or work with a work-around if possible.

Guys this issue was explained here: https://github.com/angular/angular-cli/issues/2034#issuecomment-302666897
This is a problem with about how Webpack works. @filipesilva is there any chance this will be fixed some day? Are there open issues to address this problem?
Frustrating, but just use a class instead of an interface and it will working without any warnings.

I was facing the same issue on and @Input() types by an interface.
Solved by having one file with only interfaces (and type definitions), and moving constants and classes to a different file. A little bit of a headache but not as bad as requiring separate files for every interface or type or anything like that.
Still, if what someone above said is correct and cli is happy with:
@Input() foo = null;
I do not see why the trans-compiled code should be much different for:
@Input() foo: Bar;
To the extend that webpack will implode. Is there some specific semantic difference between the two (besides the explicit null assignment)?

I notice that this error occurs when I try to export an Enum and an Interface in the same file. Since I split the Enum declaration of the Interfaces declarations, it's fine, even if I define a lot of interfaces in the same files. I don't like to split my interface and enums into differents files because they share the same "domain context" in this case.

I strangely get similar errors when importing into one .ts file but not another one in same folder.
Again, the same import works fine in one file, but the other one gets
WARNING in ./src/app/foo/bar.ts
19:50-54 "export 'Tags' was not found in '../tar/tag.model'

with tag.model.ts being
export type Tag = string;
export type Tags = Tag[];
export class TagSet {
    constructor(public category:string, public tags:Tags[]){}
}
export type TagList = TagSet[];

@polyglotinc, I would think the reason you only see the problem in one file is because of the way the imported types are used. In my case a file containing something like:
@Input() foo: Tag;   // This will cause the warning
@Input() bar: Tag[]; // This will not cause the warning
The reason I think is that after transpilation you still need to know what "Tag" represents on the former, but not for the latter, which is just a JS Array.

I got around this by casting it:
@Input() foo = null

I got around this setting it equal to null and casting the type:
@Input() foo = <SomeType>null

This will fix it if you have strict null checks:
@Inject(MD_DIALOG_DATA) public order = {} as Order
Still feels quite dirty.

Additionally, you can use @Input() property: PropertyType | null; to get around this. Not sold on this workaround, or any other workarounds though. They're just bandaids slapped on the underlying problem.

Hello,
I having warnings when I export a string literal type from one file and import it in another.
I've managed to get rid of the warnings by moving that string literal types to a d.ts file.
Hope it helps !

Heya all,
I've been working on a new compilation pipeline for Angular 5 and up that should take care of these warnings in addition to other type related issues.

I fixed the warning by doing:
@Input() event: DayEvent | null;
instead of doing:
@Input() event: DayEvent;

I had the same problem, but couldn't use the type union because my input was a setter:
@Input() set something(s: SpecialInterface) { /** */ }

The switch from es2015, as set by the @angular/cli application generator to commonjs as noted above solved it for me.

@Inject(APP_CONFIG) config: AppConfig | AppConfig
is really strange workaround, but it just works xD

yep, I can confirm what @vpArth states worked for me also.

I am getting this warning for interfaces imported via a feature module library, however the strange workaround works to suppress the warning.
`import { AccountSummary } from '@css/top-core
export class OrderComponent implements OnInit {
@Input() account: AccountSummary;
...
`

I had the same problem exporting an interface:
export interface ResourceRef {
  [id: string]: {
    expires: string;
    resources: Array<Ref>
  };
}

and using it with @Input() resourceRef: ResourceRef;
Then I simply changed the interface to be a class, which johnpapa also suggested here:
export abstract class ResourceRef {
  [id: string]: {
    expires: string;
    resources: Array<Ref>
  };
}

And the warning is gone. So, is there any downside to that?

@rafaelbiten using a class, even abstract, will generate extra code for that class when compiled. An interface gives type checking for plain objects without generating additional code.

Has this been resolved? I am not seeing the errors with the following versions and import (although originally I was using abstract class
Angular CLI - v1.6.0
TypeScript Workspace Version: 2.4.2
TypeScript VSCode Version: 2.6.1
import { InjectionToken } from '@angular/core';

export interface ContentfulKeysConfig {
  space: string;
  accessToken: string;
  contentTypeIds: {
    post: string;
  };
}

export const CONTENTFUL_KEYS_CONFIG = new InjectionToken<ContentfulKeysConfig>('contentful-keys.config');

import { CONTENTFUL_KEYS_CONFIG, ContentfulKeysConfig } from './config/contentful-keys.config';
private keysConfig: ContentfulKeysConfig;
constructor(@Inject(CONTENTFUL_KEYS_CONFIG) config: ContentfulKeysConfig) {
    super();
    this.keysConfig = config;

Why is it closed?

Still seeing the issue for Angular CLI v1.6.3

In case anyone's looking for it, this appears to be the upstream webpack issue that @TheLarkInn mentioned!
https://github.com/webpack/webpack/issues/7378

In my case, restarting ng serve helped. I had only one export in my ts file

I just restarted the server and the warnings are gone.

This is not an issue anymore. I used abstract class instead.

This is not an issue anymore. I used abstract class instead.

is there any impact on types if we change interface to abstract class

Got this issue today when updating angular's packages to 8.0.4 / 0.800.4
https://github.com/angular/angular-cli/issues/2034#issuecomment-249813801 fixed it for me

Having this issue after upgrading to angular 8

Having this issue after upgrading to angular 8

Just move out app the interface/types from the problematic file into a separate *.ts file.

@th0r do you mean the interface thats causing the issue to remove them and put them into there own separate file

@hijazikaram yes. Or you can move all the interfaces/types from the file that triggers an error into a separate file e.g. <filename>.types.ts and export all of them. Also this file should not contain any real code e.g. classes, functions, variable etc.

Same issue. Moving interface to a separate file doesn't help if use barrel.

Same issue. really don't want to move interfaces to separate files. Also, issue for aggregator ts files that do a lot of export * from.

@jeffwhelpley I just added | null which fixed the issue for me

Why is angular/typescript making it hard for us? 😞

same as @mpgo13 started getting the issue when updated to version 8.0.4 / 0.800.4,
But in my case #2034 (comment) fixed it for me didn't work.
Error is not just happening within my own libs, but also in one of the ngrx libraries

@tbnovaes I got the same issue few days ago. After setting the fixed version of angular devDependencies to 8.0.0 / 0.800.0 it was gone.

For those of you who got this error after upgrading to 8.0.4 / 0.800.4, see https://github.com/angular/angular-cli/issues/14876. A fix seems to be coming in the next release.

@larrifax figured it out yesterday


IndentationError: expected an indented block

https://github.com/wbrueckner/cv2pynq/blob/7bd90c00de9e42b071d507a7587cb99bbf120bd7/cv2pynq/cv2pynq.py#L295
https://github.com/wbrueckner/cv2pynq/blob/7bd90c00de9e42b071d507a7587cb99bbf120bd7/cv2pynq/cv2pynq.py#L302

fixed in 193ab7e15382a20fc1f99a8e3dc669f7a87600c5


Double Clicking a Word in an Input Field Highlights the Entire Field

I am using inputmask to restrict certain characters and limit the number of characters on various fields by using regex.
$("#user-name-field").inputmask({
regex: gl_strUserNameMask,
placeholder: ""
});

Everything appears to be working fine from a masking point of view. However, I stumbled upon a strange issue where if I double-click on a word within the input field (that should typically highlight only that word) it will highlight everything within that field.
Any ideas as to why this would be happening and how I can rectify this issue?
Thanks!

@mlammert ,
Which version are you using of the inputmask?  Can you try with 4.0.1 beta 17

I was using 4.0.0 beta 24.
I downloaded the latest version and dropped in the new jquery.inputmask.bundle.min.js file.
When I reloaded my web page, the entire page froze and gave a "there is a script causing this web page to run slowly" message in Firefox. I tried several time, cleared my cache, etc and could not get my page to function with the latest version file.
Thank you for your quick response and offer to help, but I think I need to move on and see if there is another solution for what I am trying to do.
BTW, this was the regex I was using [ a-zA-Z'\-]{64}

@mlammert ,
Can you provide some more feedback, as I tested your regex and don't experience any problem.  How many inputs are on the screen?

The page that "froze" had two input fields on it. Both were being masked using similar regex'es.
I have tried to narrow this down to the most basic of code and I still get the issues.
Using jQuery 3.3.1 and jQuery UI 1.12.1.
Again, I appreciate the desire to help, but I was forced to move on to a different jQuery plugin that offers similar functionality (jquery.alphanum).


Ability to set the code to execute on a failed bounds check.

Be able to set the code to execute on a failed bounds check.
eg. assert() so a fail would call abort().

Can you provide a worked example of how this would be setup and function? Would it be a macro to be inserted that would default to a noop?


docs(mesh): document caCert for cert-manager

Description
Missing docs for existing feature

Testing instructions
Preview link:
Checklist

[x] Review label added
[x] Conditional version tags added, if applicable.

LGTM


cmd/compile: document PGO policy regarding explicit user optimization hint behavior

Hi!
In LLVM  there is an interesting issue about how PGO profiles interact with user-provided hints (like //go:noinline pragma).
In the Go compiler right now only inlining decisions (AFAIK) are influenced by PGO, so the the only visible to me right now affected pragma is go::noinline. We need to document the current behavior.
Later, when the Go compiler will implement more and more optimizations, possibly other pragmas would be affected as well. They should tracked somehow and documented as well.

CC @golang/compiler.

I think in general Go will not have many compiler directives/pragmas for optimization hints. go:noinline is not an optimization hint. It is mostly used for correctness, (e.g. some runtime functions must not be inlined), and for testing (e.g. to ensure certain code-generation behavior). It tells the compiler not to do an optimization, and PGO must respect it. More generally, if in the future we introduce pragmas to instruct the compiler not to do certain optimizations, PGO should respect them as well and not apply the optimizations.
I'm not sure what to document specifically. Maybe we could add that with go:noinline, it will not be inlined even with PGO. But that doesn't seem really necessary -- go:noinline is simply not inline in all situations, including PGO.
If later we introduce a compiler directive that has interesting interactions with PGO, we can document that.

I understand it, but from the current Go documentation:

The //go:noinline directive must be followed by a function declaration. It specifies that calls to the function should not be inlined, overriding the compiler's usual optimization rules. This is typically only needed for special runtime functions or when debugging the compiler.

According to this, "function should not be inlined" I see "should not". I cannot read it right now as "a function with go:noinline directive is NEVER inlined". That's why I am asking the question. From my current reading, go:noinline directive tunes somehow inlining rules. So if the current behavior is NEVER inline - would be great if the wording would be somehow changed to make it more clear for the end-users.

I agree the current wording is fine. I don't want us to overcommit on //go: directive support.
cmd/go documents and supports more directives that are user targeted. The cmd/compile directives are for low-level details that most users shouldn't need to use or worry about.

If the current wording is fine, then I am kindly asking to add a note somewhere that the PGO optimization does not affect the inlining decisions for the functions with go:noinline attribute :) I think adding a small note to the go:noinline description about that would be fine.

But why? Who does that help?

But why? Who does that help?

This information is important for people, who optimize their programs. As you know, inlining decisions could be critical in some cases. E.g. performing extra inlining in the "wrong" place could affect the code size. Code size characteristics could be critical in certain situations. If the compiler has go:noinline directive that means there are cases where it's important to the people. Otherwise, my question is - why did you implement it in the compiler? :) If it's important for the users, they want to know, in which cases the go:noinline behavior can be changed. Applying PGO - one of the cases (which is not unique for the Go compiler - see the corresponding LLVM issue).
If you are strictly against adding such implementation detail to the documentation - okay, it's of course up to the development team. Hopefully, if someone is interested a lot about the question - they will be able to dig into the compiler and search over the GitHub issue. This way has worse UX but reduces the documentation maintenance cost.

I don't what to get to too much about wording (and I'm not an expert on it). But I think at least in this case, "should not" means never. It is not a hint, but a requirement.

Regarding meanings of words like "should", "may" and others - to eliminate different readings of the same words I like to use RFC 2119 (https://datatracker.ietf.org/doc/html/rfc2119). Maybe I am a bit pedantic in this area since I spent several years of my life with the C++ standardization process... :)
Of course, if it's the well-known fact in this area of Go that "should" has other meaning than a recommendation, the current wording is fine.

If the compiler does something it "should not" do, I'd think that is a very bad thing and only creates confusions.
That said, personally I would not oppose to changing "should not" to "must not".


clustersecretstore getting 403 from external vault but vault cli is not

looking for some help, not sure where to look next for debugging this issue i am having. any insight yall can provide would be much appreciated!
image: ghcr.io/external-secrets/external-secrets:v0.8.3
I have two kubernetes clusters, one running hashicorp vault(cluster A) and the other running with external secrets(cluster B). Unfortunately my clustersecretstore in cluster-B gives the following issue:
Warning InvalidProviderConfig cluster-secret-store unable to log in to auth method: unable to log in with Kubernetes auth: Error making API request.
URL: PUT https://<url>/v1/auth/cluster-name/kubernetes/login
Code: 403. Errors:
* permission denied

Status:
  Message: unable to create client

I am using the kubernetes auth method for a clustersecretstore resource with a spec that looks like this:
spec:
  provider:
    vault:
      auth:
        kubernetes:
          mountPath: cluster-name/kubernetes
          role: reader
          secretRef:
            key: token
            name: vault-token
            namespace: project-name
          serviceAccountRef:
            name: vault
            namespace: project-name
      caProvider:
        key: ca.crt
        name: vault-ca
        namespace: project-name
        type: Secret
      path: cluster-name/stuff
      server: https://<url>
      version: v2

I have confirmed I can connect to the vault myself by creating the following test pod in cluster-B
# test pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: vault-test
spec:
  containers:
  - args:
    - -c
    - sleep 100000
    command:
    - /bin/sh
    image: vault:1.12.3
    name: vault

and exec-ing in to run the following command in this pod from cluster-B:
kubectl exec -it vault-test -- sh
vault write -address=https://<url> -tls-skip-verify auth/cluster-name/kubernetes/login role=reader jwt=<jwt-from-vault-token-secret>
# SUCCESS!
# note, i have also done this with -ca-cert=ca.crt using my ca with the same success

This succeeds. But the clustersecretstore cannot seem to authenticate using the same url and the same jwt. I have turned on debug log level in the external-secrets pod and it says this before stacktrace.
Retrieved new token using Kubernetes auth.
unable to validate store, could not get provider client... etc

Any ideas why a test pod in cluster-B with the vault cli can authenticate, but the clustersecretstore in cluster-B cannot? I have also tried giving external-secrets cluster-admin clusterrole but without success either.
Thanks again for your help!

You specify both kubernetes.secretRef and kubernetes.serviceAccountRef, is that intentional?
IIRC the service account takes precedence. From your test pod, it looks like you've used the vault token from the secret?! jwt=<jwt-from-vault-token-secret>
spec:
  provider:
    vault:
      auth:
        kubernetes:
          mountPath: cluster-name/kubernetes
          role: reader
          secretRef:
            key: token
            name: vault-token
            namespace: project-name
          serviceAccountRef:
            name: vault
            namespace: project-name

You get a 403, that indicates that you are authenticated, but there's no policy that allows that action. Do you have access to the vault (debug) logs?

Looking at the code: the kubernetes Login() call does a WriteWithContext which does a MethodPUT! The docs say that only POST is supported. But also: Vault treats the HTTP POST and PUT verbs as equivalent from here.
I don't think POST is needed here, i'd guess it is a authn or authz issue: either a misconfigured vault policy or misconfigured kubernetes integration in vault.

Good catch on us using two methods of auth! We ended up for now just using the vault token from the secret since we accidentally configured 2 methods of auth. This is working for us now.
Our preference was the serviceaccount method, and after some debugging we suspect our particular set of systems may have an issue with clock skew. By investigating the vault audit logs we were able to find the token generated by the service account. Running the commands manually with this token also resulted in success, but failure when run automatically. The running theory was something along the lines of clock skew causing the validFrom date to be in the future, meaning the api would not yet accept this token as valid but would in a few seconds. This explained why using it manually later worked, but the automation failed because it was too quick given our clock skew.
When it fails a new token seems to be generated rather than the previous one being retried. If the previous one was retried a couple times that in theory would give some extra allowance for this condition. At some point I found some caching property I thought might help, but at that point we had something working and moved on. Reality is we should probably just try fixing clock skew issue, but in the meantime the secretRef is working until that becomes a priority.
Thanks for the help!


nuget

Did you upload nuget?name?

@jinyuttt Look for 'AvaloniaUIRibbon' on nuGet. Its a pre-release package.


[Swift][Temp Fixed] Deliver doesn't read Deliverfile

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
When executing my release lane, I was using uploadToAppStore(…) passing in only username and app arguments. I implemented a Deliverfile.swift and was expecting it to be read, but turns out uploadToAppStore()'s arguments don't default to deliverFile.<arguments>, it has its own hardcoded default arguments.
Since deliver is a mere alias for uploadToAppStore (and/or vice-versa?), I believe both methods should have the exact same default arguments, and internally, instead of calling
let command = RubyCommand(commandID: "", methodName: "deliver", className: nil, args: [ … ]
_ = runner.executeCommand(command)

It should implement
deliver(username: username,
             appIdentifier: appIdentifier,
             appVersion: appVersion,
             …)

I did some digging to try to fix this issue by myself but I couldn't find exactly where to edit the code for those default arguments in Ruby as everything's deeply parametrized 😅
Related issues, that could possibly be caused by the same behavior (unchecked/untested):

https://github.com/fastlane/fastlane/issues/12510
https://github.com/fastlane/fastlane/issues/14719
https://github.com/fastlane/fastlane/issues/14789
https://github.com/fastlane/fastlane/issues/13652

Temporary fix:
Use deliver(…) swift method from Fastfile instead of uploadToAppStore(…)
Command executed
uploadToAppStore()
Complete output when running fastlane, including the stack trace and command used
N/A
Environment

 ✅ fastlane environment ✅
Stack

Key
Value

OS
10.14.5

Ruby
2.4.1

Bundler?
true

Git
git version 2.20.1 (Apple Git-117)

Installation Source
~/Documents/Projects/tellus-ios/.vendor/ruby/2.4.0/bin/fastlane

Host
Mac OS X 10.14.5 (18F132)

Ruby Lib Dir
/usr/local/Cellar/ruby/2.4.1_1/lib

OpenSSL Version
OpenSSL 1.0.2k  26 Jan 2017

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
10.2.1

System Locale

Variable
Value

LANG
en_US.UTF-8
✅

LC_ALL
en_US.UTF-8
✅

LANGUAGE

fastlane files:
`./fastlane/Fastfile.swift`
// Hidden for privacy reasons.


Tick build again

Dummy pull. One more try to force rebuild

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


After DeprecatePythonPath experiment is finished, remove the experiment and more

[ ] Remove pythonPath string from the extension
[ ] Remove other references to pythonPath. For eg. PYTHON_PATH etc.
[ ] Remove the experiment
[ ] Undocument pythonPath settings on workspace level
[ ] Fix all failing tests with experiment on
[ ] Note this.config.getSettings(...).pythonPath API won't work in the constructor when in Experiment. --- ANNOUNCE IT

pythonPath is still being used in the extension, other issues are now fixed.


More performance work

This is mostly investigating if it would be possible to run Design Time Build directly on .sln file, rather than on the list of projects. Potentially it should lead to better performance but requires sizeable changes in the codebase - it will require some event-driven approach to the thing, rather than calling MSBuild synchronously.

Looks like it's going nowhere - we need to call DTB one by one to handle cross targeting correctly.


Getting an issue installing Crouton on Samsung Chromebook xe303c12

Please paste the output of the following command here: sudo edit-chroot -all
```chronos@localhost / $ sudo edit-chroot -all
Password:
name: xenial
encrypted: yes, unlocked
Entering /mnt/stateful_partition/crouton/chroots/xenial...
crouton: version 1-20200724165050~master:08dac970
release: xenial
architecture: armhf
xmethod: xorg
targets: touch,xfce
host: version 12105.100.0 (Official Build) stable-channel daisy
kernel: Linux localhost 3.8.11 #1 SMP Sun Jul 14 00:09:57 PDT 2019 armv7l armv7l armv7l GNU/Linux
freon: yes
Not unmounting /mnt/stateful_partition/crouton/chroots/xenial as another instance is using it.
chronos@localhost / $

#### Please describe your issue:
I am getting this error code

chronos@localhost / $ sudo startxfce4
Password:
Sorry, try again.
Password:
Entering /mnt/stateful_partition/crouton/chroots/xenial...
/usr/bin/startxfce4: Starting X server

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.15.0-124-generic armv7l Ubuntu
Current Operating System: Linux localhost 3.8.11 #1 SMP Sun Jul 14 00:09:57 PDT 2019 armv7l
Kernel command line: cros_secure console= console= loglevel=7 init=/sbin/init cros_secure root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2539520 verity payload=PARTUUID=ff875e0c-0813-6340-b7ec-f055097228c6/PARTNROFF=1 hashtree=PARTUUID=ff875e0c-0813-6340-b7ec-f055097228c6/PARTNROFF=1 hashstart=2539520 alg=sha1 root_hexdigest=3bfc672b009a3247d3cd8399a74f96ac53188553 salt=306427720380043295ff7f5e5f7ef68a81138057901e316471bd1520719b78b2" noinitrd vt.global_cursor_default=0 kern_guid=ff875e0c-0813-6340-b7ec-f055097228c6
Build Date: 30 November 2020  07:46:40PM
xorg-server 2:1.19.6-1ubuntu4.1~16.04.5 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.33.6
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/tmp/Xorg.crouton.1.log", Time: Tue Mar  9 00:37:03 2021
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.chromium.LibCrosService was not provided by any .service files
method return time=1615268223.901066 sender=:1.13 -> destination=:1.87 serial=1735 reply_serial=2
   boolean true
MESA-LOADER: failed to retrieve device information
gbm: failed to open any driver (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
gbm: Last dlopen error: /usr/lib/dri/exynos_dri.so: cannot open shared object file: No such file or directory
failed to load driver: exynos
EGL_MESA_drm_image required.
(EE)
Fatal server error:
(EE) AddScreen/ScreenInit failed for driver 1
(EE)
(EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
(EE) Please also check the log file at "/tmp/Xorg.crouton.1.log" for additional information.
(EE)
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.chromium.LibCrosService was not provided by any .service files
method return time=1615268224.909671 sender=:1.13 -> destination=:1.89 serial=1736 reply_serial=2
   boolean true
(EE) Server terminated with error (1). Closing log file.
/usr/bin/xinit: giving up
/usr/bin/xinit: unable to connect to X server: Connection refused
/usr/bin/xinit: server error
Not unmounting /mnt/stateful_partition/crouton/chroots/xenial as another instance is using it.
chronos@localhost / $

#### If known, describe the steps to reproduce the issue:
 After installation when i use the command sudo startxfce4 I get this error code. I have tried to install encrypted versions and non encrypted versions. I tried to reinstall it 3 times even once putting in capability for touch even though I don't need it.
![Screenshot 2021-03-09 at 00 29 22](https://user-images.githubusercontent.com/80306932/110424019-1a3f9880-8070-11eb-9754-50bab8032602.png)
![Screenshot 2021-03-09 at 00 29 13](https://user-images.githubusercontent.com/80306932/110424022-1ad82f00-8070-11eb-8e04-ae369ab10e3e.png)

I experienced a similar result while trying to install Xenial on my XE503C32. Try installing Focal Fossa (20.04 LTS) instead.
sudo crouton -r focal -t xfce,audio
Worked great for me.


Eve concepts has type design issues

Eve was designed such that TreeNodes can be either models or collections of these models, and that leaf nodes can either be models or POD (e.g. bool, str, etc.). This design causes a few utility functions to require erasing the type (e.g. generic_iter_children). Eve should be type-refactored to separate these.

@egparedes Could you add a new eve label and tag this with it? I don't have permissions to do that.


Fixes #10

Only one line of code seems to be the compatibility issue with Ember 2.0

The first commit makes it compatible. The second removes a deprecated bit of code so that it will remain compatible into the future.


Update F# Interactive reference for F# 5

Contributes to https://github.com/dotnet/docs/issues/21272 by emphasizing package references and, in general, revamping this article to be more of a tutorial than a word dump about F# Interactive.

@cartermp This PR introduced a couple of build warnings. Can you resolve those?

Yep, done here: https://github.com/dotnet/docs/pull/21326


Timeout while generating release notes

Azure DevOps Extension you are using
Generate Release Notes (Crossplatform)
Where are you running it?

Azure DevOps Service (VSTS)

Version of Extension/Task
Current public version, according to the log: 2.28.7
Expected behaviour and actual behaviour
Trying to see if this is a solution for us, but I keep getting a timeout:
[error]Error: connect ETIMEDOUT <IP_ADDRESS>:443
Any idea on how to fix or circumvent it?
Full log attached:
log.txt

Never seen that before.
I quick search of the web can occur when proxies are involved between the agent and Azure DevOps.
So I guess the obvious question are

is this a hosted or private agent?
is it possible to try with a different agent, to see if its agent/connection specific?
if you rerun on the same agent does it always fail at the same point?
is the list of WI listed all the ones you expect i.e is the failure trying to get a WI or the next step/api call?

It's running on a hosted agent.  Currently a vs2017-win2016.
Rerunning on the same agent gives the same error, but happened after another message (e.g. in the "getting the details of xxxx" --> it got down to a lower number after some retries).
Not sure what that number represents, as we're only up to about 400 work items in this project.
This is the first time I'm using the tool, so it's trying to collect information about a few months of history. So I'd expect about 350-380 work items to be fetched.

The Getting the details of xxx is the task looping across all the builds that have occurred in the past. In your cases as it is the first run it is every build.
I could improve the logging to give the number it intends to loop over, and put the word 'build' in the message to make it clearer.
I would expect the next message to be Detected xxxx commits/changesets and xxxx workitems between the builds., which we obviously are not getting to.
That said, I will get a new build out with more logging to give a clue where the problem lies. So I have added more logging and ran it via all the test in my release pipeline.

It ran ok on a private agent (on my laptop)
The logs showed it found 154 builds
When i tried it on the same hosted VS2017 build agents you are using I got timeouts too.

I think it is an API throttling issue.
I will continue to investigate, but any chance you could try a private agent?

Try 2.29.4 which has just been released. I have altered the retry settings for all Azure DevOps API calls.
It has fixed the issue for me on hosted agents
Let me know how it goes

Hi, just tried with v2.29.4. same error, but on a different build. See the attached log.
log2.txt
I'm unable to try it on a private agent as we don't have any running at this time.

Looks like it managed to have got further this time. But I can see that you have a lot more builds to scan than I have in my tests (700+ over about 150), so more load if it is a throttling issue.
I have had another look at the Azure DevOps Node API and added another time parameter. I set this to I think 10sec, assuming it is measured in Milliseconds, it is a bit unclear.
I made that change last night (I am in the UK so GMT) and tested it, but it timed out with a hosted agent. I tried it again this morning and it got further. I wonder if it is Azure DevOps load based?
Anyway I have upped the timeout to 30s and retested, it still failed for a hosted agent, but again was fine for a private agent.
I continue to investigate for a real solution

Thanks, haven't looked at the code yet. But perhaps a retry mechanisme is in order? (I'm in Belgium btw, GMT+1)
It sure could be that they throttle it based on the entire load of DevOps.

The SDK is meant to do throttling.
I have just done a upgrade of all packages to make sure I have the latest and retested. Still get the problem.
I am going to reach out to Microsoft to see if they have a suggestion, or if I need to write my own retry logic
I will get back when I have more to report

Just an update, I still have no real fix for this. The workaround seems to be to use a private build agent. I cannot get a timeout with a private agent.
I have an issue logged with on the Azure DevOps Node SDK repo 378

Hi, thanks for the update. I've actually wrote my own code to get the release notes based on what you were doing. So far it seems to work fine. Not sure what I'm doing differently...

Closing this as the upstream issue has been closed with no solution

Hi Richard, Did you figure out anything more on this?  I'm seeing this same timeout issue using version 3.30.21.  Same scenario where it's the first time to generate release notes for a "classic" release with lots of WI history.  It is also sporadic. It will fail then it might succeed on a subsequent re-deploy.

Yes I have been seeing the same. I have raised issues on various repos and forums, but with no answer.
I think I am going to have to implement my own retry logic as the code in the azure devops node sdk foes not seem to do the job.

I have started on a PR, assuming it works (though it is hard to test) should be out soon

Ok, that was quicker than I expected, and has been released a 3.31.2.
I have tested the retry logic by forcing the first API call to fail, but this is not the same as 'real' failures.
The retry logic is set to try 3 time in event of an API failure of any type (not just timeouts) and pause for 1sec between each try,
Reopen this issue if this retry logic does not work

Thanks for the quick turn around.  I just tested and it's hitting the max retry count.  See capture below.

Is it getting any further, has it helped at all?
If it has then I think the best option is to expose the retry count and the pause timer as variables so you can tweak them up as needed.

It looks to be failing at about at the same spot when compared to my runs from yesterday.

It is still worth a try to get them exposed, might be you have to back off   a good few seconds, I will get the change made

It's worth a try.  In case it helps, it does appear the point of the timeout error is really close to the end of the WI history when I compare it to a successful run from yesterday.

I did 6 test runs (see below) using the new retry params.  I worked up to 5 retries with a wait of 60 seconds.  Of the 4 failures, 3 were ETIMEDOUT and 1 was ECONNRESET.  It seems that once the retry logic starts it doesn’t recover.

1st succeeded with no retries
2nd failed using default retry params (3 retries waiting 5 seconds)
3rd failed using 5 retries waiting 10 seconds
4th failed using 5 retries waiting 30 seconds
5th succeeded with no retries
6th failed using 5 retries waiting 60 seconds

OK, I guess the next step is to destroy and recreate the whole combination channel, that is going to take sone thought.

I think I have got a reliable repo of the timeout in my test harness, that should help me debug the issue

Thanks for the update.  In case it helps your test harness, below are the counts for one of the runs that was successful.

Release 3.33.2 now creates the Azure DevOps REST SDK connection objects, hopefully that should clear the retry issues.

Okay... my first run was successful with no retries.  But the 2nd run  failed all 5 retries with a wait of 60 seconds.  Log below on the first retry appears to be recreating objects but immediately returns the ETIMEDOUT.  It's like the host is hosed once this starts with the Dev Ops API.

We I am out of ideas, short o a huge pause

I have ripped out all my retry logic as it does not help and wired my configuration options to the retry setting built into the Node SDK. The new retry feature is 20 times. The pause time is now ignored as this is not an option for the SDK.
This will release will come out as 3.34.x later today

Thanks for the update.  I'll give it a test when it's available.

I tested the new version using the default retry of 20.  The first 2 runs failed with the 3rd run succeeding.  For now, I'll inform my client to re-deploy until a successful run which seems to occur in 2-3 re-deploys.  I'll keep you posted if we uncover anything new that might help.

Sorry I can't get any further, I am going into to log a new more details issue with the Azue DevOps Node SDK team

Thanks Richard... I can tell you've tried everything you can on your side.   I've seen these type of odd platform issues myself in other areas of Azure.

Current Status of this Issue
This is an issue with the underlying Azure DevOps Node SDK or REST API endpoints, not this task. Hence, an issue has been raised in the the appropriate Repo #425
The best workaround at present is to always place this task, and any associated tasks e.g. one that upload the generated release notes to a WIKI, in a dedicated YML pipeline job. This allows the task to be easily retried without rerunning the whole pipeline

Historically the only workaround has been to always place this task, and any associated tasks e.g. one that upload the generated release notes to a WIKI, in a dedicated YML pipeline job. This allows the task to be easily retried without rerunning the whole pipeline.
However, with 3.37.x the error traps have been changed in the task to treat any error that occurs whilst accessing the API as a warning, but allow the task to run on to try to generate any release notes it can with the data it has managed to get. This is far from perfect but a bit more robust.


Audio and SpriteAudio are internally the same

By looking at the cache, Audio and SpriteAudio are stored the same way. I suggest to add a flag to know what type of element is inserted. That should make sound.addAudioSprite be unifiable with sound.add, making sound.add branching depending on that flag

Having looked at this, you can detect it by checking for the existence of the BaseSound.spritemap property. If it exists, it's an AudioSprite.


export not working

hi
after  updated to new change the export process not working and when manually run it only  message me like this :
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:29: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:30: warning: constant Gem::ConfigMap is deprecated
ruby: warning: shebang line ending with \r may cause problems
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
and nothing was do

Hi @msh13792,
Are you on BBB 2.4? This converter is currently for 2.3 only.

Hi, I'm on 2.3 and am having the same issue. Although, all I get is the 4 deprecated notices:
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:29: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:30: warning: constant Gem::ConfigMap is deprecated
/usr/lib/ruby/vendor_ruby/rubygems/defaults/operating_system.rb:10: warning: constant Gem::ConfigMap is deprecated
In my case at least, the export worked with no problems for 2 out of 3 recordings, this one was the exception. I'm wondering if the title of the BBB room may be one possible reason. The room where the export failes had quotation marks " and an apostrophe ' in the title. At least that's what I'll be scanning the logs for next.

Hi @adamjenkins, thanks for the feedback. The warning is harmless.
I've just merged the PR by @germanocaumo that should make the export work once you update it. Would you mind giving it a try? Thanks!

Wow, thanks so much. Will do right away and report back. Standby...

@danielpetri1 That has indeed fixed the problem. Thank you very much for your great work!
One note, I had to run bbb-record --rebuild to set the fix in motion. Running presentation.rb alone directly as the bigbluebutton user didn't work. Hence it rebuilt everything and my reply comes a little late.
Thanks again!

@adamjenkins Awesome, great to hear. Thanks for the troubleshooting steps!

@msh13792, can you please post the output of /var/log/bigbluebutton/post_publish.log?

i've got it working on bbb 2.4 by manualy running:
root@bbb24:/usr/local/bigbluebutton/core/scripts/post_publish# ./presentation.rb -f presentation -l -m 920acbcd7a7d0f274d79189b7530f9b715e67117-1639997735776
without the '-f presentation' flag it does nothing...
and first i had to install 'trollop' module, which is obsoleted, but works:
gem install trollop

Thank you @arpitest!


In "send" transaction box, let user select amount in fiat instead of just sats and btc

When in the send screen, let user switch from SATS to BTC to PREFERRED CURRENCY (fiat)
When switching to preferred currency, show available balance in preferred currency.
The input amount should be in preferred currency.
In the background, we convert the input amount in the preferred currency (fiat) to Bitcoin.
We keep the "send confirmation" screen as is.

@mocodesmo will need your help on this one.

@BullishNode we have add this feature however the way input works needs review.
It may be unintuitive to some but intuitive to others. The reason for this is because we have added formatting in the input box which adds commas every thousands *,000

Gonna wait to test until we have a final version of send page

Closing this for now as we support entering amount in fiat and https://github.com/SatoshiPortal/bullbitcoin-mobile/issues/72


Epic - Search Engine Optimization

Linked Stories:

https://github.com/jccjcat/mywebclass-simulation/issues/19
https://github.com/jccjcat/mywebclass-simulation/issues/18

Test on-page optimization, site speed and load time
Test mobile friendliness and keyword search and optimization


Lag in typing

Matthew has reported the issue several times.

2 possible culprits in https://riot.im/bugreports/listing/2018-03-22/211057/console.log.gz of https://github.com/matrix-org/riot-ios-rageshakes/issues/1047 before
2018-03-22 21:10:28.596 Riot[6909:4885802] [RageShakeManager] Start shaking with [RoomViewController]:

unexpected series of

2018-03-22 21:10:23.782 Riot[6909:4885802] [MXFileStore commit] Background task #25265 started
2018-03-22 21:10:23.823 Riot[6909:4885802] [MXFileStore commit] lasted 41ms
2018-03-22 21:10:23.823 Riot[6909:4885802] [MXFileStore commit] Background task #25265 is complete - lasted 41ms

Some crypto operations maybe on the main thread: maybeUploadOneTimeKeys and generateOneTimeKeys

Another culprit could be the contact manager that makes things on the main thread.

Even if the app is still not perfect, recent perf improvements fix this issue.


Tailwindcss doesn't rebuild CSS for new files

Describe the bug
I don't remember if we've discussed before, but tailwindcss can't seem to track new files due to limitations of this.addWatchFile: https://github.com/vitejs/vite/blob/fe30349d350ef08bccd56404ccc3e6d6e0a2e156/packages/vite/src/node/plugins/css.ts#L1433-L1444
I'm not sure if we want to special case this, or leave it to tailwind's next major to possibly fix things.
Found this from https://github.com/withastro/astro/issues/12255
Related: https://github.com/vitejs/vite/issues/15460 (but not exactly the same I think)
Reproduction
https://stackblitz.com/edit/vitejs-vite-nk6bcl?file=index.html&terminal=dev
Steps to reproduce

Start dev server
Copy the content of index.html and create a new foo.html at the root for example and paste the content in it.
Rename text-red-500 in the pasted content to something else new, like text-green-500
Open http://localhost:5173/foo and notice that the text is black, not green (for example)

After a full server restart and reload the page, the color is then correctly applied
System Info
n/a

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

We should be able to support this by doing something similar to the vite:import-glob plugin.
https://github.com/vitejs/vite/blob/ad9a987aa4ae3d9e246541d918bb2ec331bbccae/packages/vite/src/node/plugins/importMetaGlob.ts#L91-L105


Update Plugin Artifacts Links for v0.136.3

Automated changes by create-pull-request GitHub action

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


Add Cachy Browser

I added support for Cachy Browser which is a fork of Firefox that's only officially available on CachyOS for Linux, someone could probably build it for Windows or macOS but it's very unlikely.
I also formatted and linted the code using rust and cargo's builtin rustfmt and clippy tools, this should probably be a commit and pull request CI check.
I also noticed zvariant, zbus, and windows are outdated but decided to leave them alone because of the extensive changes needed for the first two, but I changed all the dependency versions to remove the unused minor/patch versions as without the = prefix they are ignored by cargo, only the major number is used.

Looks good!
What settings did you used for formatting? I'm wondering if we should add default format settings for the repo inside .vscode/settings.json or rustfmt.toml or let the user use his own format settings (not sure where)
And maybe even format tests such in tauri/workflows/lint-cli.yml


COMP: Fix variable type and syntax errors

Fix expected variable type and syntax errors in ITK_TEST_SET_GET_VALUE
calls.
Fixes:
/Users/builder/externalModules/Filtering/ImageCompare/test/itkTestingComparisonImageFilterTest.cxx:71:21: error:
called object type 'const char [55]' is not a function or function pointer
  TEST_SET_GET_VALUE(differenceThreshold, filter->GetDifferenceThreshold());
  ~~~~~~~~~~~~~~~~~~^
/Users/builder/externalModules/Filtering/ImageCompare/test/itkTestingComparisonImageFilterTest.cxx:75:21:
error: called object type 'const char [55]' is not a function or function pointer
  TEST_SET_GET_VALUE(toleranceRadius, filter->GetToleranceRadius());
  ~~~~~~~~~~~~~~~~~~^
2 errors generated.

and
/Users/builder/externalModules/Registration/Common/test/itkMattesMutualInformationImageToImageMetricTest.cxx:223:84:
error: expected ';' after static_assert
  ITK_TEST_SET_GET_VALUE(numberOfHistogramBins, metric->GetNumberOfHistogramBins())
                                                                                ^
                                                                                ;

Raised for example in:
https://open.cdash.org/viewBuildError.php?buildid=7679319
PR Checklist

[X] No API changes were made (or the changes have been approved)
[X] No major design changes were made (or the changes have been approved)

Issue introduced in #3077.


Cannot set invalid value using script even when invalidAsValue is true

See http://jsfiddle.net/gjsjohnmurray/qd732sn9/ for demonstration.
I will try and fix this.

Thank you very much once again for noticing it and especially for fixing it, John.


Add missing internal to objects

Describe your changes

This PR makes all serializers internal.
Linked issues

Breaking changes

[ ] This issue contains breaking changes

Codecov Report
Base: 61.15% // Head: 61.15% // No change to project coverage :thumbsup:

Coverage data is based on head (50a5483) compared to base (a052c68).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #126   +/-   ##
=======================================
  Coverage   61.15%   61.15%
=======================================
  Files          44       44
  Lines        1058     1058
  Branches       74       74
=======================================
  Hits          647      647
  Misses        393      393
  Partials       18       18

Impacted Files
Coverage Δ

...izers/GatewayCallContractTransformingSerializer.kt
100.00% <ø> (ø)

...ata/serializers/GatewayGetBlockNumberSerializer.kt
100.00% <ø> (ø)

...izers/GatewayGetBlockTransactionCountSerializer.kt
33.33% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Restructure navigation

This PR restructures the top-level navigation. I used the Diátaxis framework for general design guideance and several homepages of popular projects (e.g. NumPy) for applied navigation.
I've organised as follows as a suggestion:

'Overview' -- all example notebooks, and the two prose documents explaining the background and context of HARK -- this fits the 'explanation' category of Diátaxis
'Reference' -- this is the current reference section
'Guides' -- this is currently the quick start, installation, and contribution guides, but could grow to encompass tutorial style content

The notebooks were somewhat challenging to classify as tutorial (learning-first) vs explanation (understanding-first), but for ease I've put them all in explanation for now. Tutorial is the major missing Diátaxis category currently.
A
cc: @MridulS
(this PR is based on top of #1301; please review that one first!)

Thanks @AA-Turner!
Urghh, looks like the #1301 merge created too many merge conflicts. Could you rebase and push?

Done!

Some notes:
The references section behave differently for the tools sections and the models section (Not sure if it's a local issue for me). The sidebar on left goes away for tools section.
While we are on diataxis, can we great the pretty blocks like https://docs.scipy.org/doc/scipy/ for the homepage? (Doesn't need to happen in this PR)

The references section behave differently for the tools sections and the models section (Not sure if it's a local issue for me). The sidebar on left goes away for tools section.

Fixed, thanks for spotting -- an odd interaction that I'll look into in Sphinx.

While we are on diataxis, can we get the pretty blocks like https://docs.scipy.org/doc/scipy/ for the homepage? (Doesn't need to happen in this PR)

Yep!
A

@llorracc -- do you have Dominic's GitHub account name to hand please at all? I can then add him to the reviewers group for each PR I open.
Thanks,
Adam

Dominic,
Please send Adam your GitHub ID
On Thu, Jul 13, 2023 at 11:11 PM Adam Turner @.***>
wrote:

@llorracc https://github.com/llorracc -- do you have Dominic's GitHub
account name to hand please at all? I can then add him to the reviewers
group for each PR I open.
Thanks,
Adam
—
Reply to this email directly, view it on GitHub
https://github.com/econ-ark/HARK/pull/1302#issuecomment-1635202945, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKCK744LZZN3BKV2SH5DPLXQC2GXANCNFSM6AAAAAA2IUNDJ4
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Sent from Gmail Mobile

This looks good! Thanks @AA-Turner!


Hf integration

General PR for the HF/mammoth integration project, will also put some doc/pointers here

utils for loading an existing checkpoint from mammoth:
https://github.com/Helsinki-NLP/mammoth/blob/main/onmt/model_builder.py#L179C9
all CLI/ config file options: listed in https://github.com/Helsinki-NLP/mammoth/blob/main/onmt/opts.py
(in particular, see train_opts for structural options, and build_bilingual_model )

indices for special tokens are here:
https://github.com/Helsinki-NLP/mammoth/blob/main/onmt/inputters/vocab.py#L10

May this work for the SPM initialization https://github.com/google/sentencepiece/blob/master/python/add_new_vocab.ipynb?


Implement prepend feature

Hi, good job on this action. I also would like to see a prepend feature to insert new content on top of the issue's body.

Hey @ArtemkaKun
This is a good idea, I'm trying some things via https://github.com/julien-deramond/update-issue-body/pull/4. As soon as it is ready, it'll be embedded in a v1.1 🚀

It's released in v1.1.0. Don't hesitate to tell me if there are some issues with the new version or the old one, I'm not yet really aware of the GH actions release and versioning systems 😇