14 Jul

    Revisiting Primitives and Special Forms in GoLisp

    14 Jul 2015

    by Dave Astels

    For V1.0, I revisited the way primitive functions are handled to make them work more like regular functions (i.e. defined in Lisp using define/lambda). The visible change if you are writing primitives is that they now recieve evaluated arguments. I.e. they use applicative order of evaluation now. This is as it should be.

    Read full post

    29 Jun

    Announcing SteelSeries GameSense™ Beta

    29 Jun 2015

    by Dave Astels

    You’ve been able to use your SteelSeries hardware to provide input to your games since, well, forever. That is what SteelSeries products are for, afterall. But now, with the beta release of GameSense™, you can use your SteelSeries hardware to display game state information.

    Why is this interesting? Well, it’s pretty cool to start with. But it can be quite useful as well. Imagine watching an event where each player has their health level dsplayed as the color of their headset lighting. Imagine playing Minecraft and seeing your hunger level, breath, direction you are facing, and even what tool you are holding and it’s durability all displayed on your keyboard. How about getting notified when spells and abilities are available again after their cooldown expires? Now make that all user customizable.

    That’s just the start of what GameSense™ can do.

    Read full post

    12 May

    First class environments for SteelSeries/GoLisp

    12 May 2015

    by Dave Astels

    Scheme (and thus GoLisp) is lexically scoped. This is implemented by the creation of a lexical environment (aka symbol table) for each lexical scope:

    • function/lambda/macro invocations, which holds parameters and any local definitions
    • let structures, which hold the let bindings
    • do structures, which hold the do bindings

    Functions and lambdas capture a reference to the environment in which they were defined, so they always have access to its bindings (that’s a closure, btw).

    Each environment has a connection to its containing environment, and can override/hide bindings in outer scopes. When a symbol is evaluated, the most local environment is searched first. If a binding for the system isn’t found there, the containing environment is searched. This continues until a binding for the sybol is found or we go all the way to the global environment and still can’t find a binding.

    Section 3.2 of [1] does a great job of explaining environments in Scheme, which is the basis for environments in GoLisp.

    In Scheme, some environments are more important than others, mainly as they tend to be larger, long lived, and serve as the root of many other environments as a program runs. These are known as top level environments. Specifially, these are the global environment (the only environment that is contained by nothing), and any environments directly below it in the environment tree. The REPL runs in one such environment, which effectively sandboxes it, protecting the bindings in the global environment from corruption.

    In standard Scheme, environments are first class objects. That is, they can be passed around, returned, manipulated, etc. I’ve recently added this ability to GoLisp, along with the majority of the environment manipulation functions from Scheme. These are described below.

    Read full post

    02 Feb

    What's New in Engine 3.3.3

    02 Feb 2015

    by The SteelSeries Engine Team

    We recently released Engine 3.3.3, with new features and new devices. Let’s look at what 3.3.3 includes.

    Read full post

    31 Jan

    GoLisp: Same great taste, less filling

    31 Jan 2015

    by Dave Astels

    When I first wrote GoLisp I wasn’t overly concerned with space efficiency as the immediate use was quite small scale. I was also fairly new to Go at the time. As time has gone on, we have been writing more and more production code in GoLisp. Space and time performance is something that we would now like to improve as we go forward.

    Read full post