text:
highlight group selected item line

I am creating a theme and the selected item in the list currently is the same color as CursorLine but I want to have a different background for trouble then the default normal background.
So how can I theme the currently selected line in the trouble window?

There is no selected item highlight.
That is default Neovim behavior to show the current line with CursorLine.
So yes, it is by design the same as CursorLine.

Would it be possible to add a custom highlight group and link it as a default to CursorLine, so that it is possible to be themed by others? Because currently I cannot do anything abou this.

authors: folke uloco


text:
Add Japanese fonts

http://download.microsoft.com/download/B/7/B/B7B1A1A5-6ADD-428F-A710-66A745B9037E/OfficeLangPack2013_JA_x86.exe
https://web.archive.org/web/20200629064305/http://download.microsoft.com/download/B/7/B/B7B1A1A5-6ADD-428F-A710-66A745B9037E/OfficeLangPack2013_JA_x86.exe
officelr.cab

HGRGE.TTC_1041
HGRGM.TTC_1041
HGRGY.TTC_1041
HGRKK.TTC_1041
HGRMB.TTC_1041
HGRME.TTC_1041
HGRPP1.TTC_1041
HGRPRE.TTC_1041
HGRSGU.TTC_1041
HGRSKP.TTF_1041
HGRSMP.TTF_1041

shasum -a 256 OfficeLangPack2013_JA_x86.exe
59c1bf9b00f14120fe66582353893a26a16724ee6b73a4e5b3d7a0eafb1eb163  OfficeLangPack2013_JA_x86.exe

source: gharchive/issue

repo: fontist/fontist

license_type: permissive

license_source: github-api


text:
macOS install

See #275

@alexeymorozov this is ready to go? Thanks!

source: gharchive/pull-request

authors: alexeymorozov ronaldtse


text:
Typescript

Study and start using TypeScript and convert js files to ts files

Critical part of the operation is okay, and it's running without any issues.

All js files in ngClient were converted to ts, except appSettings.js
Debugging (sourcemaps), bundling, minification (gulp tasks) are okay

Quick to do:

jasmine tests will be converted and updated
Types are not there in most cases (using "any)
Some entities are using typescript classes, but some couldn't be converted:
The problem is breeze don't allow to navigation properties be defined in entity constructors, and typescript can't use undefined properties?
breeze.d.ts had to be updated - one signature was not correct
There is no _all.ts file at the moment, is it necessary?
There are no d.ts files are our own ts files, is it necessary?
angular registrations (controllers, factories etc.), should it be inside or outside of their module? What is the difference?
Study tsconfig options
Study tsd and typings - If it works properly, add d.ts files into gitignore

repo: forCrowd/WealthEconomy

license: mit

license_source: bigquery


text:
generate CMDT records shows "Cannot find module 'bluebird'"

Summary
Try to create records in a CMDT object with the command: sf cmdt generate records --csv years.csv --type-name Year__mdt
Steps To Reproduce:
Repository to reproduce: dreamhouse-lwc
NOTE: If your issue is not reproducable by dreamhouse-lwc, i.e. requires specific metadata or files, we require a link to a simple Salesforce project repository with a script to setup a scratch org that reproduces your problem.

Create a custom metadata type object
Create a csv file with one column header Name
Follow help article command: https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_cmdt_commands_unified.htm#cli_reference_cmdt_generate_record_unified

Expected result
Creation of year values in a metadata type object named Year__mdt
Actual result
Error message
ModuleLoadError: [MODULE_NOT_FOUND] require failed to load
@salesforce\plugin-custom-metadata\lib\commands\cmdt\generate\records.js: Cannot find module 'bluebird'
System Information
powershell
{
"cliVersion": "@salesforce/cli/1.73.0",
"architecture": "win32-x86",
"nodeVersion": "node-v18.15.0",
"osVersion": "Windows_NT 10.0.22621",
"shell": "cmd.exe",
"rootPath": "C:\Users\just2\AppData\Local\sfdx\client\7.196.6-a969651\sf",
"pluginVersions": [
"@oclif/plugin-autocomplete 2.1.8 (core)",
"@oclif/plugin-commands 2.2.13 (core)",
"@oclif/plugin-help 5.2.9 (core)",
"@oclif/plugin-not-found 2.3.23 (core)",
"@oclif/plugin-plugins 2.4.4 (core)",
"@oclif/plugin-search 0.0.15 (core)",
"@oclif/plugin-update 3.1.9 (core)",
"@oclif/plugin-version 1.3.2 (core)",
"@oclif/plugin-warn-if-update-available 2.0.33 (core)",
"@oclif/plugin-which 2.2.18 (core)",
"@salesforce/cli 1.73.0 (core)",
"apex 2.2.9 (core)",
"auth 2.7.11 (core)",
"custom-metadata 2.1.11 (user)",
"data 2.3.9 (core)",
"deploy-retrieve 1.8.8 (core)",
"info 2.6.4 (core)",
"limits 2.3.12 (core)",
"login 1.2.5 (core)",
"org 2.6.5 (core)",
"schema 2.3.6 (core)",
"settings 1.4.3 (core)",
"sobject 0.1.14 (core)",
"source 2.9.1 (core)",
"telemetry 2.1.3 (core)",
"templates 55.4.5 (core)",
"trust 2.4.6 (core)",
"user 2.3.7 (core)"
]
}

Hey @honestmondayJS 👋
this sounds like a bug with our just-in-time installation code...
can you try using sfdx which ships with this plugin by default?

authors: WillieRuemmele honestmondayJS

repo: forcedotcom/cli


text:
Internal Salesforce Error on System.runAs() Apex Tests

Summary
We have been using Scratch Orgs for testing as part of our automated deployment, but have encountered a recurring Internal Salesforce error when running our Apex Tests:
TestClass.ExampleTest                                                                                Fail     Internal Salesforce Error: 490571133-56370 (-1492806191) (-1492806191)

We have narrowed down the error to two specific tests that both use System.runAs() to test permissions. If we run the tests a second time, everything passes as expected. It appears that the first time a System.runAs() command is run on a Scratch Org, it throws an Internal Salesforce Error, but subsequent uses work as expected.
Our current workaround is to run the tests twice during our build process, ignoring the first result set that causes the error. However, this is suboptimal and we would like to find a better solution.
Steps To Reproduce
# Install Salesforce CLI version 2.0.2
npm install --global @salesforce/cli@2.0.2
sf --version

# Auth into Dev Hub
sf org login sfdx-url -f sfdx_auth -d -a org-shape-dev-hub

# Create Scratch Org and deploy metadata
sf org create scratch --duration-days=1 -f project-scratch-def.json --alias=dep-test-scratch-org --set-default --no-track-source --wait 10 --json
sf project deploy start -d force-app

# Run tests (human readable for debugging)
sf apex run test -r human --code-coverage --wait 5

Expected result
The tests should pass.
Actual result
TestClass.ExampleTest                                                                                Fail     Internal Salesforce Error: 490571133-56370 (-1492806191) (-1492806191)

System Information
{
  "cliVersion": "@salesforce/cli/2.0.2",
  "architecture": "wsl-x64",
  "nodeVersion": "node-v18.0.0",
  "osVersion": "Linux 5.15.90.1-microsoft-standard-WSL2",
  "shell": "zsh",
  "rootPath": "/home/mbotha/.nvm/versions/node/v18.0.0/lib/node_modules/@salesforce/cli",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.1 (core)",
    "@oclif/plugin-commands 2.2.17 (core)",
    "@oclif/plugin-help 5.2.11 (core)",
    "@oclif/plugin-not-found 2.3.26 (core)",
    "@oclif/plugin-plugins 3.1.6 (core)",
    "@oclif/plugin-search 0.0.18 (core)",
    "@oclif/plugin-update 3.1.22 (core)",
    "@oclif/plugin-version 1.3.6 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.41 (core)",
    "@oclif/plugin-which 2.2.22 (core)",
    "@salesforce/cli 2.0.2 (core)",
    "apex 2.3.4 (core)",
    "auth 2.8.4 (core)",
    "data 2.4.5 (core)",
    "deploy-retrieve 1.13.5 (core)",
    "info 2.6.25 (core)",
    "limits 2.3.23 (core)",
    "login 1.2.15 (core)",
    "org 2.9.19 (core)",
    "schema 2.3.17 (core)",
    "settings 1.4.17 (core)",
    "sobject 0.1.32 (core)",
    "source 2.10.22 (core)",
    "telemetry 2.2.1 (core)",
    "templates 55.5.2 (core)",
    "trust 2.4.27 (core)",
    "user 2.3.20 (core)"
  ]
}

Additional information
Example from one of our AWS CodeBuild deployments showing the error:

@MatthewBotha it's a good repro.  I'll pass it along to the Apex team, but as always, Support Cases help with prioritization and give that team an easier way to collaborate.

For what it's worth, we are having this problem also. Which is unfortunate because we are trying to ensure security on our external community sites and need to be able to run automated tests as a user of that site and make sure that they don't have access to more data than they need for compliance reasons. I found the link to this post via a search, but haven't found any other links on the salesforce site or anywhere else yet, so if somebody does open a case and salesforce posts the known issue can someone please post a link to that? Thanks

authors: MRASoft MatthewBotha mshanemc


