deno/Lobby

https://deno.land/

Bartek Iwańczuk

@bartlomieju

@bogdanbiv what do you mean by persisted?

Permission API in Deno is still WIP, we have an issue for that denoland/deno#2767

Bogdan Bivolaru

@bogdanbiv

I guess what I am asking is if the permissions can be loaded / written with the application or module they are refering to. In this way the app permissions could be versioned and transfered to another ENV.

WebExtensions contain an array of strings for this purpose (manifest.json):
"permissions": [
"webRequest", "webRequestBlocking", "https://example.com/*"
],

Bartek Iwańczuk

@bartlomieju

No there isn't at the moment, but please share those concerns in the issue above. If it's standardized then we might implement it

Bogdan Bivolaru

@bogdanbiv

Thanks, Bartek!

Bartek Iwańczuk

@bartlomieju

:+1:

Kitson Kelly

@kitsonk

wow, this test generates a super long TypeScript diagnostic message:

let x = {
  a: {
    b: {
      c: {
        d: {
          e: {
            f() {
              return { g: "hello" };
            }
          }
        }
      }
    }
  }
};
let y = {
  a: {
    b: {
      c: {
        d: {
          e: {
            f() {
              return { g: 12345 };
            }
          }
        }
      }
    }
  }
};
x = y;

which works fine in TypeScript, gets serialised fine in from TypeScript to Rust, works fine as a standalone test in Rust, but breaks rustfmt when trying to format the test case and deno when trying to deal with it at runtime.

Jeremy

@jmisiti42

Hello, i tryed to contribute for the first time to deno_std but all tests failled. Is this a known issue ? I'm sure that's not my code breaking everything

Nayeem Rahman

@nayeemrmn

@jmisiti42 You went over the line limit. Check that everything falls below 80 columns.

Jeremy

@jmisiti42

Oh right, norm's breaking ! Sorry

bartlomieju @bartlomieju Deno Newsletter 34 is out! deno.news/archive/199776 This week includes: Heroku buildpack for Deno, invite to 2 meetups with Deno talks and more!

Luca Casonato

@lucacasonato

Is there a path.join equivalent for deno?

Bartek Iwańczuk

@bartlomieju

@lucacasonato https://github.com/denoland/deno_std/blob/master/fs/path/mod.ts

there's join method there

dev-nicolaos

@dev-nicolaos

deno_std needs a version bump

Bogdan Bivolaru

@bogdanbiv

@bartlomieju added my comment to Deno app permissions: denoland/deno#2767

Bartek Iwańczuk

@bartlomieju

Thanks!

Christian Moritz

@chrmoritz

Hello,
did you noticed the the size of the macOS executable dropped from 51.3 MB to 42.5 MB with the last release (0.17 vs 0.18)?
This was caused by the move to cargo build and that cargo now dynamically links to libc++ (and libresolv) instead of statically linking them into the binary as with ./tools/build.py before.

Running otool on the official binary releases:

$ otool -L ~/Downloads/deno_osx_x64_0.17
~/Downloads/deno_osx_x64_0.17:
 /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.51.6)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)
$ otool -L ~/Downloads/deno_osx_x64_0.18
~/Downloads/deno_osx_x64_0.18:
    /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.251.4)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
    /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

But for the homebrew formula this lead to the unfortunate situation, that the multi gigabyte llvm dependency is now a runtime dependency instead of the build-only dependency because deno is now dynamically linked to it's libc++ and now depends on it at runtime.
(We can't use system clang because it's to old for v8 and we try to avoid using third party binaries like Google's clang in homebrew. Also setting use_custom_libcxx=false doesn't work when using a custom clang_base_path in your args.gn.)

Ryan Dahl

@ry

@chrmoritz yikes..

How is the llvm a runtime dep? i dont see that in the otool output

Christian Moritz

@chrmoritz

the otool output above is run on the official binaries, here is the one for the homebrew deno:

/usr/local/Cellar/deno/0.18.0/bin/deno:
    /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.255.3)
    /usr/local/opt/llvm/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
    /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

Ryan Dahl

@ry

i see..

Ryan Dahl

@ry

@chrmoritz This is a serious issue, can you open a issue so we can track it better?

@chrmoritz Also have you tried "cargo install deno_api" yet? The binaries I get from that don't have the libc++ dylink...

Christian Moritz

@chrmoritz

@ry Do you see it as an issue that it now dynamically links against libc++ and libresolv or just the results this has for the homebrew formula?

Christian Moritz

@chrmoritz

and what did you mean with cargo install deno_api?

Christian Moritz

@chrmoritz

I was able to bring it to dynamically link to system libc++ instead, so we could move llvm to a build-time only dependency again:

Christian Moritz

@chrmoritz

I've opened Homebrew/homebrew-core#44361 for it.

Ryan Dahl

@ry

@chrmoritz libresolv sounds fine, and probably unavoidable - but it shouldn't be using /usr/local/opt/llvm/lib/libc++.1.dylib

does that patch work?

and what did you mean with cargo install deno_api?

oops, i meant cargo install deno_cli

i recently published the cli crate to crates.io https://crates.io/crates/deno_cli

Christian Moritz

@chrmoritz

With that PR I got it to use system libc++:

/usr/local/Cellar/deno/0.18.0/bin/deno:
    /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.255.3)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1)
    /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

and cargo install deno_cli won't work for homebrew because it uses precompiled binaries of libdeno

Nayeem Rahman

@nayeemrmn

It seems the JSDoc for walk in deno_std is outdated.

Bartek Iwańczuk

@bartlomieju

@nayeemrmn please open an issue

Nayeem Rahman

@nayeemrmn

Can we remove testing/main.ts in deno_std? It would reduce the cluster of modules there which all seem to mean the same thing and it seems nonsensical...
When used as a main module it obviously does nothing, when imported it just runs runTests() but as a non-deterministic side-effect...?

Ryan Dahl

@ry

@nayeemrmn yes

but cc @bartlomieju and make sure he approves - it's fine as far as im concerned

Kitson Kelly

@kitsonk

Hey @bartlomieju @ry some interesting TypeScript APIs that I wasn't aware before that might help solve the parallel downloads better: https://github.com/microsoft/TypeScript/issues/29361#issuecomment-532968514

I will take a look at them... @bartlomieju I chatted with Ry earlier and I am going to look at how to re-use the program to speed up compilation because we are on 3.6.3 now. I think I have a good idea how to do it, and see if it improves performance

Bartek Iwańczuk

@bartlomieju

@kitsonk that looks very promising, I'm curious about it.

@kitsonk do you mean the new API that can rehydrate compiler state using .buildinfo files?

I'm glad you can look at this :pray: this should fix performance problem for dynamic inports, let me know if I can be of any help

Where communities thrive

People

Repo info

Activity