aardappel / lobster Goto Github PK
View Code? Open in Web Editor NEWThe Lobster Programming Language
Home Page: http://strlen.com/lobster
The Lobster Programming Language
Home Page: http://strlen.com/lobster
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?
Maybe I'm failing at the search within repository deal, but where's the code for the shooter tutorial (especially the promise coroutine variant?)
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.
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.
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.
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 ==========
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
(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:
while
in lobster?)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.
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
.
Currently, it is not obvious how to install lobster on you machine and successfully compile for example a simple hello world program.
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! ;-)
The homepage example is using the old include
syntax.
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?
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. :)
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.
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?
I can't make :=
or :==
to work... Is the cheat sheet obsolete?
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:
resource?
fieldif not tex: load()
def load()
method that ends with an assert tex
after having loaded from a filewhen 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!")
The web page states that the license is ZLIB and the source code distributes ASL2. Which one is right?
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.
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?
Hello
Does lobster require OpenGL 1.3?
thanks
Brian
Would be nice to use https://www.google.com/fonts/specimen/Lobster for branding this :)
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.
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.
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)
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.
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?
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.
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:
[Found running Lobster under wine on 32-bit Ubuntu 12.04 on XFCE, 3.9GB memory Intel Core 2 Quad CPU Q8300]
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);
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
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?
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):
...
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.
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.
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.
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
I'm attempting to create a simple Hello World on Windows.
lobster.exe
was output to D:\Dev\github\lobster\lobster\lobster.exe
.D:\Dev\github\lobster\lobster
to the Windows path.D:\Dev\lobster-hello-world\hello-world.lobster
with the contents:print("Hello World")
lobster hello-world.lobster
in the D:\Dev\lobster-hello-world\
directory.can't open file: stdtype.lobster
.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.
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
Using demo texscal.lobster, which:
But dragging that slider gives:
Eventually going full transparent about half way through:
Enabling the texture_format_nomimap
eliminates the alpha fade out.
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.
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 ()
Wouldn't the imgui
reflection benefit from having a bool type to turn those into toggles?
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.
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: ,
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.