New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallel commands #70

Closed
odino opened this Issue Dec 23, 2018 · 3 comments

Comments

Projects
None yet
1 participant
@odino
Copy link
Collaborator

odino commented Dec 23, 2018

Syntax

`command &`

Just like you would do on a bash terminal. This has the disadvantage of not being 100% 1:1 with windows, but we'll get there eventually (I think on win you simply use start command so it shouldn't be a big thing).

The command will run without blocking execution.

Waiting

cmd.wait()

Testing whether a command has been executed

cmd.done

@odino odino added the enhancement label Dec 23, 2018

@odino odino added this to the cauldron milestone Dec 23, 2018

@odino

This comment has been minimized.

Copy link
Collaborator Author

odino commented Dec 26, 2018

Example:

ip = $$(curl canihazip.com)
echo("sending request...")
ip.wait()
echo(ip)

@odino odino modified the milestones: cauldron, 1.0 Dec 29, 2018

@odino odino modified the milestones: 1.0, cauldron Jan 13, 2019

@odino odino modified the milestones: cauldron, 1.1 Jan 26, 2019

@odino odino modified the milestones: 1.1.x, 1.2.x Feb 2, 2019

@odino

This comment has been minimized.

Copy link
Collaborator Author

odino commented Feb 4, 2019

Here some possible scenarios:

$$(sleep 10)
&(sleep 10)
&$(sleep 10)
$(sleep 10)&
$`sleep 10`
&`sleep 10`
`sleep 10`&
bg`sleep 10`
bg$(sleep 10)

They all seem very wonky, so not sure right now.

In order to wait / do something after execution here's what I'm thinking:

cmd = ...

cmd.wait()
..do things...

# and
cmd.on('end', f(res) { ..do things...})

# and
if cmd.done() {
  ..do things...
}

I think supporting all 3 of them is not a big problem, my main worry is the syntax do declare background commands. Bash does this beautifully with the trailing &, so I'm leaning towards `sleep 10` &

Thought of the day: `sleep 10&` blocks in ABS. If we can find a way to understand whether the process is running in background then we're sorted and don't need any special syntax. Ref. We could even "fake" this whole process by checking whether the last char of our command is an &, and turn that into a background command automagically. Very on the fence at the moment :)

@odino

This comment has been minimized.

Copy link
Collaborator Author

odino commented Feb 7, 2019

Syntax and issue updated, I will start on this now.

@odino odino self-assigned this Feb 7, 2019

odino added a commit that referenced this issue Feb 12, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

odino added a commit that referenced this issue Feb 12, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

odino added a commit that referenced this issue Feb 13, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

odino added a commit that referenced this issue Feb 14, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

odino added a commit that referenced this issue Feb 18, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

odino added a commit that referenced this issue Feb 18, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

odino added a commit that referenced this issue Feb 18, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

odino added a commit that referenced this issue Feb 18, 2019

Experimental support for background commands, closes #70
This was easier than I though, but it required some changes here
and there.

The `String` object now has an internal mutex, used to keep hold of
the value of the command until it's executed.

What really changed is that:

* regular commands go through "normally"
* background commands are defined as commands that end with `&` (`$(sleep 1 &)`)
* background commands are launched in a goroutine and "locked" with the above mutex
* when the command is over, we set its output and release the mutex
* added the `cmd.wait()` function which will try to acquire the lock on the mutex, thus waiting until the command is done
* added the `.done` property on string to understand whether a command is done or not

Fun things that we can do now:

```
cmd = `sleep 10`
echo("This will be printed in 10s")

cmd = `sleep 10 &`
echo("This will be printed immediately")
sleep(9000)
cmd.done # FALSE
cmd.ok # FALSE
echo("We have been waiting 9s")
cmd.wait()
echo("And approximately another second")
cmd.done # TRUE
cmd.ok # TRUE
```

@ntwrick hat do you think?

@odino odino closed this Feb 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment