September 21, 2018
On 9/21/2018 9:29 AM, welkam wrote:
> Jai compiler perform parsing and lexing in different thread so its kinda multi threaded. Its possible to do the same with D front end. We can start here but there are plenty of low hanging fruits in compiler you just need to run profiler to find them

D was designed to support mulithreaded compilation, but that was never implemented.

An earlier DMD would do file I/O and compiling in separate threads. It was sadly removed.
September 21, 2018
On 9/21/2018 7:46 AM, Steven Schveighoffer wrote:
> I can see the marketing now, "D finds infinite loops in compile-time code way faster than Jai!".

We need you over in marketing!
September 21, 2018
On Friday, 21 September 2018 at 18:20:21 UTC, Adam D. Ruppe wrote:
> You don't need an API call to do that. You just provide the icon in a resource to the linker or a separate resource thing. Some C++ environments do it via pragmas, or you can do it traditionally in a makefile/build command line pretty easily; no need to run fancy code.

Jonathan created a built-in function to display an icon to work cross-platform without the trouble configuring for each different platform or IDE.

SG.
September 23, 2018
On Friday, 21 September 2018 at 06:34:47 UTC, Vladimir Panteleev wrote:
> On Friday, 21 September 2018 at 06:30:40 UTC, Walter Bright wrote:
>> On 9/20/2018 10:11 PM, mate wrote:
>>> Note that the build can be done at compile time because the metaprogramming capabilities of the language are not limited in terms of system calls.
>>
>> Back in the naive olden days, Microsoft released ActiveX, where a web page could load executable objects (!) from the internet and run them in the browser.
>>
>> It quickly became apparent that this was a disaster, as lots of people on the internet aren't to be trusted.
>>
>> CTFE on D doesn't allow making any system calls. This is on purpose.
>
> The usual argument against this is that source code distributions already usually include some sort of build or installation script (be it in the form of "configure", or a makefile, or a Visual Studio project), which can already execute arbitrary commands.
>
> The problem with putting it in the compiler is that it invalidates many contracts (and, thus, use cases) about what invoking the compiler can do. This means you can't bisect or reduce (as with Dustmite) the source code reliably. Reproducible builds are out too, as the produced object file is no longer purely a function of the source code and compiler version.

The counter argument is that the compiler is generally not a vector for a computer virus. If I notice I have malware on my computer, I'll think of the websites and the installer scripts I've run recently. I would never expect that some arbitrary code I included in a project would have created a virus and installed it while the compiler built. Sounds like a potential disaster to me.

I frequently copy and paste code I don't yet understand all of the time in hopes of understanding it by running it through a compiler. I will personally not ever use Jai.
September 23, 2018
On Sunday, 23 September 2018 at 21:15:17 UTC, FromAnotherPlanet wrote:
> On Friday, 21 September 2018 at 06:34:47 UTC, Vladimir Panteleev wrote:
>> On Friday, 21 September 2018 at 06:30:40 UTC, Walter Bright wrote:
>>> On 9/20/2018 10:11 PM, mate wrote:
>>>> Note that the build can be done at compile time because the metaprogramming capabilities of the language are not limited in terms of system calls.
>>>
>>> Back in the naive olden days, Microsoft released ActiveX, where a web page could load executable objects (!) from the internet and run them in the browser.
>>>
>>> It quickly became apparent that this was a disaster, as lots of people on the internet aren't to be trusted.
>>>
>>> CTFE on D doesn't allow making any system calls. This is on purpose.
>>
>> The usual argument against this is that source code distributions already usually include some sort of build or installation script (be it in the form of "configure", or a makefile, or a Visual Studio project), which can already execute arbitrary commands.
>>
>> The problem with putting it in the compiler is that it invalidates many contracts (and, thus, use cases) about what invoking the compiler can do. This means you can't bisect or reduce (as with Dustmite) the source code reliably. Reproducible builds are out too, as the produced object file is no longer purely a function of the source code and compiler version.
>
> The counter argument is that the compiler is generally not a vector for a computer virus. If I notice I have malware on my computer, I'll think of the websites and the installer scripts I've run recently. I would never expect that some arbitrary code I included in a project would have created a virus and installed it while the compiler built. Sounds like a potential disaster to me.
>
> I frequently copy and paste code I don't yet understand all of the time in hopes of understanding it by running it through a compiler. I will personally not ever use Jai.

Just to add to this previous comment...just imagine my worries but having to worry about an entire corporation worth of developers potentially doing something stupid and spreading it to everyone else via source control and the Jai compiler...
1 2 3 4
Next ›   Last »