Code Monkey home page Code Monkey logo

playdate-nim's People

Contributors

ninovanhooff avatar nycto avatar paulstraw avatar samdze avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

playdate-nim's Issues

How to deal with "declared lock level is 0, but real lock level is <unknown> [LockLevel]"

proc getLevelPaths(): seq[string] {.locks:0.} =
  playdate.file.listFiles("levels")

The above code snippet triggers a declared lock level is 0, but real lock level is <unknown> [LockLevel] warning.
Can be fixed by adding {.locks:0.} to the listFiles function.

But I wonder: can we disable this check altogether, since lck are for thread-safeness and we don't have threads on Playdate?

If that is not acceptable, can we add locks:0 to the {.push} pragma in all the api files?

Conflicting types

I've installed it on windows according to all the docs and I get this error no matter what I do.

playdate\api.nim:53:28: error: conflicting types for 'NimMain'; have 'void(void)'
53 | return -1

This is just using the test setup in the documentation

Playdate memory allocator

Hiya!

I've been working on debugging a device-only crash that I think is related to memory corruption. I started a thread about it on the playdate forum here:

https://devforum.play.date/t/device-crash-for-c-nim-based-game/16205

While investigating, I noticed that it doesn't appear that Nim is using the malloc implementation provided by the playdate SDK. I tried adding logging into the memory allocating methods in setup.c from the Playdate SDK and they were never being called. It look like Nim directly calls malloc from <stdlib.h>, as seen here:

https://github.com/nim-lang/Nim/blob/version-2-0/lib/system/mm/malloc.nim#L5

Does that sound right? Have you looked into overriding the default Nim malloc implementation to use playdate's realloc? Or have I got this all wrong?

When importing std/logging, device compilation fails

Feel free to ignore this since I don't actually need this import. I'm mostly recording this issue for posterity.

But; when importing std/logging, compilation for osx simulator still works fine, but nimble device fails with:

โฏ nimble device
  Executing task device in /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/wheelsprung.nimble
  Verifying dependencies for [email protected]
    Reading official package list
   Checking for playdate@any version
      Info: Dependency on playdate@any version already satisfied
  Verifying dependencies for [email protected]
    Reading official package list
   Checking for https://github.com/ninovanhooff/nim-chipmunk-playdate@any version
      Info: Dependency on https://github.com/ninovanhooff/nim-chipmunk-playdate@any version already satisfied
  Verifying dependencies for [email protected]
   Building wheelsprung/wheelsprung using c backend
  Executing /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.2.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src --path:/Users/ninovanhooff/.nimble/pkgs/chipmunk7-7.0.3 -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/wheelsprung /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/wheelsprung.nim
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/nim.cfg' [Conf]
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/config.nims' [Conf]
Hint: used config file '/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/config.nims' [Conf]
...........................................................................................................................
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(1226, 22) Error: undeclared identifier: 'Tm'
candidates (edit distance, scope distance); see '--spellSuggest': 
 (2, 1): '$' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(1165, 6)]
 (2, 1): '$' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(718, 6)]
 (2, 1): '*' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(780, 6)]
 (2, 1): '*' [proc declared in /Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/pure/times.nim(788, 6)]
     Error: Build failed for package: wheelsprung
        ... Execution failed with exit code 256
        ... Command: /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.2.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src --path:/Users/ninovanhooff/.nimble/pkgs/chipmunk7-7.0.3 -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/wheelsprung /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/wheelsprung.nim
stack trace: (most recent call last)
/private/var/folders/ww/sx_qg7z51jz6bgr15k4_5y8m0000gn/T/nimblecache-3905360933/nimscriptapi_3772293278.nim(187, 16)
/Users/ninovanhooff/PlaydateProjects/playdate-nim/src/playdate/build/nimble.nim(85, 16) deviceTask
/Users/ninovanhooff/PlaydateProjects/playdate-nim/src/playdate/build/utils.nim(22, 10) nimble
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/system/nimscript.nim(273, 7) exec
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/system/nimscript.nim(273, 7) Error: unhandled exception: FAILED: nimble -d:device -d:release build --verbose [OSError]
     Error: Exception raised during nimble script execution

api aliases

In lua, it's common to alias the api's like gfx = playdate.graphics.

In nim, playdate isn't initialised yet when top-level code is executed. What is an efficient and safe way to do this?

I found that proc gfx(): ptr PlaydateGraphics = playdate.graphics

works, at least. But it's a shame it is evaluated on every usage.

So I guess

var gfx: ptr PlaydateGraphics

proc init() =
  gfx = playdate.graphics

Would be the way to go, although it has the requirement of no access to gfx before init is called?

player volume: double promotion warning

Using this code

#volume
    if currentPlayer.volume.left < 1.0f:
        currentPlayer.volume = min(1.0f, currentPlayer.volume.left + 0.1f)
    if fadeoutPlayer != nil:
        if fadeoutPlayer.volume.left > 0.0f:
            fadeoutPlayer.volume = max(0.0f, fadeoutPlayer.volume.left - 0.1f)
        else:
            fadeoutPlayer.stop()
            fadeoutPlayer = nil

I get this output for nimble all: simulator bulids fine, but on device there is an implicit conversion from float64

 *  Executing task: nimble all 

  Executing task all in /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example.nimble
  Verifying dependencies for [email protected]
    Reading official package list
   Checking for playdate@any version
      Info: Dependency on playdate@any version already satisfied
  Verifying dependencies for [email protected]
   Building playdate_example/playdate_example using c backend
  Executing /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:simulator -d:debug -d:NimblePkgVersion=0.8.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/playdate_example.nim
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/nim.cfg' [Conf]
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/config.nims' [Conf]
Hint: used config file '/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/config.nims' [Conf]
.................................................................................................................................
Hint:  [Link]
ld: warning: ignoring duplicate libraries: '-lm'
ld: warning: ignoring duplicate libraries: '-lm'
Hint: dsymutil /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example [Exec]
Hint: gc: arc; opt: none (DEBUG BUILD, `-d:release` generates faster code)
103863 lines; 1.094s; 146.242MiB peakmem; proj: /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/playdate_example.nim; out: /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example [SuccessX]
  Verifying dependencies for [email protected]
    Reading official package list
   Checking for playdate@any version
      Info: Dependency on playdate@any version already satisfied
  Verifying dependencies for [email protected]
   Building playdate_example/playdate_example using c backend
  Executing /Users/ninovanhooff/.nimble/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.8.0 --path:/Users/ninovanhooff/PlaydateProjects/playdate-nim/src -o:/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/playdate_example /Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/src/playdate_example.nim
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/nim.cfg' [Conf]
Hint: used config file '/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/config/config.nims' [Conf]
Hint: used config file '/Users/ninovanhooff/PlaydateProjects/playdate-dirtbike-experiment/config.nims' [Conf]
................................................................................................................
CC: ../../playdate-nim/src/playdate/sound.nim
CC: bike_engine.nim
/Users/ninovanhooff/.cache/nim/playdate_example_r/device/@mbike_engine.nim.c: In function 'updateBikeEngine__bike95engine_15':
/Users/ninovanhooff/.cache/nim/playdate_example_r/device/@mbike_engine.nim.c:534:21: warning: implicit conversion from 'float' to 'NF' {aka 'double'} to match other operand of binary expression [-Wdouble-promotion]
  534 |   if (!(T26_.Field0 < 1.0f)) goto LA27_;
      |                     ^
/Users/ninovanhooff/.cache/nim/playdate_example_r/device/@mbike_engine.nim.c:551:15: warning: implicit conversion from 'float' to 'NF' {aka 'double'} to match other operand of binary expression [-Wdouble-promotion]
  551 |    if (!(0.0f < T37_.Field0)) goto LA38_;
      |               ^
Hint:  [Link]
Hint: gc: arc; opt: speed; options: -d:release

When changing the nim api of volume to use explicit float32 instead of float...

