On Thursday, 11 September 2014 at 10:23:56 UTC, Rikki Cattermole wrote:
> On 11/09/2014 10:05 p.m., Chris wrote:
>> On Thursday, 11 September 2014 at 09:37:04 UTC, ketmar via Digitalmars-d
>> wrote:
>>> On Thu, 11 Sep 2014 09:29:41 +0000
>>> Chris via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>>> he has
>>> she has. ;-)
>>
>> Japers, I wasn't sure, if it was he or she and just gambled on a 50%
>> chance :) My apologies.
>>
>> PS and OT I hope Higgs will become a long term project. Imagine, you
>> could combine Higgs and vibe.d. You could write your own D extensions
>> for server side JS. In this way you could have projects where anyone who
>> knows JS could contribute (good bye PHP), no need to know D. I have a
>> test version of a LuaD + Lua Server Pages + vibe.d server. Works very
>> well. JS is even more wide spread than Lua (albeit inferior as a language).
>
> *starts drooling at the idea of using Jade for Cmsed*
> Would seriously fix so many problems with templates.
>
> Any chance I could get a copy of your test for LuaD + Lua Server Pages?
> I may want to investigate that angle as well.

Of course. Once I have a "clean" version. The first test version is full of embarrassing hit-and-miss code, commented blocks etc.

But you could probably glue one together yourself.

1. get Open Luasp http://www.luasp.org/
2. get LuaD
3. create a vibe.d project (a normal default project will do, for testing at least)
4. link your project to libluad and liblualsp (or lualsp.so)

In you vibe.d code route to your lua handling function

shared static this() {
  [...]
  router.any("*", &luaTest);
  [...]
}

void luaTest(HTTPServerRequest req, HTTPServerResponse res) {
  // do your lualsp / LuaD thing
}

Then you have basically a few options. Use Lua code as in

test.lua:

repuire("lualsp")
dofile_lsp("example.html")

in (Lua)D:

lua.doFile("test.lua")

or

lua.doString("require('lualsp')");
lua.doString("dofile_lsp('public/example1.html')");

or (what I do), call the functions provided by lualsp directly

extern (C) int luaopen_lualsp(lua_State *L);
extern (C) int luaL_do_lsp_file(lua_State* L,const char* filename);
[etc....]

Or a combination of the above.

Just have a look at the various methods provided by both LuaD and lualsp.

Note: lualsp writes to stdout, make sure you use

std.c.stdio.stdout

to grab the output. Not the one provided in Phobos' std.stdio

Excerpt from dub.json

"libs": [
    "luad",
    "lua5.1",
    "lualsp"
	],

Make sure you use Lua 5.1. LuaD (afsaik) only supports 5.1 as of now.

It works like PHP (echo, print etc). I put this together in order to avoid PHP in the future. Lua is a sound language and you can expect developers to be familiar with it.

On 11/09/2014 11:13 p.m., Chris wrote:
> On Thursday, 11 September 2014 at 10:23:56 UTC, Rikki Cattermole wrote:
>> On 11/09/2014 10:05 p.m., Chris wrote:
>>> On Thursday, 11 September 2014 at 09:37:04 UTC, ketmar via Digitalmars-d
>>> wrote:
>>>> On Thu, 11 Sep 2014 09:29:41 +0000
>>>> Chris via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>>
>>>>> he has
>>>> she has. ;-)
>>>
>>> Japers, I wasn't sure, if it was he or she and just gambled on a 50%
>>> chance :) My apologies.
>>>
>>> PS and OT I hope Higgs will become a long term project. Imagine, you
>>> could combine Higgs and vibe.d. You could write your own D extensions
>>> for server side JS. In this way you could have projects where anyone who
>>> knows JS could contribute (good bye PHP), no need to know D. I have a
>>> test version of a LuaD + Lua Server Pages + vibe.d server. Works very
>>> well. JS is even more wide spread than Lua (albeit inferior as a
>>> language).
>>
>> *starts drooling at the idea of using Jade for Cmsed*
>> Would seriously fix so many problems with templates.
>>
>> Any chance I could get a copy of your test for LuaD + Lua Server Pages?
>> I may want to investigate that angle as well.
>
> Of course. Once I have a "clean" version. The first test version is full
> of embarrassing hit-and-miss code, commented blocks etc.

Personally I'm not worried. I wouldn't be able to use it in any form.

> But you could probably glue one together yourself.
>
> 1. get Open Luasp http://www.luasp.org/
> 2. get LuaD
> 3. create a vibe.d project (a normal default project will do, for
> testing at least)
> 4. link your project to libluad and liblualsp (or lualsp.so)
>
> In you vibe.d code route to your lua handling function
>
> shared static this() {
>    [...]
>    router.any("*", &luaTest);
>    [...]
> }
>
> void luaTest(HTTPServerRequest req, HTTPServerResponse res) {
>    // do your lualsp / LuaD thing
> }
>
> Then you have basically a few options. Use Lua code as in
>
> test.lua:
>
> repuire("lualsp")
> dofile_lsp("example.html")
>
> in (Lua)D:
>
> lua.doFile("test.lua")
>
> or
>
> lua.doString("require('lualsp')");
> lua.doString("dofile_lsp('public/example1.html')");
>
> or (what I do), call the functions provided by lualsp directly
>
> extern (C) int luaopen_lualsp(lua_State *L);
> extern (C) int luaL_do_lsp_file(lua_State* L,const char* filename);
> [etc....]
>
> Or a combination of the above.
>
> Just have a look at the various methods provided by both LuaD and lualsp.
>
> Note: lualsp writes to stdout, make sure you use
>
> std.c.stdio.stdout
>
> to grab the output. Not the one provided in Phobos' std.stdio
>
> Excerpt from dub.json
>
> "libs": [
>      "luad",
>      "lua5.1",
>      "lualsp"
>      ],
>
> Make sure you use Lua 5.1. LuaD (afsaik) only supports 5.1 as of now.
>
> It works like PHP (echo, print etc). I put this together in order to
> avoid PHP in the future. Lua is a sound language and you can expect
> developers to be familiar with it.


