Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 22:54
    hayd commented #2988
  • 22:42
    piscisaureus synchronize #2989
  • 22:10
    piscisaureus opened #2989
  • 19:59
    nayeemrmn edited #604
  • 19:57

    denobot on gh-pages

    Deploy denoland/deno to github.… (compare)

  • 19:35

    ry on master

    Set RUSTC_WRAPPERf in travis an… (compare)

  • 19:35
    ry closed #2978
  • 19:22
    lucacasonato synchronize #599
  • 19:10

    denobot on gh-pages

    Deploy denoland/deno to github.… (compare)

  • 19:03
    ry edited #2988
  • 19:02
    ry commented #2933
  • 19:00
    ry labeled #2988
  • 19:00
    ry opened #2988
  • 18:56
    ry commented on 56ac638
  • 18:53
    ry edited #2933
  • 18:53
    ry edited #2933
  • 18:53
    ry edited #2933
  • 18:53
    lucacasonato synchronize #599
  • 18:48

    ry on master

    Remove test.py, use cargo test … (compare)

  • 18:48
    ry closed #2967
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
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