aardappel / lobster Goto Github PK

The Lobster Programming Language

Makefile 0.20% C 28.13% Java 3.68% C++ 66.54% Assembly 0.38% CMake 0.19% Batchfile 0.04% Shell 0.01% JavaScript 0.06% TypeScript 0.78%

lobster's People

Contributors

Stargazers

Watchers

Forkers

astahl1 bradparks tanakahisateru lbohni cheshireswift tom-seddon laudarch dawidvc slagusev johnicholas deltawhy fdanielsen gnusosa tommyettinger cloudxtreme binji the-mad-pirate ezhangle javafreak88 aa10000 stethd t-mw bharathbsgowda stjordanis ricelang chewxy crazyguitar joshpurvis rahulsoibam shaunstanislauslau hhy5277 hoangpq colout linecode gitter-badger jacereda b1sounours davidbruce jcorbin shamrin kriskowal sbc100 j0ecool oieieio arvyy kripken cyb3rcrypt girish946 doytsujin kfabryczny unaimend autumn-birds joelibaceta sgraham gmacd mortimersnerd tinkerjoe-git shadowninja55 franko dcurrie acgaudette dbaileychess dibir-magomedsaygitov laplacekorea pombal kosmokleaner antonbogun rnshah9 dertee dheu3 bartwe suruz nunotexbsd samebchase altoplano ahribellah stolk icodein maierfelix forchid sidewinder1138 gteleshev dmitrykolesnikovich ishwar00 seanpm2001 ewoudje pacifio mattheww95 denise-amiga guldoman cdhagmann uamhforever arumry forksnd sarvex maxbyz shauryashaurya ghostconqueror geekstakulus jamestiotio

lobster's Issues

can't open file: stdtype.lobster

Mouse trapping on Linux

Mouse trapping in a window is currently broken on some systems. The SDL best practice is: SDL_SetRelativeMouseMode

That works for me. I'm not sure how it fits into Lobster as the code comments imply some mouse-trap-switching with gl prefixed commands. The above SDL function allows me to Alt-Tab out of the window, but it still responds to mouse movement when out of focus, so checking for focus may still be desired.

Confusing error when there's space between for and opening brace

I'm following through the Shooter tutorial. It's very nicely done, thank you!

However, I've spent 5-10 minutes figuring why Lobster fails when there's space between for and (. I found the error message to be very confusing:

game.lobster(44): error: missing arg to builtin function: for

I've even managed to make the same mistake in gl_circle call, but the error message was totally different, and similarly confusing:

game.lobster(48): error: ) expected, found: ,

Homepage example no longer valid

The homepage example is using the old include syntax.

Lobster font

Would be nice to use https://www.google.com/fonts/specimen/Lobster for branding this :)

Segmentation fault in reserved vector teardown

Given program:

import std
fatal(gl_window("Isolating test case", 400, 400))
let cache = vector_reserve(typeof resource, 1)

This program will exit with a segmentation fault.