proc volume*(this: SamplePlayer): tuple[left: float32, right: float32] =
    privateAccess(PlaydateSound)
    privateAccess(PlaydateSoundSampleplayer)
    var left, right: cfloat
    playdate.sound.sampleplayer.getVolume(this.resource, addr left, addr right)
    return (left: left.float32, right: right.float32)

The warning disappears.

Should we do this for all of the nim api?

Add module documentation

The module is a mapping of the C API, but it also provides other extra features, so, it would still be very useful to have in-editor support with full documentation coverage.

The C API documentation is available on the official Playdate SDK website.
Inside Playdate with C

Feature: Basic Lua interop

My Use case: I'm thinking of building a game that is mostly in Nim, but uses comic-style cutscenes. The Panels library is perfect for this: https://cadin.github.io/panels/docs/cutscenes.html

Unfortunately only available in Lua. Basic Lua interop is needed to realise this.
The recommended Panels api might be difficult to call from Nim
Example: Panels.startCutscene(comicData, callback) requires to call a function in a "namespace" (a global lua table, really) and requires two complex parameters.

I propose a more practical approach:

  1. In Lua, call the functions as the library offers them, and expose that as a global Lua function without parameters and return values
isCutsceneRunning = false

local cutsceneFinishedCallback = function()
  isCutSceneRunning = false
end

function getCutsceneRunning()
  return isCutsceneRunning
end

function startChapter2Cutscene()
  local comicData = [..]
  Panels.startCutscene(comicData, callback)
  isCutsceneRunning = true
end

-- nice to have / stretch goal: support for simple parameter types like int and bool:

function startChapterCutScene(chapterNumber)
  Panels.startCutscene(comicDatas[chapterNumber], callback)
  isCutsceneRunning = true
end
  1. In Nim, call the lua function to start a cutscene when necessary:
let (result, errorMessage) = playdate.lua.callFunction("startChapter2Cutscene")

proc update(): int
  var (result, errorMessage) = playdate.lua.callFunction("getCutsceneRunning")
 (result, errorMessage) = playdate.lua.callFunction("updatePanels")
  return 1

hmmm. At this point I realise that the playdate api doesn't allow for reading lua globals (isCutSceneRunning), or getting a return value from a lua function. In the example above, result is just an int indicating whether an error occurred.

If I'm not missing something, this implies we would also need to implement the playdate.lua.addFunction so that we can

var isPanelsCutsceneRunning = false

proc panelsCutsceneFinished()
  isPanelsCutsceneRunning = false

proc handler(event: PDSystemEvent, keycode: uint) {.raises: [ValueError].} =

    if event == kEventInitLua:
        let addFuncError = playdate.lua.addFunction(panelsCutsceneFinished, "onPanelsCutsceneFinished")

We can then call this from lua:

function startChapter2Cutscene()
  local comicData = [..]
  Panels.startCutscene(comicData, onPanelsCutsceneFinished)
end

So, in summary, I would like to have available:

  • playdate.lua.addFunction(someProc). For my usecase no parameters and no return types are needed for someProc)
  • playdate.lua.callFunction. For this, no arguments need to be passed to the lua function, although it would nice to have

I would encourage implementing the outerror that the playdate api returns, so that I as a developer can check whether the calls were succesful

LCD:Sprite.setImage crashes when invoked multiple times

This might be developer error on my part, but let's see...

When this lambda is invoked a few times, the debugger hangs on a SIGABRT after a few invocations. Note this might not happen when you set a breakpoint, because that reduces the amount of times per second the function will be invoked.
Happens on both sim and device

let fSpriteSetImage: TestLambda = proc() =
    playerSprite.setImage(testSprite, kBitmapUnflipped)
    (discard)

Reproduce:

  • Check out the bench branch of this project and run it. That should run without trouble

