Thread overview
dlangbot for Telegram - D compiler in your pocket
Jun 09, 2018
Anton Fediushin
Jun 10, 2018
Dechcaudron
Jun 11, 2018
Anton Fediushin
Jun 11, 2018
Dechcaudron
Jun 11, 2018
Anton Fediushin
June 09, 2018
Hello, I am glad to announce that new Telegram bot which can execute D code is up and running!

Check it out here: https://t.me/dlangbot

Features:
 - Two compilers to choose from: dmd (default) and ldc
 - Support for custom compiler arguments with `/args` command
 - It's possible to set program's stdin with `/stdin`
 - Code is automatically compiled and ran again when you edit your message

Repository: https://gitlab.com/ohboi/dlangbot

Any ideas on how to improve it are appreciated!
June 10, 2018
On Saturday, 9 June 2018 at 20:28:24 UTC, Anton Fediushin wrote:
> Hello, I am glad to announce that new Telegram bot which can execute D code is up and running!
>
> Check it out here: https://t.me/dlangbot
>
> Features:
>  - Two compilers to choose from: dmd (default) and ldc
>  - Support for custom compiler arguments with `/args` command
>  - It's possible to set program's stdin with `/stdin`
>  - Code is automatically compiled and ran again when you edit your message
>
> Repository: https://gitlab.com/ohboi/dlangbot
>
> Any ideas on how to improve it are appreciated!

As much as I love Telegram bots and D, compilation and execution offered by a bot provides no clear advantage to me (still, I kinda like it). I assume you are looking out for potential vulnerabilities?

How about allowing for download of the executable?
June 11, 2018
On Sunday, 10 June 2018 at 19:54:20 UTC, Dechcaudron wrote:
> On Saturday, 9 June 2018 at 20:28:24 UTC, Anton Fediushin wrote:
>> Hello, I am glad to announce that new Telegram bot which can execute D code is up and running!
>>
>> Check it out here: https://t.me/dlangbot
>>
>> Features:
>>  - Two compilers to choose from: dmd (default) and ldc
>>  - Support for custom compiler arguments with `/args` command
>>  - It's possible to set program's stdin with `/stdin`
>>  - Code is automatically compiled and ran again when you edit your message
>>
>> Repository: https://gitlab.com/ohboi/dlangbot
>>
>> Any ideas on how to improve it are appreciated!
>
> As much as I love Telegram bots and D, compilation and execution offered by a bot provides no clear advantage to me (still, I kinda like it). I assume you are looking out for potential vulnerabilities?
>
> How about allowing for download of the executable?

This bot has the same purpose as run.dlang.io - a sandbox to try some things and share code with people. Even though sharing can be done with simple 'highlight your message with code and bot's reply -> share these messages' I am thinking about ways to make it simpler and faster.

Regarding vulnerabilities, if there are any I and authors/maintainers of dlang-tour will be interested in fixing them ASAP. After all, dlangbot uses tour's code under the hood.

Executable downloading would require me to rewrite the back-end. I am not sure if it'll worth it because it's not clear how safe that would be for a user and how usable that feature will be. I mean, if user already has x86-64 Linux machine (that's what dlangbot uses) then will it be any simpler and faster to message the bot with code, download an executable and run it than compiling it using installed compiler?



June 11, 2018
On Monday, 11 June 2018 at 05:50:56 UTC, Anton Fediushin wrote:
> Regarding vulnerabilities, if there are any I and authors/maintainers of dlang-tour will be interested in fixing them ASAP. After all, dlangbot uses tour's code under the hood.

Then I assume all trivial vulnerabilities are taken care of. I just thought you had implemented this from scratch to run on a computer of yours.

>
> Executable downloading would require me to rewrite the back-end. I am not sure if it'll worth it because it's not clear how safe that would be for a user and how usable that feature will be. I mean, if user already has x86-64 Linux machine (that's what dlangbot uses) then will it be any simpler and faster to message the bot with code, download an executable and run it than compiling it using installed compiler?

Here you are assuming the user has a compiler installed on his machine. It may not be the case in some environments or for some people that are just toying around with the language.
June 11, 2018
On Monday, 11 June 2018 at 12:32:32 UTC, Dechcaudron wrote:
> On Monday, 11 June 2018 at 05:50:56 UTC, Anton Fediushin wrote:
>> Regarding vulnerabilities, if there are any I and authors/maintainers of dlang-tour will be interested in fixing them ASAP. After all, dlangbot uses tour's code under the hood.
>
> Then I assume all trivial vulnerabilities are taken care of. I just thought you had implemented this from scratch to run on a computer of yours.

I'd like to believe it though I know there must be a bug somewhere. There always is.

Dlangbot runs on AWS. I use docker-compose to isolate all of the related services (bot, database and the one which executes the code).

>
>>
>> Executable downloading would require me to rewrite the back-end. I am not sure if it'll worth it because it's not clear how safe that would be for a user and how usable that feature will be. I mean, if user already has x86-64 Linux machine (that's what dlangbot uses) then will it be any simpler and faster to message the bot with code, download an executable and run it than compiling it using installed compiler?
>
> Here you are assuming the user has a compiler installed on his machine. It may not be the case in some environments or for some people that are just toying around with the language.

I think my assumption is right, because newbies are more likely to start with D either reading books or dlang-tour which provides means to compile and execute examples and edit them as one wants.

Even dub, official package manager and build tool for D promotes using `dub run package` instead of building the project and running an executable manually. This approach does make sense because it prevents some silly mistakes people make.

I'll open an issue about your idea, but I can't see it being very useful so it's very unlikely to be implemented at all. Who knows though, it might be very easy to do if I decide to change the architecture of the whole project.