[Poll] What programming language would you like CodinGame to support next?


#62

It’s an official answer.


#63

Hello @andre2007

I’m sorry to disappoint you but, as I wrote earlier, there is just no simple way of doing what you propose. Our current system isn’t compatible with Docker and won’t be without huge development efforts. Currently, there is just no way for us to dedicate time on this.

However, I still intend on pushing things internally for the support of a new language (could be D) before the end of the year.

I appreciate the enthusiasm and I’ll try to work on a blog article explaining how CodinGame works.


#64

Hello @_CG_Thibaud,
Thanks for working on this topic. Yes, maybe D is added this year, but also it could be D is not added this year or the next years at all
I think I found a completely other solution, which will cost CG only a half hour to implement and makes D available:
From @eulerscheZahl I got the info that there is a C++ hack which enables loading arbitrary executables as long as they are small (https://github.com/Agade09/CG-Send-Binary). I tried it and failed as the D executable is too big. A D executable consists of 3 parts: DRuntime, the standard library Phobos and the actual user code.

Instead of compiling the DRuntime and Phobos into the executable, it is possible to just link (shared objects) agsinst them. This will reduce a 800kb application to 15kb.

What I ask you: is it possible to add the 2 shared objects DRuntime and Phobos to the environment you use for C++? Technically it is nothing more than just copying these 2 files to /usr/lib.

Could you ask your technical engineers about this solution? Even this is the most cumbersome way of using CG for D users, it is a way to use a sane, fantastic programming language. Every line you write with D is fun, if we now even could add CG to that, it will be unbelievable great!


#65

No entreprise ever will just add a “simple hack” to cover a new feature for just few users. The feature is done in a complete state for everyone or not at all.


#66

@Magus The request is not about the hack. The hack is already there and is working fine as long as you have a rather small executable (100_000 lines limit).
I asked for another thing: Including 2 shared objects from the D language (https://github.com/ldc-developers/ldc/releases/download/v1.16.0/ldc2-1.16.0-linux-x86_64.tar.xz). CG could either copy 2 shared objects into the /usr/lib folder or if they want they can just install from the Gnu Compiler Collection gdc-9 to have the libraries.


#67

2 andre2007:
u didn’t tell which 2 shared objects from TAR file should be copied

2 all:
andre2007 means that coping some dll/so to /usr/lib will allow run D(or any?)-compiled app in CG with some hack that converts EXE to C-source as base85 and run it.
D-compiled app with static linking is too big so when compile it for using shared Runtime it become smaller enough for running in CG but for such cases system should contains shared SO-s with D-runtime.


#68

@zelyony i wanted to wait until until CG responds whether they accept the approach in general or not, before going into details.

In lib folder there are these 2 shared objects:
libdruntime-ldc-shared.so.2.0.86
libphobos2-ldc-shared.so.2.0.86

Both of them have also file links (extension .so and extension so.86) which points to them. I am not a linux expert and can’t say which file extension is actually the correct one CG linux environment. (I tested it on my raspberry pi)

If you want to test it, this command will compile the executable with dynamic linking:

ldc2 app.d -link-defaultlib-shared

import std.stdio: writeln;

void main(string[] args)
{
    writeln(`Hello World`);
}

#69

adding 1 language to the infrastructure in 1 year is something weird.

yes, u have many other tasks, and for such task u should learn new language, and u have boss that think that is good right now and don’t need something change.

well, my point that adding possibility to connect CG to client machine over TCP-socket for sending string data and receiver string answer will solve problem for any programming language.
I talk now only for PRACTICE tasks - CG never shows sources to anyone public (no point share code to others) and CG don’t need sources from 1mln users for each problem at all (no? why?).
it will allow solve problems with any langs that user prefer and CG hasn’t yet and will allow receive CG points that is good for user profile and user feedback education (gamification learning langs process).

I can code some TCP-app for client in C#/Qt/Go/Kotlin/NodeJs(idk such many langs but I can learn it for task), that listen some port on client machine and redirect streams to some user selected application or script. In any case I need such app for myself and I can share app at github. Just needed some job from CG side - TCP-connector that send tests and receive answers and check it for success/failure including some timeouts like “connection is impossible for 10sec - failure”

UPD:
extension idea: TCP-tool (client side) can contains TextBox area for source and compilation command lines for compiling it - successing compile then listen socket, failure compile no listen socket. with possibility transfer source (then some protocol should be invented or some gRPC)
idea++: dunno maybe it can be Atom/VSCode plugin with intellisence and coloring


#70

One important point you forget, your approach would save CG a huge amount of money. My assumption is, the compilation server farm is the biggest cost factor for them. Laying out the compilation to the user would immediately reduce the costs.


#71

@_CG_Thibaud
Also please see this issue to make the used language and source visible to CG


#72

@andre2007
Once again, I appreciate the enthusiasm but we’re not going to support a language with that kind of work-around.