Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 11 08:25
    GJZwiers closed #191
  • Sep 11 08:25
    GJZwiers commented #191
  • Sep 11 04:15
    ayame113 commented #191
  • Sep 11 04:12
    ayame113 commented #191
  • Sep 10 22:11
    bnoordhuis commented #191
  • Sep 10 03:07
    xialvjun commented #79
  • Sep 09 21:09
    kitsonk commented #191
  • Sep 09 12:50
    MarkTiedemann commented #191
  • Sep 09 12:28
    GJZwiers commented #191
  • Sep 09 12:05
    GJZwiers commented #191
  • Sep 09 12:05
    GJZwiers commented #191
  • Sep 09 12:04
    GJZwiers commented #191
  • Sep 09 11:56
    MarkTiedemann commented #191
  • Sep 09 11:46
    GJZwiers commented #191
  • Sep 09 11:15
    MarkTiedemann commented #191
  • Sep 09 08:18
    kitsonk labeled #191
  • Sep 09 08:18
    kitsonk labeled #191
  • Sep 09 08:13
    GJZwiers opened #191
  • Sep 08 21:29
    dwiyatci commented #79
  • Sep 07 15:41

    bartlomieju on master

    chore: update dlint to 0.15.1 (… (compare)

Ryan Dahl
@ry
i meant hi
Mike Reinstein
@mreinstein
hi Ryan!
I really like the message passing style interface that the deno core provides. It reminds of microkernel architecture
Ryan Dahl
@ry
thanks - ya i think it will be nice for modularity / static typing / security
@piscisaureus is doing benchmarking to determine how exactly we're going to be passing messages
the current idea is to have two threads with a non-locking msg queue between
Mike Reinstein
@mreinstein
Is message passing the biggest perf bottleneck right now?
Ryan Dahl
@ry
@mreinstein since everything will sit on it we want to make sure it looks decent from the start
Mike Reinstein
@mreinstein
I would imagine streaming is a foundational use case we'd want to perf test as early on as possible
that socket streaming example in deno's repo is enticing
it might be worthwhile early on in this process before people start actually using deno to take the top 10 common stream operations and think them through in deno
e.g., Max's mississippi stream collection https://github.com/maxogden/mississippi
that is a major legacy pain of node and it's basically unfixable within that ecosystem because of all the modules that depend on it. Getting it right in deno the first time would be fantastic
Ryan Dahl
@ry
@mreinstein yea i agree - we're thinking about it. i'm arguing for the lowest-common denominator which is non-blocking read and writes
as for high level "stream" type stuff, I want to follow Go's Reader/Writer/ReaderCloser/WriterCloser interfaces almost exactly
Mike Reinstein
@mreinstein
deno's socket example reminds me of the old nbio socket select() call..benefits of having async/await now. I think this is the right level of abstraction
I think these interfaces are very well thought out. I will just translate them into typescript and the blocking calls be made into await calls
but that'll be a while. we need to get the basic IPC mechanism working first
Mike Reinstein
@mreinstein
makes sense. streaming will be a great stress test for the message passing for sure
Ryan Dahl
@ry
more info about one of the designs that Bert is benching: https://github.com/piscisaureus/deno/tree/jrmq?files=1
Mike Reinstein
@mreinstein
thanks for sharing
Mike Reinstein
@mreinstein
oh wow flatbuffers have already landed. sweet!
Mike Reinstein
@mreinstein
is the flatbuffer stuff effectively closing this issue? ry/deno#269
Ryan Dahl
@ry
yes, i actually had written up a big reply to that.. but somehow got lost in some tab purge
i think we're fairly tentative with the flatbuffers tho. it needs to be benchmarked - and it's not quite working fully
flackjap
@flackjap
Hi there! :)
I tried digging some more info on Deno, specifically to see if there were questions brought up about multithreading and concurrent execution of tasks, but couldn't find anything.
The biggest disadvantage I saw in node.js is that it is single-threaded, and doesn't provide built-in / easy ways to do CPU intensive tasks on other cores or other machines. For example, Go has goroutines, Erlang (and Elixir ofc) has light threads, etc. but mainly based on Actor models for concurrency. While it is awesome that we'll be able to do async/await without callback hell in Deno, I can't find anything in readme/roadmaps/discussions that would consider the cases where some iterator methods would block the execution in a single thread that was supposed to deliver fast I/O.
I can see that someone mentioned some interfaces for message passing, here in this chat, but the information is scarce and interlaced with some other facts, so I'm a bit confused :)
Ryan Dahl
@ry
@flackjap I intend to support webworkers - but that's months away at minimum
Faris Amali Alis
@f-a-a
@ry travis build seems stucked :/ https://travis-ci.com/ry/deno/builds/78854957
Ryan Dahl
@ry
@f-a-a Great job on that commit! This is very helpful
~/src/deno> time ./out/Debug/deno_cc hello.js
ts.version: 2.9.1
MessagesFromJS cmd_id = 1, msg_type = 1, msg_type_name = Start
cwd: /Users/rld/src/deno
argv ./out/Debug/deno_cc,hello.js

