Re: Looking for D developers, Saint-Petersburg

2016-05-10 Thread Temtaime via Digitalmars-d-announce 

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

2016-05-10 Thread Jesse Phillips via Digitalmars-d-announce 
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

2016-05-10 Thread Jack Applegame via Digitalmars-d-announce 

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

2016-05-10 Thread Vladimir Panteleev via Digitalmars-d-announce 

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

2016-05-10 Thread drug via Digitalmars-d-announce 
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

2016-05-10 Thread H. S. Teoh via Digitalmars-d-announce 
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

2016-05-10 Thread Stefan Koch via Digitalmars-d-announce 

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

2016-05-10 Thread Rory McGuire via Digitalmars-d-announce 
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?

Re: Battle-plan for CTFE

2016-05-10 Thread Nordlöw via Digitalmars-d-announce 
On Monday, 9 May 2016 at 18:20:46 UTC, Robert burner Schadek 
wrote:

awesome news :-) thanks you


I very much agree.

Re: Battle-plan for CTFE

2016-05-10 Thread Jacob Carlborg via Digitalmars-d-announce 

On 2016-05-09 18:57, Stefan Koch wrote:

Hi Guys,

I have been looking into the DMD now to see what I can do about CTFE.
Unfortunately It is a pretty big mess to untangle.
Code responsible for CTFE is in at least 3 files.
[dinterpret.d, ctfeexpr.d, constfold.d]
I was shocked to discover that the PowExpression actually depends on
phobos! (depending on the exact codePath it may or may not compile...)
which let to me prematurely stating that it worked at ctfe
[http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]

My Plan is as follows.

Add a new file for my ctfe-interpreter and update it gradually to take
more and more of the cases the code in the files mentioned above was
used for.

Do Dataflow analysis on the code that is to be ctfe'd so we can tell
beforehand if we need to store state in the ctfe stack or not.

Or baring proper data-flow analysis: RefCouting the variables on the
ctfe-stack could also be a solution.

I will post more details as soon as I dive deeper into the code.


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