text:
Source Tracking recognises a deleted Global Action (QuickAction) as QuickActionDefinition and fails retrieving the change

Summary
When deleting a Global Action in a source tracked org, SourceMember.MemberType is incorrectly reported as QuickActionDefinition instead of QuickAction.
sf project retrieve does not do anything because the Metadata Registry does not know this Metadata Type.
$ sf project retrieve preview
Warning: Unable to find type QuickActionDefinition in registry
...

Steps To Reproduce
I created a Minimum Reproduction Example using GitHub Actions:
https://github.com/mdapi-issues/mre-incorrect-source-member-type-quickactiondefinition
Expected result
It should retrieve the change and delete the QuickAction locally.
Actual result
It does not delete the remotely deleted Global Action.
System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.36.8",
  "nodeVersion": "node-v20.10.0",
  "osVersion": "Darwin 23.4.0",
  "rootPath": "/Users/john.doe/.config/yarn/global/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.0.13 (core)",
    "@oclif/plugin-commands 3.2.2 (core)",
    "@oclif/plugin-help 6.0.20 (core)",
    "@oclif/plugin-not-found 3.1.1 (core)",
    "@oclif/plugin-plugins 5.0.5 (core)",
    "@oclif/plugin-search 1.0.20 (core)",
    "@oclif/plugin-update 4.2.3 (core)",
    "@oclif/plugin-version 2.0.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.15 (core)",
    "@oclif/plugin-which 3.1.7 (core)",
    "@salesforce/cli 2.36.8 (core)",
    "apex 3.1.3 (core)",
    "auth 3.5.1 (core)",
    "data 3.2.4 (core)",
    "deploy-retrieve 3.5.3 (core)",
    "info 3.1.2 (core)",
    "limits 3.2.1 (core)",
    "marketplace 1.1.0 (core)",
    "org 3.6.3 (core)",
    "packaging 2.3.0 (core)",
    "schema 3.2.0 (core)",
    "settings 2.1.2 (core)",
    "sobject 1.2.1 (core)",
    "source 3.2.2 (core)",
    "telemetry 3.1.17 (core)",
    "templates 56.1.0 (core)",
    "trust 3.5.1 (core)",
    "user 3.4.3 (core)"
  ]
}

Additional information
https://github.com/mdapi-issues/mre-incorrect-source-member-type-quickactiondefinition/assets/789765/357d0b69-a8be-439a-8a6f-b2ae1209688e

once again @amtrack, thanks for the great repro, and self investigation results!

This issue is addressed in version 2.44.8 (Jun 5, 2024).

authors: WillieRuemmele amtrack jshackell-sfdc


text:
sfdx force:source:convert for Custom Label in package.xml is not working

Summary
I am trying to convert source format metadata to mdapi format and using the below command and getting the error.
sfdx force:source:convert -x ./manifest/package.xml -d ./metadataPackage
Steps To Reproduce:

Authorize devhub org in VSCode
Create a Custom Label in the org from UI
Create a project in VScode and set the default org as above authorized org.
Try to use the below command to convert the source format of Custom Label to MDApi format.

package.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <types>
        <members>*</members>
        <name>CustomLabel</name>
    </types>
    <version>49.0</version>
</Package>

Command used to convert:
sfdx force:source:convert -x ./manifest/package.xml -d ./metadataPackage
Expected result
The custom Label should be converted to mdapi format and we should see a folder name with metadataPackage inside the project folder
Actual result
Getting an error stating ERROR running force:source:convert:  The package root directory is empty.
Additional information

SFDX CLI Version
sfdx-cli/7.75.1-5585088c75 win32-x64 node-v12.18.3
SFDX plugin Version
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/analytics 0.22.0
@salesforce/sfdx-scanner 2.3.0
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.2 (core)
analytics 1.12.1 (core)
config 1.1.8 (core)
generator 1.1.3 (core)
salesforcedx 50.0.13 (pre-release)
├─ custom-metadata 1.0.10
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7
├─ salesforcedx-templates 49.5.0
├─ salesforce-alm 50.0.13
└─ apex 0.1.0
sfdx-cli 7.75.1 (core)

OS and version:
Microsoft Windows 10 Enterprise

This is now fixed with CLI v7.76.1 and salesforcedx plugin v50.1.1

I closed this by mistake.  This has not yet been fixed.

I added a partial fix for custom labels in the current release candidate. Can you try installing that to see if it unblocks you?
sfdx plugins:install salesforcedx@latest-rc
It's a partial fix because it converts/deploys all custom labels in the project versus just the labels defined in the manifest. Converting/deploying specific labels is coming soon.  I will keep this open until that fix is in the release.

Thank you @shetzel for the fix. Unfortunately, I am still not able to convert them.

C:\Users\Desktop\customLabel>sfdx plugins --core
@oclif/plugin-autocomplete 0.1.5 (core)
@oclif/plugin-commands 1.3.0 (core)
@oclif/plugin-help 3.2.0 (core)
@oclif/plugin-not-found 1.2.4 (core)
@oclif/plugin-plugins 1.9.1 (core)
@oclif/plugin-update 1.3.10 (core)
@oclif/plugin-warn-if-update-available 1.7.0 (core)
@oclif/plugin-which 1.0.3 (core)
@salesforce/analytics 0.22.0
@salesforce/sfdx-scanner 2.3.0
@salesforce/sfdx-trust 3.4.3 (core)
alias 1.1.2 (core)
analytics 1.12.1 (core)
auth 1.3.0 (core)
config 1.1.9 (core)
generator 1.1.3 (core)
salesforcedx 50.3.1 (latest-rc)
├─ templates 50.1.0
├─ custom-metadata 1.0.10
├─ @salesforce/sfdx-plugin-lwc-test 0.1.7
├─ salesforce-alm 50.3.1
└─ apex 0.1.2
sfdx-cli 7.77.0 (core)
sfdx-mohanc-plugins 0.0.73
shane-sfdx-plugins 4.41.2
├─ @mshanemc/plugin-streaming 1.1.7
└─ @mshanemc/sfdx-sosl 1.1.0
C:\Users\Desktop\customLabel>sfdx force:source:convert -x ./manifest/package.xml -d ./metadataPackage
ERROR running force:source:convert:  The package root directory is empty.
But Using this below command worked
C:\Users\Desktop\customLabel>sfdx force:source:convert -m CustomLabel -d convertedLabel
Source was successfully converted to Metadata API format and written to the location: C:\Users\Desktop\customLabel\convertedLabel
Thanks.

@saicharanreddyk - what is the content of your manifest?  Is the path correct?

@shetzel
manifest.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata">     <types>         <members>*</members>         <name>CustomLabel</name>     </types>     <version>50.0</version> </Package>
Project folder CustomLabels
package.xml is under ==> CustomLabels/manifest/package.xml
I am not sure what has changed but it started working now. I haven't changed any structure / package.xml / command to execute. All remain the same.

authors: saicharanreddyk shetzel


text:
api versions are outdated in package templates

The versions used in quickstart config store templates have outdated API versions and the version as far as I can tell doesn't get overwrriten when using template to create the actual package.xml file.  I believe version should be a part of the 'template' and get overriden with the value specified in devhub config.

@W-11934133

Hi @mkosak-sf I believe this issue was resolved with this PR: https://github.com/forcedotcom/commerce-on-lightning/pull/130 so I will be closing this issue

authors: joeluong-sfcc mkosak-sf trinasfdx

repo: forcedotcom/commerce-on-lightning


text:
Release parameterized 1.0.1

There are no changes except for a dependency update, and an MSRV increase from 1.36 to 1.38

bors r+

repo: foresterre/parameterized


text:
Next js implementation

Current Behavior
Builds new repo
Desired Behavior
Just adds the tsconfig and eslint files along with installing the correct packages without any of the build steps at that will be handled by nextjs
Suggested Solution
Just create the config files and install packages without the rest of the folders and files
Who does this impact? Who is this for?
Anyone using typescript and nextjs
Describe alternatives you've considered
I've currently done this by creating a tsdx folder running the create command then working out the full eslint files used and creating them in my nextjs repo
Additional context

Next.js has support for typescript, if you change the extension of any file to .tsx then run yarn dev it will prompt you to install typescript and then generate a tsconfig.json file for you.

authors: The-Code-Monkey giraffesyo

repo: formium/tsdx

license: MIT


text:
Adds require_one rule validation

Adds require_one validation rule with testing and locale message translations.
Issue: https://github.com/formkit/formkit/issues/546
Supporting documentation pull request can be found here

@devoidofgenius thanks! Can you do a pnpm install and resubmit (should just update your lockfile)

authors: devoidofgenius justin-schroeder

repo: formkit/formkit


text:
buildForm produces side effects on dynamically constructed fields

[x] bug report

Having a FieldArrayType implementation, when pressing remove(), buildForm() rebuilds other fields, which can have side effects.
As remove() changes the model, which has to be addressed in other fields the behaviour is correct in my eyes.
However I have an implementation, which populates select options dynamically, these get lost, when another field's remove() is called and buildForm() repopulates this field, giving the implementation not the chance to act on the new repopulation.
https://stackblitz.com/edit/angular-bh6dx1?file=src%2Fapp%2Frepeat-section.type.ts
The example has two repeating fields, the first repeating field has a column with a select, for which the options are populated dynamically. Press the remove button of one of the rows of the second repeating field. The first repeating field select options are empty.
Please read the comments in the source also.
Version: 5.0.0-beta.1