Process:               lobster [7818]
Path:                  /Users/USER/*/lobster
Identifier:            lobster
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        vim [5580]
Responsible:           lobster [7818]
User ID:               501

Date/Time:             2019-11-17 14:52:51.027 -0800
OS Version:            Mac OS X 10.14.6 (18G1012)
Report Version:        12
Bridge OS Version:     4.1 (17P1081)
Anonymous UUID:        C5E594AB-DC1B-8095-B0AB-1AF755FE8D36

Sleep/Wake UUID:       E01A3DAD-DEE4-4837-B831-258FEAD8D14F

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000009
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [7818]

VM Regions Near 0x9:
--> 
    __TEXT                 000000010c616000-000000010c9fe000 [ 4000K] r-x/r-x SM=COW  /Users/USER/*

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   lobster                       	0x000000010c76b19e lobster::RefObj::DECDELETENOW(lobster::VM&) + 62
1   lobster                       	0x000000010c72149a int lobster::VM::VarCleanup<0>(std::__1::basic_ostringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, int) + 234
2   lobster                       	0x000000010c72119e lobster::VM::FunOut(int, int) + 782
3   lobster                       	0x000000010c71dc8a lobster::VM::EvalProgram() + 74
4   lobster                       	0x000000010c683798 EngineRunByteCode(lobster::VMArgs&&) + 40
5   lobster                       	0x000000010c6d4c76 main + 5526
6   libdyld.dylib                 	0x00007fff7d6943d5 start + 1

Thread 1:
0   libsystem_pthread.dylib       	0x00007fff7d8873f0 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	0x00007fff7d8873f0 start_wqthread + 0

Thread 3:
0   libsystem_pthread.dylib       	0x00007fff7d8873f0 start_wqthread + 0

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000001  rbx: 0x00007fc8f8064f80  rcx: 0x000000010c76b33c  rdx: 0x0000000000000000
  rdi: 0x0000000000000000  rsi: 0x00007ffee35e5f50  rbp: 0x00007ffee35e5e20  rsp: 0x00007ffee35e5e10
   r8: 0x00007ffee35e61d0   r9: 0x0000000000000001  r10: 0x0000000000000000  r11: 0x0000000000000000
  r12: 0x00007fc9070093cc  r13: 0x0000000000000001  r14: 0x00007ffee35e5f50  r15: 0x00007fc9070093c4
  rip: 0x000000010c76b19e  rfl: 0x0000000000010217  cr2: 0x0000000000000009
  
Logical CPU:     0
Error Code:      0x00000004
Trap Number:     14

Assert doesn't erase nilable when used in branch tail...

Rather it only seems to work when it's in the main branch.

This fails:

class such:
    x = 0

var much = nil

if not much:
    much = such {}
    assert much

much.x++
print(much)

much.x++
print(much)

With foo.lobster(10): error: type such? does not have field: x

But hoisting the assert much works.

This has been a contrived example, reduced down from something like:

a class with a nil-able resource? field
where I load it the first time through, something like if not tex: load()
where there's a def load() method that ends with an assert tex after having loaded from a file
I ended up just inlining the loader method, and hoisting its guard assertion into main control flow...

Feature request: choose random element

This is a request for design feedback before submitting a change.

A “choose one from vector” method would be handy in the standard library.

def foo(xs): xs[rnd(length(xs))]

I’ll follow up with some messages we can 👍 or 👎 for specifics details.

Sublime Text support

I've got a 90% solution for building with Sublime Text. (On windows)

The problem I'm running into is rooted in compiler errors. The output for an error looks like:
file.lobster(2): error: unknown identifier: foo

When parsed I get a filename of file.lobster, which is mostly okay. However, in order to invoke the compiler it has to either live on my path or I have to specify lobster.exe's path as the working directory. (otherwise we get can't open file: sdt.lobster)

If I specify the working directory as lobster.exe's path, I can't properly navigate to source files with errors as it tries to open them from the working directory.

If I add lobster.exe's path to my PATH I am still unable to build due to can't open file: std.lobster.

The easiest solution I see is to have the compiler output absolute path to file in errors.

It works fine if I don't try to use Sublime Text's error location opening to jump to the offending line. That is, I can compile (and even run if no errors) if I avoid the functionality.

Windows build problem: SDL link error

Using visual studio 2019 version 16.3.4, the build solution fails to link SDL (or is it a uclibc problem?):

...
3>------ Rebuild All started: Project: lobster, Configuration: Release Win32 ------
3>main.cpp
3>LIBCMT.lib(ftol2.obj) : error LNK2005: __ftol2_sse already defined in engine.lib(SDL_stdlib.obj)
3>   Creating library ..\..\bin\lobster.lib and object ..\..\bin\lobster.exp
3>engine.lib(SDL_stdlib.obj) : error LNK2001: unresolved external symbol _SDL_uclibc_exp
3>engine.lib(SDL_stdlib.obj) : error LNK2001: unresolved external symbol _SDL_uclibc_fmod
3>engine.lib(SDL_stdlib.obj) : error LNK2001: unresolved external symbol _SDL_uclibc_log10
3>C:\Users\jcorb\lobster\dev\lobster\..\..\bin\lobster.exe : fatal error LNK1120: 3 unresolved externals

Full build output fwiw:

1>------ Rebuild All started: Project: language, Configuration: Release Win32 ------
1>stdafx.cpp
1>idl_gen_text.cpp
1>idl_parser.cpp
1>util.cpp
1>towasm.cpp
1>builtins.cpp
1>disasm.cpp
1>file.cpp
1>compiler.cpp
1>lobsterreader.cpp
1>platform.cpp
1>tocpp.cpp
1>tonative.cpp
1>vm.cpp
1>vmdata.cpp
1>vmlog.cpp
1>language.vcxproj -> C:\Users\jcorb\lobster\dev\lobster\..\..\build\lobster\language\language.lib
2>------ Rebuild All started: Project: engine, Configuration: Release Win32 ------
2>stdafx.cpp
2>autofit.c
2>ftapi.c
2>ftbase.c
2>ftbbox.c
2>ftbitmap.c
2>ftdebug.c
2>ftglyph.c
2>ftinit.c
2>ftstroke.c
2>ftsynth.c
2>ftsystem.c
2>cff.c
2>pshinter.c
2>psnames.c
2>raster.c
2>sfnt.c
2>smooth.c
2>truetype.c
2>imgui.cpp
2>imgui_demo.cpp
2>imgui_draw.cpp
2>imgui_impl_opengl3.cpp
2>imgui_impl_sdl.cpp
2>imgui_widgets.cpp
2>SDL_wasapi_winrt.cpp
2>b2BroadPhase.cpp
2>b2CollideCircle.cpp
2>b2CollideEdge.cpp
2>b2CollidePolygon.cpp
2>b2Collision.cpp
2>b2Distance.cpp
2>b2DynamicTree.cpp
2>b2TimeOfImpact.cpp
2>b2ChainShape.cpp
2>b2CircleShape.cpp
2>b2EdgeShape.cpp
2>b2PolygonShape.cpp
2>b2BlockAllocator.cpp
2>b2Draw.cpp
2>b2FreeList.cpp
2>b2Math.cpp
2>b2Settings.cpp
2>b2StackAllocator.cpp
2>b2Stat.cpp
2>b2Timer.cpp
2>b2TrackedBlock.cpp
2>b2Body.cpp
2>b2ContactManager.cpp
2>b2Fixture.cpp
2>b2Island.cpp
2>b2World.cpp
2>b2WorldCallbacks.cpp
2>b2ChainAndCircleContact.cpp
2>b2ChainAndPolygonContact.cpp
2>b2CircleContact.cpp
2>b2Contact.cpp
2>b2ContactSolver.cpp
2>b2EdgeAndCircleContact.cpp
2>b2EdgeAndPolygonContact.cpp
2>b2PolygonAndCircleContact.cpp
2>b2PolygonContact.cpp
2>b2DistanceJoint.cpp
2>b2FrictionJoint.cpp
2>b2GearJoint.cpp
2>b2Joint.cpp
2>b2MotorJoint.cpp
2>b2MouseJoint.cpp
2>b2PrismaticJoint.cpp
2>b2PulleyJoint.cpp
2>b2RevoluteJoint.cpp
2>b2RopeJoint.cpp
2>b2WeldJoint.cpp
2>b2WheelJoint.cpp
2>b2Particle.cpp
2>b2ParticleAssembly.cpp
2>b2ParticleGroup.cpp
2>b2ParticleSystem.cpp
2>b2VoronoiDiagram.cpp
2>b2Rope.cpp
2>StackWalker.cpp
2>StackWalkerHelpers.cpp
2>dynamic_flac.c
2>dynamic_fluidsynth.c
2>dynamic_mod.c
2>dynamic_modplug.c
2>dynamic_mp3.c
2>dynamic_ogg.c
2>effects_internal.c
2>effect_position.c
2>effect_stereoreverse.c
2>fluidsynth.c
2>load_aiff.c
2>load_flac.c
2>load_mp3.c
2>load_ogg.c
2>load_voc.c
2>mixer.c
2>music.c
2>music_cmd.c
2>music_flac.c
2>music_mad.c
2>music_mod.c
2>music_modplug.c
2>music_ogg.c
2>wavestream.c
2>SDL_wasapi.c
2>SDL_windows_main.c
2>SDL_dataqueue.c
2>SDL_vulkan_utils.c
2>SDL_windowsvulkan.c
2>e_atan2.c
2>e_log.c
2>e_pow.c
2>e_rem_pio2.c
2>e_sqrt.c
2>k_cos.c
2>k_rem_pio2.c
2>k_sin.c
2>k_tan.c
2>s_atan.c
2>s_copysign.c
2>s_cos.c
2>s_fabs.c
2>s_floor.c
2>s_scalbn.c
2>s_sin.c
2>s_tan.c
2>SDL.c
2>SDL_assert.c
2>SDL_atomic.c
2>SDL_audio.c
2>SDL_audiocvt.c
2>SDL_audiodev.c
2>SDL_audiotypecvt.c
2>SDL_blendfillrect.c
2>SDL_blendline.c
2>SDL_blendpoint.c
2>SDL_blit.c
2>SDL_blit_0.c
2>SDL_blit_1.c
2>SDL_blit_A.c
2>SDL_blit_auto.c
2>SDL_blit_copy.c
2>SDL_blit_N.c
2>SDL_blit_slow.c
2>SDL_bmp.c
2>SDL_clipboard.c
2>SDL_clipboardevents.c
2>SDL_cpuinfo.c
2>SDL_d3dmath.c
2>SDL_dinputhaptic.c
2>SDL_dinputjoystick.c
2>SDL_directsound.c
2>SDL_diskaudio.c
2>SDL_drawline.c
2>SDL_drawpoint.c
2>SDL_dropevents.c
2>SDL_dummyaudio.c
2>SDL_dynapi.c
2>SDL_egl.c
2>SDL_error.c
2>SDL_events.c
2>SDL_fillrect.c
2>SDL_gamecontroller.c
2>SDL_gesture.c
2>SDL_getenv.c
2>SDL_haptic.c
2>SDL_hints.c
2>SDL_iconv.c
2>SDL_joystick.c
2>SDL_keyboard.c
2>SDL_log.c
2>SDL_malloc.c
2>SDL_mixer.c
2>SDL_mmjoystick.c
2>SDL_mouse.c
2>SDL_nullevents.c
2>SDL_nullframebuffer.c
2>SDL_nullvideo.c
2>SDL_pixels.c
2>SDL_power.c
2>SDL_qsort.c
2>SDL_quit.c
2>SDL_rect.c
2>SDL_render.c
2>SDL_render_d3d.c
2>SDL_render_d3d11.c
2>SDL_render_gl.c
2>SDL_render_gles2.c
2>SDL_render_sw.c
2>SDL_RLEaccel.c
2>SDL_rotate.c
2>SDL_rwops.c
2>SDL_shaders_gl.c
2>SDL_shaders_gles2.c
2>SDL_shape.c
2>SDL_spinlock.c
2>SDL_stretch.c
2>SDL_string.c
2>SDL_surface.c
2>SDL_syscond.c
2>SDL_sysfilesystem.c
2>SDL_sysloadso.c
2>SDL_sysmutex.c
2>SDL_syspower.c
2>SDL_syssem.c
2>SDL_systhread.c
2>SDL_systimer.c
2>SDL_systls.c
2>SDL_thread.c
2>SDL_timer.c
2>SDL_touch.c
2>SDL_video.c
2>SDL_wave.c
2>SDL_windowevents.c
2>SDL_windows.c
2>SDL_windowsclipboard.c
2>SDL_windowsevents.c
2>SDL_windowsframebuffer.c
2>SDL_windowshaptic.c
2>SDL_windowsjoystick.c
2>SDL_windowskeyboard.c
2>SDL_windowsmessagebox.c
2>SDL_windowsmodes.c
2>SDL_windowsmouse.c
2>SDL_windowsopengl.c
2>SDL_windowsopengles.c
2>SDL_windowsshape.c
2>SDL_windowsvideo.c
2>SDL_windowswindow.c
2>SDL_winmm.c
2>SDL_xaudio2.c
2>SDL_xinput.c
2>SDL_xinputhaptic.c
2>SDL_xinputjoystick.c
2>SDL_yuv_mmx.c
2>SDL_yuv_sw.c
2>SDL_wasapi_win32.c
2>hid.c
2>SDL_hidapijoystick.c
2>SDL_hidapi_ps4.c
2>SDL_hidapi_switch.c
2>SDL_dummysensor.c
2>SDL_sensor.c
2>SDL_yuv.c
2>yuv_rgb.c
2>audio.cpp
2>cubegen.cpp
2>engine.cpp
2>font.cpp
2>fontrenderer.cpp
2>glgeom.cpp
2>glloadiqm.cpp
2>glshader.cpp
2>gltexture.cpp
2>glvr.cpp
2>graphics.cpp
2>meshgen.cpp
2>glsystem.cpp
2>octree.cpp
2>physics.cpp
2>sdlsystem.cpp
2>simplex.cpp
2>steamworks.cpp
2>imbind.cpp
2>sdlaudiosfxr.cpp
2>C:\Users\jcorb\lobster\dev\src\imbind.cpp(317,36): warning C4459: declaration of 'boolean' hides global declaration
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\include\concepts(213,9): message : see declaration of 'std::boolean' (compiling source file ..\src\imbind.cpp)
2>SDL_stdlib.c
2>lobster.vcxproj -> C:\Users\jcorb\lobster\dev\lobster\..\..\build\lobster\engine\engine.lib
2>Done building project "lobster.vcxproj".
3>------ Rebuild All started: Project: lobster, Configuration: Release Win32 ------
3>main.cpp
3>LIBCMT.lib(ftol2.obj) : error LNK2005: __ftol2_sse already defined in engine.lib(SDL_stdlib.obj)
3>   Creating library ..\..\bin\lobster.lib and object ..\..\bin\lobster.exp
3>engine.lib(SDL_stdlib.obj) : error LNK2001: unresolved external symbol _SDL_uclibc_exp
3>engine.lib(SDL_stdlib.obj) : error LNK2001: unresolved external symbol _SDL_uclibc_fmod
3>engine.lib(SDL_stdlib.obj) : error LNK2001: unresolved external symbol _SDL_uclibc_log10
3>C:\Users\jcorb\lobster\dev\lobster\..\..\bin\lobster.exe : fatal error LNK1120: 3 unresolved externals
3>Done building project "main.vcxproj" -- FAILED.
========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ==========

Stacktrace does not work properly

var a = 1
let b = 0
print a / b

---- result with head rev, both MSVC and MinGW/MSYS:
stackunwind.lobster(3): VM error: division by zero
in function: __top_level_expression -> stackunwind.lobster(3)
globals:
a = 0

---- expected:
stackunwind.lobster(3): VM error: division by zero
in function: __top_level_expression -> stackunwind.lobster(3)
globals:
a = 1

Physics support

How far along would you call the physics support? It looks like it's just good enough to create the demos you have (that is, falling boxes and water). I don't see any way of getting a physics object back to apply thrust or rotation, or even get position from.

Also, is this the best place for questions like this?

building on linux: stb_image.c

I got this to build on linux 64 bits (I think, I haven't gotten anything to actually run yet). I had to hand-compile a SDL2 recent enough to work. I did run into one snag:

The default makefile does this:

cc -c -o ../lib/stb_image.o ../lib/stb_image.c

For me it fails then, because it builds it as a 64 bit .o file by default, and that won't work as lobster apparently wants 32 bits. To fix this I hand-compiled it with the -m32 switch first. Perhaps this can be solved in the Makefile.

Can't compile against wayland

Is there a way to avoid compiling against wayland? I run into issues when building:

[ 44%] Building C object external/SDL/CMakeFiles/SDL2-static.dir/src/video/wayland/SDL_waylandmouse.c.o
/home/max/Documents/Dev/lobster/dev/external/SDL/src/video/wayland/SDL_waylandevents.c:41:10: fatal error: pointer-constraints-unstable-v1-client-protocol.h: No such file or directory
 #include "pointer-constraints-unstable-v1-client-protocol.h"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

willow% lsb_release -irc
Distributor ID:	Ubuntu
Release:	18.04
Codename:	bionic
willow%

Revision 314f6c6

64-bit build?

I finally got a 32-bit linux build working with symlink magic -- but I'd much rather just build a 64-bit version. How much work is it to switch over? I wouldn't mind taking a look if you'd consider taking the PR. :)

making a drawlist

hello, i triead making a drawlist and add points to this. however it seems as if the list is cleared when i add many items to it. i created a global list, add 1 item per frame to it (a position) with .push and than did:

for(linesegments) s:
    gl_translate(s):
        gl_color(color_olive):
            gl_circle(1,50)

however this only renders 1 circle at the last position added. am i doing something wrong or is this an compiler optimalisation?

Windows: The build tools for llvm cannot be found

I'm attempting to build Lobster on Windows using Visual Studio 2019 Community Edition.

I've installed Visual Studio and loaded lobster.sln as directed by the getting started instructions.

Visual Studio fails to build the solution and reports an error

The build tools for llvm (Platform Toolset = 'llvm') cannot be found. To build using the llvm build tools, please install llvm build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selection "Retarget Solution".

I've tried installing some Clang / LLVM things but it hasn't helped.
http://releases.llvm.org/download.html (The windows 32bit build)
https://github.com/zufuliu/llvm-utils

Is there something else I should install?

Lobster without the engine

Is it possible to build lobster without the engine? In the docs here:http://aardappel.github.io/lobster/implementation.html#adding-your-code-to-lobster

It explains removing an engine folder, but that no longer appears to be accurate.

Unexpected interaction between xyzw types and coroutines

I was exploring the included samples to get a feel for the language and found the coroutine version of the shooter tutorial was acting in a very strange and unexpected manner.

I isolated the behavior with this snippet.

import std

def corotest (vec, id, iter):
    for(10) count:
        iter(nil)
        print "id:"+string(id)+" iter:"+string(count)+" "+string(vec)
        vec += vec
        print "id:"+string(id)+" iter:"+string(count)+" "+string(vec)
    return nil

let vec = xyzw{1,2,3,4}

let cts = []

for(4) i:
    cts.push(coroutine corotest(vec,i))

print "Running coroutine version"
forever():
    for(length(cts)) i:
        if cts[i].active:
            cts[i].resume()
        else:
            return from forever

Running it produces...

Process started (PID=14788) >>>
Running coroutine version
id:0 iter:0 xyzw_i{1, 2, 3, 4}
id:0 iter:0 xyzw_i{2, 4, 6, 8}
id:1 iter:0 xyzw_i{1, 4, 6, 8}
id:1 iter:0 xyzw_i{2, 8, 12, 16}
id:2 iter:0 xyzw_i{1, 8, 12, 16}
id:2 iter:0 xyzw_i{2, 16, 24, 32}
id:3 iter:0 xyzw_i{1, 16, 24, 32}
id:3 iter:0 xyzw_i{2, 32, 48, 64}
id:0 iter:1 xyzw_i{2, 32, 48, 64}
id:0 iter:1 xyzw_i{4, 64, 96, 128}
id:1 iter:1 xyzw_i{2, 64, 96, 128}
id:1 iter:1 xyzw_i{4, 128, 192, 256}
id:2 iter:1 xyzw_i{2, 128, 192, 256}
id:2 iter:1 xyzw_i{4, 256, 384, 512}
id:3 iter:1 xyzw_i{2, 256, 384, 512}
id:3 iter:1 xyzw_i{4, 512, 768, 1024}
id:0 iter:2 xyzw_i{4, 512, 768, 1024}
id:0 iter:2 xyzw_i{8, 1024, 1536, 2048}
id:1 iter:2 xyzw_i{4, 1024, 1536, 2048}
id:1 iter:2 xyzw_i{8, 2048, 3072, 4096}
id:2 iter:2 xyzw_i{4, 2048, 3072, 4096}
id:2 iter:2 xyzw_i{8, 4096, 6144, 8192}
id:3 iter:2 xyzw_i{4, 4096, 6144, 8192}
id:3 iter:2 xyzw_i{8, 8192, 12288, 16384}
id:0 iter:3 xyzw_i{8, 8192, 12288, 16384}
id:0 iter:3 xyzw_i{16, 16384, 24576, 32768}
id:1 iter:3 xyzw_i{8, 16384, 24576, 32768}
id:1 iter:3 xyzw_i{16, 32768, 49152, 65536}
id:2 iter:3 xyzw_i{8, 32768, 49152, 65536}
id:2 iter:3 xyzw_i{16, 65536, 98304, 131072}
id:3 iter:3 xyzw_i{8, 65536, 98304, 131072}
id:3 iter:3 xyzw_i{16, 131072, 196608, 262144}
id:0 iter:4 xyzw_i{16, 131072, 196608, 262144}
id:0 iter:4 xyzw_i{32, 262144, 393216, 524288}
id:1 iter:4 xyzw_i{16, 262144, 393216, 524288}
id:1 iter:4 xyzw_i{32, 524288, 786432, 1048576}
id:2 iter:4 xyzw_i{16, 524288, 786432, 1048576}
id:2 iter:4 xyzw_i{32, 1048576, 1572864, 2097152}
id:3 iter:4 xyzw_i{16, 1048576, 1572864, 2097152}
id:3 iter:4 xyzw_i{32, 2097152, 3145728, 4194304}
id:0 iter:5 xyzw_i{32, 2097152, 3145728, 4194304}
id:0 iter:5 xyzw_i{64, 4194304, 6291456, 8388608}
id:1 iter:5 xyzw_i{32, 4194304, 6291456, 8388608}
id:1 iter:5 xyzw_i{64, 8388608, 12582912, 16777216}
id:2 iter:5 xyzw_i{32, 8388608, 12582912, 16777216}
id:2 iter:5 xyzw_i{64, 16777216, 25165824, 33554432}
id:3 iter:5 xyzw_i{32, 16777216, 25165824, 33554432}
id:3 iter:5 xyzw_i{64, 33554432, 50331648, 67108864}
id:0 iter:6 xyzw_i{64, 33554432, 50331648, 67108864}
id:0 iter:6 xyzw_i{128, 67108864, 100663296, 134217728}
id:1 iter:6 xyzw_i{64, 67108864, 100663296, 134217728}
id:1 iter:6 xyzw_i{128, 134217728, 201326592, 268435456}
id:2 iter:6 xyzw_i{64, 134217728, 201326592, 268435456}
id:2 iter:6 xyzw_i{128, 268435456, 402653184, 536870912}
id:3 iter:6 xyzw_i{64, 268435456, 402653184, 536870912}
id:3 iter:6 xyzw_i{128, 536870912, 805306368, 1073741824}
id:0 iter:7 xyzw_i{128, 536870912, 805306368, 1073741824}
id:0 iter:7 xyzw_i{256, 1073741824, 1610612736, -2147483648}
id:1 iter:7 xyzw_i{128, 1073741824, 1610612736, -2147483648}
id:1 iter:7 xyzw_i{256, -2147483648, -1073741824, 0}
id:2 iter:7 xyzw_i{128, -2147483648, -1073741824, 0}
id:2 iter:7 xyzw_i{256, 0, -2147483648, 0}
id:3 iter:7 xyzw_i{128, 0, -2147483648, 0}
id:3 iter:7 xyzw_i{256, 0, 0, 0}
id:0 iter:8 xyzw_i{256, 0, 0, 0}
id:0 iter:8 xyzw_i{512, 0, 0, 0}
id:1 iter:8 xyzw_i{256, 0, 0, 0}
id:1 iter:8 xyzw_i{512, 0, 0, 0}
id:2 iter:8 xyzw_i{256, 0, 0, 0}
id:2 iter:8 xyzw_i{512, 0, 0, 0}
id:3 iter:8 xyzw_i{256, 0, 0, 0}
id:3 iter:8 xyzw_i{512, 0, 0, 0}
id:0 iter:9 xyzw_i{512, 0, 0, 0}
id:0 iter:9 xyzw_i{1024, 0, 0, 0}
id:1 iter:9 xyzw_i{512, 0, 0, 0}
id:1 iter:9 xyzw_i{1024, 0, 0, 0}
id:2 iter:9 xyzw_i{512, 2, 3, 4}
id:2 iter:9 xyzw_i{1024, 4, 6, 8}
id:3 iter:9 xyzw_i{512, 2, 3, 4}
id:3 iter:9 xyzw_i{1024, 4, 6, 8}
<<< Process finished (PID=14788). (Exit code 0)

When one of the standard xy types is shared between coroutines like this, each coroutine gets its own copy of the x element but they all seem to share the yzw elements. This behavior is surprising and given that it severely breaks one of the example programs, I'm guessing its not intended.

What's even more surprising to me is it happens even in the modified code below, where I pass in each element individually, guessing that the issue might have something to do with a shared reference. The modified code exhibits exactly the same behavior despite looking like each coroutine should create its own completely independent xyzw that shouldn't interact with the others.

import std

def corotest (x,y,z,w, id, iter):
    var vec = xyzw{x,y,z,w}
    for(10) count:
        iter(nil)
        print "id:"+string(id)+" iter:"+string(count)+" "+string(vec)
        vec += vec
        print "id:"+string(id)+" iter:"+string(count)+" "+string(vec)
    return nil

let cts = []

for(4) i:
    cts.push(coroutine corotest(1,2,3,4,i))

print "Running coroutine version"
forever():
    for(length(cts)) i:
        if cts[i].active:
            cts[i].resume()
        else:
            return from forever

So far I haven't been able to recreate this behavior with any combination of nested types and/or functions. Only coroutines in this particular style of setup. And only for the xy standard types. Classes and vectors seem to behave in sensible manners here.

linux lobster: fatal error: Unable to initialize SDL: No available video device

I managed to compile lobster on Linux (Fedora) against a home-compiled 32 bits SDL. At least I think I did..

A simple hello world example works.

Unfortunately when I want to run any of the samples, I get this error:

fatal error: Unable to initialize SDL: No available video device

I don't know how to debug this. -v doesn't say anything more.

compiler crashes when trying to use default.lbc

when i use the -b on the compiler to create a bytecode file. however when i do this for a hello world program then the compiler crashes when i just call the compiler without any arguments wich should load the bytecode file.
i put the bytecode file in the same folder as the compiler.
I use win7 64-bit and the code i tried was:

print("Hello, World!")

Bool support

Wouldn't the imgui reflection benefit from having a bool type to turn those into toggles?

Recursion and multiple value return

This fails to compile:

def return3oe(x):
    if x > 0:
        return return3oe(x-1)
    else:
        return 1, 2, 3

Whereas this equivalent version works:

def return3oe(x):
    if x <= 0:
        return 1, 2, 3
    else:
        return return3oe(x-1)

Computed Textures Fade As They Downsample (unless mimap gen is disabled)

Using demo texscal.lobster, which:

draws a colorful test pattern into a texture
then draws that texture on a unit square
over a colored white square to make the alpha fade mare apparent (vs the global black background)

So you start out with:

But dragging that slider gives:

Eventually going full transparent about half way through:

Enabling the texture_format_nomimap eliminates the alpha fade out.

Provide guide for installing lobster

Currently, it is not obvious how to install lobster on you machine and successfully compile for example a simple hello world program.

Function pointers can't be nilable?

Contrived example:

def no_fun(a:int) -> int

var ynot : no_fun? = nil

Yields: foo.lobster(3): error: value types can't be made nilable

More realistic examples, like an array of nilable optional behavior pointers:

var behavior = []::no_fun?

Also fail with the same problem.

So you can have a nilable class and sentinel method, but not a nilable function pointer? Bogus! ;-)

clang-format

Hi,

Could you clang-format the code under dev/src? I want to PR some changes and I don't want to pollute it with formatting stuff.

Also, I guess the .clang-format file should be moved to dev/src, since you probably don't want to clang-format external dependencies.

Crash when accidentally using '+' to try to append vectors.

I'm running on 64 bit linux, with the latest commits from today: 317cc21

Dumb mistake on my part, I forgot to use append to append two vectors. Can be reproduced with this:

    let c = [1, 2] + [3] 
    print("c=" + c)

It will crash. From the stack trace, I'd say it wasn't impressed with my attempt at concatenating:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000561df6aac11e in lobster::CodeGen::GenMathOp(lobster::TypeRef, lobster::TypeRef, lobster::TypeRef, int) ()
(gdb) bt
#0  0x0000561df6aac11e in lobster::CodeGen::GenMathOp(lobster::TypeRef, lobster::TypeRef, lobster::TypeRef, int) ()
#1  0x0000561df6aae09d in lobster::CodeGen::Gen(lobster::Node const*, unsigned long) ()
#2  0x0000561df6a82385 in lobster::Define::Generate(lobster::CodeGen&, unsigned long) const ()
#3  0x0000561df6ac5d75 in lobster::CodeGen::CodeGen(lobster::Parser&, lobster::SymbolTable&, bool, int) ()
#4  0x0000561df6a967d4 in lobster::Compile(lobster::NativeRegistry&, std::basic_string_view<char, std::char_traits<char> >, std::basic_string_view<char, std::char_traits<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool, bool, bool, int) ()
#5  0x0000561df6a6d6fb in main ()

Feature Request: Adding range support to for and vectors

Currently ranges are only used in switch statements. What are your thoughts on adding them to loops and vectors:

let x = [4..10]
//Giving us a vector of [4,5,6,7,8,9,10]

for 4..6: print(_)
//result:
//4
//5
//6

Currently I am using this for ranges:

//not inclusive
def range(start, end, func):
    let r = []
    while start < end:
        r.push(start)
        start = func(start) 
    return r

def range(start, end):
    return range(start,end): _ + 1

It works, but language level support would be nice.
I can take a look at this if you support this feature.

Discussion about namespaces

Does include do a text inclusion and is there only one global namespace for all function names? Is there a way to namespace the functions and types? If not, is there a plan to add these?

Discussion about the semantics of 'while'

(Not sure if this is the appropriate forum for discussion but I didn't find a mailing list.)

I wanted to discuss the special evaluation semantics of expressions passed to while in the language. This actually confused me for a bit until I made my way to the end of the language reference (https://htmlpreview.github.io/?https://raw.githubusercontent.com/aardappel/lobster/master/lobster/docs/language_reference.html#built-in-functions). Before that I was looking for a way to pass unevaluated expressions around, but now I understand only calling while can pass an unevaluated expression (perhaps wrapping it in an anonymous function?) while all other calls pass the evaluated value.

Specifically, in the following code expr is passed unevaluated to while, but expr2 and expr3 are immediately evaluated and the value is then passed to the respective function:

while expr:
   body

if expr2:
  body

for(expr3):
  body

From a design point of view, special casing while sticks out a bit. It breaks the expectation that expressions are evaluated immediately, but it does offer the convenient syntax. However it can still be confusing, e.g. I'm not sure how to pass an expression when calling while with the while(...) syntax, as opposed to the while ...: ... syntax.

I have a couple of questions:

Is there a way to define a function that accepts an unevaluated expression (i.e. can I implement while in lobster?)
Are there an plans or ideas to 'sort out' the above exception around while?

I'm thinking if we have (1) above, then maybe while would not look like an outlier. OTOH, it means we would always have to look at the definition to know the call semantics.

Build error

This might be something I'm doing wrong, but using the cmake file I got this error:

/Users/andrew/lobster/dev/src/platform.cpp:186:9: error: 'CreateStandardAlert' was not declared in this scope
         CreateStandardAlert(kAlertStopAlert, CFSTR("Error:"), sr, nullptr, &alertDialog);
/Users/andrew/lobster/dev/src/platform.cpp:187:9: error: 'RunStandardAlert' was not declared in this scope
         RunStandardAlert (alertDialog, nullptr, nullptr);

Regression for

Prior, I believe, to the introduction of generics for functions, a method shared through a generic base class was valid. Now, it appears that the first class to declare the method wins the race to declaring a method with the context object’s type.

class qux:
class quux:

class base<T>:
    def method():
        print "hi"

class foo: base<qux>
class bar: base<quux>

let f = foo{}
let b = bar{}

b.method()
f.method()

temp.lobster(15): error: "method" (1st argument) requires type: bar, got: foo

I’m not entirely certain that this should work, since this is likely fallout from combining dynamic dispatch and generics in the same language. I recall running into similar problems in C++ when I used virtual functions and generics together, though in C++, the programmer decides whether to use inline/generic or virtual and it’s on their head if they explode when mixed. I suspect Lobster might be better off without dynamic dispatch at all.

Using construct to avoid prefixes

What's your stance on something like this?

using gui:
      setclickcolors(color_dark_green, color_green)
      start(gl_window_size(), 1, 1, true):
        hblock(1, 0):
        
      ...

linux unit test failure

I figured I'd try to run the unit tests (unittest.lobster). I get an error:

unittest.lobster(316): VM error: assertion failed

seems like something unexpected is happening surrounding garbage collection?

Clarify license

The web page states that the license is ZLIB and the source code distributes ASL2. Which one is right?

Building on OSX: No member named 'string_view' in 'flatbuffers::String'

Hey, C/C++ noob here - saw the post on HN and decided to give Lobster a shot. I've built stuff from source before, but for whatever reason I'm having issues getting this to work.

I opened up the XCode project and tried to build with the command line target, which failed with 10 of the following build-time errors across disasm.h and vm.cpp:
/Users/joerimmer/Documents/Dev/Lobster/lobster/dev/src/lobster/disasm.h:30:54: No member named 'string_view' in 'flatbuffers::String'

Trying to target lobsterapp results in the same, with an LLVM segfault for good measure. lobster_ios fails to build tonative.cpp in addition to the above.

I know that Apple's LLVM/clang is a bit behind the curve on new C++17 features, which I gather string_view might be? It seems like using string_view in Lobster was added recently, so maybe this slipped through.

Any ideas on what to do? Reading through the docs, Lobster seems pretty neat.

Linux segfault with --cpp

I see that it explicitly states "don't run" in the command line options, but I thought I'd bring it to your attention anyway.

The program I am attempting to use the --cpp command with is:

class tree {
    left: tree?,
    right: tree?,
    def item_check():
    	if not left || not right: return 1
        else: return 1 + left.item_check() + right.item_check()
}

def bottom_up_tree(depth: int) -> tree:
    if 0 < depth: return tree { bottom_up_tree(depth - 1), bottom_up_tree(depth - 1) }
    else: return tree { nil, nil }

let n = 15
let min_depth = 4
let max_depth = 
    if n < (min_depth + 2): min_depth + 2
    else: n 

let stretch_depth = max_depth + 1
print("Stretch tree depth " + stretch_depth + "\t check: " + bottom_up_tree(stretch_depth).item_check()) 


let long_lived_tree = bottom_up_tree(max_depth)

let results = []

var d = min_depth
while d <= max_depth: 
    let depth = d
    var check = 0

    let iterations = 1 << (max_depth - depth + min_depth)
    var i = 1
    while i <= iterations:
        check += bottom_up_tree(depth).item_check()
        i++
    results.push(iterations + "\t trees of depth " + depth + "\t check: " + check) 
    d += 2

for results: print _ 
print "long lived tree of depth " + max_depth + "\t check: " + long_lived_tree.item_check()

The code runs fine with the VM.
My Lobster build is based off of https://github.com/aardappel/lobster/tree/8a0c3d60657763c0f040d6b176617c37b816fd8d

I can provide additional information, but this is all I get:

~/Git/tools/lobster/lobster $ ./lobster binarytree.lobster --verbose --cpp
compiling...
SDLLoadFile: modules/binarytree.lobster
SDLLoadFile: ./modules/binarytree.lobster
SDLLoadFile: /usr/share/lobster/modules/binarytree.lobster
SDLLoadFile: binarytree.lobster
SDLLoadFile: modules/stdtype.lobster
SF count: multi: 0, orig: 14, cloned: 2
Node count: orig: 199, cloned: 23
Most clones: item_check (binarytree.lobster:4) -> 12 nodes accross 1 clones (+1 orig)
Most clones: function3else (binarytree.lobster:6) -> 11 nodes accross 1 clones (+1 orig)
optimizer: 13 optimizations
Segmentation fault

[doc] http://strlen.com/lobster/ - outdated explanation? outdated example?

gl_scalevec allows us to scale all rendering by…

Only the example does not use gl_scalevec. ;-)
By looking at the explanation it feels like missing a few more sentences anyway.

Crash with samples/shooter_tutorial/tut_coro.lobster

I'm using the lastest commit from master, on x64 linux, compiled to 32 bit. (FWIW, I get the same result compiled to 64 bit as well). gcc (GCC) 6.2.1 20160830

When I run the tut_cor.lobster sample, the menu comes up, but when I hit space to play, the process dies with a segfault. In the stack trace below, curcoroutine == 0.

Thread 1 "lobster_cmake" received signal SIGSEGV, Segmentation fault.
0x08251947 in lobster::VM::CoClean (this=0x8506040) at /home/pkelley/src/lobster/dev/src/vm.cpp:565
565         for (int i = 1; i <= *curcoroutine->varip; i++) {
(gdb) print i
$1 = 1
(gdb) print curcoroutine
$2 = (lobster::CoRoutine *) 0x0
(gdb) bt
#0  0x08251947 in lobster::VM::CoClean (this=0x8506040) at /home/pkelley/src/lobster/dev/src/vm.cpp:565
#1  0x0825961d in lobster::VM::F_COEND (this=0x8506040) at /home/pkelley/src/lobster/dev/src/vm.cpp:1246
#2  0x0825977b in lobster::VM::EvalProgram (this=0x8506040) at /home/pkelley/src/lobster/dev/src/vm.cpp:1310
#3  0x0825ee1e in lobster::RunBytecode(char const*, std::vector<unsigned char, std::allocator<unsigned char> >&&, void const*, void const*) (programname=0x8505bf8 "tut_coro.lobster", 
    bytecode=<unknown type in /home/pkelley/src/lobster/lobster/lobster_cmake, CU 0x42bf28, DIE 0x450799>, entry_point=0x0, static_bytecode=0x0) at /home/pkelley/src/lobster/dev/src/vm.cpp:1553
#4  0x08248e21 in EngineRunByteCode(char const*, std::vector<unsigned char, std::allocator<unsigned char> >&&, void const*, void const*) (fn=0xffffdd24 "samples/shooter_tutorial/tut_coro.lobster", 
    bytecode=<unknown type in /home/pkelley/src/lobster/lobster/lobster_cmake, CU 0x3d69e1, DIE 0x3f3464>, entry_point=0x0, static_bytecode=0x0) at /home/pkelley/src/lobster/dev/src/sdlsystem.cpp:678
#5  0x08228872 in main (argc=2, argv=0xffffdbc4) at /home/pkelley/src/lobster/dev/src/main.cpp:129
(gdb) bt full
#0  0x08251947 in lobster::VM::CoClean (this=0x8506040) at /home/pkelley/src/lobster/dev/src/vm.cpp:565
        i = 1
        co = 0x8528c20
#1  0x0825961d in lobster::VM::F_COEND (this=0x8506040) at /home/pkelley/src/lobster/dev/src/vm.cpp:1246
No locals.
#2  0x0825977b in lobster::VM::EvalProgram (this=0x8506040) at /home/pkelley/src/lobster/dev/src/vm.cpp:1310
        op = 126
#3  0x0825ee1e in lobster::RunBytecode(char const*, std::vector<unsigned char, std::allocator<unsigned char> >&&, void const*, void const*) (programname=0x8505bf8 "tut_coro.lobster", 
    bytecode=<unknown type in /home/pkelley/src/lobster/lobster/lobster_cmake, CU 0x42bf28, DIE 0x450799>, entry_point=0x0, static_bytecode=0x0) at /home/pkelley/src/lobster/dev/src/vm.cpp:1553
No locals.
#4  0x08248e21 in EngineRunByteCode(char const*, std::vector<unsigned char, std::allocator<unsigned char> >&&, void const*, void const*) (fn=0xffffdd24 "samples/shooter_tutorial/tut_coro.lobster", 
    bytecode=<unknown type in /home/pkelley/src/lobster/lobster/lobster_cmake, CU 0x3d69e1, DIE 0x3f3464>, entry_point=0x0, static_bytecode=0x0) at /home/pkelley/src/lobster/dev/src/sdlsystem.cpp:678
No locals.
#5  0x08228872 in main (argc=2, argv=0xffffdbc4) at /home/pkelley/src/lobster/dev/src/main.cpp:129
        parsedump = false
        default_bcf = 0x83f77e9 "default.lbc"
        bcf = 0x0
        fn = 0xffffdd24 "samples/shooter_tutorial/tut_coro.lobster"
        helptext = {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, 
            _M_p = 0x85058f0 "\nUsage:\nlobster [ OPTIONS ] [ FILE ]\nCompile & run FILE, or omit FILE to load default.lbc\n-w", ' ' <repeats 21 times>, "Wait for input before exiting.\n-b", ' ' <repeats 21 times>, "Compile to bytecode file, don't r"...}, 
          _M_string_length = 688, {_M_local_buf = "\260\002\000\000\000\000\000\000X\332\377\377G\224$\b", _M_allocated_capacity = 688}}
        disasm = false
        to_cpp = false
        bytecode = {<std::_Vector_base<unsigned char, std::allocator<unsigned char> >> = {_M_impl = {<std::allocator<unsigned char>> = {<__gnu_cxx::new_allocator<unsigned char>> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, 
              _M_end_of_storage = 0x0}}, <No data fields>}
        wait = false
        from_bundle = false

Can't open file: stdtype.lobster

I'm attempting to create a simple Hello World on Windows.

Lobster has been built. The lobster.exe was output to D:\Dev\github\lobster\lobster\lobster.exe.
Added D:\Dev\github\lobster\lobster to the Windows path.
Created a new Lobster file D:\Dev\lobster-hello-world\hello-world.lobster with the contents:

print("Hello World")

Run lobster hello-world.lobster in the D:\Dev\lobster-hello-world\ directory.
The result is can't open file: stdtype.lobster.
I can see the stdtype.lobster file in the \lobster\modules directory.

Is something else needed so that the Lobster compiler can find the files in the lobster directory?

PS: I was able to compile hello-world.lobster by copying the modules directory to D:\Dev\lobster-hello-world\, but I assume that is not the intended thing to do.

Anonymous function syntax

Computer says no for all of the following:

let id1 = : _
let id2 = x: x
let id3 = (x): x
let id4 = function(x): x

What am I doing wrong?

Fails to build: GenBO type mismatch

I'm getting the following error when building now, though I was able to successfully build a few days ago:

lobster/glinterface.h:209:17: error: no matching function for call to ‘GenBO(uint&, long unsigned int, gsl::span<int>::pointer)’
     return GenBO(type, sizeof(T) * d.size(), d.data());
            ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/lobster/dev/src/lobster/glinterface.h:208:28: note: candidate: template<class T> uint GenBO(uint, gsl::span<T>)
 template <typename T> uint GenBO(uint type, span<T> d) {
                            ^~~~~
src/lobster/dev/src/lobster/glinterface.h:208:28: note:   template argument deduction/substitution failed:
src/lobster/dev/src/lobster/glinterface.h:209:17: note:   mismatched types ‘gsl::span<T>’ and ‘long unsigned int’
     return GenBO(type, sizeof(T) * d.size(), d.data());

Perhaps related to a recent commit, e.g. 9027361. When I sync to f84b2f9 and build, I do not get an error.

Limitations Under Wine

Not sure whether this should be counted as a defect (if it will be common to run Lobster on Linux with Wine) or an enhancement (if most people will compile or eventually use a package to get Lobster) but:

Under Wine:

unable to play audio (looks like XAudio2Create() is failing)
mouse support is spotty (iqm demo failing to get mouse events)

[Found running Lobster under wine on 32-bit Ubuntu 12.04 on XFCE, 3.9GB memory Intel Core 2 Quad CPU Q8300]

Feature request: sample of rendering a textured mesh

One exercise I’d like to do while learning Lingua de Lagosta is to render a cube with a die face on each side. I could use a hint, especially considering how I stumbled through rendering a texture on a unit square.

I’d be glad to submit the sample, but could use a push here.

Shooter Tutorial Code?

Maybe I'm failing at the search within repository deal, but where's the code for the shooter tutorial (especially the promise coroutine variant?)

Version of Open GL required for Lobster

Hello

Does lobster require OpenGL 1.3?

thanks

Brian

C-style cheat sheet obsolete?

I can't make := or :== to work... Is the cheat sheet obsolete?

"Could not create GL context" under Linux

I was able to get the project to compile on my 64-bit Arch Linux machine after making a few changes to the Makefile and adding #include <stdarg.h> to platform.cpp. But now when I try to run one of the sample programs I get this error:

$ lobster samples/shooter_tutorial/tut1.lobster
ERROR: Could not create GL context
Unable to create OpenGL context: Could not create GL contextUnable to create OpenGL context: Could not create GL contextfatal error: Unable to create OpenGL context: Could not create GL context

I'm not sure how to further diagnose this. I can run other OpenGL games, and I'm pretty sure at least one of my Steam games is a 32-bit executable. Actually I can also run lobster.exe under Wine. Any thoughts? I tried compiling with -DDEBUG instead of -DNDEBUG but it did not give any additional messages.

Lossy --parsedump

Given

def foo(x, y):
  def bar(a):
    return a*a*y
  let barx = bar(x)
  let bary = bar(y)
  return barx+bary

return foo(1,2)

--parsedump generates:

FUNCTION: __top_level_expression() -> void
    (list
      struct xy:void
      struct xyz:void
      struct xyzw:void
      struct xy_f:void
      struct xy_i:void
      struct xyz_f:void
      struct xyz_i:void
      struct xyzw_f:void
      struct xyzw_i:void
      enumbool:void
      (return (foo 1:int 2:int):void):void)

FUNCTION: foo(x:int y:int ) -> void
    (list
      (barx var (bar x:int):int):void
      (bary var (bar y:int):int):void
      (return (+ barx:int bary:int):void):void)

FUNCTION: bar(a:int ) -> int
(list (return (* (* a:int a:int):int y:int):int):void)

Notice how bar is referring to a non-scoped y:int.

Is it intended to be useable as an intermediate representation for external code generators?

Also, note the missing space in enumbool.