On Tuesday, 11 February 2014 at 13:11:06 UTC, The Guest wrote:
> On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
>> Barely running but already fun and a little useful.
>>
>> Example:
>>
>> D> import std.algorithm, std.array, std.file;
>> => std
>> D> auto name(T)(T t) {
>> |     return t.name;
>> | }
>> => name
>> D> dirEntries(".", SpanMode.depth).map!name.join(", ")
>> => ./drepl_sandbox
>> D>
>>
>> https://github.com/MartinNowak/drepl
>> http://drepl.dawg.eu/
>
> http://dpaste.dzfl.pl/1969487a
> Works for me when playing around.
> Not sure we'll ever see a real D repl.

SDC is capable to JIT whatever D it support. That mean you can
create a REPL fairly easily. This has been in my TODO list for a
while, but supporting more feature is higher priority.

Feel free to contact me is that is of interest for you (Martin,
please do as well if you think it is worth it).

On 02/11/2014 04:24 PM, Martin Nowak wrote:
>>
>
> No problem :), it's the most important TODO right now to prevent this.
> https://github.com/MartinNowak/drepl/blob/master/examples/server.d#L34

I wish SELinux was simpler, but it isn't. So instead of using a TCP socket, I quickfixed this issue by polling non-blocking process pipes https://github.com/MartinNowak/drepl/commit/1aef9acedb4ee4ee7cdcceda56796aba6d460cbe.

On Tuesday, 11 February 2014 at 11:33:53 UTC, thedeemon wrote:
>
>> Have you seen Dabble?
>> https://github.com/callumenator/dabble
>
> Just found out its author added Linux support. I was able to build an x86 version but it didn't work properly in a 64 bit system: it assumes dmd makes x86 binaries by default while it really makes 64-bit ones. And for 64 bits Dabble doesn't compile: as it often happens, it's too easy to forget that array.length is not always uint.

I don't have a 64-bit tool-chain to play with, could submit those 64 bit build errors on github?

On Wednesday, 12 February 2014 at 04:43:00 UTC, cal wrote:
> On Tuesday, 11 February 2014 at 11:33:53 UTC, thedeemon wrote:
>>> Have you seen Dabble?
>>> https://github.com/callumenator/dabble
>>
>> Just found out its author added Linux support. I was able to build an x86 version but it didn't work properly in a 64 bit system: it assumes dmd makes x86 binaries by default while it really makes 64-bit ones.

> I don't have a 64-bit tool-chain to play with, could submit those 64 bit build errors on github?

I've just submitted a pull request for compiling dabble repl in 64 bits and created an issue on github with the linking problem arising when it tries to work. My diagnosis of the problem might be absolutely wrong though.

Am 12.02.2014 03:49, schrieb Martin Nowak:
> On 02/11/2014 04:24 PM, Martin Nowak wrote:
>>>
>>
>> No problem :), it's the most important TODO right now to prevent this.
>> https://github.com/MartinNowak/drepl/blob/master/examples/server.d#L34
>
> I wish SELinux was simpler, but it isn't. So instead of using a TCP
> socket, I quickfixed this issue by polling non-blocking process pipes
> https://github.com/MartinNowak/drepl/commit/1aef9acedb4ee4ee7cdcceda56796aba6d460cbe.
>

BTW, if you (can) use the latest vibe.d beta version, there is also the vibe.core.core.createFileDescriptorEvent function, which should work for waiting on the non-blocking pipes instead of busy-waiting with yield().

On 02/12/2014 10:29 AM, Sönke Ludwig wrote:
>
> BTW, if you (can) use the latest vibe.d beta version, there is also the
> vibe.core.core.createFileDescriptorEvent function, which should work for
> waiting on the non-blocking pipes instead of busy-waiting with yield().

Nice, will try.

On 02/11/2014 11:32 AM, thedeemon wrote:
>>
>
> Have you seen Dabble?
> https://github.com/callumenator/dabble
> It works pretty well on my Win 7.

I will try it again, there is a lot of recent activity.
Last time it didn't work.
https://github.com/callumenator/dabble/issues/1
I think it still misses an essential part.
To make a real REPL one has to support importing of modules and linking,
otherwise one can only imitate certain language constructs.
For example it should be possible to call a function or inherit from a class that were defined earlier.

On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
> Barely running but already fun and a little useful.

Interesting!

I was playing around:

D> write("test");
=> undefined identifier write
D> import std.stdio;
=> std
D> write("test");
D>

Shouldn't code above print "test"?

On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
> Barely running but already fun and a little useful.
>
> Example:
>
> D> import std.algorithm, std.array, std.file;
> => std
> D> auto name(T)(T t) {
>  |     return t.name;
>  | }
> => name
> D> dirEntries(".", SpanMode.depth).map!name.join(", ")
> => ./drepl_sandbox
> D>
>
> https://github.com/MartinNowak/drepl
> http://drepl.dawg.eu/

I'm kind of amazed how well this works. Awesome.

already added a bug report in github for that


On Wed, Feb 12, 2014 at 11:56 AM, MattCoder <somekindofmonster@email.com.br>wrote:

> On Tuesday, 11 February 2014 at 04:46:41 UTC, Martin Nowak wrote:
>
>> Barely running but already fun and a little useful.
>>
>
> Interesting!
>
> I was playing around:
>
> D> write("test");
> => undefined identifier write
> D> import std.stdio;
> => std
> D> write("test");
> D>
>
> Shouldn't code above print "test"?
>