already fixed I think by #1110, to be checked!

Thanks for the quick fix. I will check as soon as your release a new version.
Or is there another way to test it (git cloning, going to samples and adapt one). I tried once, but it didn't work somehow, missing dependencies, etc. Are the libraries in samples taken relative or from npm?
Please explain how such testing can be accomplished.

tested on my side, it appear that is partially fixed but still there an issue which related to the select type
to test it locally:
git clone git@github.com:formly-js/ngx-formly.git
cd ngx-formly
npm install
npm run start

the remaining issue can be solved by yourself by adding this.change() after remove call similar to add:
  remove(i: number) {
     ...
    this.change();
  }

Tested your fix locally and is fine. thx.

authors: FritzHerbers aitboudad

repo: formly-js/ngx-formly


text:
Migrate Terraform Forseti Install to Forseti-Security github org

Migrate the Terraform Forseti Install from: https://github.com/terraform-google-modules/terraform-google-forseti to new repo in Forseti-Security org.

@morgante Added this issue based on our discussions related to moving forseti terraform repo.

This issue has been resolved by moving the terraform-google-forseti repo into the Forseti Security organization: https://github.com/forseti-security/terraform-google-forseti

authors: dekuhn hshin-g

repo: forseti-security/forseti-security


text:
update to bindgen 0.51.0

This patch lets us compile mbedtls-sys with recent clang versions.
It still has a hack calling "sed" in it, which fixes some of the enum
generated names, but it is a good starting point.

Got rid of the sed

LGTM. @jethrogb ?

@jack-fortanix  @jethrogb
friendly ping

Final PR: #152

authors: haraldh jack-fortanix jethrogb

repo: fortanix/rust-mbedtls


text:
Add QUADPACK to fpm registry

I actually would be willing to do all of the work here but am not sure where to start.
AFAICT the original source has been converted to Fortran 90 by John Burkardt (single and double precision). The big concerns then are (A) LICENSE, this is the biggest (B) build tooling e.g. Make or CMake, not sure what fpm prefers (C) documentation.

QUADPACK was included in SLATEC and is thereby in public domain (at least in the USA). See this comment from the Scipy repository. The website from Leuven University also mentions QUADPACK is included in Octave and that C translations are available in GSL. So open source usage seems to be permitted.
The version of QUADPACK included in SciPy has some fixes, like replacing calls to linpack routines with their respective lapack equivalents. Personally, I would prefer to use the Scipy version over those of Burkardt. The Intel Fortran compiler could be used to automatically generate the missing interfaces, and leave the source as F77 code. The automatically generated interfaces could then be manually compared to the documentation and published listings to get the intent attributes correct.
Concerning build tools, the idea of the fpm registry is to collect fpm compatible packages. The best approach is to allow fpm to do the building, no make or cmake is required. One hurdle will be how to provide both single and double precision versions.
Currently, fpm offers no tools to automate documentation. Most fortran-lang projects are using FORD and GitHub actions to automate the site generation. Personally, I find FORD to a bit quirky. For the QUADPACK documentation it might be possible to extract the comments from the source files (either the SciPy or SLATEC versions) using a Python/Perl script and generate restructured text for some other documentation website generator (Sphinx, MkDocs, ...).

We could consider using the quadpack from SciPy. That way we are fine with the license, we'll have the fixes and it can also be useful from the point of view of SciPy and other such libraries to eventually use the quadpack fpm package.
Also, I would recommend to maintain this under the fortran-lang github organization. Many of the issues facing here are identical to fftpack: #40, see the discussion there.
Let's figure out a good approach to these things.

RE: SciPy source, the files in https://github.com/scipy/scipy/tree/v1.6.3/scipy/integrate/quadpack are all Fortran 77. The merits of the Burkardt code is that it is in Fortan 90, making it accessible to a wider set of compilers (e.g. lfortran). I am very open here on where the source comes from and I would say NOT very educated on historical forks since the original QUADPACK in 1981, just trying to see if there is something stable AND quasi-modern.