I see hmm, I may compile a custom lua dll then with lanes (think threading). Well maybe, we shall see.
Might also be a good idea to hook it up to my skeleton tool[0] to enable using e.g. gists for require's.

[0] https://github.com/rikkimax/skeleton

On Thursday, 11 September 2014 at 11:28:38 UTC, Rikki Cattermole wrote:
>
> I see hmm, I may compile a custom lua dll then with lanes (think threading). Well maybe, we shall see.
> Might also be a good idea to hook it up to my skeleton tool[0] to enable using e.g. gists for require's.
>
> [0] https://github.com/rikkimax/skeleton

Maybe I can set up a simple test version for you, when I find the time. Can't promise but I'll try. One thing I haven't looked into yet is a clever way of handling the output in stdout. At the moment, I write to a temporary file ("test.txt") I read in again.

>There are various api the compiler use to allocate from the GC. Some do not specify if the allocated memory contains pointers or not, and none do specify the type qualifier of the memory.

Is it true about pointers? Which functions?
And why type qualifiers matter?

Am Thu, 11 Sep 2014 14:30:05 +0000
schrieb "Kagamin" <spam@here.lot>:

> >There are various api the compiler use to allocate from the GC. Some do not specify if the allocated memory contains pointers or not, and none do specify the type qualifier of the memory.
> 
> Is it true about pointers? Which functions?
> And why type qualifiers matter?

Immutable data structures cannot have pointers changed or set to null. Also they can only reference other immutable data. This means that they form sort of a big blob that is kept alive by one or more pointers to it, but the GC never needs to check the immutable pointers inside of it.

Shared/unshared may affect implementations that provide thread local GC. E.g. only shared data needs to be handled by a global stop the world GC. I'm not sure though.

-- 
Marco

On Thursday, 11 September 2014 at 11:28:38 UTC, Rikki Cattermole wrote:

Rikki, I have a basic LuaD / vibe.d / Lua LSP server now. I needed actually less code than expected. If you give me your email address, I can send it to you. It has a simple form example.

On 12/09/2014 11:30 p.m., Chris wrote:
> On Thursday, 11 September 2014 at 11:28:38 UTC, Rikki Cattermole wrote:
>
> Rikki, I have a basic LuaD / vibe.d / Lua LSP server now. I needed
> actually less code than expected. If you give me your email address, I
> can send it to you. It has a simple form example.

Okay sweet.
alphaglosined /at/ gmail /dot/ com

On Friday, 12 September 2014 at 11:46:08 UTC, Rikki Cattermole wrote:
> On 12/09/2014 11:30 p.m., Chris wrote:
>> On Thursday, 11 September 2014 at 11:28:38 UTC, Rikki Cattermole wrote:
>>
>> Rikki, I have a basic LuaD / vibe.d / Lua LSP server now. I needed
>> actually less code than expected. If you give me your email address, I
>> can send it to you. It has a simple form example.
>
> Okay sweet.
> alphaglosined /at/ gmail /dot/ com

Ok, I've sent it.

On Thursday, 11 September 2014 at 16:26:37 UTC, Marco Leise wrote:
> Immutable data structures cannot have pointers changed or set
> to null. Also they can only reference other immutable data.
> This means that they form sort of a big blob that is kept
> alive by one or more pointers to it, but the GC never needs
> to check the immutable pointers inside of it.

GC still should free unreachable parts of that blob.

> Shared/unshared may affect implementations that provide thread
> local GC. E.g. only shared data needs to be handled by a
> global stop the world GC. I'm not sure though.

Can get in a way, when you need a thread-local immutable object.

On Saturday, 13 September 2014 at 18:06:47 UTC, Kagamin wrote:
> On Thursday, 11 September 2014 at 16:26:37 UTC, Marco Leise wrote:
>> Immutable data structures cannot have pointers changed or set
>> to null. Also they can only reference other immutable data.
>> This means that they form sort of a big blob that is kept
>> alive by one or more pointers to it, but the GC never needs
>> to check the immutable pointers inside of it.
>
> GC still should free unreachable parts of that blob.
>
>> Shared/unshared may affect implementations that provide thread
>> local GC. E.g. only shared data needs to be handled by a
>> global stop the world GC. I'm not sure though.
>
> Can get in a way, when you need a thread-local immutable object.

Hmm... when is that necessary? Wouldn't `const` be enough? AFAICS, `immutable` is mostly useful for shared data.