This project is a benchmark that invokes api methods multiple times. Note that setImage is used in other places as well (1x per sprite) without problem

  • In bech.nim; Change (name: "spriteSetImage - Bench Error?", lambda: fNotImplemented), to (name: "spriteSetImage - Bench Error?", lambda: fSpriteSetImage),
    Running again will cause the debugger to halt at this exception:
    image

Note1 that the debugger shows that the free property of image is true. Not sure what that means but it might be relevant.
Note2: the name of the testSprite in this project is misleading, it is actually of type LCDBitmap

Unclear naming requirement for main entrypoint nim file

I adopted the sample project, and it took me some trial and error to find out what the naming requirements were for various parts.

My project is called wheeelsprung

I was unaware that the name of the nimble file defines the project name, and that there exists a requirement for that to match the value of bin in that nimble file.

At some point I used main.nim as the entrypoint for my game and also used

wheelsprung.nimble

bin           = @["main"]

accordingly. I then had some file not found errors. When changing main to wheelsprung everywhere to match wheelsprung.nimble, the problem was resolved.

Perhaps, I would not have run into this problem when starting from scratch (nim setup).

My suggestion: add a comment to the example .nimble file:

## the main entrypoint of your game. In this example the file `<project root>/src/playdate_example.nim` is
## the first nim file that is executed when the game is started
srcDir        = "src"
bin           = @["playdate_example"]

Implement Std/random

importing std/random or std/re fails. There may be more, but these are the ones I encountered so far

I'd say random is quite essential for game dev, would be great if it could be added.

nim-1.6.16/lib/pure/os.nim(63, 10) Error: OS module not ported to your operating system!

I wouldn't give the regex module any priority at the moment.

I wonder how many Std modules are OS dependent?

Does not compile with Nim 2.0.0

When trying to compile the basic example project after following all the instructions, I get the following errors:

nimble simulator
  Verifying dependencies for [email protected]
     Info:  Dependency on playdate@any version already satisfied
  Verifying dependencies for [email protected]
  Executing task simulator in /Users/simjnd/Documents/Lab/pdnim-test/pdnim_test.nimble
  Verifying dependencies for [email protected]
     Info:  Dependency on playdate@any version already satisfied
  Verifying dependencies for [email protected]
   Building pdnim_test/pdnim_test using c backend
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/std/typedthreads.nim(51, 10) Error: Threads not implemented for os:any. Please compile with --threads:off.
       Tip: 4 messages have been suppressed, use --verbose to show them.
nimble.nim(229)          buildFromDir

    Error:  Build failed for the package: pdnim_test
stack trace: (most recent call last)
/private/var/folders/41/034yz3fs4f3_lj9tkvwjvw5m0000gn/T/nimblecache-189809156/nimscriptapi_3428472986.nim(210, 16)
/Users/simjnd/.nimble/pkgs/playdate-0.7.2/playdate/build/nimble.nim(78, 5) simulatorTask
/Users/simjnd/.nimble/pkgs/playdate-0.7.2/playdate/build/nimble.nim(10, 5) nimble
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/system/nimscript.nim(265, 7) exec
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/system/nimscript.nim(265, 7) Error: unhandled exception: FAILED: nimble -d:simulator build [OSError]
       Tip: 3 messages have been suppressed, use --verbose to show them.
nimscriptwrapper.nim(160) execScript

    Error:  Exception raised during nimble script execution

When trying to disabled threads, the following error message appears:

Verifying dependencies for [email protected]
     Info:  Dependency on playdate@any version already satisfied
  Verifying dependencies for [email protected]
   Building pdnim_test/pdnim_test using c backend
/opt/homebrew/Cellar/nim/2.0.0_1/nim/lib/system/osalloc.nim(218, 10) Error: Port memory manager to your platform
       Tip: 4 messages have been suppressed, use --verbose to show them.
nimble.nim(229)          buildFromDir

    Error:  Build failed for the package: pdnim_test

Runtime crashes halt simulator without any indication of problems

This had me stumped for some time because the background music keeps playing, so really only the screen freezing gives an indication that something went wrong.

Am I missing something?

I would expect a stack trace in the simulator console and attached debugger console.

