Re: ArrayFire, a GPU library, is now open source

2015-05-13 Thread Pavan Yalamanchili via Digitalmars-d-announce

On Wednesday, 17 December 2014 at 12:58:23 UTC, ponce wrote:
Hi, I'm kind of embarrassed by my bitter post, must have been a 
bad day :).


On Tuesday, 16 December 2014 at 19:49:37 UTC, Shehzan wrote:
We also support CPU and OpenCL backends along with CUDA. This 
way, you can use the same ArrayFire code to run across any of 
those technologies without changes. All you need to do is link 
the correct library.


Cool, this was reason enough to avoid using NPP until now.

I've certainly found desirable to be able to target OpenCL, CPU 
or CUDA indifferently from the same codebase. What I'd like 
more than a library of functions though is an abstracted 
compute API. This would be a compiler from your own compute 
language to OpenCL C or CUDA C++ also an API wrapper. That 
would probably mean to leave some features behind to have the 
intersection. Similar to bgfx but for compute APIs, which has a 
shader compiler to many targets.


We used a BSD 3-Clause license to make it easy for everyone to 
use in their own projects.


Here is a blog I made about implementing Conway's Game of Life 
using ArrayFire 
http://arrayfire.com/conways-game-of-life-using-arrayfire/. It 
demonstrates how easy it is to use ArrayFire.


Our goal is to make it easy for people to get started with GPU 
programming and break down the barrier for non-programmers to 
use the hardware efficiently. I agree that complex algorithms 
require more custom solutions, but once you get started, 
things become much easier.


Your example is indeed very simple, so I guess it has its uses.


I know this is a really old post, but just to add to what Shehzan 
already mentioned, we have double precision support (both real 
and complex) since day one (and quite a long time before that as 
well). Our documentation does not make it obvious immediately 
because we just have a single array class. The array class holds 
the metadata of the data types and we eventually launch the 
appropriate kernels.


ArrayFire can also integrate with existing CUDA or OpenCL code. 
The goal of libraries (be it Thrust or Bolt or ArrayFire) is to 
not take back control, but to make sure users are not 
re-inventing the wheel over and over again. Having access to 
highly optimized, pre-existing GPU kernels for commonly used 
algorithms can only increase productivity.


Re: DlangIDE

2015-05-13 Thread Vadim Lopatin via Digitalmars-d-announce

On Tuesday, 12 May 2015 at 21:03:05 UTC, JohnnyK wrote:

On Friday, 6 February 2015 at 14:03:07 UTC, Vadim Lopatin wrote:

Hello,

I'm working on cross-platform D language IDE - DlangIDE.
It's written in D using DlangUI based GUI.

Project on GitHub: https://github.com/buggins/dlangide

It's in alpha stage but already allows:

* Open DUB based projects
* Edit source files
* Build and run projects using DUB
* D source code syntax highlight

Requires DUB for building projects.

Features missing so far:

* Debugging support
* Code completion
* Code folding
* Go to definition
* Smart indentation

Best regards,
  Vadim


Is DUB required to install and use the IDE?


DUB is required to build IDE, and to build and run projects using
IDE.


Re: Calypso: Direct and full interfacing to C++

2015-05-13 Thread Abdulhaq via Digitalmars-d-announce

On Tuesday, 12 May 2015 at 21:44:04 UTC, Kelly wrote:
Well the first fully working example of a large library is 
finally working with Calypso. Elie has managed to get a Qt5 
demo program to compile and run!!


The demo is a D version of the Qt5 Widgets demo. This is a 
simple window with a pseudo address book app. The demo uses a D 
class inheriting from QWidget, calls 'super(parent)' from D 
code and uses the QStrings, QLabel, QLineEdit, QLayout, 
QGridLayout classes, among other things. You can see the code 
here: 
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d


The demo is confirmed to work with Qt5.4 and Qt5.2.1.



This really is a huge leap, congratulations!


Re: Calypso: Direct and full interfacing to C++

2015-05-13 Thread John Colvin via Digitalmars-d-announce

On Tuesday, 12 May 2015 at 21:44:04 UTC, Kelly wrote:
Well the first fully working example of a large library is 
finally working with Calypso. Elie has managed to get a Qt5 
demo program to compile and run!!


The demo is a D version of the Qt5 Widgets demo. This is a 
simple window with a pseudo address book app. The demo uses a D 
class inheriting from QWidget, calls 'super(parent)' from D 
code and uses the QStrings, QLabel, QLineEdit, QLayout, 
QGridLayout classes, among other things. You can see the code 
here: 
https://github.com/Syniurge/Calypso/blob/master/tests/calypso/qt5/qt5demo.d


The demo is confirmed to work with Qt5.4 and Qt5.2.1.

While this might not seem like a really big deal, please keep 
in mind that while compiling this demo, Calypso effectively 
parses and produces 692 object files, including large swathes 
of the C++ STL and most of the Qt library!


The latest push last night also cut down on compile times quite 
a lot. Doing the initial compile of the example takes about 28 
seconds on my mid-level Intel i5 machine, versus around 2 
seconds for just the C++ version. After generating a cache file 
with last nights commits you can recompile the project in just 
7.5 seconds...which I think is quite good for just getting 
things up and running :)


Thanks,
Kelly


That's great! I'm looking forward to being able to easily make 
direct use of some of the great C++ code out there.


Are there are performance pitfalls to watch out for that are 
unique to the way calypso interfaces between D and C++? E.g. 
sneaky copies, implicit callbacks to keep things synced etc.


dfmt 0.3.5

2015-05-13 Thread Brian Schott via Digitalmars-d-announce

https://github.com/Hackerpilot/dfmt/releases/tag/v0.3.5

Just bug fixes, nothing exciting.