On Monday, 12 August 2013 at 19:28:41 UTC, michaelc37 wrote:
> On Monday, 12 August 2013 at 15:47:02 UTC, Russel Winder wrote:
>> On Wed, 2013-07-31 at 14:59 +0200, michaelc37 wrote:
>>
>> I have cloned you qtd-experimental to try a build with ldc2. However it
>> seems cmake/FindD.cmake needs amending to cope with ldc2 in a user
>> defined place :-(
>
> I haven't tried ldc2/gdc yet, I'll have a look a bit later.

patched the make file for ldc2, but ran into a problem during compile with Atomic.d.

I think the llvm_memory_barrier function no longer exists. I found and tried to apply fixes from a patch made to tango's Atomic.d
http://www.dsource.org/projects/tango/attachment/ticket/2101/llvm3.atomic.patch), ended up with a compile error that made no sense to me "Error: Integer constant expression expected instead of ordering"

AtomicOrdering ordering = getOrdering(ms == msync.rel ? msync.seq : ms);
...
...
llvm_atomic_store!(T)(cast(T)newval, cast(shared T*)&val, ordering);

On Monday, 12 August 2013 at 19:08:14 UTC, David Nadlinger wrote:
> On Monday, 12 August 2013 at 15:28:34 UTC, Russel Winder wrote:
>> https://code.google.com/p/qtd/ (which has a Subversion repository)
>> clearly points to http://www.dsource.org/projects/qtd – which I guess has a checkoutable (Subversion) repository.
>
> It's a Mercurial repository. QtD moved to BitBucket because of DSource stability problems impairing development. I suggested Eldar to nuke the DSource one to avoid confusion – i.e. either disable it, or replace it with a singe "repo has moved" text file in the root directory, or something like that –, but somehow this never happened (I don't recall whether there was actually disagreement about this or if we just never got around to do the change).
>
>>But then there is https://bitbucket.org/qtd/repo
>
> As far as I am aware, this is the "current" repository, i.e. the last that Eldar, Max, Alexey and I actually committed to. However, I don't think any of us are actually working on QtD right now, and even simple patches/pull requests take inexcusably long to merge.
>
>> and https://github.com/qtd-developers/qtd
>
> This seems to be an attempt to revive QtD, possibly by Michael Crompton, who contributed a few patches on BitBucket before. The URL is unnecessarily long, though – I just reserve github.com/qtd, if somebody wants admin rights for the organization, just drop me a line.

That was actually me. I started working on it, and I got a few patches in when I got really busy with work. Unfortunately, that was just about the same time I started understanding the build system...

It is unfortunately long, but I borrowed the naming scheme from ldc... Also, if anyone wants admin rights, drop me a line. I probably shouldn't be in charge of it since I only really have a passing interest (I just wanted to fix the PKGBUILD for Arch Linux..., also, if someone else can actually fix it, let me know).

>> Before any activity gets going on QtD might it be an idea to decide with
>> which VCS and support tools?
>
> Yep. I can't speak for Eldar and Max, who are really the ones who "own" QtD (I only contributed a few smaller fixes), but I'd say, if somebody wants to genuinely pick up QtD development, they should go ahead and choose whatever they feel most comfortable with. Git/GitHub certainly would be a good fit for the D ecosystem.
>
>> Perhaps more should be done on http://www.dsource.org/projects/qtd to
>> make it clear where action is to happen?
>
> I just tried to; the person behind the GitHub repository (Michael?) is welcome to amend that page. Note that the actual installation guides linked from that page all referred to the proper repository before as well.
>
> David

I unfortunately don't have a dsource account, and I'm not sure how to get one.

Please, let me know how I can help out. I'm 100% ok with handing over the qtd-developers org (if that's what we want to use).

On Tue, 2013-08-13 at 05:11 +0200, michaelc37 wrote:
[…]
> patched the make file for ldc2, but ran into a problem during compile with Atomic.d.

Your changes are better than mine so I ditched mine.

> I think the llvm_memory_barrier function no longer exists. I
> found and tried to apply fixes from a patch made to tango's
> Atomic.d
> http://www.dsource.org/projects/tango/attachment/ticket/2101/llvm3.atomic.patch),
> ended up with a compile error that made no sense to me "Error:
> Integer constant expression expected instead of ordering"
> 
> AtomicOrdering ordering = getOrdering(ms == msync.rel ? msync.seq
> : ms);
> ...
> ...
> llvm_atomic_store!(T)(cast(T)newval, cast(shared T*)&val,
> ordering);

