wren-lang / wren-cli Goto Github PK

hi, i tried to build wren on pocc and embarcadero. both effort failed because of lack competencies in C and compiler knowledge. (both compiler are c99 compliant)
i just cant use visual studio for the size, and requirement that cannot be meet.

it is a good idea to provide windows build. both debug and release.
it is time saving for those want justcto try wren works.
and if you are generous enough, please provide with
clang build, both win32 and win64 in COFF format.
so I can use it with dlang especially ldc compiler which is clang based too.

thanks.

Currently, Wren considers strings to be UTF-8 strings, which makes array-indexing operations as well as length calculations costly.

For performance reasons, the diverse find/search functions currently do not return UTF-8 character indices but rather byte offsets.

This is inconsistent, and also inefficient because obtaining the length of a string is a frequent operation.

My suggestion to this mess would be to reverse the current roles of UTF-8- and byte-semantics for strings:

Rather than interpreting strings as UTF-8 by default and providing a method for reinterpreting them as byte arrays, make it the other way around!

That is, all strings would be byte strings by default, just like in Lua.

The find/search functions would then return valid string indices, not just loosely related offsets with no direct connection.

Determining the length of the string would be a cheap operation.

Also, most of the time, strings are just concatenated and not iterated character by character. Such concatenation works with byte strings the same as it does for UTF-8 strings, no changes there necessary in scripts or the Wren implementation.

And if someone really wants to access an UTF-8 string as a character array, a helper method can reinterpret the byte string as an array of UNICODE codepoints or characters.

This would make cheap things the default, and the expensive ones still possible.

Obviously this would break (some) existing code, and would require incrementing the major version number because it is an incompatible chance (assuming wren uses semantic versioning).

Such a change should not be made lightly.

But it would unify things and make the search/find functions "good citizens" again.

Hey. I tried to build CLI using vs2017 on Windows, but it didn't work.

I did some digging and found some issues related to python pre-build events. Before building python is running two scripts from util directory: update_deps.py and build_libuv.py. After running first script I got this error:

subprocess.CalledProcessError: Command '['cmd', '/c', 'rd', '/s', '/q', 'deps\\libuv\\build\\gyp\\infra']' returned non-zero exit status 2

This basically means that python tried to remove deps/libuv/build/gyp/infra directory, but couldn't find it.