real    0m0.303s
user    0m0.261s
sys    0m0.031s
~/src/deno> time ./out/Debug/deno_cc_nosnapshot hello.js
Reading javascript runtime bundle from /Users/rld/src/deno/out/Debug/gen/bundle/main.js
ts.version: 2.9.1
MessagesFromJS cmd_id = 1, msg_type = 1, msg_type_name = Start
cwd: /Users/rld/src/deno
argv ./out/Debug/deno_cc_nosnapshot,hello.js

real    0m3.800s
user    0m3.720s
sys    0m0.072s
Faris Amali Alis
@f-a-a
cool!! I would love to work on more deno stuff but I can't tell what the priorities are from the issues. Any cues?
Ryan Dahl
@ry
@f-a-a it's a bit difficult just at the moment because we're trying to fork lift the prototype JS code onto the rust code
but let me think about it if there's something independent
one we've finished this fork lift, it will be more obvious where people can contribute
Ryan Dahl
@ry
@f-a-a ry/deno#362
maybe that's an issue you could look at
Faris Amali Alis
@f-a-a

@f-a-a Great job on that commit! This is very helpful

sorry didn't see this earlier, thank you @ry for the kind words! :beers:

robbym
@robbym
@ry I made a cargo subcommand that does what you want for ry/deno#366
I don't know how you feel about third-party cargo subcommands though.
Faris Amali Alis
@f-a-a
@ry @robbym following from our discussions in #370 , I've added a comment to the issue to summarize: https://github.com/ry/deno/issues/366#issuecomment-405731652

but I'm guessing:

I don't know how you feel about third-party cargo subcommands though.

this discussion still stands...

robbym
@robbym
@f-a-a Did you manage to get download-deps working with the rest of the build system btw?
I'm trying to but am getting:
ninja: error: '../../third_party/rust_crates/percent_encoding/lib.rs', needed by 'obj/build_extra/rust/libpercent_encoding.rlib'
missing and no known rule to make it
Faris Amali Alis
@f-a-a
not quite...
  1. It fails when the directory (i.e //third_party/rust_crates) is not found (but I see that you've addressed in your latest commit)
  2. Installed crate naming, related to :point_up:
yeah the reason you are getting that is because the installed crates are named with versions appended to it
robbym
@robbym
I made it rename the folder to just the regular name a few commits back.
Faris Amali Alis
@f-a-a
oh, let me see if I can have it working
last I checked, the installed libraries with your subcommand generated these directory names:
third_party/rust_crates
├── 2efa106 <- this was created when using git semantics in Cargo.toml
├── idna-0.1.5
├── libc-0.2.42
├── matches-0.1.6
├── percent-encoding-1.0.1
├── percent_encoding
├── unicode-bidi-0.3.4
├── unicode-normalization-0.1.7
└── url-1.7.1

10 directories, 0 files