<Check Object "If there is not an object at (x,y)">
{
<Create Instance "create instance of object at (x,y)">
}
...
Using Game Maker events, I created a repeated process like the one above, checking one space and then the other, and filling all the empty ones. The code works fine, but I want to add a message at the end ONLY IF NONE OF THE SPACES ARE EMPTY. I tried using an ELSE at the end, but that only uses the very last if.
Sorry for bad wording, I can elaborate if needed.
What you want is an if-else if-else structure. You can do this by nesting conditions:
if () {
...
} else {
if(...) {
...
} else {
if(...) {
...
} else {
...
}
}
}
Though your code would be easier to read were it to use GML, rather than the visual language, as in GML you can do this:
if () {
...
} else if(...) {
...
} else if(...) {
...
} else {
...
}
Related
I'm exploring optimizations for the HVM, a parallel functional runtime written in Rust. The way it works by spawning several threads, and then having each one busy on a main work loop where tasks are popped and executed. It works more or less like this:
// Modes
enum Mode {
Visiting, // visits a node
Reducing, // applies a rewrite rule
Fetching, // pops a local task
Stealing, // steals a global task
}
// Main loop
loop {
match mode {
Visiting => { ... do stuff ... }
Reducing => { ... do stuff ... }
Fetching => { ... do stuff ... }
Stealing => { ... do stuff ... }
}
}
// Change mode with:
mode = Mode::Visiting;
continue 'main;
I expected Rust's compiler to optimize that to a goto, but, to my surprise, it doesn't. In an attempt to improve the situation, I've replaced the Mode enum by two booleans, and adjusted my loop as follows:
// Modes
let mut a : bool;
let mut b : bool;
// Main loop
loop {
if a {
if b {
... do stuff ...
} else {
... do stuff ...
}
} else {
if b {
... do stuff ...
} else {
... do stuff ...
}
}
}
// Change mode with:
a = true;
b = true;
continue 'main;
To my surprise, this small change resulted in a ~15% improvement on the overall performance of HVM's runtime! This is still not ideal though. If I was in C, I'd just have labels, and jump via GOTO. My question is: can I change my Rust code in a way that will let the compiler optimize to the expected jumping code? I.e., something like this?
// Main loop:
loop {
'visiting { ... do stuff ... }
'reducing { ... do stuff ... }
'fetching { ... do stuff ... }
'stealing { ... do stuff ... }
}
// Change mode with:
goto 'visiting
I'm looking to possibly help update the File::HomeDir module which was never finished. While inspecting it, I noticed that stubbed out methods were causing infinite loops:
In the File::HomeDir role:
unit class File::HomeDir;
use File::HomeDir::Win32;
use File::HomeDir::MacOSX;
use File::HomeDir::Unix;
my File::HomeDir $singleton;
method new
{
return $singleton if $singleton.defined;
if $*DISTRO.is-win {
$singleton = self.bless does File::HomeDir::Win32;
} elsif $*DISTRO.name.starts-with('macos') {
$singleton = self.bless does File::HomeDir::MacOSX;
} else {
$singleton = self.bless does File::HomeDir::Unix;
}
return $singleton;
}
method my-home {
return File::HomeDir.new.my-home;
}
method my-desktop {
return File::HomeDir.new.my-desktop;
}
<snip>
In the File::HomeDir::MacOSX module:
use v6;
unit role File::HomeDir::MacOSX;
method my-home {
# Try HOME on every platform first, because even on Windows, some
# unix-style utilities rely on the ability to overload HOME.
return %*ENV<HOME> if %*ENV<HOME>.defined;
return;
}
method my-desktop {
!!!
}
<snip>
With this code, calling say File::HomeDir.my-desktop; results in an infinite loop.
This module was first written about 5 1/2 years ago. I'm assuming it worked at the time. But it appears now that if a role method has a listop operator, it causes the parent's class to be called which then called the role method which then calls the parent class, etc.
I'd do it like this, staying close to the original design:
role File::HomeDir::Win32 {
method my-home() { dd }
method my-desktop() { dd }
}
role File::HomeDir::MacOSX {
method my-home() { dd }
method my-desktop() { dd }
}
role File::HomeDir::Unix {
method my-home() { dd }
method my-desktop() { dd }
}
class File::HomeDir {
my $singleton;
# Return singleton, make one if there isn't one already
sub singleton() {
without $singleton {
$_ = File::HomeDir but $*DISTRO.is-win
?? File::HomeDir::Win32
!! $*DISTRO.name.starts-with('macos')
?? File::HomeDir::MacOSX
!! File::HomeDir::Unix;
}
$singleton
}
method my-home() { singleton.my-home }
method my-desktop() { singleton.my-desktop }
}
File::HomeDir.my-home;
File::HomeDir.my-desktop;
I am trying to refrence the base class to change a sub class based on a BEM modifier.
This works well in SASS, but I'm working with LESS now.
Heres the SASS refrence...
https://css-tricks.com/the-sass-ampersand/
And heres the code that dosn't work...
.s-body {
#self: &;
...
&__door {
...
&--state-past {
#{#self}__image {
...
}
}
}
&__image {
...
}
}
It isn't possible in LESS to assign the current class to a variable using an ampersand (&). But you can set the class name as a variable like this:
.s-body {
#self: .s-body;
}
After that, you can use the variable as a selector like this: #{self}. For further explanation, check the LESS documentation: http://lesscss.org/features/#variables-feature-variable-interpolation
In your example, this will result in the following code:
.s-body {
#self: .s-body;
&__door {
&--state-past {
#{self}__image {
}
}
}
&__image {
}
}
I want to implement a different error handling approach in a project without chaining exceptions.
To make it simple as possible, I am tend to write my own basic either-like model.
class Either<F, T> {
final F failure;
final T value;
const Either(this.failure, this.value);
Object check (){
if (failure != null) return failure;
return value;
}
}
I am concerning about returning the type Object, is there any problem or considerations with that in Dart or any other language?
Edit:
or returning dynamic type...
dynamic check(){
if (failure != null) return failure;
return value;
}
I think in your case, it's kind of a wired implementation. The question is, what do you want to do with the actual implementation ? Do you want to replace an if else that will appear over and over? In that case, what would you do if you have to handle the error (failure) ? I think a better approach is to use functions as parameters. Here's a short suggestion.
class Either<T, F> {
T value;
F fail;
Either(this.value, this.fail);
void check(success(T value), {failure(F fail)}) {
if (fail != null && failure != null) {
failure(fail);
} else if (value != null) {
success(value);
}
}
}
class SomeClass {
void checkTheImplementation() {
Either<String, Error> maybeString = Either("testing", null);
// if you don't want to handle the error.
maybeString.check((value) => print(value));
// if you want to handle the error
maybeString.check((value) => print(value), failure: (err) {
print(err.toString());
});
}
}
I have looked over and decided to go with baihu92's either_type way. It's much more clear and comprehensible than either in the dartz package. Here is my implementation:
and the usage is like:
Consider the following code:
enum MyErrorType:ErrorType {
case BadTimes
}
var mightHaveAValue: String?
do {
if let value = mightHaveAValue {
// do stuff with value
} else {
throw MyErrorType.BadTimes
}
// do stuff with NSFileManager using mightHaveAValue which might throw
} catch {
// handle error
}
...in which I have a large do/try/catch block. In this instance the error handling will be the same, whether mightHaveAValue is empty or something bad happens with NSFileManager later on. So it makes sense to re-use the error handling code.
Is this the cleanest approach going in Swift2, or is there some way I can automatically throw/catch on unwrapping an optional with no value?
It looks ok, but it's even better with guard let instead of if let because it lets you use the unwrapped value in the main do block instead of having to work inside an if let branch. You can also use several catch branches to handle different error types.
do {
guard let value = mightHaveAValue else {
throw MyErrorType.BadTimes
}
// do stuff with value
} catch let error as MyErrorType {
// handle custom error
} catch let error as NSError {
// handle generic NSError
}
There is no automatic way to handle unwrapping optionals, you have to use one of the many known ways: if let, guard let, nil coalescing, etc.
Maybe just use an extension like this 🤔
extension Optional {
func throwing() throws -> Wrapped {
if let wrapped = self {
return wrapped
} else {
throw NSError("Trying to access non existing value")
}
}
}