On Monday, 4 July 2016 at 07:33:48 UTC, ZombineDev wrote:
> BTW, do you plan to handle stuff like exceptions, virtual calls and associative arrays and if so how? Sounds quite challenging.

on the lower level, it's all just arrays and jumps. ;-)

On Tuesday, 5 July 2016 at 16:40:05 UTC, ketmar wrote:
> so, we played a little game with Stefan: i wrote a simple stack-based VM implementation for our beloved bug6498, and got

What is «bug6498»?

On Tue, Jul 05, 2016 at 05:44:14PM +0000, Ola Fosheim Grøstad via Digitalmars-d-announce wrote:
> On Tuesday, 5 July 2016 at 16:40:05 UTC, ketmar wrote:
> > so, we played a little game with Stefan: i wrote a simple stack-based VM implementation for our beloved bug6498, and got
> 
> What is «bug6498»?

https://issues.dlang.org/show_bug.cgi?id=6498


T

-- 
Give me some fresh salted fish, please.

On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote:
> Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different from CTFE?

Not that I opposes this, but please keep it focused. Doing a bytecode interpreter is a huge task on its own and this seems largely orthogonal.

and just to make sure that my approach is working: bytecode compiler now compiles simple free functions without args and returning int (yep, there are some in phobos! ;-), while passing everything other to old interpreter. it works, and all phobos unittests are passed (and some functions were actually executed with VM).

that's where i should stop, i think, until it comes too far. ;-)

On Tue, Jul 5, 2016 at 11:54 PM, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> and just to make sure that my approach is working: bytecode compiler now compiles simple free functions without args and returning int (yep, there are some in phobos! ;-), while passing everything other to old interpreter. it works, and all phobos unittests are passed (and some functions were actually executed with VM).
>
> that's where i should stop, i think, until it comes too far. ;-)
>

Are you sharing this code / how you did it with the GSOC intern?

On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote:
> Are you sharing this code

yes. we are chatting with Stefan in IRC, and the repository is public (i mean, the link was there ;-). yet it won't compile with "vanilla" dmd anyway -- i require my dmd fork ("aliced"). and i don't really want to make it more public, as i have no intentions to turn that into full-blown engine.

also, not only our codebases are completely different, but our designs and approaches are drastically different. we just can't share/reuse the code, those projects are as compatible as WLIV and Z80. ;-)

> how you did it with the GSOC intern?
Stefan in not GSOC intern. ;-)

On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote:
> Are you sharing this code

i mean "my code is publicly available, but we aren't sharing any code between our projects".

On Tuesday, 5 July 2016 at 21:11:39 UTC, deadalnix wrote:
> On Monday, 4 July 2016 at 07:29:49 UTC, ZombineDev wrote:
>> Nice work! Any chance that you could also improve AliasSeq algorithms, like those in std.meta to compile faster and use less memory during compilation? Or is that too different from CTFE?
>
> Not that I opposes this, but please keep it focused. Doing a bytecode interpreter is a huge task on its own and this seems largely orthogonal.

I was actually wondering if they're orthogonal or some of the CTFE improvements could be reused. I was not saying the he should work on both if they're not related.

On Wed, Jul 6, 2016 at 8:09 AM, ketmar via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 6 July 2016 at 05:54:48 UTC, Rory McGuire wrote:
>
>> Are you sharing this code
>>
>
> yes. we are chatting with Stefan in IRC, and the repository is public (i mean, the link was there ;-). yet it won't compile with "vanilla" dmd anyway -- i require my dmd fork ("aliced"). and i don't really want to make it more public, as i have no intentions to turn that into full-blown engine.
>
Nice! Sounds like fun.


>
> also, not only our codebases are completely different, but our designs and approaches are drastically different. we just can't share/reuse the code, those projects are as compatible as WLIV and Z80. ;-)

Thought as much, wondered if the ideas about how they work were being shared; often one idea sparks another.


>
> how you did it with the GSOC intern?
>>
> Stefan in not GSOC intern. ;-)
>
doh! my bad.