Here is a workaround: wrap the update call with:

import strformat

proc catchingUpdate(): int = 
    try:
        return update()
    except:
        var message: string = ""
        try: 
            message = &"{getCurrentExceptionMsg()}\n{getCurrentException().getStackTrace()}\nFATAL EXCEPTION. STOP"
        except:
            message = getCurrentExceptionMsg() & getCurrentException().getStackTrace()
            playdate.system.error(message) # this will stop the program
            return 0 # code not reached

... and set catchingUpdate as the update callback.

Produces

index -1 not in 0 .. 99
/Users/ninovanhooff/.nimble/pkgs/playdate-0.10.0/playdate/system.nim(38) privateUpdate
/Users/ninovanhooff/PlaydateProjects/nim_snake/src/nim_snake.nim(135) catchingUpdate
/Users/ninovanhooff/PlaydateProjects/nim_snake/src/nim_snake.nim(110) update
/Users/ninovanhooff/.choosenim/toolchains/nim-1.6.16/lib/system/fatal.nim(54) sysFatal

FATAL EXCEPTION. STOP

Rather than doing this in the program itself, playdate/system.nim might be a better place for a catch-all.

Build for device OS 2.0 error: undefined reference to `_fini'

Playdate OS 2.0 brought some changes to how C games are built.
This unexpectedly made the example Nim project unable to compile.

This is the error the compiler outputs:

...
fini.c:(.text.__libc_fini_array+0x20): undefined reference to `_fini'
collect2: error: ld returned 1 exit status
make: *** [build/pdex.elf] Error 1

Workaround:
manually defining and exporting to C a _fini function somewhere in the codebase fixes the issue:

proc fini() {.cdecl, exportc: "_fini".} =
    discard

The error seems to be caused by Nim generating C code that calls exit, which is not supported by the Playdate.
The exit calls generated by Nim seem related to exception handling.

Mac device Debug builds for device profiling

For profiling device code on Mac, an .elf file is needed. This is currently not generated.
I'm assuming this would be, if we could build device debug builds on mac.
The source mentions this is currently not supprted. I'm wondering what would be needed to make this possible

image

implement os module

import os

sleep(1000)

Gives a OS module not ported to your operating system error

Publish to nimble

Are there any plans to make this repo available as a nimble module?

I know there are some specific build configurations required to allow a module to build, but I think those can also be vended.

Cheers!

Use `projectName()` instead of static PDX name?

๐Ÿ‘‹ figured I'd start with some easy feedback. It's very possible I'm just missing something. Right now when I build, the output is a playdate.pdx. That means when I upload to device via the sim, other apps with that PDX name get overwritten.

It seems like this should be easy to change by updating the bundlePDX build proc to use projectName():

exec(pdcPath() & " --verbose -sdkpath " & sdkPath() & " source " & projectName())

This change seems to work well for me locally, but I'm not sure whether there's a specific reason it's set up like this, so I figured I'd open an issue instead of just PRing.

Add an extension system for pluggable build-time tasks

The idea is to explore whether/how NimScript can allow us to plug-in custom tasks to perform when the user builds the project.

Here's an examples of a use case, but can be applied to all kinds of assets pre-processing:

A task that searches for image files with a predetermined suffix and generates spritesheets containing rotations of the original images. Useful to optimize rotated images drawing on device.

The pluggable tasks could be other packages, but this is still to be decided depending on ease of use and amount of setup/configuration to be done.

An implementation of the use case above can initially be provided embedded in this module.

sigabrt: double free when calling file.close()

It seems the nim-bindings take care of closing files when they go out of scope. This is kind of nice, but it was unexpected for me.

This creates opportunity for a dev to trigger a double free: when the game-dev uses file.close() the file is free-ed, and subsequently by the nim bindings =destroy again. This could lead to a SIGABRT: double free with a stacktrace that leads to:

/home/nino/.nimble/pkgs/playdate-#main/playdate/file.nim(35) =destroy

