Re: Looking for D developers, Saint-Petersburg
Контакт для связи drug2004(at)bk(dot)ru с темой "dlang, работа"
Re: Looking for D developers, Saint-Petersburg
On 10.05.2016 18:41, Jack Applegame wrote: On Tuesday, 10 May 2016 at 14:39:27 UTC, drug wrote: I'm curious are there D developers in Saint Petersburg who doesn't mind to make some money? Вопрос, зачем нужно высшее образование? Хорошего знания D/C++ недостаточно? И как часто нужно кататься в офис? Для работы однозначно достаточно знаний, для официального трудоустройства не совсем - бюрократия. Без высшего просто оплата будет меньше. Частота поездок, если честно мне не ведома, так как опыта пока такого нет, можно ориентироваться на раз в неделю/две. Но когда есть результат - все решаемо.
Re: Looking for D developers, Saint-Petersburg
On Tuesday, 10 May 2016 at 14:39:27 UTC, drug wrote: I'm curious are there D developers in Saint Petersburg who doesn't mind to make some money? Я использую D для внутренних инструментов в компании. Сейчас масштабы увеличиваются и нужен помощник. Есть согласие руководства на использование D и позиция разработчика с вилкой 40-60 т.р. на руки, трудоустройство в белую, полная/частичная занятость, гибкий график, возможна удаленка, но с ней могут быть нюансы. Требование высшее техническое (для студентов можно и неоконченное, но в первую очередь нужен помощник, а не ученик), на удаленке все равно нужна будет возможность приезжать в офис. Помимо D нужно знание opengl 3+ (простая промышленная графика, не гейм-индустрия), способности/склонность к метапрограммированию (здесь D очень себя проявляет по сравнению с C++). Знание теории вероятности и матстатистики будет плюсом. Работать c C++ тоже нужно будет. Если кто подскажет как и где найти людей, буду признателен. Готов откликнуться, куда можно написать, чтобы узнать подробности?
Codebuilder with line info insertion
One of the things that can be really annoying about using string
mixin's, especially when there is a lot of code, is that the
compile complains about syntax errors on a line within the mixin
that doesn't exist in the code.
While at the D Conference this issue was mention along with the
file/line feature of function calls. It got me thinking about a
code builder I had been using in ProtocolBuffer[1]. I just
checked and found that the use of the #line language feature
combined with the file/line feature allowed for providing better
information about where a mixin went wrong. So I pulled out the
code and packaged it for dub[2].
Documentation is lacking in examples, but is used with
ProtocolBuffer[3]. It uses a put/push/pop approach to provide
some freedom in organizing the code; but I'll admit doesn't help
readability (the call to finalize will pop all code elements push
to the stack).
This package doesn't do too much to help with building code, one
of the main parts it provides is pretty printing (indenting)
which isn't important for a mixin. So please feel free to send of
suggestions from experience trying to use it, I won't consider
the API stable at this point.
Since ProtocolBuffer support D1 and D2, so does this library.
Instead of -- test.d-mixin-4(4): Error: semicolon expected, not
'}'
I get -- test.d(11): Error: semicolon expected, not '}'
-
import codebuilder.structure;
void main() {
mixin(genCode); // Line 4
}
auto genCode() {
auto cb = CodeBuilder(1);
cb.put("struct m {");
cb.push("}"); // Line 11
cb.put("int a"); // Missing semicolon
return cb.finalize;
}
-
1. https://github.com/JesseKPhillips/ProtocolBuffer/
2. http://code.dlang.org/packages/codebuilder
3.
https://github.com/JesseKPhillips/ProtocolBuffer/blob/master/conversion/dlang.d
Re: Looking for D developers, Saint-Petersburg
On Tuesday, 10 May 2016 at 14:39:27 UTC, drug wrote: I'm curious are there D developers in Saint Petersburg who doesn't mind to make some money? Вопрос, зачем нужно высшее образование? Хорошего знания D/C++ недостаточно? И как часто нужно кататься в офис?
Re: Looking for D developers, Saint-Petersburg
On Tuesday, 10 May 2016 at 14:39:27 UTC, drug wrote: I'm curious are there D developers in Saint Petersburg who doesn't mind to make some money? Здравствуй Друг, If the position is likely to remain open for at least some time, I recommend adding this to the job listing page on our wiki: https://wiki.dlang.org/Jobs
Looking for D developers, Saint-Petersburg
I'm curious are there D developers in Saint Petersburg who doesn't mind to make some money? Я использую D для внутренних инструментов в компании. Сейчас масштабы увеличиваются и нужен помощник. Есть согласие руководства на использование D и позиция разработчика с вилкой 40-60 т.р. на руки, трудоустройство в белую, полная/частичная занятость, гибкий график, возможна удаленка, но с ней могут быть нюансы. Требование высшее техническое (для студентов можно и неоконченное, но в первую очередь нужен помощник, а не ученик), на удаленке все равно нужна будет возможность приезжать в офис. Помимо D нужно знание opengl 3+ (простая промышленная графика, не гейм-индустрия), способности/склонность к метапрограммированию (здесь D очень себя проявляет по сравнению с C++). Знание теории вероятности и матстатистики будет плюсом. Работать c C++ тоже нужно будет. Если кто подскажет как и где найти людей, буду признателен.
Re: Battle-plan for CTFE
On Mon, May 09, 2016 at 05:36:21PM -0700, Walter Bright via Digitalmars-d-announce wrote: > On 5/9/2016 2:32 PM, Andrej Mitrovic via Digitalmars-d-announce wrote: > >On 5/9/16, Stefan Koch via Digitalmars-d-announce > > wrote: > >>I was shocked to discover that the PowExpression actually depends on > >>phobos! > > > >I seem to remember having to implement diagnostics in DMD asking for > >the user to import std.math. I'm fairly confident it had something to > >do with power expressions. > > > >Yah, it's a mess. :) > > > > The pow stuff should just be done in dmd without reference to the > library. +1. It makes little sense for a language built-in operator to require std.math, when the whole point behind the druntime/phobos split is to make it possible for implementations *not* to implement Phobos. T -- Some days you win; most days you lose.
Re: Battle-plan for CTFE
On Tuesday, 10 May 2016 at 07:44:54 UTC, Rory McGuire wrote: On Tue, May 10, 2016 at 8:45 AM, Jacob Carlborg via Digitalmars-d-announce wrote: I was listening to a discussion Don and Daniel had about the current implementation of CTFE. They talked about using a byte code interpreter. Even implementing a really crappy byte code interpreter would be a huge improvement. -- /Jacob Carlborg Does anyone know whether it would be worth while keeping the LLVM JIT in mind when writing this new CTFE engine? Yes I do know the llvm jit, it is slow as a three legged dog. But I do plan for a way of plugging it in. This is not a main priority however.
Re: Battle-plan for CTFE
On Tue, May 10, 2016 at 8:45 AM, Jacob Carlborg via Digitalmars-d-announce wrote: > > I was listening to a discussion Don and Daniel had about the current > implementation of CTFE. They talked about using a byte code interpreter. > Even implementing a really crappy byte code interpreter would be a huge > improvement. > > -- > /Jacob Carlborg Does anyone know whether it would be worth while keeping the LLVM JIT in mind when writing this new CTFE engine?