Good point. The only reason I suggested SciPy is that I know they maintain it and fix bugs and the code should be correct and working. If we use some older unmaintained version, it might have bugs. Aren't there tools to convert fixed form to free form? We could start with the SciPy version, convert to free form, add to modules, etc.
P.S. LFortran will eventually have a parser for fixed form also (https://gitlab.com/lfortran/lfortran/-/issues/82).

I added a couple of formatters to the package index a while ago.
I made good experience with findent, which is primary targeted to parse legacy Fortran and handle dozens of non-standard extensions (packaged on conda-forge here). Camfort and fortran-src also have legacy Fortran parsers and there is fpt from the last monthly call.
So plenty of tools for the job out there, but most important is to have tests to verify the converted code against the original one.

Good point. The only reason I suggested SciPy is that I know they maintain it and fix bugs and the code should be correct and working. If we use some older unmaintained version, it might have bugs.

Not sure if we can call it maintenance. The code has been untouched for the last 3 years and there are some open bug tickets however, only one seems to be an actual numerical issue, the rest look like compiler and build setup issues.
The SciPy version of QUADPACK would also benefit from some refactoring (see https://github.com/scipy/scipy/issues/4455, great issue title!). The QUADPACK routines make use of the following three machine constants:

machine epsilon (d1mach(4))
the largest non-overflowing positive real number (d1mach(2))
the smallest non-underflowing positive real number (d1mach(1))

which are currently retrieved using the d1mach() function (a description can be found in the  SLATEC documentation or BLAS faqs). The version used in SciPy looks like it is taken from Netlib, but from some third package (not SLATEC or QUADPACK). In the meantime (30 years ago...) Fortran 90 added intrinsic functions to retrieve these constants directly using intrinsic functions. I am aware of a few different refactored versions of d1mach:

https://github.com/certik/fortran-utils/blob/master/src/legacy/amos/d1mach.f90
http://computer-programming-forum.com/49-fortran/9d39e9771b0d8e20.htm
https://people.sc.fsu.edu/~jburkardt/f_src/machine/machine.html
one more approach is to put them directly in an array of size 5 (@jacobwilliams perhaps?)

Interestingly, the version SciPy is using even contains a commented out C implementation:
 C implementation
```
 /* Standard C source for D1MACH -- remove the * in column 1 */
#include
#include
#include
double d1mach_(long *i)
{
	switch(*i){
	  case 1: return DBL_MIN;
	  case 2: return DBL_MAX;
	  case 3: return DBL_EPSILON/FLT_RADIX;
	  case 4: return DBL_EPSILON;
	  case 5: return log10((double)FLT_RADIX);
	  }
	fprintf(stderr, "invalid argument: d1mach(%ld)\n", *i);
	exit(1); return 0; /* some compilers demand return values */
}
```

Note that Carlos @brocolis already has an fpm package for the original quadpack here which also includes an f90 interface module.

Note that Carlos @brocolis already has an fpm package for the original quadpack here which also includes an f90 interface module.

That's exactly what I had in mind! @brocolis would you be interested in moving the package under fortran-lang so that we can maintain it as a community?

Yes. Someone with appropriate permissions could move it to fortran-lang.

My original plan was to write an higher level function quad on top of QUADPACK, but since I read the GNU Octave implementation for quad, I believe I cannot re-implement it myself under a different license. However, I would be happy to transfer the repository to fortran-lang as it is now.

The scipy.integrate.quad has a very similar interface to the Octave quad. The SciPy version is under a BSD-3 license.
But I would suggest we do it jointly under the fortran-lang repository.

However, I would be happy to transfer the repository to fortran-lang as it is now.

I think if you follow the instructions on transferring repositories you could transfer to @milancurcic, and he could put it under the fortran-lang organization.
The other option would be to simply clone the repository, and push it into a new fortran-lang repository (not forking it).

Repository transfers can currently only be handled by @certik, @milancurcic and @LKedward, either by temporarily raising member privileges or by a two step transfer. I don't think we have yet established a workflow for this process.

@LKedward, @milancurcic I would be interested in your feedback on maintaining this under fortran-lang.

@LKedward, @milancurcic I would be interested in your feedback on maintaining this under fortran-lang.

I have no fundamental objections to moving this and other legacy packages to fortran-lang as long as we have one or more persons identified to spearhead the initial modernisation and maintenance required to bring the packages up to standard. (Which it looks like we do here!) In particular, we should strive to maintain a high quality of packages maintained under fortran-lang which I will clarify by quoting from our extra 'recommend criteria' in the package index guidance:

Documentation: any form of written documentation aimed at users of the package. Ideally this should cover:

Supported / tested compilers, dependencies, build and install process, modules contained within the package, procedures made available and their interfaces, example code

Contributing: details on how users may submit issues and contribute to the development of the package
Tests: any form of executable test(s) that can be used to verify the functionality of the package
Portability: no non-standard language extensions or proprietary dependencies
fpm: support installation by the Fortran Package Manager fpm

I am not a user of QUADPACK, but I have experimented with it. In the
various versions I have (one from Netlib and one by John Burkhardt) I see
no regular test programs, like you find with LAPACK, but it might be a nice
community project to set up a comprehensive set of such programs. Within
the framework of fpm we can make them available. And perhaps en passant
provide modern interfaces.
Op do 27 mei 2021 om 15:41 schreef Sebastian Ehlert <
@.***>:

Do we know of any users of QUADPACK, who are interested in devendoring
their version in favor of a @fortran-lang
https://github.com/fortran-lang one? Is anyone involved in this thread
using QUADPACK in a production code and willing to offer their code base
for testing?
I'm also wondering about the QUADPACK license, is it public domain since
it is part of SLATEC? How would we handle and license contributions to this
project?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/fortran-lang/fpm-registry/issues/43#issuecomment-849644531,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN6YR5BQVL3LCLOZZSJDKLTPZDX3ANCNFSM446N37RQ
.

Is anyone involved in this thread using QUADPACK in a production code and willing to offer their code base for testing?

Well there are the possibly thousands of users using it via SciPy and Octave. Also the NAG quadrature routines are based upon QUADPACK. Also the IMSL library seems to be based off QUADPACK. Several papers discussing QUADPACK (with some tests) can also be found in

Keast, P., & Fairweather, G. (Eds.). (1987). Numerical integration: recent developments, software and applications. https://doi.org/10.1007/978-94-009-3889-2

SciPy has a set of tests for QUADPACK that can be adapted: test_quadpack.py.
The QUADPACK book (https://link.springer.com/book/10.1007%2F978-3-642-61786-7) contains error plots of 17 test integrals. There are also 10 demonstration programs. I would suggest to add these as the original tests.

SciPy is the most obvious one. Yes, some of the SciPy maintainers are open to the idea of using fortran-lang's version, but of course it would depend on the details. I have not seen any objections like "absolutely not". So that means we should do our best, and if we do, there is a good chance of SciPy using it, one way or another.

I must say the book by Keast en Fairweather is a bit expensive (200 euros
for the e-book version). The other one a bit less so.
By looking at the WIkipedia page I found an update of two of the automatic
integrators in QUADPACK, namely QAG and QAGS, as well as an integrator for
multidimensional functions (TOMS algorithms 691 and 824).
Should there be interest, I also have the implementaton of quadrature
(cubature) formulae by Stroud - a vast collection of routines.
Op do 27 mei 2021 om 17:32 schreef Ivan Pribec @.***>:

Is anyone involved in this thread using QUADPACK in a production code and
willing to offer their code base for testing?
Well there are the possibly thousands of users using it via SciPy and
Octave. Also the NAG quadrature
https://www.nag.com/numeric/cl/nagdoc_latest/html/d01/d01conts.html
routines are based upon QUADPACK. Also the IMSL library
http://envi.geoscene.cn/help/Subsystems/idl/Content/Reference Material/Functional List of IDL Routines/IMSLRoutinesQuadrature.htm
seems to be based off QUADPACK. Several papers discussing QUADPACK (with
some tests) can also be found in
Keast, P., & Fairweather, G. (Eds.). (1987). Numerical integration: recent
developments, software and applications.
https://doi.org/10.1007/978-94-009-3889-2
SciPy has a set of tests for QUADPACK that can be adapted:
test_quadpack.py
https://github.com/scipy/scipy/blob/4ec4ab8d6ccc1cdb34b84fdcb66fde2cc0210dbf/scipy/integrate/tests/test_quadpack.py
.
The QUADPACK book (
https://link.springer.com/book/10.1007%2F978-3-642-61786-7) contains
error plots of 17 test integrals. There are also 10 demonstration programs.
I would suggest to add these as the original tests.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/fortran-lang/fpm-registry/issues/43#issuecomment-849731558,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN6YR7WH6HGC54LW3UI5Q3TPZQYHANCNFSM446N37RQ
.

So the next step, as @LKedward said, is to find a person who would be willing to take the lead on this. @dhermes and @brocolis, would you have time for that? The aim should be to maintaining this as a community, under fortran-lang. But it's good if at least initially there is one or two people who push the community to get it done, i.e., takes the lead on this.
One possible path forward is:

Take the repository https://github.com/brocolis/quadpack by @brocolis.
Figure out the license situation. If in doubt, we might want to just take the version from SciPy, which is under BSD license.
Move it under fortran-lang.
Improve the tests, per @ivan-pi's pointers
Improve documentation
Apply any fixes

What should be the long term goal? Should we include integration routines that we develop, such as by @arjenmarkus as indicated above? I would suggest to define what the long term objective is. I feel we should probably just "maintain it", i.e. ensure it compiles without warnings, fix any bugs if they are discovered, and maintain modern Fortran and C API to it. But other than that, I think new algorithms should go into a new/separate fpm package. What do you think?

I would highly recommend not moving F77 code to fortran-lang. Or wrapping F77 with a modern interface. I think that is a bad idea. We need to modernize the code to show what can be done with modern Fortran. There is a lot of room for improvement in quadpack. We don't want to be stuck with the old F77 code like some sort of new netlib. Convert it to free-form and then go from there.

I think we should discuss this at the next Fortran call.
@jacobwilliams I think we all agree that we want modern Fortran implementations of these basic algorithms, whether as standalone packages and/or part of stdlib. Many of such packages could be maintained under fortran-lang also.
The main problem that we are trying to solve in this thread is that codes depend on these old packages (fftpack, odepack, minpack, quadpack, ...) so having a maintained version helps.
The question is whether the modernized version should be part of the same package, replacing the old code (I think that is what you are suggesting?), or a separate package.
I think as long as performance and the API can be kept exactly the same, it is fine to be part of the same package. If the API changes, then I think it should probably be a separate package.
As another example, I took fftpack and modernized it here:
https://github.com/certik/hfsolver/blob/b4c50c1979fb7e468b1852b144ba756f5a51788d/src/fourier.f90#L201
Things to keep in mind when modernizing:

performance: did it get slower? To answer it, I think we want to have the original package, easy to install, to compare against
accuracy: is it as accurate?
API: is the new API easier to use?

I have benchmarked my new "modern Fortran" fft implementation, and on the one benchmark I used (about million element 1D fft), it was about the same. But later I realized that for smaller fft, such as 128 (which is used for 3D 128^3, very common in electronic structure calculations), it might be slower. Based on my experience, I think it is actually really hard to ensure the new code is as fast.
For all these reasons, I think it would be valuable to "conserve" or "preserve" these old libraries, and only do changes that keep performance, accuracy and API. Moving to fixed form is fine I think. Keeping the performance is tough, for that we need good benchmarks, or not change the code significantly. Keeping the API is simple (we just need tests), but that does not allow to modernize the API.

I must say the book by Keast en Fairweather is a bit expensive (200 euros for the e-book version). The other one a bit less so.

For the time-being, I have access to digital versions of both books through a university subscription. I am happy to extract the tests from the books.
One problem with modifying the API is that old codes that already use QUADPACK will require refactoring to use our "maintained" version. I think this is not constructive. Any older codes should continue to work, with the minor exception that we ask programmers to add a use quadpack, only: ... statement.
My personal goals for the modernization would include:

Provide an interface module (already done by @brocolis)
Provide the missing tests, build tools, and online documentation
Refactor the original sources to free form, removing any obsolescent language constructs, and following any modern computational/software practices.

Performing step 3 after adding tests, helps guarantee accuracy and performance are preserved. The results and timings of the tests, should be preserved as build artefacts.
Only after these steps are complete would I be in favor of adding new routines with simplified API's (through use of optional arguments, or derived types).

@Ivan Pribec @.***> I agree with your list of goals. And
to prevent lots of work on old code, we might provide an old-style
interface to the modern version of QUADPACK or any other venerable package.
Op do 27 mei 2021 om 23:59 schreef Ivan Pribec @.***>:

I must say the book by Keast en Fairweather is a bit expensive (200 euros
for the e-book version). The other one a bit less so.
For the time-being, I have access to digital versions of both books
through a university subscription. I am happy to extract the tests from the
books.
One problem with modifying the API is that old codes that already use
QUADPACK will require refactoring to use our "maintained" version. I think
this is not constructive. Any older codes should continue to work, with the
minor exception that we ask programmers to add a use quadpack, only: ...
statement.
My personal goals for the modernization would include:

Provide an interface module (already done by @brocolis
https://github.com/brocolis)
Provide the missing tests, build tools, and online documentation
Refactor the original sources to free form, removing any
obsolescent language constructs, and following any modern
computational/software practices.

Performing step 3 after adding tests, helps guarantee accuracy and
performance are preserved. The results and timings of the tests, should be
preserved as build artefacts.
Only after these steps are complete would I be in favor of adding new
routines with simplified API's (through use of optional arguments, or
derived types).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fortran-lang/fpm-registry/issues/43#issuecomment-849969361,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN6YRZLGHWNU7DTFS2HSPLTP26CJANCNFSM446N37RQ
.

We need to modernize the API. We can't hold up something that requires you to stuff your problem data into iwork and rwork arrays as any kind of modern way to write code. This does great damage to Fortran anytime anyone sees code like this. It's just a fact. If somebody wants to use the old F77 code and never wants to change anything, that's fine, but those people should not be holding back progress (they have held back progress for decades now... it's time to move on). Make a modernized version, and let people see that it is better and they should use it, and if somebody is still using the old one they have an incentive to use the new one because it is better.

@jacobwilliams, we all agree that we want to use modern API to these legacy libraries. That is not a question.
The question is how to get there. You said not to move the "F77 code to fortran-lang." You also suggested to rather work on a modern Fortran replacement, a "modernized version", and it is my understanding that you do not want to use the legacy code at all, but rewrite from scratch?
I think from a practical perspective, I want to have these legacy libraries maintained, because people use them. And I would like to be able to use them at least for performance and accuracy comparison against a "modernized version" that you propose.
To conclude, are you against the plan here: https://github.com/fortran-lang/fpm-registry/issues/43#issuecomment-849969361 ?
That plan still allows to have a separate library, written from scratch, in modern Fortran.

If the association of @fortran-lang with the legacy QUADPACK is a blocking issue here, than I might have a suggestion to move this forward. https://github.com/quadpack is currently free, I suggest we claim the @quadpack namespace by creating a new open-source organization and move the legacy version there. This allows to cooperatively develop the QUADPACK under a neutral namespace and once we have reached a point were we want to associate our quadpack-ng with @fortran-lang we can move it here.
I personally use this strategy a lot for my projects, once they mature I tend to move them into separate organization (see @toml-f or @dftd4), since it allows me to separate the stable version from my development branches in a fork and also gives a nice namespace to include additional example packages as well.

I absolutely support using the legacy code. There's no need to rewrite it from scratch. All I was warning against was being locked into the old api or coding style forever just to make sure that it could be used by somebody who refuses to make even the smallest modifications to their code to use it.
Consider how I made a modernized version of some these spline interpolation routines: https://github.com/jacobwilliams/bspline-fortran
At its core, are routines from CMLIB and SLATEC. I didn't have to rewrite them from scratch, but they have been changed. I had to change them in order to make the interfaces more modern, allow them to be reentrant, add features that weren't present in the original code, etc. At no point did I worry about keeping the old interface. Note that there are even two interfaces, an object oriented one (that I use), but also a subroutine one that is closer (but not identical) to the old interfaces.
So like all these sorts of codes my advice is:

convert fixed to free form.
put them in a module or modules
remove obsolete features: goto, common, data, iwork(), rwork(), etc.

Then you can start expanding beyond what the old codes had (maybe adding new algorithms, maybe an object-oriented interface if it makes sense, etc.)

@jacobwilliams perfect! I think the actual plan you just wrote is identical to https://github.com/fortran-lang/fpm-registry/issues/43#issuecomment-849969361, isn't it?
The only technical issue left is "put them in a module or modules", which I would very much prefer, but I don't know if this can cause issues in existing codes like SciPy. But we can help them move over to modules.
@jacobwilliams would you be against moving quadpack under fortran-lang, and we would do this work there?
What @awvwgk suggested above (quadpack organization) also works, but remember that there are tons of other libraries in the same category (fftpack, minpack, odepack, etc.), so we could create fortran-lang-legacy organization and put it there, but we might as well just put it under fortran-lang.

I'm all for it! As long as the goal is to modernize, and not keep them frozen in amber like they are in netlib. :)
Definitely think getting SciPy used to modern fortran should also be a major goal! It is inevitable that they are going to get rid of all that Fortran 77 code that nobody wants to work on. The only question is can we offer up modern alternatives, or are they going to replace it with C/C++. I hope it will be the former.
I would also suggest avoiding the term "legacy"... Is the intent to have a namespace to work on projects that are big libraries that are outside of stdlib? I guess I'm not sure where to draw the line of separate libs vs adding them to stdlib.

Good point. I would like to "rejuvenate" these libraries, so they are no more "legacy". Thus fortran-lang.
Regarding stdlib or not --- these libraries are well established, so should live outside. As we modernize them or even do a rewrite as a separate library, we can also think how it should be included in stdlib. I don't know yet if stdlib has to be strictly without dependencies, or if it can have dependencies (in which case just depending on these libraries must be a way).

I think as fpm becomes ubiquitous, it won't even matter so much where a library comes from, it will "just work"!

How about using a name like "fortran-lang-numerics" for these libraries (at
least I recognise that as a common theme)? We should indeed avoid "legacy",
as that seems synonymous to "old", "ancient", "deprecated",
"to-be-avoided-at-all-cost-but-the-cost-is-currently-too-high-to-indeed-do-so".
Op ma 31 mei 2021 om 22:20 schreef Jacob Williams @.***

:

I think as fpm becomes ubiquitous, it won't even matter so much where a
library comes from, it will "just work"!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fortran-lang/fpm-registry/issues/43#issuecomment-851669853,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN6YR7EZQSVVEMULBSQ3ELTQPVSRANCNFSM446N37RQ
.

So we discussed this at the last Fortran call (https://fortran-lang.discourse.group/t/fortran-monthly-call-june-2021/1334) and it seems there were no objections to start to maintain these packages under fortran-lang. We also agreed to keep the original API, but add optional modern Fortran API as appropriate, and that we will figure out some of the other details as we go.
@milancurcic, @LKedward you were not at the call, are you both ok with doing that also?

Thanks @certik that sounds good to me

I apologize for dragging this further, but I'd like to review the discussion in the call recording and get back to you later today. Overall the plan sounds good to me, but I will have a few questions.

For the concrete case of QUADPACK I have a couple of questions.

From which source is this project going to start exactly?
(https://github.com/brocolis/quadpack, https://github.com/scipy/scipy/tree/v1.6.3/scipy/integrate/quadpack, http://www.netlib.org/quadpack/, ...)
Which license will changes be contributed under?
For public domain we might have to require contributors to explicitly disclaim their copyright
Who is going to lead the project?
@dhermes extended an offer, also @brocolis offered their version as well, maybe they are still interested
(BTW, we should really invite them into the @fortran-lang organization)

Let's wait for @milancurcic to approve, then we can choose either @dhermes or @brocolis (or both) lead the effort and resolve the questions that @awvwgk posted.

I just noticed @nshaffer (member of fortran-lang) has also previously started an effort to provide a modern QUADPACK package: https://github.com/nshaffer/modern_quadpack
@nshaffer, would you care to provide your thoughts on this thread?
I also just found two re-implementations of the QUADPACK algorithms in C and C++:

cquadpack
quadpackpp

I agree, let's do it. My questions and comments are:

Is there a quadpack repo that @dhermes and @brocolis agree to start from together? I think that would be ideal.
Regarding license, I think the initial content can remain public domain and the additions and changes can be MIT. Does anyone know enough about this to confirm?
We should have some criteria to decide which repos should be maintained under fortran-lang, like having dedicated maintainers, the library is high impact / common dependency, etc. This may have been discussed already.
Related to 3., are there already any fpm packages that depend on quadpack? This could be a proof of need.

Thanks Milan.
@brocolis, @dhermes would one of you (or both!) be willing to take a lead on this?
This first thing to figure out is which repository to use and the license situation.

I currently can't commit many hours to this project. However if we move in small steps, I think it is doable long-term.

Thanks for the ping @ivan-pi. I just finished reviewing the call. I think my general opinion on maintaining old, important packages under fortran-lang is very similar to @certik's. But to be explicit, and raise a few points that I think have not come up yet:
I would first like to see the f77 source maintained with minimal modifications. The initial commit can be the source as it is on netlib or in scipy, or whatever. From there, we can fix bugs (including standards-conformance issues), improve documentation, supply proper tests, and restructure to be packaged with fpm. This is the top priority if these packages are to remain useful for another 40-50 years. People will forget them and/or lose confidence in them if they just sit as tarballs on netlib. This repository should contain no API changes unless a bug is found that makes an existing API unsalvageable.
The "legacy" repository should also provide a nice f90 module interface to the library. The purpose is not to change the API at all, but rather to have an explicit interface for compilers to check. I think it would also be appropriate to define flags and return codes as module parameters with sensible names. In this f90 module, we should also provide C bindings wherever possible. If we can provide explicit f90 interfaces and "official" C bindings for these libraries, that will already be a big success and a service to scientific computing, in my opinion.
With that as the groundwork, I think it is also appropriate to have fortran-lang develop modernized packages. These can either be pretty wrappers around the f77 code (using the fortran-lang module as an entry point) or total rewrites using the f77 code as a reference. The point is this is a separate repo. I was initially inclined not to have these be under fortran-lang, to instead let users write their own. But this is basically what we have already: many people have their own little wrappers around whatever subset of LAPACK they use most. Sometimes they have tests, sometimes they don't. If those efforts are pooled together under fortran-lang, the result will be a more visible, more credible, and ultimately more useful package.

On Mon, Jun 21, 2021 at 9:16 PM Nathaniel Shaffer @.***>
wrote:

The "legacy" repository should also provide a nice f90 module interface to
the library. The purpose is not to change the API at all, but rather to
have an explicit interface for compilers to check. I think it would also be
appropriate to define flags and return codes as module parameters with
sensible names. In this f90 module, we should also provide C bindings
wherever possible. If we can provide explicit f90 interfaces and "official"
C bindings for these libraries, that will already be a big success and a
service to scientific computing, in my opinion.
With that as the groundwork, I think it is also appropriate to have
fortran-lang develop modernized packages.

As I mentioned to Ondrej recently, I hope to live to see the day when
Fortran 90 is no longer considered modern.  Fortran 90 is probably older
than some of the people commenting in this thread!  It has become so common
to write Fortran with "90" appended to it that one could be forgiven for
thinking it is a permanent part of the language name.  Giving external
procedures explicit interfaces is a great step in the right direction that
often can be accomplished trivially with not much more than a module
wrapping a series of include statements.  I recommend stepping a couple of
decades closer to the present by taking advantage of Fortran 2008 to write
interface bodies in modules and move procedure definitions to submodules.
Separating the interface from the implementation can make it much less
laborious for a user to understand an API.  The user need not read through
the entire implementation just to understand how to use the procedures
involved.
Damian

As I mentioned to Ondrej recently, I hope to live to see the day when
Fortran 90 is no longer considered modern.

I think we are all in agreement Damian. :) When I wrote Fortran 90, I did not mean in on purpose, it's just a habit. After you pointed that out, I try to just say "modern Fortran" instead. However, I have a request for you Damian also. We should not be using the .f90 extension for the same reason you just pointed out, but rather just the .f extension, see https://github.com/fortran-lang/fpm/issues/363. I noted your opposition there, but I think you should reconsider. The extension might be even more important for the "optics" than mentioning "Fortran 90" in issue comments, because the file extension is seen all the time, everywhere, by every Fortran user.

Fair points, Damian. Indeed the Fortran 90 standard is a little older than I am (but only by a little). It's a bad habit of mine to use "f77" and "f90" as shorthand for "legacy" and "modern".
The idea of using submodules is interesting. So the gist would be to declare the interfaces in a module, then either copy-paste or include the fixed-form sources in a (fixed-form?) submodule file?

You can of course do either, but some editing is necessary as of old the
end of a subroutine was characterised by the keyword END and that is
incompatible with the end of a submodule.
Op di 22 jun. 2021 om 16:06 schreef Nathaniel Shaffer <
@.***>:

Fair points, Damian. Indeed the Fortran 90 standard is a little older than
I am (but only by a little). It's a bad habit of mine to use "f77" and
"f90" as shorthand for "legacy" and "modern".
The idea of using submodules is interesting. So the gist would be to
declare the interfaces in a module, then either copy-paste or include the
fixed-form sources in a (fixed-form?) submodule file?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/fortran-lang/fpm-registry/issues/43#issuecomment-866015121,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN6YR3MCAHHJSLP34Y56DDTUCKIDANCNFSM446N37RQ
.

On Tue, Jun 22, 2021 at 6:54 AM Ondřej Čertík @.***>
wrote:

I think we are all in agreement Damian. :) When I wrote Fortran 90, I did
not mean in on purpose, it's just a habit. After you pointed that out, I
try to just say "modern Fortran" instead. However, I have a request for you
Damian also. We should not be using the .f90 extension for the same
reason you just pointed out, but rather just the .f extension, see
fortran-lang/fpm#363 https://github.com/fortran-lang/fpm/issues/363. I
noted your opposition there, but I think you should reconsider. The
extension might be even more important for the "optics" than mentioning
"Fortran 90" in issue comments, because the file extension is seen all the
time, everywhere, by every Fortran user.

Ondřej, thanks for prompting me to reconsider.  Now that I'm moving to fpm
for every project to which I'm actively contributing, I'll be glad to make
the switch to .f.  I've always been a minimalist so I like the conciseness
of it. :)
I still have a slight preference for choosing something new rather than
overloading an extension that is already widely used, but I agree that to
be consistent with my earlier comments, .f is preferable to .f90.
Damian

On Tue, Jun 22, 2021 at 7:06 AM Nathaniel Shaffer @.***>
wrote:

The idea of using submodules is interesting. So the gist would be to
declare the interfaces in a module, then either copy-paste or include the
fixed-form sources in a (fixed-form?) submodule file?

Yes, my personal preference is to avoid repeating the interface information
in the procedure definition, but I'm in the minority in this opinion.
Here's an example:

module:
https://github.com/sourceryinstitute/sourcery/blob/main/src/array_functions_interface.f90
submodule:
https://github.com/sourceryinstitute/sourcery/blob/main/src/array_functions_implementation.f90

Note: the "module" keyword in the interface bodies is required and the
"implicit none" in each interface bodies is strongly recommended.
In addition to separating interfaces from implementations, this style
avoids unnecessary compilation cascades, in which a change to the procedure
definition causes a domino effect of recompiling any code that depends on
the procedure even if the relevant procedure's interface is unchanged.
I hope this helps.
Damian

Well, I guess I had forgotten about this thread. I went ahead and modernized quadpack. See: https://github.com/jacobwilliams/quadpack
This is a full modernization & cleanup of the code (converted to free-form, removed obsolescent features, cleaned up the doc strings, etc.) It's now all in one module. The API is the same though! At least it is for the double precision version. I removed the single-precision routines and make it so you can create a single or even quad precision module using some preprocessing trickery.
I used the netlib/quadpack one as a starting point. That one has the recent bug fixes from SciPy. I need to see what else they have done.
My intent is to use this as an FPM dependency in my quadrature-fortran library, so I can use it for 1D-6D integration.

Well, I guess I had forgotten about this thread. I went ahead and modernized quadpack. See: https://github.com/jacobwilliams/quadpack
This is a full modernization & cleanup of the code (converted to free-form, removed obsolescent features, cleaned up the doc strings, etc.) It's now all in one module. The API is the same though! At least it is for the double precision version. I removed the single-precision routines and make it so you can create a single or even quad precision module using some preprocessing trickery.
I used the netlib/quadpack one as a starting point. That one has the recent bug fixes from SciPy. I need to see what else they have done.
My intent is to use this as an FPM dependency in my quadrature-fortran library, so I can use it for 1D-6D integration.

authors: LKedward arjenmarkus awvwgk brocolis certik dhermes ivan-pi jacobwilliams milancurcic nshaffer rouson

repo: fortran-lang/fpm-registry


text:
fix lookup and automatic installation of fortls on Windows

Hey there, gnikit,
-- personal message ;) --
first off, let me say what a tremendous job you have done with fortls!
The extension is leaps ahead from what it was two years ago. I only managed to update a couple of months ago after you posted to Discourse and I was amazed.
-- end personal message --
I hopefully made the extension a bit more usable on Windows, where pip installs fortls in the %appdata%\Roaming\Python\Python311\Scripts\ folder, which is typically not in PATH, so the extension wouldn't find fortls after installing it.
So the only way to use it would be to enter the path to the above folder to the config or to install fortls with admin privileges.
In any case, automatic installation by the extension or updates weren't possible.
Now the extension also looks for fortls in this folder, so all of that is gone.
Other changes:

The user configured path to fortls must now be absolute.
This simplified a lot of things and it doesn't make sense to me to
have multiple versions of fortls on the system, per workspace.
Please let me know if this is not OK.
The fortls.disabled config value now gets stored in the USER settings
instead of workspace. Similar reasons as above, it seems easier to
find.
A check for python presence is performed before running pip.
On Windows, python is used instead of python3 as this is the standard command name on the platform.
Added --end-of-line auto argument to prettier to keep me sane.
(Otherwise prettier would convert everything to LF, which results in hundreds of modified files in git, because git checks out files with CRLF by default on Windows. They're still commited with LF, don't worry.).

Thanks for a quick review!
Sorry about the PR being a bit messy/containing multiple features. It is my first PR containing more than a couple of lines of code. I will try to be more granular next time.

We cannot force people to use absolute paths. A lot of people work with workspace local virtual environments, some companies use weird project configurations that require them to use relative paths or it's more convenient for them to use relative paths.

Understood. I will fix this.

The fortls.disabled config value now gets stored in the USER settings
instead of workspace. Similar reasons as above, it seems easier to
find.

I like this idea but there is a reason why I chose not implement it this way. It was for the people that truly wanted an editor for Fortran without any bells and whistles. I suspect that it might be time to re-evaluate this or offer the option to do both.

I'm not sure you understood what I meant. The extension still allows all settings to be set in both user and the workspace settings.
What I want to change is what happens when you click Disable in the Forlts wasn't found on your system. prompt.
I think it makes more sense to store the disabled state in the user setting than in the workspace setting as more users will install fortls globally (I for one think in most cases the extension should install it for them semi-automatically and they shouldn't worry about it). Do you agree?

On another note, I think the proposed solution for spawning fortls will break in some edge cases because of the asynchronicity in the initialiser.

I'm new to the async await concept (this was my first time doing anything in TypeScript), but I thought I thought about it sufficiently. I will look into it again, though, to be sure.

The other part is that by moving the this.path into the activation function removes the ability of users being able to change the path to fortls without restarting vsocde. There is a reason why the fortls initialisation is written that way.

Understood. Will fix this.

In the client.ts there are a lot of changes that are not clear to me why they are necessary and what they are addressing. This seems more like a code refactoring which should not be part of this PR.

The refactoring made sense for the changes I made. But I guess there's no point going into detail now, before I make the changes you requested...

A check for python presence is performed before running pip.

Not sure if this is worth it. Almost any OS or Fortran development environment comes with Python (Linux, FreeBSD, MacOS, WSL, MinGW, Cygwin, Intel OneAPI). If the user doesn't have Python in their system and reachable, it is a safe bet that they will also have troubles compiling any code. The way that we plan to guide new users through the installation bit is via Walkthroughs, which I have yet to write see https://github.com/fortran-lang/vscode-fortran-support/issues/472

I would argue so.
In my opinion, the extension should work as effortlessly as possible.
An example for this being my boss, a mechanical engineer, who has never used python and I know he won't, unless he's absolutely forced to. He's never worked with a package manager, so obviously he doesn't know pip either.
These are already two obstacles for him to get fortls working instead of just saying "just install python and than this".
I know another company here in Brno, where at least half of the Fortran users are similar 50+ year old guys who I'm sure don't regularly use python either.
I want the extension to work for them as well.
Also, expecting Python to be installed alongside a Fortran compiler is not such a safe bet as you say it is, in my opinion. Intel OneAPI does come with their distribution of Python, but nothing forces you to install it. You don't need it to compile Fortran code. I've compiled several open-source libraries (arpack being one of them, off the top of my head) without needing Python.
Also, if we keep the Python check, it could be improved by also checking the python version, as fortls only supports >= 3.7 (however this is probably not critical...).

This is also incorrect (which I just learned myself), it should be py not python, see https://packaging.python.org/en/latest/tutorials/installing-packages/#installing-from-pypi (Windows option). I have no idea why Windows has these nuances, but I guess we will have to work around it.

I'm sure a bad enough reason exists. OK, will fix this to py, will leave python3 on other platforms. Thanks for that.

Added --end-of-line auto argument to prettier to keep me sane.
(Otherwise prettier would convert everything to LF, which results in hundreds of modified files in git, because git checks out files with CRLF by default on Windows. They're still commited with LF, don't worry.).

I don't think I understand what the issue is. All files should be formatted and committed with LF in all OSs. Does prettier format something that it shouldn't on Windows hence the large diffs? Setting this to auto can lead to mixed line endings which we can't permit. Using WSL is the safest solution IMO. BTW VS Code should be able to account for LF or CRLF on any OS.

Don't worry, everything still gets commited with LF.
The way git works on Windows by default is that it checks out everything with CRLF (even if it's stored in the repo with LF) and when you commit, it internally converts all CRLF back to LF.
The problem with prettify was that by doing its thing, it would result files containing just LF.
This then shows up in git as unstaged changes in all of the files.
The --end-of-line auto option should work the way that it looks whether CRLF or LF is used on the first line (this would be CRLF on Windows, LF elsewhere) and then uses this line ending for the rest of the file.
When I commit, git then saves this as LF.
Another option would be to configure git to "checkout LF, convert CRLF to LF, commit LF" (this can be done per repo), but I would strongly recommend we stick to the default behaviour, otherwise things get messy (i.e. when copying stuff between projects with different settings)...

The greater question with this PR I guess is how do people configure their Python environments on Windows? How do they reach binaries installed via pip? On Linux and MacOS the user install location for pip is not in the PATH either. There is just the assumption, potentially erroneously, that the user has done some minimal setup for their development environment. It might be worth doing a try-except if binary X is not found in default vscode settings try the "default" pip location first, which might be outside of PATH.

As I said, I think the ideal scenario is that the extension installs fortls itself using pip install --user fortls and then it is able to find and run it from the user location, whether the user did include it in PATH or not. If a user wants to tinker/adjust the installation themself, they can always do that, but the process should be as effortless as possible. And as the user site of pip can easilly be queried, there's no point in not looking in there.
Looking forward for your thoughts.

repo: fortran-lang/vscode-fortran-support


text:
Tracks Page bugs

Replaced speakers by sessions in pop-over
Fixed Responsiveness affected by previous PR's.
Add Home tag in nav bar to go to generator page.

[Current coverage][cc-pull] is 56.67%

Merging [#493][cc-pull] into [development][cc-base-branch] will not change coverage

@@           development       #493   diff @@
=============================================
  Files                4          4
  Lines              397        397
  Methods             43         43
  Messages             0          0
  Branches            48         48
=============================================
  Hits               225        225
  Misses             172        172
  Partials             0          0

Powered by Codecov. Last updated by [0c32d8d...f862049][cc-compare]
[cc-base-branch]: https://codecov.io/gh/fossasia/open-event-webapp/branch/development?src=pr
[cc-compare]: https://codecov.io/gh/fossasia/open-event-webapp/compare/0c32d8d2428588ab3254cfc414130b15d56ff3e1...f8620494351f20cfbd625542828a32a118e8f37e?src=pr
[cc-pull]: https://codecov.io/gh/fossasia/open-event-webapp/pull/493?src=pr

authors: aayusharora codecov-io

repo: fossasia/open-event-webapp


text:
storage

What is the storage capacity?

Limiting factor so far is the device memory as ObjectDB is currently 100% in-memory. This will be addressed in a further version.

authors: allessandrosj flexwie

repo: fosscom/objectdb


text:
Produce bindings for enums

Component
Forge
Describe the feature you would like
I would like forge to generate Rust enums of the following Solidity code:
pragma solidity ^0.8.13;

contract Foo {
    enum Bar {
        A,
        B,
        C
    }

    function doSomething(Foo foo) public view {}
}

The above should generate something like this:
#[derive(Debug, Clone, Copy)]
#[repr(u8)]
enum Bar {
    A,
    B,
    C,
}

impl Bar {
    fn from_u8(val: u8) -> Option<Bar> {
        match val {
            0 => Some(Bar::A),
            1 => Some(Bar::B),
            2 => Some(Bar::C),
            _ => None,
        }
    }

    fn to_u8(&self) -> u8 {
        *self as u8
    }
}

Additional context
As I understand this is a limitation because only the abi field is used from the json file.
This information can be retrieved from ast field, but abigen does not accept this kind of input.

Is this a feature request for forge bind, or a feature request for abigen? abigen is not in this repository, it's in ethers-rs

It is for forge bind.

+1 would be very nice to access these enums with types in rust

I don't think enum variants are included in the abi itself.
contract Foo {
    enum Bar {
        A,
        B,
        C
    }

    function doSomething(Bar bar) public view {}
}

	"abi": [
		{
			"inputs": [
				{
					"internalType": "enum Foo.Bar",
					"name": "bar",
					"type": "uint8"
				}
			],
			"name": "doSomething",
			"outputs": [],
			"stateMutability": "view",
			"type": "function"
		}
	]

so we only know that there's an enum but don't know anything about the variants

This is true. As @oblique mentioned, the enum variants can be found in the ast section of the forge output, but not abi

right, so we'd need to check if the json input contains the ast field and start extracting enums from that. then use them if we see them in abi

Bindings for enums are now produced when running forge bind --alloy, marking as resolved

authors: jaeaster mattsse oblique onbjerg zerosnacks

repo: foundry-rs/foundry


text:
Formulas in delta fields

This adds functionality to execute formulas in Delta Fields. This pull also implements the logic within #1860, this is because the new logic is an extension, and dependent on the logic in #1860 .
The use case for this is primarily complex situations where multiple effects may be added nearly simultaneously.
For example, if a DM mishears their player, they may want to both add and subtract at the same time.
This also works very well for currency, where a player may in the same transaction receive and spend money. This shortens the amount of time needed for them to process the change.
This is also very useful for damage multipliers. If you need to apply damage in a way like, they rolled for damage IRL and you don't want to do that math, the sheet can now do it for you. I would at some point like to expand this to work as a delta but for now I believe this is added functionality at a very low complexity cost.

@Fyorl This is the PR I opened that contains the new functionality of evaluating formulas in delta input fields.

Hm, how will this impact existing modules?


text:
[#3305] Add enchantment usage dialog & application tray

Introduces enchantment to the AbilityUseDialog using the applyEnchantment and enchantmentProfile options, with similar details to how summoning is handled.

When enchantment is performed it adds a new "Enchant" tray to chat cards. This tray has a place to drop an item which is then enchanted when the apply button is pressed.

Enchantments are tracked with concentration, so if concentration on the enchanting spell ends then the enchantments will be removed.

Enchantments are tracked with concentration, so if concentration on the enchanting spell ends then the enchantments will be removed.

Are enchantments intended to work only with items that require concentration?

Enchantments are tracked with concentration, so if concentration on the enchanting spell ends then the enchantments will be removed.

Are enchantments intended to work only with items that require concentration?

Nope. That just means if you are enchanting from an item with concentration it will link them, but otherwise you can enchant normally. Eventually there will be a way to end non-concentration enchantments from the item that provided them, but that’s not implemented yet

@Fyorl I made a change so now the chat card remembers what enchantments were added using it, rather than losing them on re-render and gave them a remove enchantment button. This does result in the chat card becoming potentially longer if multiple items are enchanted with it, so I wonder if it might make sense to move the enchanted items back into a tray and maybe only have the drop area out of it?


text:
Weird GM roll formatting in Chat

Our GM rolled a damage roll vs an Animal Companion, and this was shown to the chat (ignore the red dot, that is Windows)

We're going to need to see what the GM saw to get any useful insight there.

Player view

vs GM view

No modules activated
Foundry version 11, 315
PF2e version 5.13.5

It was the same Actor doing the damage both times, if that changes anything

What is weird about the hidden rolls made by the GM being hidden? (Besides perhaps the empty parenthesis)

It's the empty parenthesis referred to

authors: MrVauxs robinsving stwlam


text:
Fix schema warnings from Ajv

With the upgrade to the latest version of Ajv it logs warnings about invalid schema. This PR fixes those warnings
Issue: https://github.com/fourTheorem/slic-watch/issues/74

Hey @eoinsha sorry to be a pain, but any chance you could look at this one? 🙌

@eoinsha I've cleaned up the PR :)

repo: fourTheorem/slic-watch


text:
🛑 Advantage Print Solutions is down

In 36f2c96, Advantage Print Solutions (https://www.advantageprintsolutions.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Advantage Print Solutions is back up in f76db30.

repo: fourthfloor/uptime


text:
foxglove recordings list`

Description
Running foxglove recordings list results in the following error:
❯ foxglove recordings list
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x732f82]

goroutine 1 [running]:
github.com/foxglove/foxglove-cli/foxglove/console.RecordingsResponse.Fields({{0xc000028a60, 0x10}, {0xc000312000, 0x46}, 0xeabefe, 0x36, {0xc00002c168, 0x18}, {0xc00002c180, 0x18}, ...})
        /home/runner/work/foxglove-cli/foxglove-cli/foxglove/console/api.go:232 +0x2c2
github.com/foxglove/foxglove-cli/foxglove/cmd.renderList[...]({0xb43ca0, 0xc000014018}, 0xa61e42, 0x5?, {0xa61e5b?, 0x5})
        /home/runner/work/foxglove-cli/foxglove-cli/foxglove/cmd/utils.go:100 +0x3de
github.com/foxglove/foxglove-cli/foxglove/cmd.newListRecordingsCommand.func1(0xc0001f6280?, {0xa618b3?, 0x0?, 0x0?})
        /home/runner/work/foxglove-cli/foxglove-cli/foxglove/cmd/recordings.go:38 +0x5b0
github.com/spf13/cobra.(*Command).execute(0xc0001f6280, {0xf13268, 0x0, 0x0})
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.3.0/command.go:860 +0x663
github.com/spf13/cobra.(*Command).ExecuteC(0xc0001b3680)
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.3.0/command.go:974 +0x3bd
github.com/spf13/cobra.(*Command).Execute(...)
        /home/runner/go/pkg/mod/github.com/spf13/cobra@v1.3.0/command.go:902
github.com/foxglove/foxglove-cli/foxglove/cmd.Execute({0xb40f50, 0x7})
        /home/runner/work/foxglove-cli/foxglove-cli/foxglove/cmd/root.go:230 +0xd16
main.main()
        /home/runner/work/foxglove-cli/foxglove-cli/foxglove/main.go:11 +0x27

API key is loaded and working with other commands such as foxglove devices list. The API key I'm using has all options enabled.

Version:

❯ foxglove version
v1.0.12

Platform:
Windows 11 running WSL with Ubuntu 22.04

Steps To Reproduce

Pretty simply running the foxglove recordings list command.
Expected Behavior
List of at least some of the recordings in the data platform.

Thank you for the report; this should be fixed with v1.0.13

authors: adamsj-ros bryfox

repo: foxglove/foxglove-cli


text:
Add responsive styling

At present, the current styles are not responsive beyond a little bit of flexibility. This should be rectified.

 Complete Styling tasks


text:
pandoc for th_trello

Trello uses markdown where the content provided is in HTML
Have to use https://pypi.python.org/pypi/pypandoc for that

done 5d19b0bd72a9c32b340f85c8dc6c70131bd8b586 line 142

repo: foxmask/django-th


text:
Win32Exception: Permission denied on Azure

Good morning,
I'm trying to launch library on Azure WebApp. Unfortunately all the time I have an error:
System.ComponentModel.Win32Exception (13): Permission denied    at Wkhtmltopdf.NetCore.GeneratePdf.GetByteArray[T](String View, T model)
For test purpose I injected also IRazorViewToStringRenderer class from the library to check is HTML rendered properly
await this.razorViewToStringRenderer.RenderViewToStringAsync("Views/Home/Index.cshtml", results);
At this moment everything working good, method is returning rendered HTML.
Problem is starting when I try to call
await generatePdf.GetByteArray("Views/Home/Index.cshtml", results);
About environment:
Everything is deployed by Azure Pipelines for sure I'm giving there 755 chmod for Linux/wkhtmltopdf and Windows/wkhtmltopdf.exe files.
WebApp is launched on App Service Plan S1 with Linux environment

Hi!
Locally in your pc is running fine? what version of the library are you running?

Yes, locally everything works perfect, latest version

Hi @fpanaccia,
Any updates in this area ?

Same happens for AWS

@fpanaccia I have the same problem

@fpanaccia Any news about this?

I had the same problem, but making wkhtmltopdf executable helped me. I wrote in console:
chmod +x /path_to_app/Rotative/Linux/wkhtmltopdf
Maybe it will help someone. @adriantheking are you really sure Azure Pipelines gives 755 chmod for wkhtmltopdf?

@lookinsidethebox Yes I double checked it. How you running your application ?

@adriantheking I publish the application with MS Visual Studio in a local folder, manually copy files from the folder to my server (Alt Linux 8.2) and restart the application with supervisor.
Have you tried asking Azure Support? Maybe you need special permissions to run scripts on your server.

This errors is expected on azure since azure doesn't let you execute .exe files on the app services.
There is no way to fix this unless you run your own app inside a own VPS or this library changes to use .dll directly (which lead in a total source code refactor) instead of executing the .exe.

authors: adriantheking arivera12 fpanaccia jlfjunior lndr-ssantos lookinsidethebox query-wow

license: Unlicense


text:
containers-0.5.10.2

containers-0.5.10.2 is out of bounds for:

[ ] functor-classes-compat-1 (>=0.4 && < 0.5.9.1). Oleg Grenrus oleg.grenrus@iki.fi @phadej. @phadej. Used by: library

flag containers should be True.

authors: lwm phadej

repo: fpco/stackage


text:
Update externs to match Electron 1.0 release

Electron has gone 1.0 but their API has changed.  It would be awesome if the externs could get updated to support the revised API.

Totally ... PRs are very well accepted :)

We should port the api-demo-app: https://github.com/electron/electron-api-demos too.

That's a great idea, maybe worth splitting the issues?

I'm not opposed to doing some externs but it will have to wait until I have
a project at the workplace that requires it, that could be within the next
month.
On Wed, May 11, 2016 at 5:57 PM, Franco Ponticelli <notifications@github.com

wrote:

That's a great idea, maybe worth splitting the issues?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/fponticelli/hxelectron/issues/17#issuecomment-218602709

--
Phillip Chertok

So I started working on this and I have run into a dilemma.  In certain scenarios you need different @jsRequire calls and I don't know how to handle it.
For example if you need to access a browser window from the main process you need the following metadata
@:jsRequire("electron", "BrowserWindow")
but if you need the Browser Window in a render process you need the following;
@:jsRequire("electron", "remote.BrowserWindow")
Any thoughts on how to handle it?

How about a compiler flag?
#if electron_main
@:jsRequire("electron", "BrowserWindow")
#elseif electron_renderer
@:jsRequire("electron", "remote.BrowserWindow")
#end

We could cheat and do something like this:
@:jsRequire("electron", "BrowserWindow || require('elecron').remote. BrowserWindow")

NOT TESTED!

Someone in IRC suggested making a base class with fields and without
@:jsRequire's and then two extending classes that have @:jsRequire.  I like
this idea a bit more than the previous 2 suggested solutions but it's still
not optimal.
On Thu, May 12, 2016 at 11:58 AM, Franco Ponticelli <
notifications@github.com> wrote:

We could cheat and do something like this:
@:jsRequire("electron", "BrowserWindow || require('elecron').remote. BrowserWindow")
NOT TESTED!
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/fponticelli/hxelectron/issues/17#issuecomment-218802689

--
Phillip Chertok

It is clean but I don't like much the artificial class inheritance. Maybe we could try that and add a macro magic to remove the parent class?

At some point there sould be a json file describing the api we can use to generate the extern types (electron/electron#3375). But, like with atom-api.json, these descriptions do not describe everything, so we would end up with a lot of Dynamic (correct me if i am wrong).
If we want to depend on this i think we still should create full typed externs by hand (as we already have for <1.0) and use the description file, as soon as it's available, to validate them.

Work in progress: https://github.com/electron/electron/pull/6408

What's the state of this? Does someone have a WIP in a branch somewhere?

Here https://github.com/tong/hxelectron/tree/generate-externs is a initial version which auto generates the externs (currently electron 1.4.3). Not heavily tested, but the docs are building and the demo app is working.

That's great, are there plans to integrate the generated stuff with hand curated type? I see quite a few Dynamics here and there that could be replaced.

I've already added some improvements and think it should be possible to rely on generated externs only.
There are some glitches cause of invalid documentation, namely:

Types of instance properties seem to be missing from api description.
There is a electron.Any type which comes from invalid description as it should be an Object.
The electron.Accelerator description is missing
The electron.App type is manually patched with a static on() method.

To distinguish between types available in main and/or renderer process i 've added @:require(electron_main) and @:require(electron_renderer) meta data. I am not sure if that's cool with --display, needs test.

@tong awesome!

authors: fponticelli ousado pchertok tong zeke

repo: fponticelli/hxelectron