Note that this has only been observed when building for Linux, with the fPIC compiler argument. (I added that argument because the compiler itself suggested to do so). When building for mac, win or device, this behavior is not triggerd

I'd say that the bindings should not expose file.close() if it is not intended to be used by game devs. Indeed the example project doesn't use it either.

As it is, I think it is easy to trip up here. Even in menory managed languages like Java, devs are expected to call file.close()

arm-none-eabi-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directory

I get the above error when compiling the example on an M1 Mac, with Nim installed from source. Details below - any help would be greatly appreciated!

% nim -v
Nim Compiler Version 1.6.18 [MacOSX: arm64]
Compiled at 2024-01-11
Copyright (c) 2006-2023 by Andreas Rumpf
% nimble -v
nimble v0.13.1 compiled at 2024-01-11 20:22:03
git hash: d13f3b8ce288b4dc8c34c219a4e050aaeaf43fc9
% arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/arm-none-eabi-gcc/13.2.0/libexec/gcc/arm-none-eabi/13.2.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --target=arm-none-eabi --prefix=/opt/homebrew/Cellar/arm-none-eabi-gcc/13.2.0 --infodir=/opt/homebrew/Cellar/arm-none-eabi-gcc/13.2.0/share/info/arm-none-eabi --disable-nls --without-isl --without-headers --with-as=/opt/homebrew/opt/arm-none-eabi-binutils/bin/arm-none-eabi-as --with-ld=/opt/homebrew/opt/arm-none-eabi-binutils/bin/arm-none-eabi-ld --enable-languages=c,c++
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (GCC)

Error message:

% nimble device
  Executing task device in /Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/playdate_example.nimble
  Verifying dependencies for [email protected]
    Reading official package list
   Checking for playdate@any version
      Info: Dependency on playdate@any version already satisfied
  Verifying dependencies for [email protected]
   Building playdate_example/playdate_example using c backend
  Executing /Users/sdwfrost/Programs/Nim-1.6.18/bin/nim c --colors:on --noNimblePath -d:device -d:release -d:NimblePkgVersion=0.8.0 --path:/Users/sdwfrost/.nimble/pkgs/playdate-0.12.0 -o:/Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/playdate_example /Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/src/playdate_example.nim
Hint: used config file '/Users/sdwfrost/Programs/Nim-1.6.18/config/nim.cfg' [Conf]
Hint: used config file '/Users/sdwfrost/Programs/Nim-1.6.18/config/config.nims' [Conf]
Hint: used config file '/Users/sdwfrost/Projects/playdate/playdate-nim/playdate_example/config.nims' [Conf]
..........................................................................................................
CC: setup
CC: ../../../../../Programs/Nim-1.6.18/lib/std/private/digitsutils.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system/formatfloat.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system/dollars.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system/repr_v2.nim
CC: ../../../../../Programs/Nim-1.6.18/lib/system.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/utils.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/graphics.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/system.nim
CC: ../../../../../.nimble/pkgs/playdate-0.12.0/playdate/bindings/file.nim
arm-none-eabi-gcc: fatal error: cannot read spec file 'nosys.specs': No such file or directory
compilation terminated.

Any guidance on unit tests?

I see the main repo contains tests, but the playdate_example doesn't. The Nim docs mentoin the existence of the unittest module and the testament executable. Briefly tried testament, but I think it tried to compile my project for the host system (apple arm64) and failed. Decided not to dive into that rabbit hole. My testing requirements are simple:

  • no need to test any playdate api's, only pure Nim utility functions (mostly math)
  • Should not run in release device builds
  • Should give a clear message indicating what test failed
  • nice-to-have: test report showing multiple failed tests

My current approach uses a bunch of asserts, which are placed outside of the src folder. The runTests proc is wrapped in a catching function that prints a stacktrace to the playdate error console, which halts execution. Therefore, it only shows the first failed test

So I'm wondering whether there is a recommended approach for this, and what you think of my current approach: https://github.com/ninovanhooff/wheelsprung/tree/rider/

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.