I commented this out (it seems that this directory doesn't exist anymore) and was able to successfully run first script.

I tried to build CLI again, but now I had this error:

LINK : fatal error LNK1104: cannot open file 'libuv.lib'

Linker couldn't find it, because it wasn't build, so build_libuv.py had to fail somehow.

After some tests I found that problem lies in this function: link which is running vcbuild.bat with some parameters to build libuv.lib.

Running this file failed, because it couldn't find visual studio. It couldn't find visual studio, because we are using libuv with version 1.10.0 which doesn't support vs2017. So basically you cannot build it if you have vs2017.

To fix this we have two options:

1. We can manually patch vcbuild.bat so it can detect vs2017.
2. We upgrade libuv to a newer version, 1.13.0 seems to be able to detect vs2017.

I did some tests on second option. My vs2017 was successfully detected, compilation of libuv started, however I ran into some new problem related to missing test files:

Error C1083 Cannot open source file: 'test\benchmark-async.c': No such file or directory.

I will update this post if I know something new.

I'm trying to build the interpreter on my Android phone in Termux, and I'm hitting an error. Maybe it's because my phone's not rooted, or maybe it's the limited Android C libraries.

make[1]: Entering directory '/data/data/com.termux/files/home/src/wren'
       run util/build_libuv.py
b'[\'-f\', \'make\', \'/data/data/com.termux/files/home/src/wren/deps/libuv/uv.gyp\', \'-I\', \'/data/data/com.termux/files/home/src/wren/deps/libuv/common.gypi\', \'--depth=.\', \'-Goutput_dir=/data/data/com.termux/files/home/src/wren/deps/libuv/out\', \'--generator-output\', \'/data/data/com.termux/files/home/src/wren/deps/libuv/out\', \'-Dhost_arch=aarch64\', \'-Dtarget_arch=aarch64\', \'-Duv_library=static_library\']\nTraceback (most recent call last):\n  File "gyp_uv.py", line 94, in <module>\n    run_gyp(gyp_args)\n  File "gyp_uv.py", line 38, in run_gyp\n    rc = gyp.main(args)\n  File "./build/gyp/pylib/gyp/__init__.py", line 538, in main\n    return gyp_main(args)\n  File "./build/gyp/pylib/gyp/__init__.py", line 514, in gyp_main\n    options.duplicate_basename_check)\n  File "./build/gyp/pylib/gyp/__init__.py", line 130, in Load\n    params[\'parallel\'], params[\'root_targets\'])\n  File "./build/gyp/pylib/gyp/input.py", line 2776, in Load\n    check, generator_input_info)\n  File "./build/gyp/pylib/gyp/input.py", line 602, in LoadTargetBuildFilesParallel\n    parallel_state.pool = multiprocessing.Pool(multiprocessing.cpu_count())\n  File "/data/data/com.termux/files/usr/lib/python2.7/multiprocessing/__init__.py", line 232, in Pool\n    return Pool(processes, initializer, initargs, maxtasksperchild)\n  File "/data/data/com.termux/files/usr/lib/python2.7/multiprocessing/pool.py", line 140, in __init__\n    self._setup_queues()\n  File "/data/data/com.termux/files/usr/lib/python2.7/multiprocessing/pool.py", line 236, in _setup_queues\n    self._inqueue = SimpleQueue()\n  File "/data/data/com.termux/files/usr/lib/python2.7/multiprocessing/queues.py", line 352, in __init__\n    self._rlock = Lock()\n  File "/data/data/com.termux/files/usr/lib/python2.7/multiprocessing/synchronize.py", line 147, in __init__\n    SemLock.__init__(self, SEMAPHORE, 1, 1)\n  File "/data/data/com.termux/files/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, in __init__\n    sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)\nOSError: [Errno 38] Function not implemented\n'
make[1]: *** [util/wren.mk:242: build/libuv.a] Error 1
make[1]: Leaving directory '/data/data/com.termux/files/home/src/wren'
make: *** [Makefile:16: release] Error 2

Colors and refresh can't work very well on Xcode. If you try type something like "var x = 1", you get:

\\/"-
 \_/   wren v0.1.0
�[2K�[30;1m
> �[0m
�[2Cvar�[2K�[30;1m
> �[0m�[0mv�[0m
�[3C�[2K�[30;1m
> �[0m�[0mva�[0m
�[4C�[2K�[30;1m
> �[0m�[36mvar�[0m
�[5C x�[2K�[30;1m
> �[0m�[36mvar�[0m�[0m �[0m
�[6C�[2K�[30;1m
...

I "fix" it erasing the function refreshLine and colors, but it is a workaround. What is the correct way to fix it?

Moving data between applications and/or languages is much easier when objects can be serialized in a platform independent manner.

It would be even more amazing if the serialization format worked like captain proto so that objects do not need to be parsed when loaded.

Currently if building on OS X I get the following make output:

        cc src/aux/wren_aux_meta.c        -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/aux/wren_aux_random.c      -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/vm/wren_compiler.c         -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/vm/wren_core.c             -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/vm/wren_debug.c            -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/vm/wren_primitive.c        -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/vm/wren_utils.c            -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/vm/wren_value.c            -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/vm/wren_vm.c               -O0 -DDEBUG -g -std=c99 -fPIC
        ar lib/libwrend.a                 rcu
        cc lib/libwrend.dylib             -O0 -DDEBUG -g -std=c99 -fPIC 
        cc src/cli/main.c                 -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/cli/modules.c              -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/cli/vm.c                   -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/module/io.c                -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/module/scheduler.c         -O0 -DDEBUG -g -std=c99 -fPIC
        cc src/module/timer.c             -O0 -DDEBUG -g -std=c99 -fPIC
        cc bin/wrend                      -O0 -DDEBUG -g -std=c99 -fPIC
ld: warning: object file (build/libuv.a(core.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(fs.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(tty.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(uv-common.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(loop.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(pipe.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(stream.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(timer.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(async.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(loop-watcher.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(kqueue.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(fs-poll.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(darwin.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(poll.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(process.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(signal.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(tcp.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(udp.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(threadpool.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(inet.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(thread.o)) was built for newer OSX version (10.11) than being linked (10.10)
ld: warning: object file (build/libuv.a(fsevents.o)) was built for newer OSX version (10.11) than being linked (10.10)

It looks like the SDK version being used to build libuv is different to that being used to build Wren. It looks like i'm currently using XCode 7 with Clang 7 to build this. Maybe we need to set -mmacosx-version-min=version when building Wren on OS X?

I've just downloaded wren (hi!), but I can't get any modules to load:

Could not load module 'E:\E:/downloads/misc/wren/wren_cli-windows-0.3.0/pattern'.

Where I'm using import "/pattern" for Pattern and the pattern.wren off rosettacode.
It does not matter where I put it, it ain't ever getting past that "E:\E:/" (as proved with procmon).
Running on windows 10

Pete

I noticed today that Timer.sleep not only suspends the current fiber but it also suspends System.clock.

For example, if I run this script (using the time command on Linux for comparison) I obtain the results shown:

import "timer" for Timer

var start = System.clock
Timer.sleep(2000)
System.print("Time elapsed since program started is %(System.clock-start) seconds.")

/*
    Time elapsed since program started is 8.9e-05 seconds.

    real   0m2.007s
    user   0m0.000s
    sys    0m0.005s
*/

If this is expected behavior, I think it should be documented somewhere. The question is where?

The Timer class is currently undocumented and System.clock is documented in the main repo rather than here.

Having a .wren directory in home (%AppData% in Windows) can be useful for configuration files and custom code extensions (both in wren files and if implemented in the possible ffi plugins).

Inside Wren files one can use this format

import "~/mywrencode" for WrenCode
import "~/utils/env" for Env

That could be translated to

import "/usr/home/myuser/.wren/mywrencode" for WrenCode
import "/usr/home/myuser/.wren/utils/env" for Env

A simple tree structure can be the following

.wren/
├── .wrenconfig.wren
├── mywrencode.wren
└── utils
    ├── env.dll
    ├── env.dylib
    ├── env.so
    └── env.wren

Related

• #52
• #70

f5f08bb

Goal is just to validate the intent here.
It seems to behave as intended (stat on a directory has no size, unlike unix-likes)

This might have to go to the main Wren repo but is it possible to have a way to get command line arguments passed to a wren script?

I'm trying to figure out a way to do a node.js-style relative import, but loadModuleFn doesn't seem to be quite enough on its own. I can adjust the base directory before the import, but can't figure out how to restore it again after the module fiber runs. I need something to hook into there for sequential import statements to be rooted at the correct level. Any ideas?

I was farting around with the REPL (specifically working on adding persistent history between sessions) and I came across the need to know where the user's home dir is so I could save the history in a file.

I took a stab at implementing this myself inside System. It was fun!

I do have one question though; what should the return value be to jive with Wren the best at https://github.com/cacciatc/wren/commit/3a12d253b8948a8b932f253cc53acebe4e62968a#diff-dcb6b0b39dab081abcb7497e66762a57R1066.

Some functions are missing, and the io index page doesn't list FileFlags.

Would this be a welcome addition? Perhaps ~/.wren_history or some such?

Any language needs its way to run native code. As a language for embedding, Wren gives you the flexibility to control the modules you load through the config bindForeignMethodFn and bindForeignClassFn.

However, the CLI is meant to run programs and not for embedded scripting. As such, it needs a way to load user-written native modules.

I suggest the following:

• There will be a function, named, say, Module.importNative(), which will take a normal module path.
• When invoked, it'll search for a .dll or .so file with the same name (depending on the operating system).
• If not found, this is an error.
• If found, it'll load the module into memory and search for a certain function name, let's call it wrenInitModule().
• This function will take no arguments, and will return a pointer to struct WrenNativeModule. This struct will be distributed in a .h file, and any native module will include it.
• The struct will have four fields:
  • classes array of type WrenNativeClass, and its length (alternatively, we can pass an entry filled with NULLs at last. This is the strategy used in CPython).
  • methods array of type WrenNativeMethod and its length (ditto).
• The structs will be defined as follows:

typedef struct
{
  const char* module;
  const char* className;
  WrenForeignClassMethods classMethods;
} WrenNativeClass;

typedef struct
{
  const char* module;
  const char* className;
  bool isStatic;
  const char* signature;
  WrenForeignMethodFn method;
} WrenNativeMethod;

• Module.importNative() will append these arrays to vectors of WrenNativeClass and WrenNativeMethod, accordingly.
• Future import of the same module will be ignored (as with the Wren import system).
• In the implementation of bindForeignClassFn and bindForeignMethodFn, the CLI will look at its defined native methods and return the one appropriate, or NULL if not found.
  • A side note: I know that the VM caches calls to these methods, but I don't know whether it caches only successful calls or even when not found. If the second assumption is the correct, we need to change it.
• This will also be a drop-in replacement for the current implementation, and we'll just implement the standard library as any other native module.

A complete example:

Let's say we want to implement a method that squares its argument, but as native.

Let's start with the C code:

#include <stdbool.h>

#include "wren.h"
#include "wren-cli.h" // Or wherever the above defined

#if defined(_WIN32) || defined(__WIN32__)
#define EXPORT extern "C" __declspec(dllexport)
#else
#define EXPORT extern "C"
#endif

extern "C" void myMathSquare(WrenVM* vm)
{
  double arg = wrenGetSlotDouble(vm, 1);
  wrenSetSlotDouble(vm, 0, arg * arg);
}

static const WrenNativeModule module = {
  // Classes
  { }, 0
  // Methods
  {
    { "myMath", "MyMath", true, "square(_)", myMathSquare }
  },
  1
};
EXPORT const WrenNativeModule* wrenInitModule()
{
  return &module;
}

Now, define myMath.wren:

Module.importNative("./myMath-native")

class MyMath {
  foreign static square(a)
}

Now, compile the C code to a dll or so under the name myMath-native. Our Wren code is serving a bridge between Wren's foreign interface and the user code, so it can use it just as if it would be a normal Wren module:

import "myMath" for MyMath

System.print(MyMath.square(15))

Once the discussion around this topic is finished, I would like to implement this myself.

Wren is SO AMAZING!!!!! 🎉 🎉 🎉 Best regards.

Edit:

We'll still need one special case handling in bindForeignMethodFn - the Module.importNative() function itself...

Is it expected behaviour that tasks added to the Scheduler don't drain after execution?

Given some code like this:

import "scheduler" for Scheduler
import "io" for File

Scheduler.add {
  System.print("before")
}

System.print(File.read("test.wren"))

Scheduler.add {
  System.print("after")
}

The before will print, then the File.read(...) will print, but the after will never print. Is it possible to drain the scheduler automatically before the root fiber ends?

hi, Since wren uses libuv, is there a way for wren to use underlying libuv's network IO functions, maybe via io module, I haven't found any thing in the docs regarding the wren built in io module. It says it's up to the host application to provide interfaces, but what about using wren script as a stand alone application.
Also I am coming from web development background, as opposed to game dev. It would really be cool to be able to write a web framework using wren

The fflush() C API call in stdoutFlush(WrenVM*) should check the return code and throw an exception if it is nonzero.

In particular

$ cat test.wren 
import "io" for Stdout
System.write("Hello, world!\n")
Stdout.flush()

$ wren-cli test.wren > /dev/full ; echo "return code = $?"
return code = 0

There is currently no error message to indicate the output error, nor a failure return code.

This is a quite small thing, but most interpreters have it.

$ wren -e 'System.print("Hello, world!")'

It seems simple enough (famous last words, right?) to add in basic support for it by breaking the runFile function into the part that actually loads the file and the part that runs the VM (probably in a new function called runVM), and then looking for the flag on the commandline (maybe just seeing if argc == 3 and taking argv[2] for now and not worrying about a full commandline parser).

If this sounds like something you want I can probably do this myself and submit a pull request.

Any text printed using System.print or System.write is displayed twice. It is happening only for REPL and not in file mode(even when the file contains only a single print statement)

When System.print is used with an if(true) statement, it is printed only once but the same condition causes System.write to not print anything at all.

The current module loading setup doesn't work very well when you try and pull in modules from other repositories and include them as you'd be accustomed to in other languages. As a quick example, say I have the following directory structure:

/wren-path
    /deps
        /wren-test (pulled in as a git submodule fwiw)
main.wren

When I try and include a file from wren-path/deps/wren-test in main.wren it doesn't load because Wren will only look for modules in the the outer wren-path directory. This makes it effectively impossible to reuse Wren modules elsewhere.

One possible solution is to allow module relative imports by having every ObjModule know from what file path it was loaded and then add its parent as a place to look in loadModule defined in main.c.

Hi,
When usin Stdin.readByte it incorrectly read bytes depending on the value of the previously byte read.
If you look at the code:

static readByte() {
  return read_ {
    // Peel off the first byte.
    var byte = __buffered.bytes[0] // This operates on bytes
    __buffered = __buffered[1..-1] // This operates on UTF8 strings
    return byte
  }
}

Meaning that for every byte values > 127 the whole utf8 character is skipped instead of a single byte.

Using bash to redirect Stdin from a file seems to fail.

Here is the simplest example test1.wren:

import "io" for Stdin, Stdout
var line = Stdin.readLine()
System.print("line: " + line)

When I run interactively it works:

chris@WIN-FE4HG5BFASB:~$ wren/wren test1.wren
fred
line: fred
chris@WIN-FE4HG5BFASB:~$

However, when I redirect stdin to read from a non-empty file it fails:

chris@WIN-FE4HG5BFASB:~$ wren/wren test1.wren < sales.txt
Aborted
chris@WIN-FE4HG5BFASB:~$ head sales.txt
--
-- PostgreSQL database dump
--

-- Dumped from database version 11.5
-- Dumped by pg_dump version 11.5 (Debian 11.5-3.pgdg80+1)

SET statement_timeout = 0;
SET lock_timeout = 0;
SET idle_in_transaction_session_timeout = 0;

Using Ubuntu on WSL 2 on Windows 10.

I don't see any CI on pull requests... if we're still using Travis.ci (or something else) could it be hooked into GitHub so that PRs always have CI running on them? And if we're not I've been very happy with GitHub Actions for Highlight.js.

This confused me for a good while.

Expected behavior:

> var x = 1
> x
1
> System.print(x)
1

>

Actual behavior:

> var x = 1
> x
 
> System.print(x)
1

>

I stared at repl.wren for a good while until I noticed that it actually prints the result of evaluating an expression, but in bright white. If your background color is the same, you won't see anything, even if selecting the text (because that swaps foreground and background color which are the same, so no difference).

What's the way forward here? Simply dropping the color escapes for this case to make use of the default foreground color? Introducing a light/dark color scheme? Checking the value type and reusing the built-in associations for picking the right color? Making a function that gives you the printed representation of a value, lexing it and printing it the same way as the input?

I noticed that the util scripts utils/update_deps.py and utils/build_libuv.py don't utilize deps/libuv but instead, create there own copy; Is this intended?

If not, I have a pull request ready!

Also, building libuv with vs2017 has been patched in v1.20.0 - would it be possible to update the version used to v1.20.0 instead of v1.10.0?

In the source/help:

    printf("Usage: wren [file] [arguments...]\n");
    // ...
    printf("wren %s\n", WREN_VERSION_STRING);

Are we wren or wren_cli. I'd prefer wren to be honest (like node)... can we agree on which it is though so this can be made consistent?

It is frequently useful to read a script from a pipe or ssh-connection rather than from a local file.

I would like to do something like this:

$ echo 'System.print("hello")' | wren-cli

or

$ echo 'System.print("hello")' | wren-cli -

or

$ echo 'System.print("hello")' | wren-cli /dev/stdin

but none of these work.

Another useful pattern is embedding in a shell script, which I do quite frequently with awk. For instance, it would be nice if one could do the following:

#! /bin/sh
...
wren-cli /dev/fd/5 < input.txt 5<< 'EOF'
... wren code goes here...
EOF
... shell script continues

Note that in this example both the script and the file to be processed from standard input are not passed directly to wren, but indirectly via shell redirections. In this example the code comes in via file descriptor # 5, allowing file descriptor # 0 (standard input) to be used normally for feeding input to the script.

Also note that this redirection / EOF handling stuff is all done by the shell - wren-cli does not have to care about it. It just needed to support opening the /dev/fd/5 as a stream. A simple fopen() would do the trick. But obviously wren-cli does additional checks which fail, because /dev/fd/5 is a pipe and not a regular file. In particular, one cannot fseek() within a pipe or get its size in advance. The only thing one can do is just reading from it until EOF occurs.

And all this is embedded within a shell script, which makes things easier because a single file suffices for the combined task tackled by the shell, wren-cli, and potentially even more languages like awk invoked in the same way from within the script.

Anyway, it would really be nice if wren allowed reading its script from a pipe and not just from a real file. Currently, the following happens:

$ echo 'System.print("hello")' | wren-cli /dev/stdin
Could not read file "/dev/stdin".

I am curious why does File.open only support reading files inside the supplied function? Is this a design decision or hasn't been implemented?

I build wren and libuv both with 'msbuild_toolset': 'v140_xp', /MT , VS2015,
both successfully.

And then I put wren.exe on window 2003 server, and run the scirpt:

import "io" for File

var rp = File.realPath(".")
System.print(rp) 

the output:

function not implemented
[scheduler line 18] in runNextScheduled_()
[io line 99] in realPath(_)
[main line 3] in (script)

wren.exe self is OK, just can not use function in libuv.

Any suggestion, thank you!

There's a few things the module directory currently covers that seem to be typical standard library material. However, there are some notable things missing, networking in particular. TCP sockets and HTTP will likely be needed before any sort of package manager can exist, unless it's written in something else. I think that would be a huge missed opportunity to create a sizeable complex application purely within the confines of the language itself though.

Do you see more of these things living in wren itself, included in the module directory, or do you have something else in mind? It'd be good to get your ideas for this laid out, even if they aren't super fleshed out yet. I'd love to help out however I can. I've been working on node.js core for a long time, so I'm quite familiar with libuv. 😸

Some things I'd like to see:

• Expose native Buffer types similar to typed arrays in JS and the Buffer type in node, allowing binary data to be passed around without needing to serialize unless it is used within wren code. (ie: File.write('dest', File.read('source')) would never serialize the read data into a wren string)
• Stream base classes for File and, eventually, Socket to inherit from, for consistent read/write interfaces. Stream should probably inherit from Sequence for fancy iteration magic.
• TCP and maybe UDP Socket classes inheriting a DuplexStream class, or something like that
• An HTTP Parser stream

Also, I feel like all of this stuff, including what is already in module could probably actually live in a separate project which gets pulled in just like libuv currently. It'd be great to have some sort of consistent mechanism to attach native modules, similar to what mruby does. I think that half of the module system could exist before a package manager to make it easier to move as much of what is needed to make a package manager work into userland space.

If we can decide on an interface for native modules, I'd be happy to get started making that work. 😸

Hello,

my code looks like this:

import "io" for File

class WebRen {
  construct new() {
     var x = "x"
  }

  write() {
    File.open("communicator.data") {|file|
        file.writeBytes("hello")
    }
  }
}

But if I call write(), this error comes up:'

operation not permitted
[io line 86] in openWithFlags(_,_,_)
[io line 65] in open(_,_)

Does somebody know whats the Error or how to fix it?

Thx.

For now the following tests are skipped:

• test/io/stdin/read_byte_eof.wren
• test/io/stdin/read_line_eof.wren
• test/io/stdin/read_line.wren

On windows they time out, and on mac they have assertions.
It seems the behavior of stdin is not consistent here (wren-cli code) or the test mechanics in python side (util/test.py) has differences. Given that the errors come from wren-cli side it's hard to tell since the code is the same.

Running the test manually via `bin/wren_cli test/io/stdin/read_line.wren) will work ok, because we're in a terminal typing on stdin.

I already spotted the call extern/Scheduler.runNextScheduled_() pattern:

  static mkdir(path) {
     ensurePath_(path)
     mkdir_(path, Fiber.current)
     return Scheduler.runNextScheduled_()
     return await { mkdir_(path, Fiber.current) }
   }

And was replacing it with:

  static mkdir(path) {
     ensurePath_(path)
     return await_ { mkdir_(path, Fiber.current) }
   }

But much like #65 it why don't we just move this responsibility into Scheduler:

  static mkdir(path) {
     ensurePath_(path)
     return Scheduler.await_ { mkdir_(path, Fiber.current) }
   }

await is no doubt familiar to those doing async in JavaScript, but open to a better name...

I had a build error on OSX using my brew-installed gcc-4.9:

/usr/local/bin/gcc-4.9 src/optional/wren_opt_meta.c   -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/optional/wren_opt_random.c -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/vm/wren_compiler.c         -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/vm/wren_core.c             -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/vm/wren_debug.c            -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/vm/wren_primitive.c        -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/vm/wren_utils.c            -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/vm/wren_value.c            -O3 -std=c99 -fPIC
/usr/local/bin/gcc-4.9 src/vm/wren_vm.c               -O3 -std=c99 -fPIC
        ar lib/libwren.a                  rcu
/usr/local/bin/gcc-4.9 lib/libwren.dylib              -O3 -std=c99 -fPIC
Build settings from command line:
    ARCHS = i386 x86_64
    BUILD_DIR = out
    ONLY_ACTIVE_ARCH = NO

=== BUILD TARGET libuv OF PROJECT uv WITH CONFIGURATION Release ===

Check dependencies

CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/fs-poll.o src/fs-poll.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Git/wren/deps/libuv
    export LANG=en_US.US-ASCII
    /usr/local/bin/gcc-4.9 -x c -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -Os -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_DARWIN_USE_64_BIT_INODE=1 -D_DARWIN_UNLIMITED_SELECT=1 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.11 -g -fvisibility=hidden -Wno-sign-conversion -I/Git/wren/deps/libuv/out/Release/include -Iinclude -Isrc -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources/i386 -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources -Wall -Wextra -Wno-unused-parameter -Wall -Wendif-labels -W -Wno-unused-parameter -F/Git/wren/deps/libuv/out/Release -g --std=gnu89 -pedantic -fstrict-aliasing -MMD -MT dependencies -MF /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/fs-poll.d --serialize-diagnostics /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/fs-poll.dia -c /Git/wren/deps/libuv/src/fs-poll.c -o /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/fs-poll.o
gcc-4.9: error: /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/fs-poll.dia: No such file or directory
gcc-4.9: error: unrecognized command line option '-fdiagnostics-show-note-include-stack'
gcc-4.9: error: unrecognized command line option '-fmacro-backtrace-limit=0'
gcc-4.9: error: unrecognized command line option '--serialize-diagnostics'
Command /usr/local/bin/gcc-4.9 failed with exit code 1

CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/threadpool.o src/threadpool.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Git/wren/deps/libuv
    export LANG=en_US.US-ASCII
    /usr/local/bin/gcc-4.9 -x c -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -Os -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_DARWIN_USE_64_BIT_INODE=1 -D_DARWIN_UNLIMITED_SELECT=1 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.11 -g -fvisibility=hidden -Wno-sign-conversion -I/Git/wren/deps/libuv/out/Release/include -Iinclude -Isrc -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources/i386 -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources -Wall -Wextra -Wno-unused-parameter -Wall -Wendif-labels -W -Wno-unused-parameter -F/Git/wren/deps/libuv/out/Release -g --std=gnu89 -pedantic -fstrict-aliasing -MMD -MT dependencies -MF /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/threadpool.d --serialize-diagnostics /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/threadpool.dia -c /Git/wren/deps/libuv/src/threadpool.c -o /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/threadpool.o
gcc-4.9: error: /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/threadpool.dia: No such file or directory
gcc-4.9: error: unrecognized command line option '-fdiagnostics-show-note-include-stack'
gcc-4.9: error: unrecognized command line option '-fmacro-backtrace-limit=0'
gcc-4.9: error: unrecognized command line option '--serialize-diagnostics'
Command /usr/local/bin/gcc-4.9 failed with exit code 1

CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/inet.o src/inet.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Git/wren/deps/libuv
    export LANG=en_US.US-ASCII
    /usr/local/bin/gcc-4.9 -x c -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -Os -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_DARWIN_USE_64_BIT_INODE=1 -D_DARWIN_UNLIMITED_SELECT=1 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.11 -g -fvisibility=hidden -Wno-sign-conversion -I/Git/wren/deps/libuv/out/Release/include -Iinclude -Isrc -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources/i386 -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources -Wall -Wextra -Wno-unused-parameter -Wall -Wendif-labels -W -Wno-unused-parameter -F/Git/wren/deps/libuv/out/Release -g --std=gnu89 -pedantic -fstrict-aliasing -MMD -MT dependencies -MF /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/inet.d --serialize-diagnostics /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/inet.dia -c /Git/wren/deps/libuv/src/inet.c -o /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/inet.o
gcc-4.9: error: /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/inet.dia: No such file or directory
gcc-4.9: error: unrecognized command line option '-fdiagnostics-show-note-include-stack'
gcc-4.9: error: unrecognized command line option '-fmacro-backtrace-limit=0'
gcc-4.9: error: unrecognized command line option '--serialize-diagnostics'
Command /usr/local/bin/gcc-4.9 failed with exit code 1

CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/uv-common.o src/uv-common.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
    cd /Git/wren/deps/libuv
    export LANG=en_US.US-ASCII
    /usr/local/bin/gcc-4.9 -x c -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -Wno-trigraphs -Os -Wno-missing-field-initializers -Wno-missing-prototypes -Wno-return-type -Wno-missing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wno-empty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wno-shorten-64-to-32 -Wpointer-sign -Wno-newline-eof -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_DARWIN_USE_64_BIT_INODE=1 -D_DARWIN_UNLIMITED_SELECT=1 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fstrict-aliasing -Wdeprecated-declarations -mmacosx-version-min=10.11 -g -fvisibility=hidden -Wno-sign-conversion -I/Git/wren/deps/libuv/out/Release/include -Iinclude -Isrc -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources/i386 -I/Git/wren/deps/libuv/build/uv.build/Release/libuv.build/DerivedSources -Wall -Wextra -Wno-unused-parameter -Wall -Wendif-labels -W -Wno-unused-parameter -F/Git/wren/deps/libuv/out/Release -g --std=gnu89 -pedantic -fstrict-aliasing -MMD -MT dependencies -MF /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/uv-common.d --serialize-diagnostics /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/uv-common.dia -c /Git/wren/deps/libuv/src/uv-common.c -o /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/uv-common.o
gcc-4.9: error: /Git/wren/deps/libuv/build/uv.build/Release/libuv.build/Objects-normal/i386/uv-common.dia: No such file or directory
gcc-4.9: error: unrecognized command line option '-fdiagnostics-show-note-include-stack'
gcc-4.9: error: unrecognized command line option '-fmacro-backtrace-limit=0'
gcc-4.9: error: unrecognized command line option '--serialize-diagnostics'
Command /usr/local/bin/gcc-4.9 failed with exit code 1

** BUILD FAILED **


The following build commands failed:
  CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/fs-poll.o src/fs-poll.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
  CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/threadpool.o src/threadpool.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
  CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/inet.o src/inet.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
  CompileC build/uv.build/Release/libuv.build/Objects-normal/i386/uv-common.o src/uv-common.c normal i386 c com.apple.compilers.llvm.clang.1_0.compiler
(4 failures)

make[1]: *** [build/libuv.a] Error 65
make: *** [release] Error 2

If anyone else is having this problem, I managed to get it to build using the following:

CC="/usr/bin/gcc" make

This just forces make to use the native OSX Apple LLVM to compile.

In Wren, assignment returns its value, like in C:

var a
System.print(a = 5) // 5

When implementing setters, we need to maintain this behavior:

// Not good
class C {
  static a=(value) {
    __a = value
  }
}
System.print(C.a = 5) // null

// Good
class C {
  static a=(value) { __a = value }
}
System.print(C.a = 5) // 5

// Also good
class C {
  static a=(value) {
    __a = value
    return value
  }
}
System.print(C.a = 5) // 5

Generally, the CLI do that, except in one foreign setter - Stdin.isRaw=(_):

Instead we should do:

void stdinIsRawSet(WrenVM* vm)
{
  initStdin();
  
  isStdinRaw = wrenGetSlotBool(vm, 1);
  
  if (uv_guess_handle(stdinDescriptor) == UV_TTY)
  {
    uv_tty_t* handle = (uv_tty_t*)stdinStream;
    uv_tty_set_mode(handle, isStdinRaw ? UV_TTY_MODE_RAW : UV_TTY_MODE_NORMAL);
  }
  else
  {
    // Can't set raw mode when not talking to a TTY.
    // TODO: Make this a runtime error?
  }

  wrenEnsureSlots(vm, 1); // Is that required? Probably not
  wrenSetSlotBool(vm, 0, isStdinRaw);
}

System.print("📟")

will throw Unhandled key-code [dec]: 240

using MacOS Catalina
Wren 0.3.0

Thought: Since the core library is so small... could we just hard-code the list of all static methods so that not only could you auto-complete module names, but you could also auto-complete the methods also well?

We have:

• isDirectory
• isFile

Should it not be isSpecialDevice?

This would keep with our "simple naming" philosophy. Do we need to consider this a breaking change and support both for some period of time, or because we're still <1 we can just change it?

https://github.com/wren-lang/wren-cli/blame/master/README.md#L7-L18

The building of wren-cli is completed, but now what, where to start and what to expect? I'm using Linux.

I see:

  // TODO: Copied from File. Figure out good way to share this.
  static ensureString_(path) {
    if (!(path is String)) Fiber.abort("Path must be a string.")
  }

Why not just have a common utility class, ie: Ensure.string or Util.assertString...

class Util {
  static assertString(path) {
    if (!(path is String)) Fiber.abort("Path must be a string.")
  }
}

Open to suggestions for naming.

Alternaties: Subclass a common base class with the utilities but I'm not sure this is fully possible with foreign classes.

Would you like to add more error handling for return values from functions like the following?

• fseek ⇒ readFile
• printf ⇒ main

I would like to use wren-cli for writing real scripts that work reliably, not just toying around for learning the languages and trying out things.

Unfortunately, wren-cli is not reliable yet because it fails to detect write errors in certain situations. And reliable programs must catch at least input/output errors!

In order to demonstrate the problem, compare

$ echo 'System.print("hello")' > test.wren
$ wren0 test.wren > /dev/full

versus

$ echo puts hello | tclsh > /dev/full
error writing "stdout": no space left on device

wren should also display an error message in this case, and could even surpass tclsh by also returning EXIT_FAILURE in this case, allowing a script invoking wren-cli to detect the failure and react accordingly.

The reason why wren-cli currently misses this error is because it obviously does not call fflush(0) and check its success before exiting.

The problem are the C standard I/O functions which normally work buffered. Which means a printf() might be successful, even tough it did not write anything yet. It only wrote to the internal buffer.

When main() returns, the C runtime automatically calls fflush(0) internally, which tries to write out the contents all yet-unwritten buffers. This fails, but at this time main() has already exited and cannot detect the error any more. It is implementation-defined what the C runtime does in this situation. Under Linux obviously it ignores the error and returns as if everything was fine.

But if wren called fflush() itself before exit() or returning from main(), it had a chance to catch the write error and to report it or throw an exception.

I would very much appreciate if wren-cli would do this, because then it would be possible to write scripts that catch all output errors - and not just most.

While messing about with Wren's CLI, I noticed a few issues.

Firstly and most pressingly, when mucking about in the CLI, any error (at least with undefined variables) is fatal, to the point of requiring a new wren CLI session. For example:

> System.print(SOME_UNDEFINED_VAR)
(Error message)
> System.print("Valid String!")
(Exact same error message)

Any valid code after that first System.print refuses to work. Period. Tested on both mainline master and my custom linenoise fork.

Secondly.

> class Test {
(ERROR!)
> class Test {}
(ERROR! Test is already defined!)
> System.print(Test)
null

You can probably see the issue. Classes and blocks really should allow definitions across multiple lines, and a REPL-mode class definition error should fail without creating the class.

Regular files are fine, just the CLI in REPL mode gets these errors. This unfortunately renders the CLI unusable as a prototyping tool.

Hi,
if I have something like the following file architecture:
main.wren: import "foo"
wren_module/foo/foo.wren: import "./bar"
wren_module/foo/bar.wren: // Do some really important stuff
I get an error like: Could not load module './bar'.
but if I modify
main.wren: import "foo/foo"
Then it works. It seems import aliasing barf oddly there.
Cheers

I just noticed that using an undefined variable in the REPL will silently initialize it to 1:

> a + 1
[repl line 1] Error at 'a': Variable is used but not defined.
> a + 1
2
> a
1

I'm using Wren 0.3.0 built from the latest main as I'm writing this (i.e. b82cf5a).