onepub-dev / onepub-dev/dcli

Implement Runnable concept

Open
#11 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Dart
Stars
265
Forks
30
PR merge metrics
No merged PRs in 30d

Description

In addition to the ideas below:

The one problem with the below concept is that if you write:
find('*.jpg')
nothing will happen.
Consider having the 'find' command return a 'Runnable' object.
The Runnable object contains a future with a 500ms delay.
If the runnable isn't executed in 500ms then the future outputs a warning to the console
telling the user that the forgot to place a verb after the find.
This is likely to be dumped out in the midst of other code but given the importance I think this is ok.
Will need to include a stacktrace with line no. give the above noted disassociation with the original find line.

I've been struggling with the find function

find('*.jpg').forEach((file) => print(file));

The above syntax is elegant but it has a fundamental problem.

The mandate for dshell is that all builtin functions are to be sync so users don't have to worry about futures.

This causes a problem.

In the above find example the order of execution is:

find - runs to completion and finds all files

returns a ForEach object

ForEach.forEach runs and prints all the files.

What this means is that you don't get to see any output until the find completes and all of the files found are stored in a stream consuming memory which could exhaust heap.

So I had this neat idea.

We have a class of functions that (for what of a better term) I refer to as runnables.

Runnables don't run.

Rather the require a 'verb' to run.

So the verbs would be:

forEach(...)

run

print

asList - potential to cause memory issues but that would be the users decision.

So if you write:

find('*.jpg')

nothing happens, the find doesn't run because its a runnable and you must provide a verb

if you now write:

find('*.jpg').print

The find command creates a runnable, returns it and the 'print' verb is executed on the runnable.

The runnable can now output the file names as the find command runs rather than waiting for the find command to complete.

We now get progressive output and eliminate our heap problems.

So now when you write:

find('*.jpg').forEach((file) => print(file));

The file names are printed as you go.

What do you think of the syntax?

Is it confusing that writing:

find('*.jpg')

does nothing?

Currently there would only a small no. of runnables:

head

cat

read

find

and of course the existing string runnables:

'tail -f /var/log/syslog'.run

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing string runnable behavior, particularly 'tail -f /var/log/syslog'.run, then examine how the issue's find, head, cat, and read commands would expose the proposed verbs. The work is complete when the Runnable design, delayed warning behavior, stack trace handling, and progressive output semantics are defined and implemented consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
dart
Domain
cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.