I don't think I got that far as I got a "Can't find the D compiler problem. It seems the build rebuilds the build in some way but fails. :-((


Classes in typesystem: 538
Generated:
  - d.........: 529 (529)
  - cpp-impl..: 506 (506)
  - cpp-h.....: 399 (399)
  - meta-info.: 28 (28)
  - pri.......: 7 (7)

Done, 344 warnings (577 known issues)
[100%] Built target dgen
Scanning dependencies of target main
-- The CXX compiler identification is GNU 4.8.1
-- The C compiler identification is GNU 4.8.1
-- Check for working CXX compiler: /home/users/russel/bin.Linux.x86_64/c++
-- Check for working CXX compiler: /home/users/russel/bin.Linux.x86_64/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /home/users/russel/bin.Linux.x86_64/gcc
-- Check for working C compiler: /home/users/russel/bin.Linux.x86_64/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
CMake Error at cmake/FindD.cmake:41 (message):
  D compiler is not found
Call Stack (most recent call first):
  CMakeLists.txt:180 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!
make[2]: *** [main] Error 1
make[1]: *** [CMakeFiles/main.dir/all] Error 2
make: *** [all] Error 2


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Am 01.08.2013 16:36, schrieb michaelc37:
>
> I compiled against Qt4, I want to try it on Qt5 soon but there is
> another annoying issue I discovered when trying to update and compile
> all of the qtd exmples: All slot functions must now be declared public..
> I'm guessing something changed in traits recently.
>

Yes since dmd 2.061 typeof no longer works on members you don't have access to. But it is possible to bypass this using the tupleof property. See typeOfFieldImpl in

https://github.com/Ingrater/druntime/blob/master/src/core/traits.d

Kind Regards
Benjamin Thaut

On Tuesday, 13 August 2013 at 11:03:33 UTC, Russel Winder wrote:
> I don't think I got that far as I got a "Can't find the D compiler
> problem. It seems the build rebuilds the build in some way but
> fails. :-((

The cmake/FindD.cmake script searched for 'ldc' only, not 'ldc2'.

Am on the way home right now, but I just pushed a commit (yay for git-hg) that should fix that issue (but only that issue).

David

On Wednesday, 14 August 2013 at 15:16:27 UTC, David Nadlinger wrote:
> On Tuesday, 13 August 2013 at 11:03:33 UTC, Russel Winder wrote:
>> I don't think I got that far as I got a "Can't find the D compiler
>> problem. It seems the build rebuilds the build in some way but
>> fails. :-((
>
> The cmake/FindD.cmake script searched for 'ldc' only, not 'ldc2'.
>
> Am on the way home right now, but I just pushed a commit (yay for git-hg) that should fix that issue (but only that issue).
>
> David

I'm not sure that enough, the output of the "ldc2 --version" compiler seems to have changed. Also i found that in CMakeLists.txt ldc2 needs "D_FLAGS -d-version=QtdCppShared" for the D_IS_LLVM condition.

Here is what i did.
https://bitbucket.org/michaelc37/qtd-experimental/commits/bfd137549ab266cc0c2131be18d8ad955e78a501

I managed to get it to compile with ldc2, after hacking up a fix for Atomic.d , i did commit that change as i am not familiar with llvm at all..  But if anyone wants to try it, it is attached to https://bitbucket.org/michaelc37/qtd-experimental/issue/1/cannot-compile-with-ldc2

I'd love to see good working Qt bindings in D. I have considered resurrecting the QtD project before, but I've been far too busy and/or lazy to really do anything.

On Wednesday, 14 August 2013 at 07:20:14 UTC, Benjamin Thaut wrote:
> Am 01.08.2013 16:36, schrieb michaelc37:
>>
>> I compiled against Qt4, I want to try it on Qt5 soon but there is
>> another annoying issue I discovered when trying to update and compile
>> all of the qtd exmples: All slot functions must now be declared public..
>> I'm guessing something changed in traits recently.
>>
>
> Yes since dmd 2.061 typeof no longer works on members you don't have access to. But it is possible to bypass this using the tupleof property. See typeOfFieldImpl in
>
> https://github.com/Ingrater/druntime/blob/master/src/core/traits.d
>
> Kind Regards
> Benjamin Thaut

Thanks, i just tried this but it didnt work as i expected or maybe i misunderstood.


e.g.

class Test
{
	private void aa(){};
	private int bb;
	public void cc(){};
}

writeln(Test.tupleof.length);  //prints 1
writeln(Test.tupleof[0].stringof);  //prints (Test).bb

it didnt see aa(), or cc()