Re: DVM - D Version Manager 0.3.0 (including support for Windows)
No I think I've only tested the beta.
Re: DTagLib - D Wrapper Library for the TagLib ID-tagging library
On 7/19/11, Johannes Pfau s...@example.com wrote: I can confirm that it works on linux without any changes :-) Talk about cross-platform compatibility in D without even thinking about it! Well, TagLib authors deserve all the credit. :) Oh and dmd on linux doesn't need import libs. Wait, you're telling me someone actually gave a thought or two when designing Linux shared libraries? I'll need to have a chat with Mr. Gates. :p
Re: DVM - D Version Manager 0.3.0 (including support for Windows)
On 7/19/2011 5:52 AM, Andrej Mitrovic wrote: No I think I've only tested the beta. Yeah, the beta didn't complain either, only this new version. Also, it won't trigger UAC (because we're not asking to elevate), it just fails to open.
Re: DPortAudio
14.7.2011 22.34, Andrej Mitrovic kirjoitti: There are already two bindings that exist for PortAudio. One is at http://www.dsource.org/projects/bindings/wiki/Portaudio, and the other is Derelict which has its own binding as well. However the dsource bindings have missing symbols, and the 1-byte alignment of struct members crashes the tests which I've ported to D. When using default 4-byte alignment the tests will run without issues (the PortAudio documentation recommends 4-byte alignment, so I don't know why 1-byte alignment was used). I made the bindings on dsource... I don't know about the alignment stuff. The decision to use 1-byte alignment was made with trial and error. I think it was propably the only way the whole thing worked on Linux at the time. (A couple of years ago.) It still works fine on Linux and Mac OS X with the 1-byte alignment. I should propably test 4-byte alignment again. (If I get the time...) I'm using GDC as the compiler. There were some performance issues with the D versions. It was much easier for the D versions to drop audio, than the corresponding C versions, but that might have been due to the alignment or other issues... I remember there were some issues with threads, GC and crashes. But it eventually worked. By trial and error, which isn't such a good way to write software. For the above reasons (and because I've worked on PortMidi as well), I've started my own bindings to PortAudio. Currently it's only built on Win32 platforms, but I'll see about getting it to work on Linux as well. Project link: https://github.com/AndrejMitrovic/DPortAudio It has about 15 ported tests, with a few dozen more to do. Great stuff. I hope you get it to work on Linux as well, as I don't want to start messing with it until somebody else has gotten it working. You are obviously doing a much better job at making the bindings complete with good examples. That is great! More samples will be coming by, including how to use PortAudio with PortMidi to make some cool realtime manipulation of audio data and visuals via a MIDI interface. That would be nice. I've been meaning to test PortMidi to get some midi controls for my app (the Pihlaja video viewer thing). On a related note, I've also made bindings (barely working) for Jack. http://www.dsource.org/projects/bindings/browser/trunk/jack It might not be much interest for Windows users, and it's a bit more complex system, but I found it to perform a little better than PortAudio. (But that might be due to the alignment issues in my PortAudio bindings, as discussed above.) Oh, and Jack also works on Windows nowadays. I'm still using PortAudio for my app, as it was easier to bundle into my installer, but I might change to Jack (it also has midi support) if my app ever becomes more audio oriented. I can change between the two with a compile switch (hurray, how wonderful). Jonas Kivi
Re: DPortAudio
On 7/20/11, Jonas Kivi seewebs...@foremail.fom wrote: That would be nice. I've been meaning to test PortMidi to get some midi controls for my app (the Pihlaja video viewer thing). There's bindings for that too (although only Windows was tested): https://github.com/AndrejMitrovic/DPortMidi You might be interested in this example: https://github.com/AndrejMitrovic/DPortMidi/blob/master/samples/win32_drawshapes.d It draws midi CC control changes as envelopes, it uses a plain C binding to Cairo to draw on a Win32 surface. Here's a screenshot: http://i.imgur.com/19vKa.png It's not my best code, I should be using a cyclic buffer to pass data from the Midi worker thread to the GUI drawing thread, but instead I've used some hackish array duplication. :)
Re: DPortAudio
On 7/20/11, Jonas Kivi seewebs...@foremail.fom wrote: Great stuff. I hope you get it to work on Linux as well, as I don't want to start messing with it until somebody else has gotten it working. Sure, I'll test it on Ubuntu sometime soon and see how it works there.
Re: DPortAudio
IOW is there a utility I can use on Linux to list .so exports?
Re: DPortAudio
Ok this does the trick: nm -D libportaudio.so It does list all of those functions though.
Re: DPortAudio
The C examples compile and run fine, so I must be doing something wrong on the D side.
Re: D Programming Language Specification ebook
On 7/17/2011 6:14 AM, Mike James wrote: I've had the ebook on my kindle for a while now and read it cover to cover. It's very readable in this form. The only problem I could see with it is that some of the tables are not rendered properly. For example the Basic Data Types table, the text is truncated by the grid. I tried different font sizes and orientations but it didn't make much difference. We'll try to improve the formatting. Anyway, its handy to have when your stuck on a airport with nothing to read :-) Reading specs for fun, I love it!
Re: Site updated to Phobos 2.054
On Mon, Jul 18, 2011 at 6:51 PM, Johann MacDonagh johann.macdonagh.no@ spam.gmail.com wrote: On 7/18/2011 9:46 PM, Johann MacDonagh wrote: On 7/18/2011 8:28 PM, Andrei Alexandrescu wrote: On 7/18/11 5:58 PM, Andrei Alexandrescu wrote: There was a misunderstanding between Walter and myself - he thought I needed the tag v2.054 on the d-programming-language.org repository, whereas I needed it in the phobos repository. The website www.d-p-l.org is NOW updated to the latest and greatest. There was a mixup of macros that caused some stuff to be wrongly generated (Walter updated win32.mak but not linux.mak). I regenerated the site now. Please let me know if this works better. Thanks, Andrei Nope, lex.html's Byte Order Marks table is still the same. Oops, scratch that. Hitting F5 pulled in the cached version. A Ctrl+F5 pulled in your new version. Looks good now. I'm guessing the page for etc.c.zlib isn't supposed to be blank?
Trouble with std.zlib
I'm using std.zlib in an application, and I'm having trouble decompressing a file. The file is gzipped, and I can easily see the contents with `cat file | gzip -d` but this code doesn't work: auto arr = read(file.gz); ubyte[] realarr = cast(ubyte[])uncompress(arr); output: std.zlib.ZlibException@std/zlib.d(59): data error From the header file, it seems like zlib should be detecting a gzip header and *just working*, but, well, it isn't. I have to store data in a compressed format, and eventually the code I'm writing will be used in-memory instead of on files, so I'm going to have to uncompress it somehow. Has anyone encountered this before? Thanks, Andrew
Re: Orbit - Package Manager - Specification/ideas
Jacob Carlborg wrote: On 2011-07-18 18:03, Johannes Pfau wrote: It would be possible to install libraries into the dmd default search path. Right now, this would be /usr/include/d/dmd and library files in /usr/lib on posix, but any path can be used as long as it's included in dmd.conf. However, this means that only one version of a library can be installed system-wide, so it's not optimal. It should also be noted, that linking against a specific library version can only work well with static libraries. With static libraries you can give linker a specific path to the library at compile time (So you can have multiple versions in different directories). Using different directories with dynamic libraries requires setting LD_LIBRARY_PATH before executing a program, so this won't work. We'll have to use the library versioning mechanism that's used by C libraries (e.g for linux: http://www.ibm.com/developerworks/linux/library/l-shlibs/index.html ). I don't know if windows even supports library versioning, but as windows programs usually don't install dlls globally that's less of a problem. You can give a specific path to the compiler with dynamic libraries as well. Link with libfoo, version 3.4.0: dmd -L-L/path/to/libfoo-3.4.0 -L-lfoo Or have I missed something? I'd have to test that, but I doubt it will work. This will help to find the library at compile time, but not at runtime. The runtime linker will only search in directories listed in /etc/ld.so.conf.d or in the LD_LIBRARY_PATH variable. Each .so library has a 'soname' embedded. If you link like in your example command the resulting binary only contains the sonames of the libraries it needs, not the full path. At runtime, the linker then reads that soname and searches in its cache for a library with the same soname. It might be possible to make this soname mechanism use absolute paths or subdirectories, but this seems like a hack. Sonames are usually just libfoo.so.3 where 3 is a ABI revision. I think we'll eventually have to install shared libraries exactly the way C does it, i.e all in /usr/lib and using the soname versioning. But we can think about that when dmd finally supports shared libraries on linux, it's not important right now. -- Johannes Pfau
Re: Orbit - Package Manager - Specification/ideas
On 2011-07-19 03:58, Nick Sabalausky wrote: What about orb/orblib, or orbit/liborbit, etc? Be easier to tell which is which that way anyway. Yeah, that would be one option. You can also see like this: Hey, I have a compiler, it's named 'GNU C Compiler', it's invoked with the 'gcc' command. What's the confusion with that? Ok, I see. That makes sense. Ok, good. Is it a good idea to take the name directory where the orbspec is located? No, I don't think it is. When orb downloads/installs a package it should definitely put it in a directory named the same as the package. But I often have reason to projects in a directory with a (slightly) different name from the project, so I don't think they should be expected to be the same names a packages the user is developing. So I'm fine with the orbspec filename being prepended with the package name...Only one minor potential issue I see: What happens if a single project has both foo.orbspec and bar.orbspec? When building the package? You just run orb build foo or or build bar. Were you hoping for only orb build? In that case I guess it would be possible if there's only one .orbspec in the current directory. That know if that's confusing. Sorry, can you be more specific on what you mean by that? The syntax you suggested. Instead of having ~ 0.3.4 then you could have ~ 0.3.4+ or ~ 0.3+.4+. True, so I guess there should be a way to do platform-specific packages. Don't know how much of an issue this is in reality. Although there could be fairly large libraries and applications. I know DWT is quite large. Suppose there's a (possibly default) repository: http://www.super-d-repos.com/joesmith/ And the user runs: $ orb install foo 1.2.3 What url does orb try to retreive?: http://www.super-d-repos.com/joesmith/foo-1.2.3.zip http://www.super-d-repos.com/joesmith/linux/foo-1.2.3.zip http://www.super-d-repos.com/joesmith/multiplatform/foo-1.2.3.zip I guess that just needs to be standardized. Etc... We'd need to have some well-designed standard for how that works. I'm not sure we should require the repo actually be specified as: http://www.super-d-repos.com/joesmith/linux/ Because that would be platform-dependent and require extra platform-handling code for the orbspec author. And it would be different for different repos. Come to think of it, the same issue applies to making the platform part of the package name. So maybe a good path-based system would be better. How would it require extra platform-handling for the orbspec author? All repositories behave in the same way, if not, it's not an orb repository. This makes me think of another question: Once different comression formats are allowed, if someone uses orb to download/install a package, how does orb know whether to grab a .zip, or a .bz2, or a .7z, etc? I guees it's same as with the platform. Just standardize on a specific order. i.e. 7z, then bz2 and last zip. If, for example, the author wants the windows package to be separate because it (hypothetically) has a lot of differences from posix, but the different posix versions are very similar so may as well be in the same package. That is for a source package? Good point. Although, of course, that only applies to binary packages. So yea, it seems that both multi-platform and platform-specific packages should be supported. And there needs to be some system for dealing with that. There is way more to think about than one actually want to recognize :) This is another thing I'm unclear on, the nature of installing. It almost sounds like you're saying that all the files in the package other than libraries and executables are just not used for anything and just thrown away. I doubt that's it though. If you but main.d and main.exe in the files field. And you have main.exe in the executables field it, will only install main.exe. There is no point in installing main.d as well, you actually don't need to put in the package in the first place. But there could be an option to install the source code as well, if present. Is this how you're envisioning it?: 1. User says orb install foo. 2. Orb downloads and extracts the foo package to a temp directory. 3. Orb invokes the build process to build foo (BTW, how is that how to build commandline string specified in the orbspec? The closest thing I see is the build field, but it looks like that's just the name of the tool used. An actual command line string is going to be needed.) 4. Orb copies the files listed in libraries and executables from the temp dir to their permanent location. 5. Temp dir is cleared. Something like that. If so, how do you account for non-compiled source-based libraries? Include the *.d files in libraries? That's a good question. Maybe the type field needs to include source. Hmm, I guess files isn't so bad. Oh, and Dake does this with the help of Orbit. It's acutally Orbit that generates the orbspec but Dake passes all
Re: Prototype buildsystem Drake
On 2011-07-19 04:51, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message Ok. Will the build script change the configuration file? Yes. Seems kind of strange. Usually the config file is used to control the build script, not the other way around. It's not really the other way around since the buildscript would still load the configuration file and use the settings in it (I guess I neglected to mention that part). It's just that creating it isn't done separately from the buildscript like with the clunky autotools. From a quick browse through the docs, Waf seems to have the buildscript direct the creation of the configuration file, too. I start to think that we mean different things when we say config file. What would you have in the config file? -- /Jacob Carlborg
Re: Orbit - Package Manager - Specification/ideas
On 2011-07-19 10:16, Johannes Pfau wrote: I'd have to test that, but I doubt it will work. This will help to find the library at compile time, but not at runtime. The runtime linker will only search in directories listed in /etc/ld.so.conf.d or in the LD_LIBRARY_PATH variable. Each .so library has a 'soname' embedded. If you link like in your example command the resulting binary only contains the sonames of the libraries it needs, not the full path. At runtime, the linker then reads that soname and searches in its cache for a library with the same soname. It might be possible to make this soname mechanism use absolute paths or subdirectories, but this seems like a hack. Sonames are usually just libfoo.so.3 where 3 is a ABI revision. I think we'll eventually have to install shared libraries exactly the way C does it, i.e all in /usr/lib and using the soname versioning. But we can think about that when dmd finally supports shared libraries on linux, it's not important right now. Oh, at runtime, didn't think of that :). The above command is only for compile time. What about the linker flag -rpath? That seems it could be used. Linux is not the only OS, it's easy to add support for dynamic libraries on Mac OS X. All code is already in druntime, it just needs to be enabled. Tango already supports this. -- /Jacob Carlborg
Re: ID3 library wrapper (taglib, id3lib, anything)
Andrej Mitrovic wrote: I've just built a wrapper library for TagLib. Not that this is still the Abstract API that's used. The full API is written in C++ and this would be very difficult to wrap in D. I'll make an announcement shortly. I've started a SWIG wrapper for TagLib some time ago, but more to learn how to use swig than for the TagLib library. Most classes are wrapped, but there are lots of warnings (not properly wrapped overloaded functions, etc). I won't work on it for some time, it's actually quite frustrating: You can do almost everything with the abstract API and the effort to create a complete wrapper is huge. But for some planned projects I'll need custom tags, which are not supported in the abstract API. Anyway for those interested in swig/d it could be useful: https://github.com/jpf91/TagLibD/tree/ -- Johannes Pfau
Re: Prototype buildsystem Drake
Jacob Carlborg d...@me.com wrote in message news:j03fe0$101m$1...@digitalmars.com... On 2011-07-19 04:51, Nick Sabalausky wrote: Jacob Carlborgd...@me.com wrote in message Ok. Will the build script change the configuration file? Yes. Seems kind of strange. Usually the config file is used to control the build script, not the other way around. It's not really the other way around since the buildscript would still load the configuration file and use the settings in it (I guess I neglected to mention that part). It's just that creating it isn't done separately from the buildscript like with the clunky autotools. From a quick browse through the docs, Waf seems to have the buildscript direct the creation of the configuration file, too. I start to think that we mean different things when we say config file. What would you have in the config file? Granted, I've never used this sort of feature from any buildsystem, but I thought we were talking about something like the configure command in Waf. My understanding is that it's like the ./configure from autotool's ./configure make make install, (except hopefully without needing to check quite so much stuff or needing the user to manually run the configure command). Apperently some projects need to have their buildsystem check for the existance of, locations of, and details about certain things on the local system before building. So...that stuff.
Re: ID3 library wrapper (taglib, id3lib, anything)
That might be a cool thing to look into if I ever get around to playing with SWIG. Thanks for putting it online.
Re: Prototype buildsystem Drake
On Tue, 2011-07-19 at 05:28 -0400, Nick Sabalausky wrote: [ . . . ] Granted, I've never used this sort of feature from any buildsystem, but I thought we were talking about something like the configure command in Waf. My understanding is that it's like the ./configure from autotool's ./configure make make install, (except hopefully without needing to check quite so much stuff or needing the user to manually run the configure command). Waf does indeed have a configure phase and a build phase. As long as the configuration remains unchanged after a waf configure and there hasn't been a waf distclean then you only ever need to build. SCons on the other hand runs all the configuration checks in the SConscript file on every run. I am never sure which I prefer, they both have positives and negatives. Apperently some projects need to have their buildsystem check for the existance of, locations of, and details about certain things on the local system before building. So...that stuff. I would have thought this would be all projects that are distributed as source? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
event based timer
Hi everyone, for getting to know d a little bit I'm writing a simple pingpong game using gtk. for it to work I need to be able to do something every 0.1 seconds so I was wondering if there was some kind of timer in the phobos library. I've looked everywhere but couldn't find one. Is it missing and do i have to write my own or have I overlooked it? maarten
Re: Orbit - Package Manager - Specification/ideas
Jacob Carlborg wrote:
On 2011-07-19 10:16, Johannes Pfau wrote:
I'd have to test that, but I doubt it will work. This will help to
find the library at compile time, but not at runtime. The runtime
linker will only search in directories listed in /etc/ld.so.conf.d
or in the LD_LIBRARY_PATH variable. Each .so library has a 'soname'
embedded. If you link like in your example command the resulting
binary only contains the sonames of the libraries it needs, not the
full path. At runtime, the linker then reads that soname and
searches in its cache for a library with the same soname. It might
be possible to make this soname mechanism use absolute paths or
subdirectories, but this seems like a hack. Sonames are usually just
libfoo.so.3 where 3 is a ABI revision. I think we'll eventually
have to install shared libraries exactly the way C does it, i.e all
in /usr/lib and using the soname versioning. But we can think about
that when dmd finally supports shared libraries on linux, it's not
important right now.
Oh, at runtime, didn't think of that :). The above command is only for
compile time. What about the linker flag -rpath? That seems it could
be used. Linux is not the only OS, it's easy to add support for
dynamic libraries on Mac OS X. All code is already in druntime, it
just needs to be enabled. Tango already supports this.
Seems like rpath could indeed work in this case. I can't find much
documentation about it though. Debian recommends not to use it:
http://wiki.debian.org/RpathIssue but I'm not sure if this problem
applies to orbit.
I'd prefer installing shared libraries system wide though. The
soname/version approach is not that bad. Your proposed package
versioning scheme could even be mapped 1:1 to the soname versions. Or
we could use libtools versioning scheme, which is similar, ('major' and
'minor' are one field, 'build' stays the same, and an additional 'age'
field is added)
http://sourceware.org/autobook/autobook/autobook_91.html
Having read more about it, i think I have to correct my previous
statement: It is possible to link to specific versions with the soname
approach. It's maybe a little more limited (You can't say: I want to
use libfoo.so.1.2.0, You can only say: I want to use libfoo 1.x.x,
and the linker could end up using 1.1.0, 1.2.0 ...) but it seems this
should be good enough.
--
Johannes Pfau
Re: Orbit - Package Manager - Specification/ideas
On 2011-07-19 12:33, Johannes Pfau wrote:
Seems like rpath could indeed work in this case. I can't find much
documentation about it though. Debian recommends not to use it:
http://wiki.debian.org/RpathIssue but I'm not sure if this problem
applies to orbit.
Won't the same problem occur if rpath isn't used? With LD_LIBRARY_PATH
for example.
I'd prefer installing shared libraries system wide though. The
soname/version approach is not that bad. Your proposed package
versioning scheme could even be mapped 1:1 to the soname versions. Or
we could use libtools versioning scheme, which is similar, ('major' and
'minor' are one field, 'build' stays the same, and an additional 'age'
field is added)
http://sourceware.org/autobook/autobook/autobook_91.html
I don't want to install the libraries system wide. Again your assuming
Linux only. It has to work on all supported platforms. At least: Linux,
Mac OS X and Windows.
Having read more about it, i think I have to correct my previous
statement: It is possible to link to specific versions with the soname
approach. It's maybe a little more limited (You can't say: I want to
use libfoo.so.1.2.0, You can only say: I want to use libfoo 1.x.x,
and the linker could end up using 1.1.0, 1.2.0 ...) but it seems this
should be good enough.
No, I want to be able to use an exact version.
--
/Jacob Carlborg
Re: Orbit - Package Manager - Specification/ideas
Jacob Carlborg wrote:
On 2011-07-19 12:33, Johannes Pfau wrote:
Seems like rpath could indeed work in this case. I can't find much
documentation about it though. Debian recommends not to use it:
http://wiki.debian.org/RpathIssue but I'm not sure if this problem
applies to orbit.
Won't the same problem occur if rpath isn't used? With LD_LIBRARY_PATH
for example.
I'm not sure about that, but using LD_LIBRARY_PATH is even more
discouraged (because it propagates to child processes)
I'd prefer installing shared libraries system wide though. The
soname/version approach is not that bad. Your proposed package
versioning scheme could even be mapped 1:1 to the soname versions. Or
we could use libtools versioning scheme, which is similar, ('major'
and 'minor' are one field, 'build' stays the same, and an additional
'age' field is added)
http://sourceware.org/autobook/autobook/autobook_91.html
I don't want to install the libraries system wide. Again your assuming
Linux only. It has to work on all supported platforms. At least:
Linux, Mac OS X and Windows.
I'm not sure if we can have one perfect approach for all operating
systems. But we could just use the rpath way and see how it works out.
Having read more about it, i think I have to correct my previous
statement: It is possible to link to specific versions with the
soname approach. It's maybe a little more limited (You can't say: I
want to use libfoo.so.1.2.0, You can only say: I want to use
libfoo 1.x.x, and the linker could end up using 1.1.0, 1.2.0 ...)
but it seems this should be good enough.
No, I want to be able to use an exact version.
I agree that's a nice-to-have feature, but is it ever really necessary?
This mechanism always picks up the newest ABI compatible library
version. Why would you want to specify one version explicitly if the
newer version can be used as a 1:1 replacement?
--
Johannes Pfau
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Jul 17, 2011, at 4:34 PM, Trass3r wrote: I have just come to know that there is an experimental branch in druntime with a concurrent GC: https://github.com/D-Programming-Language/druntime/tree/CDGC I really wonder why this wasn't announced here so people actually try it out, find bugs etc. Has anyone tried it yet? I made sure it was functional back when I added the branch. The runtime code is horribly out of date though. What needs to happen is for the branch to be re-created from main. I also need to see if Leandro has updated his CDGC since the branch was created.
Re: Has anyone ever tested CDGC (Concurrent D GC)?
I made sure it was functional back when I added the branch. The runtime code is horribly out of date though. What needs to happen is for the branch to be re-created from main. I also need to see if Leandro has updated his CDGC since the branch was created. What we really need is to put it into the master branch in its own directory and add some makefile magic so you can easily switch GCs when compiling druntime (just like Tango does) instead of having it rot in some branch that nobody even knows about. I'm already working on this and managed to compile CDGC with latest druntime. Now it needs extensive testing and bug fixing.
Re: Prototype buildsystem Drake
On 2011-07-19 11:28, Nick Sabalausky wrote: Granted, I've never used this sort of feature from any buildsystem, but I thought we were talking about something like the configure command in Waf. My understanding is that it's like the ./configure from autotool's ./configure make make install, (except hopefully without needing to check quite so much stuff or needing the user to manually run the configure command). I would hope D never had to use something like ./configure. It checks for C language features and similar (probably other things as well). I don't think that that belongs in a build system for D. Apperently some projects need to have their buildsystem check for the existance of, locations of, and details about certain things on the local system before building. So...that stuff. Isn't that to check what libraries, and so on, are present? That is the whole point of a package manager. A package specifies what dependencies it has, then the package manager makes sure the dependencies are met, or else it can't be installed. Don't know what locations it would check for. The package as no saying in where it should be installed, the package manger decides that. Oh, now I mixing package manager and build tool and assume the build tool will be used with the package manager. When I was talking about config file I was thinking something more like Rebuild's config files, example: http://pastebin.com/rYc47wXQ -- /Jacob Carlborg
Re: Expose underlying Mutex in Condition?
Steven Schveighoffer Wrote:
Hm... actually, we could do away with the mutex, and have the condition's
monitor be the mutex:
auto fooCondition = new Condition(); // automatically generates new mutex.
synchronized(fooCondition)
{
fooCondition.notifyAll();
// or
while(!someCondition)
fooCondition.wait();
}
We could keep the current behavior (accept a mutex), but still have the
mutex passed in be used as the monitor for the condition. Actually, can a
mutex be used as the monitor for more than one object? Because it's
possible multiple conditions can use the same mutex, so it's a legitimate
concern.
Sean? I think this is a really good idea...
Seems easy enough. Why not.
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Tue, 19 Jul 2011 21:53:01 +0900, Trass3r u...@known.com wrote: I made sure it was functional back when I added the branch. The runtime code is horribly out of date though. What needs to happen is for the branch to be re-created from main. I also need to see if Leandro has updated his CDGC since the branch was created. What we really need is to put it into the master branch in its own directory and add some makefile magic so you can easily switch GCs when compiling druntime (just like Tango does) instead of having it rot in some branch that nobody even knows about. I'm already working on this and managed to compile CDGC with latest druntime. Now it needs extensive testing and bug fixing. I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? Masahiro
Re: Orbit - Package Manager - Specification/ideas
On 2011-07-19 03:58, Nick Sabalausky wrote:
3. Orb invokes the build process to build foo (BTW, how is that how to
build commandline string specified in the orbspec? The closest thing I see
is the build field, but it looks like that's just the name of the tool
used. An actual command line string is going to be needed.)
Yes, it's the name of the build tool to invoke. By default it has
support for a couple of build tools and knows how to invoke them. Example:
To invoke Make it would just be make. To invoke DSSS it would be dsss
build.
In addition to that the build field accepts a variable argument list
with arguments to the build tool. Example:
build :make, -f foo.mak
Would invoke make -f foo.mak.
One of the known build tools is shell which basically lets you run
arbitrary commands. Example:
build :shell, ./build_my_app.sh
build :shell, rdmd --build-only main.d.
What about projects that don't use {project_root} as the include
directory? My projects, for instance, typically use {project_root}/src.
Actually I don't think this will be a problem. The working directory
when installing a package will look the same as the project directory
where you created the package.
Example:
1. You have all source files in {project_root}/src. When you build the
package, from {project_root}, it will create a src directory in the
package and all you source files will be in this directory.
2. When the package is to be installed the package manager extracts the
package and you will have the src folder in the working directory/a
temp directory.
3. The package manager will execute the build command from the working
directory. So the build system you have chosen just needs to find the
src folder relative to the working directory.
Lets take Make as an example, because it's a tool that exists and we
know how it works. Either you have the makefile in the working directory
(the original place was the project root). Or it will be in the src
directory.
This is how the orbspec will look like when the makefile is in the root
folder:
build :make
Or when the makefile is in the src folder:
build :make, -f src/makefile
--
/Jacob Carlborg
What is __dtor() supposed to do?
This is somewhat in reference to a bug that I was having trouble with
(Issue 5667 - http://d.puremagic.com/issues/show_bug.cgi?id=5667).
Right now __dtor() simply represents the function defined between the
curly braces of ~this(), not the compiler generated function that
calls ~this() and the destructors of members in proper order. To
illustrate:
import std.stdio;
struct A { ~this() { writeln( A.~this()); } }
struct B {
~this() { writeln(B.~this()); }
A member;
}
struct C {
A member;
}
void main() {
A a;
B b;
C c;
writeln( using __dtor );
a.__dtor(); // prints A.~this() as expected
b.__dtor(); // prints B.~this(), but not A.~this()
// c.__dtor(); // does not compile because there is no ~this() defined in C
writeln( using TypeInfo_Struct.destroy )
typeid(B).destroy(a); // prints both A.~this() and B.~this()
typeid(C).destroy(c); // compiles prints A.~this();
writeln( going out of scope );
}
Basically my question is - is this the required behaviour? Or should
__dtor and destroy() do the same thing? If they should, then the bug I
mentioned is a compiler bug. Otherwise, the fix I proposed to druntime
would work.
---
Cristi Cobzarenco
BSc in Artificial Intelligence and Computer Science
University of Edinburgh
Profile: http://www.google.com/profiles/cristi.cobzarenco
Re: Prototype buildsystem Drake
2011/7/19 Jacob Carlborg d...@me.com: Apperently some projects need to have their buildsystem check for the existance of, locations of, and details about certain things on the local system before building. So...that stuff. Isn't that to check what libraries, and so on, are present? That is the whole point of a package manager. A package specifies what dependencies it has, then the package manager makes sure the dependencies are met, or else it can't be installed. All dependencies aren't always mandatory. It's not uncommon for some software to adapt itself to the environment, say enabling certain features IF certain other packages can be found, otherwise just disable the functionality. Also it might adapt itself on other conditions, say auto-detecting checking what OS-kernel we are building for, and pass along D versions-keywords accordingly, including allowing the user to override, to do cross-platform or cross-version builds. Also, most build-systems offers options for whomever is building, such as --use-test-codeX, much like Tango now allows you to build with the regular, or the less tested concurrent GC. Don't know what locations it would check for. The package as no saying in where it should be installed, the package manger decides that. Same here. You may have multiple builds of the same package, and want to cross test a dependent package against two different installs to do regression-testing. (Or the classic i386/x86_64 debacle) Oh, now I mixing package manager and build tool and assume the build tool will be used with the package manager. I think the build-tool and package manager must be independent, but well integrated. Otherwise, you risk making it difficult for D-software to come by default in Linux-distros, and you make it difficult for the D-package-manager to carry a package with a different build-system (even a D based package with different build-system).
Re: Has anyone ever tested CDGC (Concurrent D GC)?
I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? I don't know. On Windows you can't use fork anyway and we have to figure out an alternative way. Maybe he explains it in his thesis, but it's only available in Spanish: http://www.llucax.com.ar/proj/dgc/index.html
Re: What is __dtor() supposed to do?
On Tue, 19 Jul 2011 09:42:32 -0400, Cristi Cobzarenco
cristi.cobzare...@gmail.com wrote:
This is somewhat in reference to a bug that I was having trouble with
(Issue 5667 - http://d.puremagic.com/issues/show_bug.cgi?id=5667).
Right now __dtor() simply represents the function defined between the
curly braces of ~this(), not the compiler generated function that
calls ~this() and the destructors of members in proper order. To
illustrate:
import std.stdio;
struct A { ~this() { writeln( A.~this()); } }
struct B {
~this() { writeln(B.~this()); }
A member;
}
struct C {
A member;
}
void main() {
A a;
B b;
C c;
writeln( using __dtor );
a.__dtor(); // prints A.~this() as expected
b.__dtor(); // prints B.~this(), but not A.~this()
// c.__dtor(); // does not compile because there is no ~this()
defined in C
writeln( using TypeInfo_Struct.destroy )
typeid(B).destroy(a); // prints both A.~this() and B.~this()
typeid(C).destroy(c); // compiles prints A.~this();
writeln( going out of scope );
}
Basically my question is - is this the required behaviour? Or should
__dtor and destroy() do the same thing? If they should, then the bug I
mentioned is a compiler bug. Otherwise, the fix I proposed to druntime
would work.
destroy calls the xdtor member made by the compiler. The code for this
function as far as I can tell is generated by the compiler, so I would say
this is *definitely* a compiler bug. IMO, __dtor should map to the same
thing.
There is no reason I can think of to separate out the __dtor and the calls
to the destructors for any sub members. Can you?
-Steve
Re: Trouble with std.zlib
Andrew Wiley Wrote: I'm using std.zlib in an application, and I'm having trouble decompressing a file. The file is gzipped, and I can easily see the contents with `cat file | gzip -d` but this code doesn't work: auto arr = read(file.gz); ubyte[] realarr = cast(ubyte[])uncompress(arr); The zlib format is different from the gzip format. http://www.zlib.net/zlib_faq.html#faq18 One is made for file storage and the other internal data transfer. D does not provide a wrapper to the gzip functions at this time but they are available in std.c.zlib (with the C interface).
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Tue, 19 Jul 2011 22:57:47 +0900, Trass3r u...@known.com wrote: I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? I don't know. On Windows you can't use fork anyway and we have to figure out an alternative way. Maybe he explains it in his thesis, but it's only available in Spanish: http://www.llucax.com.ar/proj/dgc/index.html Thanks for the link! But, I didn't read Spanish...
Re: Prototype buildsystem Drake
On 2011-07-19 15:48, Ulrik Mikaelsson wrote: 2011/7/19 Jacob Carlborgd...@me.com: Apperently some projects need to have their buildsystem check for the existance of, locations of, and details about certain things on the local system before building. So...that stuff. Isn't that to check what libraries, and so on, are present? That is the whole point of a package manager. A package specifies what dependencies it has, then the package manager makes sure the dependencies are met, or else it can't be installed. All dependencies aren't always mandatory. It's not uncommon for some software to adapt itself to the environment, say enabling certain features IF certain other packages can be found, otherwise just disable the functionality. Also it might adapt itself on other conditions, say auto-detecting checking what OS-kernel we are building for, and pass along D versions-keywords accordingly, including allowing the user to override, to do cross-platform or cross-version builds. Also, most build-systems offers options for whomever is building, such as --use-test-codeX, much like Tango now allows you to build with the regular, or the less tested concurrent GC. Ok, I see. Don't know what locations it would check for. The package as no saying in where it should be installed, the package manger decides that. Same here. You may have multiple builds of the same package, and want to cross test a dependent package against two different installs to do regression-testing. (Or the classic i386/x86_64 debacle) Oh, now I mixing package manager and build tool and assume the build tool will be used with the package manager. I think the build-tool and package manager must be independent, but well integrated. Otherwise, you risk making it difficult for D-software to come by default in Linux-distros, and you make it difficult for the D-package-manager to carry a package with a different build-system (even a D based package with different build-system). The package manager and build system will be independent. I just got confuse and it was a mess in my head :). Was unsure if what I wrote would make any sense. -- /Jacob Carlborg
Re: Prototype buildsystem Drake
On Tue, 2011-07-19 at 14:55 +0200, Jacob Carlborg wrote: On 2011-07-19 11:28, Nick Sabalausky wrote: Granted, I've never used this sort of feature from any buildsystem, but I thought we were talking about something like the configure command in Waf. My understanding is that it's like the ./configure from autotool's ./configure make make install, (except hopefully without needing to check quite so much stuff or needing the user to manually run the configure command). I would hope D never had to use something like ./configure. It checks for C language features and similar (probably other things as well). I don't think that that belongs in a build system for D. Well Autoconf, Waf and SCons check for a whole lot more than C features, there are C++, Fortran, Python, . . . but yes one part of configuration is (not unreasonably) which version of which languages are available in order to build from source. Apperently some projects need to have their buildsystem check for the existance of, locations of, and details about certain things on the local system before building. So...that stuff. Isn't that to check what libraries, and so on, are present? That is the whole point of a package manager. A package specifies what dependencies it has, then the package manager makes sure the dependencies are met, or else it can't be installed. There is clearly a string coupling between configuration and package management. Autoconf, Waf and SCons have to be portable across package management since they are not dedicated to one scheme -- springing up as they did from before package management as standard. Don't know what locations it would check for. The package as no saying in where it should be installed, the package manger decides that. Oh, now I mixing package manager and build tool and assume the build tool will be used with the package manager. There are some potentially tricky issues here. Ruby gets round it by having a language specific package and build system which therefore causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive headaches. Haskell/Cabal, Python/Eggs, etc. The conflict between language packaging and platform packaging is central. Having a D language packaging system that was in some way harmonious with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy. Indirectly it would make traction a whole lot easier. As evidence I present Java, Ruby, Python, Haskell, etc. When I was talking about config file I was thinking something more like Rebuild's config files, example: http://pastebin.com/rYc47wXQ -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Orbit - Package Manager - Specification/ideas
On 2011-07-19 13:43, Johannes Pfau wrote: Jacob Carlborg wrote: On 2011-07-19 12:33, Johannes Pfau wrote: Seems like rpath could indeed work in this case. I can't find much documentation about it though. Debian recommends not to use it: http://wiki.debian.org/RpathIssue but I'm not sure if this problem applies to orbit. Won't the same problem occur if rpath isn't used? With LD_LIBRARY_PATH for example. I'm not sure about that, but using LD_LIBRARY_PATH is even more discouraged (because it propagates to child processes) Ok. What is used to tell the system where to find a library? Only the default paths as /usr/lib ? I'm not sure if we can have one perfect approach for all operating systems. But we could just use the rpath way and see how it works out. Yeah. We'll see how it turns out. I agree that's a nice-to-have feature, but is it ever really necessary? This mechanism always picks up the newest ABI compatible library version. Why would you want to specify one version explicitly if the newer version can be used as a 1:1 replacement? I don't know if it's really necessary but that's how I've been thinking that I want it to behave. -- /Jacob Carlborg
Re: Orbit - Package Manager - Specification/ideas
On 2011-07-19 12:33, Johannes Pfau wrote: Seems like rpath could indeed work in this case. I can't find much documentation about it though. Debian recommends not to use it: http://wiki.debian.org/RpathIssue but I'm not sure if this problem applies to orbit. The problem mentioned on that page is: A problem arises when binary A defines a NEEDED dependency on libraries B.so.1 and C.so.2, while library B.so.1 depends on library C.so.1 How is this handled when rpath isn't used and in general? -- /Jacob Carlborg
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Tue, 19 Jul 2011 10:19:09 -0400, Masahiro Nakagawa repeate...@gmail.com wrote: On Tue, 19 Jul 2011 22:57:47 +0900, Trass3r u...@known.com wrote: I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? I don't know. On Windows you can't use fork anyway and we have to figure out an alternative way. Maybe he explains it in his thesis, but it's only available in Spanish: http://www.llucax.com.ar/proj/dgc/index.html Thanks for the link! But, I didn't read Spanish... He explains a lot of it in his blog. CDGC is an example of a snapshot GC. In short, when a collection is triggered, a snapshot of the program's entire memory subsystem is created. The GC can then trace using this snapshot without having to worry about program writes, etc, messing it up. When finished, it passes back to the main program what objects are garbage and the snapshot is discarded. Now, a userland implementation of this is horribly inefficient, so CDGC uses fork to leverage the OS's ability to do copy-on-write at the page level. I believe CDGC also uses a memory mapped file for the GC's meta info, to avoid the update message passing overhead. While Windows does support allocating memory in a COW manner, there's no way to do add this dynamically to an existing page. Windows does support page-level write tracking (since 2K SP3), which is very useful for incremental GC. i.e. the GC can use OS to only trace through modified pages. There are two other alternative, modern GCs that I know of which fit system programming languages like D. One used a kernel patch to trap hardware writes efficiently, allowing one to bolt a traditional concurrent GC onto a system's language. Which, while cool, isn't practical until OS APIs support it out of the box. The other is thread-local GCs, which according to Apple, have roughly equivalent performance to existing concurrent GCs. Given shared and immutable, thread-local GC's make a lot of sense for D and can be combined with other concurrent options should they be/become available.
Re: How D may replace PHP ASPX on the Web!!!
On 7/19/2011 2:00 AM, Adam Ruppe wrote: Matthew Ong wrote: Now, SugarCRM is being use not because all web pages are CRM product, but to show how a professional product is implemented in PHP. Yes, I've had to work with it's code before... it was so brutally slow and overcomplicated that we ended up deciding to just throw more hardware at the problem instead! It was moderately painful hooking it into the external application too. Blargh. Yes. I am well aware that PHP is slow because of 3-tier approaches. The KEY idea that I am trying to suggest is the modeling of the D Web Framework that could beat google go. It is about how many build in ability within the existing framework that is shown here in SugarCRM as a single example for discussion points for what may needs to be in the new Web framework from D. Not as a product to be build by a developer. PHP by itself is rather primitive, it does not have all those feature listed in my previous message. However PHP developer has nuke, joomla, sugarcrm... already there to ride on top off. D is currently not the case, I think. A single post pass over http server, next php engine before it reaches the core processing of the application. It actually passes via at least 2 process id runtime before the request is ever handled. What I am showing here is Not to use the SugarCRM over all architecture, but rather, build a list of supported nice features directly within the webframework in D. What would be nice is the D- Webframework itself will provide a minimum http/s secure server to serve the framework and can be configure within the framework. The framework itself should be a single pid within the OS. That way, a single request is only handled within one single pid process all the way until the response packet. Not doing the traditional CGI approaches. But more like the Java Tomcat JSP approaches in the framework level. JSP is slower than D because of JVM. So, DSP(D version of JSP) would be processed within a single PID. 1.3) date time format / timezone automatically calculated. What I did for timezone was to use a little javascript to set a cookie based on the users' local clock. Incredibly simple and worked very well. That is needed within the logic of the server to track data for security purpose and also tx time. Browser site time format might allow hacker to mess the time info of attacks. 2) Support skin theme switching and customization. This will With my D sites, I was able to express the vast majority of changes in css, and the rest through a DOM post-processor and separate template directories when appropriate. Skin in PHP Joomla SugarCRM uses css and images within a well-know layout and also name. This is a nice feature that may be adopted to ease designers for customizing and deployment. The post-processor is the special thing - most apps treat templates as strings, which maybe could do these things, but I doubt it'd be as clear and easy as with the higher level structures. I actually in favor the Microsoft asmx + aspx approaches here, but the aspx and asmx must be within the same SINGLE PID memory space. A single asmx code to be call within the same DSP process without soap-xml but when the asmx code is call without the process, soap-xml is used. SEE: http://msdn.microsoft.com/en-us/magazine/cc163674.aspx By using asmx as the controller and call direct (NO Soap-xml) by view from within the SAME process, things can happen really fast. When a call to controller from outside the process it uses Soap-Xml. That way, we can separate the testing and also integrations to other languages. http://www.asp.net/mvc/tutorials/understanding-models-views-and-controllers-cs Support customization of forms and also building new module on the fly. web.d attacks this by letting you alias in other classes to your main app, and of course, with dom templates editing forms is easy. 5) Allow developer to paste in new code updates into some form of hooks web.d exposes your public functions via javascript, which makes this pretty simple. When I integrated sugarcrm with my D application, I used web.d's javascript functionality and a standard onclick handler to bring the D functions in very easily. Dealing with PHP made it harder than it had to be, but it was still pretty simple. (that thing goes both ways btw - web.d's functions are easily accessed with a small PHP library too, that uses curl.) I am in favor of asmx model. See the explanation above. 7) Support multiple platforms including some mobiles devices. Any website that doesn't work on mobile devices already is garbage. The whole point of the web is device independence! True, but many many web application is currently not yet mobile ready because they are stuck in the CGI model(Aspx/JSP/Strut) rather than the full MVC model like asmx + aspx. BTW: I started writing a higher level explanation of my cgi.d.
Re: Trouble with std.zlib
On Tue, Jul 19, 2011 at 7:11 AM, Jesse Phillips jessekphillip...@gmail.comwrote: Andrew Wiley Wrote: I'm using std.zlib in an application, and I'm having trouble decompressing a file. The file is gzipped, and I can easily see the contents with `cat file | gzip -d` but this code doesn't work: auto arr = read(file.gz); ubyte[] realarr = cast(ubyte[])uncompress(arr); The zlib format is different from the gzip format. http://www.zlib.net/zlib_faq.html#faq18 One is made for file storage and the other internal data transfer. D does not provide a wrapper to the gzip functions at this time but they are available in std.c.zlib (with the C interface). I know, but if you look at the docs for the inflate functions, zlib is supposed to be autodetecting the gzip header and uncompressing the payload correctly, if I understand the documentation (which I probably don't at this point).
Re: Prototype buildsystem Drake
On 2011-07-19 16:46, Russel Winder wrote: There is clearly a string coupling between configuration and package management. Autoconf, Waf and SCons have to be portable across package management since they are not dedicated to one scheme -- springing up as they did from before package management as standard. Ok. There are some potentially tricky issues here. Ruby gets round it by having a language specific package and build system which therefore causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive headaches. Haskell/Cabal, Python/Eggs, etc. The conflict between language packaging and platform packaging is central. Having a D language packaging system that was in some way harmonious with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy. Indirectly it would make traction a whole lot easier. As evidence I present Java, Ruby, Python, Haskell, etc. The whole point of having a D package manager is so I don't have to create packages for all these system specific package managers. -- /Jacob Carlborg
Re: Trouble with std.zlib
Andrew Wiley Wrote: I know, but if you look at the docs for the inflate functions, zlib is supposed to be autodetecting the gzip header and uncompressing the payload correctly, if I understand the documentation (which I probably don't at this point). Not sure what documentation you are talking of. But it doesn't sound like it does auto detection, an answer to one of the question: You can request that deflate write the gzip format instead of the zlib format using deflateInit2(). You can also request that inflate decode the gzip format using inflateInit2(). Read zlib.h for more details.
Re: Trouble with std.zlib
On Tue, Jul 19, 2011 at 9:57 AM, Jesse Phillips jessekphillip...@gmail.comwrote: Andrew Wiley Wrote: I know, but if you look at the docs for the inflate functions, zlib is supposed to be autodetecting the gzip header and uncompressing the payload correctly, if I understand the documentation (which I probably don't at this point). Not sure what documentation you are talking of. But it doesn't sound like it does auto detection, an answer to one of the question: You can request that deflate write the gzip format instead of the zlib format using deflateInit2(). You can also request that inflate decode the gzip format using inflateInit2(). Read zlib.h for more details. Ah, I stand corrected: inflate() can decompress and check either zlib-wrapped or gzip-wrapped deflate data. The header type is detected automatically, if requested when initializing with inflateInit2().
Re: Trouble with std.zlib
On Tue, Jul 19, 2011 at 10:14 AM, Andrew Wiley wiley.andre...@gmail.comwrote: On Tue, Jul 19, 2011 at 9:57 AM, Jesse Phillips jessekphillip...@gmail.com wrote: Andrew Wiley Wrote: I know, but if you look at the docs for the inflate functions, zlib is supposed to be autodetecting the gzip header and uncompressing the payload correctly, if I understand the documentation (which I probably don't at this point). Not sure what documentation you are talking of. But it doesn't sound like it does auto detection, an answer to one of the question: You can request that deflate write the gzip format instead of the zlib format using deflateInit2(). You can also request that inflate decode the gzip format using inflateInit2(). Read zlib.h for more details. Ah, I stand corrected: inflate() can decompress and check either zlib-wrapped or gzip-wrapped deflate data. The header type is detected automatically, if requested when initializing with inflateInit2(). Looks like this is the solution: ubyte[] realarr = cast(ubyte[])uncompress(arr, 0, 47); The 47 makes zlib autodetect the header (because the 32 bit is set; if you wanted to force gzip, you'd set the 16 bit).
Re: How D may replace PHP ASPX on the Web!!!
Matthew Ong
The KEY idea that I am trying to suggest is the modeling of the D Web
Framework that could beat google go
Go's offering for web apps is very, very poor (at least it was last
I checked when they did that web apps in go advertisement). It
seemed content with offering only the bare minimum.
D is already much better.
The framework itself should be a single pid within the OS.
Why?
Note btw: D already has this. My cgi.d can be used with an embedded
http server, meaning all data is handled by a single process.
But I recommend against it because that's less robust. If the one
process dies, everyone suffers.
It also doesn't scale as well as a multiple process approach, but
this is surely my implementation more than anything else.
There are things I kinda like about single process, but the
robustness is a huge hit against it.
Browser site time format might
allow hacker to mess the time info of attacks.
No, you still use one time format inside the app. Timezone
translation is only done for user input and output.
I actually in favor the Microsoft asmx + aspx approaches here, but
the aspx and asmx must be within the same SINGLE PID memory space.
It looks like that has a lot in common with web.d.
In web.d, you implement a service like this:
===
class MySite : ApiProvider {
int add(int a, int b) { return a+b; }
string sayHello(string name) { return Hello, ~ name ~ !; }
}
===
If you're in the same process, you can call the functions directly:
===
auto api = new MySite();
assert(api.add(1, 2) == 3);
===
It's just a regular class, so you call methods normally if you're
local. If you are on a remote server, a very similar interface
lets you call the functions remotely.
Javascript example:
MySite.add(1, 2).get(alert); // calls alert(3);
You can also do other languages, nested calls, custom formats, etc.
Anyway, this is super fast if local - it's just a method call - and
reasonably fast and accessible if remote, while giving nice looking
code.
It gets really cool when you start using enums, alias, and structs
though.
True, but many many web application is currently not yet mobile
ready because they are stuck in the CGI model(Aspx/JSP/Strut)
rather than the full MVC model like asmx + aspx.
Meh, those fancy sites tend to work worse in my experience.
I am on +0800GMT what time zone you are on?
I'm at GMT - 0400
Re: How D may replace PHP ASPX on the Web!!!
On Tue, 19 Jul 2011 23:59:34 +0800, Matthew Ong wrote: 7) Support multiple platforms including some mobiles devices. Any website that doesn't work on mobile devices already is garbage. The whole point of the web is device independence! True, but many many web application is currently not yet mobile ready because they are stuck in the CGI model(Aspx/JSP/Strut) rather than the full MVC model like asmx + aspx. That makes no sense to me at all. What on earth does the server-side model have to do with how a mobile device renders a Web page? Furthermore, how is JSP or Strut anything like CGI, and how is MVC an alternative to CGI? If there is value in your post, I think you are obscuring it by making confusing statements like these. Pointing at a CMS or a set of diverse tools and saying, D should have something like this! is not terribly productive. Perhaps you could start by offering an itemized list of (clear, specific) features that you think a D Web framework ought to support. Graham
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Wed, 20 Jul 2011 00:25:58 +0900, Robert Jacques sandf...@jhu.edu wrote: On Tue, 19 Jul 2011 10:19:09 -0400, Masahiro Nakagawa repeate...@gmail.com wrote: On Tue, 19 Jul 2011 22:57:47 +0900, Trass3r u...@known.com wrote: I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? I don't know. On Windows you can't use fork anyway and we have to figure out an alternative way. Maybe he explains it in his thesis, but it's only available in Spanish: http://www.llucax.com.ar/proj/dgc/index.html Thanks for the link! But, I didn't read Spanish... snapshot GC I have heard this by A Real-Time Garbage Collection for Java using Snapshot Algorithm. I understand a basic mechanism(above article uses a thread instead of fork()). Hmm... I want to see a comparison of fork() and thread. There are two other alternative, modern GCs that I know of which fit system programming languages like D. One used a kernel patch to trap hardware writes efficiently, allowing one to bolt a traditional concurrent GC onto a system's language. Which, while cool, isn't practical until OS APIs support it out of the box. The other is thread-local GCs, which according to Apple, have roughly equivalent performance to existing concurrent GCs. Given shared and immutable, thread-local GC's make a lot of sense for D and can be combined with other concurrent options should they be/become available. I didn't know the former. Thanks for the information. Latter approach is similar to Erlang. Erlang provides GC per-process and I like this approach. Is Thread-local GC in D realistic? D allows global mutable state...
Re: std.path review: update
Lars T. Kyllingstad public@kyllingen.NOSPAMnet wrote in message news:j01trl$2ia$6...@digitalmars.com... On Mon, 18 Jul 2011 13:16:29 -0400, Steven Schveighoffer wrote: In driveName: Should std.path handle uunc paths? i.e. \\servername\share\path (I think if it does, it should specify \\servername\share as the drive) Yes, std.path is supposed to support UNC paths. For instance, the following works now: assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo`, bar, baz])); I guess you would rather have that assert (equal(pathSplitter(`\\foo\bar\baz`), [`\\foo\bar`, baz])); then? I am not very familiar with Windows network shares; is \\foo never a valid path on its own? I don't know whether or not it's never a valid path, but dir \\server always fails and dir \\server\share always works (assuming it exists, at least). So treating the whole thing as a drive might be the right thing to do. (Of course, it's completely moronic that WIndows works that way...) fcmp: On Windows, fcmp is an alias for std.string.icmp, which yields a case insensitive comparison. On POSIX, it is an alias for std.algorithm.cmp, i.e. a case sensitive comparison. What about comparing c:/foo with c:\foo? This isn't going to be equal with icmp. I am a bit unsure what to do about the comparison functions (fcmp, pathCharMatch and globMatch). Aside from the issue with directory separators it is, as was pointed out by someone else, entirely possible to mount case-sensitive file systems on Windows and case-insensitive file systems on POSIX. (The latter is not uncommon on OSX, I believe.) I am open to suggestions. If such mountings are possible, it would seem that there must be some way to check the sensitivity (otherwise the OS itself would probably crap out on it). Although, at least in the case of case-insensitive mountings on posix, doesn't that mean such paths would have both case-sensitive and case-insensitive parts? Ex: /mount/damnWinDrive/dir/subdir Wouldn't the mount/damnWinDrive part be case-sensitive and the dir/subdir part be insensitve? (I'm starting to really despise case-insensitive filesystems.)
Re: Prototype buildsystem Drake
Russel Winder rus...@russel.org.uk wrote in message news:mailman.1770.1311086829.14074.digitalmar...@puremagic.com... There are some potentially tricky issues here. Ruby gets round it by having a language specific package and build system which therefore causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive headaches. Haskell/Cabal, Python/Eggs, etc. The conflict between language packaging and platform packaging is central. Having a D language packaging system that was in some way harmonious with Apt/Deb, Yum/RPM, Ports, etc. would make a lot of people very happy. Indirectly it would make traction a whole lot easier. As evidence I present Java, Ruby, Python, Haskell, etc. What would be needed for a D package manager to be harmonious with such systems? I don't know anything about the issues OS packagers face regarding language-oriented package systems.
Package Managers: What about 0install?
This has been hanging in the back of my mind and it's about dang time I bring it up: The main reason we've been discussing the creation of a D package manager is because existing package managers are highly OS-specific. So what about 0install?: http://0install.net/ I haven't actually used it yet, but 0install has already gone through great pains to try to be cross-platform, distributed, safe, and overall well-designed. And it already exists. So maybe we're needlessly re-inventing the wheel here? Would it make sense to just use 0install as D's standard package management tool? If not, would it be best to just adapt it to our needs?
Re: Package Managers: What about 0install?
On 19/07/2011 21:21, Nick Sabalausky wrote: This has been hanging in the back of my mind and it's about dang time I bring it up: The main reason we've been discussing the creation of a D package manager is because existing package managers are highly OS-specific. So what about 0install?: http://0install.net/ I haven't actually used it yet, but 0install has already gone through great pains to try to be cross-platform, distributed, safe, and overall well-designed. And it already exists. So maybe we're needlessly re-inventing the wheel here? Would it make sense to just use 0install as D's standard package management tool? If not, would it be best to just adapt it to our needs? I don't know if it's changed, but about a year or so ago I tried using something that required 0install... It didn't end well at all, I seem to recall I had to re-image my system eventually after a few hours of trying to get it working :/ -- Robert http://octarineparrot.com/
Re: std.path review: update
Here's some relevant info: http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx
Re: Package Managers: What about 0install?
Robert Clipsham rob...@octarineparrot.com wrote in message news:j04u7t$nue$1...@digitalmars.com... On 19/07/2011 21:21, Nick Sabalausky wrote: This has been hanging in the back of my mind and it's about dang time I bring it up: The main reason we've been discussing the creation of a D package manager is because existing package managers are highly OS-specific. So what about 0install?: http://0install.net/ I haven't actually used it yet, but 0install has already gone through great pains to try to be cross-platform, distributed, safe, and overall well-designed. And it already exists. So maybe we're needlessly re-inventing the wheel here? Would it make sense to just use 0install as D's standard package management tool? If not, would it be best to just adapt it to our needs? I don't know if it's changed, but about a year or so ago I tried using something that required 0install... It didn't end well at all, I seem to recall I had to re-image my system eventually after a few hours of trying to get it working :/ What OS was that? The Windows support is fairly new, so that might have still been in beta at that point.
Re: Package Managers: What about 0install?
On 19/07/2011 23:54, Nick Sabalausky wrote: What OS was that? The Windows support is fairly new, so that might have still been in beta at that point. Linux, don't remember what flavour. -- Robert http://octarineparrot.com/
RDMD is broken on Windows7
In DMD 2.054 RDMD is broken. It crashes on any file, and this only came to my attention after simendsjo started reporting that he can't build neither gtkD nor my DWindowsProgramming project. It works fine on XP, but on Win7 it just crashes with any piece of code: http://i.imgur.com/X9s9y.png
Re: RDMD is broken on Windows7
On Wed, 20 Jul 2011 02:05:03 +0300, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: In DMD 2.054 RDMD is broken. It crashes on any file, and this only came to my attention after simendsjo started reporting that he can't build neither gtkD nor my DWindowsProgramming project. It works fine on XP, but on Win7 it just crashes with any piece of code: http://i.imgur.com/X9s9y.png See here: http://comments.gmane.org/gmane.comp.lang.d.dmd.beta/788 -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: RDMD is broken on Windows7
Yep. See thread 'gtkD doesn't compile on windows' in D.learn. If I compile rdmd (with my patch, haven't tried the original) without -g, it crashes when trying to compile anything... Does this also happen if you compile it with -g and then run cv2pdb on it? I cannot compile anything without first compiling rdmd with -g. Compiling rdmd with -g and running cv2pdb on it works. It fails on the return statement in getDependencies. It never gets to the line after getDependencies in main.
Re: RDMD is broken on Windows7
See here: http://comments.gmane.org/gmane.comp.lang.d.dmd.beta/788 Well Walter states that adding printf's would make it work. But I think simendsjo added printfs and it still crashed.
Re: Prototype buildsystem Drake
Nick Sabalausky a@a.a wrote in message
news:ivviur$2ks8$1...@digitalmars.com...
Jacob Carlborg d...@me.com wrote in message
news:ivp1gd$500$2...@digitalmars.com...
Ok, have you thought about how this will look (in code) and behave?
Not extensively, but here's what I have in mind so far. In an early
initial version of Drake, it would be like this:
task(configure, drake.conf);
file(drake.conf,
(Target t)
{
// Do all configuring here and save to drake.conf
}
);
Actually, I think that might have to be more like:
// This part added:
if(DrakeArgs.target == configure)
remove(drake.conf);
task(configure, drake.conf);
file(drake.conf,
(Target t)
{
// Do all configuring here and save to drake.conf
}
);
Otherwise drake configure wouldn't re-generate the configuration unless
drake.conf was manually deleted first. Or, maybe there should just be a
--force option (also accesible from code? on a per-task basis?) to skip
the dependency checks and forcefully rebuild.
Oh, and maybe the configuration fle should just be named configure:
// Use --force to re-configure
file(configure,
(Target t)
{
// Do all configuring here and save to 'configure'
}
);
Pardon the public brainstorming...
Re: RDMD is broken on Windows7
On Wed, 20 Jul 2011 02:10:42 +0300, Trass3r u...@known.com wrote: See here: http://comments.gmane.org/gmane.comp.lang.d.dmd.beta/788 Well Walter states that adding printf's would make it work. But I think simendsjo added printfs and it still crashed. Well, I reduced the crash to an exception thrown inside the constructor of a temporary (see bug report[1]), but I didn't notice the fragility (heisenbug traits) that Walter described. While they MIGHT be different bugs, they definitely share something related to destruction of temporaries. [1]: http://d.puremagic.com/issues/show_bug.cgi?id=6308 -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Kotlin language
Kotlin is a new statically typed language for the Java VM. It's similar to
Scala, but it's simpler. It looks easy to learn.
---
It seems to have well designed null-safety, types annotated with ? are nullable:
http://confluence.jetbrains.net/display/Kotlin/Null-safety
All statically typed languages that are coming out in the last years seem to
have something similar.
It even has the little amount of type state to make things handy and safe:
var a : String = abc // not nullable string
var b : String? = abc // nullable string
val l = b.length() // error: variable 'b' can be null
val l = if (b != null) b.length() else -1 // OK
Plus some other nice details. But I have not programmed wiht Kotlin and I don't
know know it manages the situations of partially initialized objects in a
contructor (that is an important special case).
---
It has type-safe Groovy-style builders, to define tree-shaped data structures
in a a semi-declarative way. They are useful to generate XML, lay out UI
components, describe 3D scenes, etc:
http://confluence.jetbrains.net/display/Kotlin/Type-safe+Groovy-style+builders
---
It has ranges:
http://confluence.jetbrains.net/display/Kotlin/Ranges
// Check range membership, i.e. contains
// (optimized for Ints)
if (a in 1..100) {
print(in range)
}
// Iterate through a range, i.e. iterator()
// (optimized for Ints)
for (x in 1..100) {
print(x)
}
Bye,
bearophile
Re: Has anyone ever tested CDGC (Concurrent D GC)?
On Tue, 19 Jul 2011 13:28:04 -0400, Masahiro Nakagawa repeate...@gmail.com wrote: On Wed, 20 Jul 2011 00:25:58 +0900, Robert Jacques sandf...@jhu.edu wrote: On Tue, 19 Jul 2011 10:19:09 -0400, Masahiro Nakagawa repeate...@gmail.com wrote: On Tue, 19 Jul 2011 22:57:47 +0900, Trass3r u...@known.com wrote: I am interested in Concurrent GC. But, I have a question about CDGC. AFAIK, other language runtimes use thread for concurrent processing. Why use fork()? What is the merit of fork() approach? I don't know. On Windows you can't use fork anyway and we have to figure out an alternative way. Maybe he explains it in his thesis, but it's only available in Spanish: http://www.llucax.com.ar/proj/dgc/index.html Thanks for the link! But, I didn't read Spanish... snapshot GC I have heard this by A Real-Time Garbage Collection for Java using Snapshot Algorithm. I understand a basic mechanism(above article uses a thread instead of fork()). Hmm... I want to see a comparison of fork() and thread. There are two other alternative, modern GCs that I know of which fit system programming languages like D. One used a kernel patch to trap hardware writes efficiently, allowing one to bolt a traditional concurrent GC onto a system's language. Which, while cool, isn't practical until OS APIs support it out of the box. The other is thread-local GCs, which according to Apple, have roughly equivalent performance to existing concurrent GCs. Given shared and immutable, thread-local GC's make a lot of sense for D and can be combined with other concurrent options should they be/become available. I didn't know the former. Thanks for the information. Latter approach is similar to Erlang. Erlang provides GC per-process and I like this approach. Is Thread-local GC in D realistic? D allows global mutable state... Well, given that D has separate types for immutable and shared data, implementing a thread-local GC in D is a while lot easier and safer than other languages like Objective-C and Java, etc for which people have already written thread-local GCs. But, unlike Erlang, D would also have to have a global shared GC in addition to the thread local GCs, in order to handle shared/immutable objects. Though how often the shared GC would actually run would be dependent on the form of concurrency you're using.
Problems building Qtd on Windows
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe -- broken
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054cmake -GMinGW Makefiles ../
-DCMAKE_CXX_FLAGS=-m32
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe -- broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
cmTryCompileExec/fast
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
Re: Problems building Qtd on Windows
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054cmake -GMinGW Makefiles ../
-DCMAKE_CXX_FLAGS=-m32
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
cmTryCompileExec/fast
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for this?
This is using cmake 2.8.5
Re: Problems building Qtd on Windows
On 19.07.2011 11:20, simendsjo wrote:
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054cmake -GMinGW Makefiles ../
-DCMAKE_CXX_FLAGS=-m32
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
cmTryCompileExec/fast
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for this?
This is using cmake 2.8.5
I've also tried cmake 2.6 without any luck.
I forced the try compile stuff to report as succeeded by modifying
CMakeTestCXXCompiler.cmake and CMakeTestCCompiler.cmake.
This allowed me to begin compilation, but the underlying problem is not
gone, and linking fails during compilation:
Linking CXX shared library lib\libcpp_core.dll
Error opening link script CMakeFiles\cpp_core.dir\link.txt
mingw32-make[5]: *** [lib/libcpp_core.dll] Error 1
mingw32-make[4]: *** [CMakeFiles/cpp_core.dir/all] Error 2
mingw32-make[3]: *** [all] Error 2
mingw32-make[2]: *** [main] Error 2
mingw32-make[1]: *** [CMakeFiles/main.dir/all] Error 2
mingw32-make: *** [all] Error 2
Re: Calling D from C++
On 2011-07-19 05:46, Johann MacDonagh wrote:
What is the best method to accomplish this, and are there any
limitations with this method (do I have to allocate the class with
malloc instead etc.)?
Your C++ class Base is not compatible with your D Foo class. The
v-tables are not guaranteed to be identical. I'm not even sure if D's
thiscall is the same as C++'s thiscall. It's just not going to work.
Most languages don't support this. This is why we use C bindings.
Everyone supports C ;)
Now, you can do something like this:
struct Foo
{
int x;
float y;
}
extern(C) void* GetNewFoo()
{
// Note: Don't use new here otherwise the GC may clean it up
return cast(void*) core.memory.GC.malloc(Foo.sizeof);
}
extern(C) float Foo_DoSomething(Foo* foo)
{
return foo.x + foo.y;
}
extern(C) void FreeFoo(Foo* foo)
{
core.memory.GC.free(foo);
}
I haven't tried this, but something like this should work. Structs are
inherently compatible between languages. Of course, you won't be able to
do any kind of polymorphism.
Does this help?
Very interesting!
This might help depends; are you able to have structures with functions?
Are they still analogous if you implement them?
Also, how come the class-interface inheritance didn't work to
communicate with C++. Is the Interface to C++ doc's outdated?
Calling D Virtual Functions From C++
http://www.digitalmars.com/d/2.0/cpp_interface.html
Re: Problems building Qtd on Windows
On 19.07.2011 11:56, simendsjo wrote:
On 19.07.2011 11:20, simendsjo wrote:
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054cmake -GMinGW Makefiles ../
-DCMAKE_CXX_FLAGS=-m32
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
cmTryCompileExec/fast
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E
cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for
this?
This is using cmake 2.8.5
I've also tried cmake 2.6 without any luck.
I forced the try compile stuff to report as succeeded by modifying
CMakeTestCXXCompiler.cmake and CMakeTestCCompiler.cmake.
This allowed me to begin compilation, but the underlying problem is not
gone, and linking fails during compilation:
Linking CXX shared library lib\libcpp_core.dll
Error opening link script CMakeFiles\cpp_core.dir\link.txt
mingw32-make[5]: *** [lib/libcpp_core.dll] Error 1
mingw32-make[4]: *** [CMakeFiles/cpp_core.dir/all] Error 2
mingw32-make[3]: *** [all] Error 2
mingw32-make[2]: *** [main] Error 2
mingw32-make[1]: *** [CMakeFiles/main.dir/all] Error 2
mingw32-make: *** [all] Error 2
Trying SO:
http://stackoverflow.com/questions/6745911/cmake-error-opening-link-script-cannot-change-directory
Re: Calling D from C++
On 2011-07-19 12:39, Loopback wrote:
On 2011-07-19 05:46, Johann MacDonagh wrote:
What is the best method to accomplish this, and are there any
limitations with this method (do I have to allocate the class with
malloc instead etc.)?
Your C++ class Base is not compatible with your D Foo class. The
v-tables are not guaranteed to be identical. I'm not even sure if D's
thiscall is the same as C++'s thiscall. It's just not going to work.
Most languages don't support this. This is why we use C bindings.
Everyone supports C ;)
Now, you can do something like this:
struct Foo
{
int x;
float y;
}
extern(C) void* GetNewFoo()
{
// Note: Don't use new here otherwise the GC may clean it up
return cast(void*) core.memory.GC.malloc(Foo.sizeof);
}
extern(C) float Foo_DoSomething(Foo* foo)
{
return foo.x + foo.y;
}
extern(C) void FreeFoo(Foo* foo)
{
core.memory.GC.free(foo);
}
I haven't tried this, but something like this should work. Structs are
inherently compatible between languages. Of course, you won't be able to
do any kind of polymorphism.
Does this help?
Very interesting!
This might help depends; are you able to have structures with functions?
Are they still analogous if you implement them?
Also, how come the class-interface inheritance didn't work to
communicate with C++. Is the Interface to C++ doc's outdated?
Calling D Virtual Functions From C++
http://www.digitalmars.com/d/2.0/cpp_interface.html
I noticed that function seems to work functions with structures.
Are there any restrictions worth knowing or is it just like any other
structure when D and C++ communicate?
Can I have private variables, public, properties etc?
And just not to forget, why the C++ and interface class didn't work?
Re: Problems building Qtd on Windows
On 19.07.2011 12:45, simendsjo wrote:
On 19.07.2011 11:56, simendsjo wrote:
On 19.07.2011 11:20, simendsjo wrote:
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054cmake -GMinGW Makefiles ../
-DCMAKE_CXX_FLAGS=-m32
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler c:/Qt/2010.05/mingw/bin/g++.exe is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
cmTryCompileExec/fast
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E
cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
C:\Program Files (x86)\CMake 2.8\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script CMakeFiles\cmTryCompileExec.dir\link.txt
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for
this?
This is using cmake 2.8.5
I've also tried cmake 2.6 without any luck.
I forced the try compile stuff to report as succeeded by modifying
CMakeTestCXXCompiler.cmake and CMakeTestCCompiler.cmake.
This allowed me to begin compilation, but the underlying problem is not
gone, and linking fails during compilation:
Linking CXX shared library lib\libcpp_core.dll
Error opening link script CMakeFiles\cpp_core.dir\link.txt
mingw32-make[5]: *** [lib/libcpp_core.dll] Error 1
mingw32-make[4]: *** [CMakeFiles/cpp_core.dir/all] Error 2
mingw32-make[3]: *** [all] Error 2
mingw32-make[2]: *** [main] Error 2
mingw32-make[1]: *** [CMakeFiles/main.dir/all] Error 2
mingw32-make: *** [all] Error 2
Trying SO:
http://stackoverflow.com/questions/6745911/cmake-error-opening-link-script-cannot-change-directory
Giving up... Tried 3 versions of qt + 2 of cmake + 2 of qtd.
Is windows not supported anymore?
Re: std.concurrency.spawn does not accept delegates
On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On 2011-07-18 15:15, teo wrote: On Mon, 18 Jul 2011 18:14:45 +, Jonathan M Davis wrote: On 2011-07-18 10:54, Simen Kjaeraas wrote: On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: On Monday 18 July 2011 15:55:52 teo wrote: On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote: On Sun, 17 Jul 2011 15:29:02 -0400, teo teo.ubu...@yahoo.com wrote: It looks like std.concurrency.spawn does not accept delegates. Is there any reason for that? There is no type attached to the hidden 'this' pointer. So spawn cannot guarantee it doesn't point to unshared data. -Steve Bad. I tried to pass as an argument a pointer to an instance of a class - a this pointer. That didn't work. Only stuff that's immutable or implicitly convertible immutable can be passed across threads using spawn and send. Otherwise, there's a risk of it ending up getting altered by both threads (or altered by one when the other one is using at it). Sometimes, that can be a bit restrictive (particularly when you _know_ that something isn't going to be altered by the thread sending it after its sent but the compiler doesn't), but it avoids all kinds of problems. If you want to send a class object across, then it needs to be immutable (which tends to be a bit of a pain to do for classes, since they need to have an immutable constructor, which is often a pain to do). It could be that assumeUnique should handle this, by transforming the delegate into something spawn() and friends could handle. Might be worth an enhancement request. There have been discussions about how to do it in the past. Whether assumeUnique will work depends on whether casting to immutable(C) will work (where C is the class' type), and I don't know whether that cast will work or not. If it does, then assumeUnique will do it, since all it does is cast to immutable, but it's the sort of thing that requires language support. There _might_ be a way to solve the problem with some sort of Unique template that spawn and send knew about, but nothing of the sort has been done yet. But until a number of the issues with const and immutable in the compiler have been sorted out, that sort of thing would probably be problematic anyway. - Jonathan M Davis This is a bit too restrictive in my opinion. Only the shared data between two threads should be immutable. But the threads can access all sorts of mutable data as well. And in this case we are actually talking about the control function (or start routine) of a thread. As long as it's address is fixed within the memory of a process its usage for that purpose should be fine. Nobody is going to pass that address around. Am I missing anything here? When passing data between threads, it must be immutable. I have to jump in and correct you, nobody else has. You can also pass data marked as shared. A solution could be to cast the class as shared, pass it, then cast it back to unshared (ensuring you don't access the class from the originator anymore). This is not a compiler-enforced solution, but it gets the job done. But there is risk of concurrency errors if you don't do it right. My recommendation is to isolate the parts that create and pass the shared data. -Steve
gtkD doesn't compile on windows
Giving up on qtD, I tried gtkD. Not much luck there either. As I've spent most of my day trying to compile qt, I'm not really in the mood to spend many hours trying to get gtk working. Is anybody actually using D for GUI development on Windows at all..? c:\d\ext\gtkd\d\dsss-0.78-x86-windows\bin\dsss.exe build undemofy Creating imports for DD-atk Creating imports for DD-cairo Creating imports for DD-gdk Creating imports for DD-gdkpixbuf Creating imports for DD-gio Creating imports for DD-glade Creating imports for DD-glib Creating imports for DD-gobject Creating imports for DD-gthread Creating imports for DD-gtk Creating imports for DD-gtkc Creating imports for DD-pango atk = DD-atk DD-atk_static.rf: No such file or directory Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting.
Re: Problems building Qtd on Windows
On 19.07.2011 14:46, Trass3r wrote: Giving up... Tried 3 versions of qt + 2 of cmake + 2 of qtd. Is windows not supported anymore? Was it ever? I always hit that: http://dsource.org/projects/qtd/ticket/54 I made it work (read: compile and crash on application start) on Win7x86 a while ago. My problem was some programs build on Qt on the path before the SDK, so the wrong DLL was picked up.
Re: gtkD doesn't compile on windows
atk = DD-atk DD-atk_static.rf: No such file or directory Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool?
Re: gtkD doesn't compile on windows
On 19.07.2011 15:12, Trass3r wrote: atk = DD-atk DD-atk_static.rf: No such file or directory Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool? No verbose flag. What other build tool? rdmd still doesn't understand subfolders on windows, and it doesn't give good error messages: c:\d\ext\gtkd\demos\gtkrdmd -v HelloWorld.d Failed: dmd -v -v -o- HelloWorld.d -I. HelloWorld.d.deps The dmd command works, so it's rdmd that fails.
Re: gtkD doesn't compile on windows
On 19.07.2011 15:29, Trass3r wrote: I built the fourth example (http://dsource.org/projects/gtkd/wiki/CodeExamples) using rdmd and it worked fine (regarding gtkD). (svn version of gtkD) There's a rdmd bug though. 'rdmd --build-only --chatty -I~/coding/gtkD/src/ -L-ldl test.d' doesn't directly work cause the .rsp file contains 'dmd'. But if you execute the command inside the .rsp it builds without problems. What is the command line? rdmd segfaults on me using this: c:\temprdmd --build-only --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- t.d -I. t.d.deps
Re: gtkD doesn't compile on windows
What is the command line? rdmd segfaults on me using this: c:\temprdmd --build-only --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- t.d -I. t.d.deps dmd -I~/coding/gtkD/src/ -L-ldl -v -o- 'test.d' -I'.' test.d.deps dmd '@/tmp/.rdmd/rdmd.6FC1F920EA8D2136FC5ECC4E5ED4404A.rsp' with rsp containing: dmd -I~/coding/gtkD/src/ -L-ldl -of/tmp/.rdmd/tmp/test.d.6FC1F920EA8D2136FC5ECC4E5ED4404A -od/tmp/.rdmd/rdmd-test.d-6FC1F920EA8D2136FC5ECC4E5ED4404A -I. test.d ~/coding/gtkD/src/gdk/Cursor.d ~/coding/gtkD/src/gtk/Widget.d ~/coding/gtkD/src/gtk/Label.d ~/coding/gtkD/src/atk/StateSet.d ~/coding/gtkD/src/pango/PgEngineShape.d ~/coding/gtkD/src/gdk/Drawable.d ~/coding/gtkD/src/gtkc/gobjecttypes.d ~/coding/gtkD/src/pango/PgAttributeIterator.d ~/coding/gtkD/src/pango/PgContext.d ~/coding/gtkD/src/gtk/TextBuffer.d ~/coding/gtkD/src/gtk/VBox.d ~/coding/gtkD/src/gtk/TextTag.d ~/coding/gtkD/src/gtk/Main.d ~/coding/gtkD/src/gtk/ActivatableT.d ~/coding/gtkD/src/gtk/Builder.d ~/coding/gtkD/src/gtk/Clipboard.d ~/coding/gtkD/src/gtk/Tooltips.d ~/coding/gtkD/src/glib/Module.d ~/coding/gtkD/src/glib/Quark.d ~/coding/gtkD/src/gtk/RcStyle.d ~/coding/gtkD/src/gtkc/pango.d ~/coding/gtkD/src/pango/PgFontMap.d ~/coding/gtkD/src/gobject/Type.d ~/coding/gtkD/src/gdk/Rectangle.d ~/coding/gtkD/src/gdk/Font.d ~/coding/gtkD/src/gtk/ButtonBox.d ~/coding/gtkD/src/gtkc/gio.d ~/coding/gtkD/src/gtk/BuildableT.d ~/coding/gtkD/src/pango/PgFontFace.d ~/coding/gtkD/src/atk/ObjectAtk.d ~/coding/gtkD/src/pango/PgCoverage.d ~/coding/gtkD/src/pango/PgTabArray.d ~/coding/gtkD/src/atk/Relation.d ~/coding/gtkD/src/gtkc/gdkpixbuf.d ~/coding/gtkD/src/glib/GException.d ~/coding/gtkD/src/pango/PgFontMetrics.d ~/coding/gtkD/src/pango/PgLanguage.d ~/coding/gtkD/src/gtk/BuildableIF.d ~/coding/gtkD/src/gobject/ObjectG.d ~/coding/gtkD/src/gdk/Pixmap.d ~/coding/gtkD/src/pango/PgEngine.d ~/coding/gtkD/src/gdkpixbuf/PixbufAnimationIter.d ~/coding/gtkD/src/gtk/Box.d ~/coding/gtkD/src/gtkc/gthread.d ~/coding/gtkD/src/pango/PgFontset.d ~/coding/gtkD/src/gobject/Signals.d ~/coding/gtkD/src/gdk/Region.d ~/coding/gtkD/src/pango/PgLayoutLine.d ~/coding/gtkD/src/gtkc/atktypes.d ~/coding/gtkD/src/gtk/AboutDialog.d ~/coding/gtkD/src/gdk/Window.d ~/coding/gtkD/src/gtk/IconSource.d ~/coding/gtkD/src/gobject/Closure.d ~/coding/gtkD/src/glib/ListG.d ~/coding/gtkD/src/gtk/Container.d ~/coding/gtkD/src/gtkc/gobject.d ~/coding/gtkD/src/gdk/Visual.d ~/coding/gtkD/src/gtk/Window.d ~/coding/gtkD/src/gobject/TypeModule.d ~/coding/gtkD/src/glib/ListSG.d ~/coding/gtkD/src/gdk/Color.d ~/coding/gtkD/src/gdk/Display.d ~/coding/gtkD/src/gobject/Value.d ~/coding/gtkD/src/gdk/Bitmap.d ~/coding/gtkD/src/gobject/TypePlugin.d ~/coding/gtkD/src/gtkc/gtktypes.d ~/coding/gtkD/src/pango/PgFontFamily.d ~/coding/gtkD/src/gdk/Event.d ~/coding/gtkD/src/gtkc/giotypes.d ~/coding/gtkD/src/gdk/ImageGdk.d ~/coding/gtkD/src/gtk/IconSet.d ~/coding/gtkD/src/gtkc/glibtypes.d ~/coding/gtkD/src/gdk/Colormap.d ~/coding/gtkD/src/gtkc/pangotypes.d ~/coding/gtkD/src/gdk/GC.d ~/coding/gtkD/src/glib/ScannerG.d ~/coding/gtkD/src/gtk/WindowGroup.d ~/coding/gtkD/src/pango/PgLayoutIter.d ~/coding/gtkD/src/gtkc/gtk.d ~/coding/gtkD/src/gdk/Pixbuf.d ~/coding/gtkD/src/gtkc/gthreadtypes.d ~/coding/gtkD/src/pango/PgMatrix.d ~/coding/gtkD/src/gthread/Mutex.d ~/coding/gtkD/src/gtkc/cairotypes.d ~/coding/gtkD/src/gobject/ParamSpec.d ~/coding/gtkD/src/gio/IconT.d ~/coding/gtkD/src/gtkc/paths.d ~/coding/gtkD/src/glib/PtrArray.d ~/coding/gtkD/src/pango/PgAttributeList.d ~/coding/gtkD/src/gtk/Bin.d ~/coding/gtkD/src/gtk/TextAttributes.d ~/coding/gtkD/src/glib/ErrorG.d ~/coding/gtkD/src/gthread/Thread.d ~/coding/gtkD/src/gtk/ObjectGtk.d ~/coding/gtkD/src/gdk/Threads.d ~/coding/gtkD/src/gtk/TextIter.d ~/coding/gtkD/src/gtk/TargetList.d ~/coding/gtkD/src/pango/PgAttribute.d ~/coding/gtkD/src/pango/PgGlyphString.d ~/coding/gtkD/src/gtk/ActivatableIF.d ~/coding/gtkD/src/cairo/FontOption.d ~/coding/gtkD/src/gtk/Style.d ~/coding/gtkD/src/pango/PgFontDescription.d ~/coding/gtkD/src/gio/Cancellable.d ~/coding/gtkD/src/gdkpixbuf/PixbufFormat.d ~/coding/gtkD/src/glib/ConstructionException.d ~/coding/gtkD/src/gtkc/Loader.d ~/coding/gtkD/src/gtkc/cairo.d ~/coding/gtkD/src/gtkc/atk.d ~/coding/gtkD/src/gtkc/gdktypes.d ~/coding/gtkD/src/gobject/Flags.d ~/coding/gtkD/src/gio/AsyncResultIF.d ~/coding/gtkD/src/gtk/AccelGroup.d ~/coding/gtkD/src/gtk/Image.d ~/coding/gtkD/src/gtk/Action.d ~/coding/gtkD/src/gtk/Dialog.d ~/coding/gtkD/src/gtk/TextChildAnchor.d ~/coding/gtkD/src/gtk/VButtonBox.d ~/coding/gtkD/src/gtkc/gdk.d ~/coding/gtkD/src/gtkc/glib.d ~/coding/gtkD/src/gtk/TextTagTable.d ~/coding/gtkD/src/glib/MainContext.d ~/coding/gtkD/src/gio/Icon.d ~/coding/gtkD/src/pango/PgFont.d ~/coding/gtkD/src/glib/Str.d ~/coding/gtkD/src/gtkc/gdkpixbuftypes.d ~/coding/gtkD/src/gtk/OrientableT.d
Re: gtkD doesn't compile on windows
On 19.07.2011 15:53, Trass3r wrote: What is the command line? rdmd segfaults on me using this: c:\temprdmd --build-only --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- t.d -I. t.d.deps dmd -I~/coding/gtkD/src/ -L-ldl -v -o- 'test.d' -I'.' test.d.deps dmd '@/tmp/.rdmd/rdmd.6FC1F920EA8D2136FC5ECC4E5ED4404A.rsp' with rsp containing: (...) So your command line is simply rdmd --build-only --chatty -I\d\ext\gtkd\src -L-ldl t.d? rdmd calls dmd -I\d\ext\gtkd\src -L-ldl -v -o- t.d -I. t.d.deps, and then segfaults (win7x64).
Re: gtkD doesn't compile on windows
simendsjo Wrote: Giving up on qtD, I tried gtkD. Not much luck there either. As I've spent most of my day trying to compile qt, I'm not really in the mood to spend many hours trying to get gtk working. Is anybody actually using D for GUI development on Windows at all..? I use DFL, but that was mostly because I didn't want to depend on QT or GTK. But even DFL needs updates for the latest compiler and I haven't forked and pushed those I've made.
Re: gtkD doesn't compile on windows
So your command line is simply rdmd --build-only --chatty -I\d\ext\gtkd\src -L-ldl t.d? Yes, and in theory that would be enough. (if it didn't put 'dmd' in the .rsp) rdmd calls dmd -I\d\ext\gtkd\src -L-ldl -v -o- t.d -I. t.d.deps, and then segfaults (win7x64). Doesn't segfault on Linux x64. You should compile a debug version of rdmd and see if you get a stacktrace. github.com/D-Programming-Language/tools
Up to date win32 bindings / d wrappers
There are several bindings for win32, but some seems quite dead. Juno - last updated 2009 http://dsource.org/projects/juno Bindings - last updated 2011 http://dsource.org/projects/bindings/wiki/WindowsApi Core32 - last updated 2009 http://dsource.org/projects/core32 Seems limited and outdated DWindowsProgramming - last updated 2011 https://github.com/AndrejMitrovic/DWindowsProgramming/tree/master/win32 Druntime https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/windows.d Am I missing some projects? Does anyone know how complete/usable these bindings are? Compiles with newer dmd versions?
Re: gtkD doesn't compile on windows
On 19.07.2011 16:19, Trass3r wrote: So your command line is simply rdmd --build-only --chatty -I\d\ext\gtkd\src -L-ldl t.d? Yes, and in theory that would be enough. (if it didn't put 'dmd' in the .rsp) rdmd calls dmd -I\d\ext\gtkd\src -L-ldl -v -o- t.d -I. t.d.deps, and then segfaults (win7x64). Doesn't segfault on Linux x64. You should compile a debug version of rdmd and see if you get a stacktrace. github.com/D-Programming-Language/tools I haven't found the bug, but compiling without optimizing doesn't crash it: c:\temprdmd --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- t.d -I. t.d.deps dmd @C:\Users\simen\AppData\Local\Temp\.rdmd\rdmd.0B610F9A43C84525CA4F687638D0E F2B.rsp Error: cannot read file dmd.d dmd.d...?
Re: gtkD doesn't compile on windows
dmd.d...? That's what I was talking about. it calls dmd @...rsp and rsp contains dmd again. So it in fact calls dmd dmd ... We should really get rid of the response file crap and call dmd directly. This would also clean up rdmd --dry-run
Re: gtkD doesn't compile on windows
On 19.07.2011 17:23, simendsjo wrote: I removed compiler from todo = compiler ~ ... (two places) in rebuild() and added the compiler name to the later run() instead. Solves the problem. Sorry I haven't made a pull request for rdmd; I have never used git before. Seems I could use github direcly: https://github.com/D-Programming-Language/tools/pull/3
Re: gtkD doesn't compile on windows
The -L-ldl isn't recognized by optlink. OPTLINK : Warning 9: Unknown Option : LDL What's the equivalent? I think you don't need it on Windows. But according to the demo dsss.conf files you might need -lladvapi32 Might also be -L-Ladvapi32. It tries to pick up zlib1.dll from my Intel WiFi program folder, and I cannot find it in the gtk or dmd folders. Yep, it's installed system-wide on Linux.
Re: gtkD doesn't compile on windows
Seems I could use github direcly: https://github.com/D-Programming-Language/tools/pull/3 Thanks! But we should really also try to track down why rdmd crashes on Windows.
Re: gtkD doesn't compile on windows
On 19.07.2011 17:30, Trass3r wrote: The -L-ldl isn't recognized by optlink. OPTLINK : Warning 9: Unknown Option : LDL What's the equivalent? I think you don't need it on Windows. But according to the demo dsss.conf files you might need -lladvapi32 Might also be -L-Ladvapi32. It tries to pick up zlib1.dll from my Intel WiFi program folder, and I cannot find it in the gtk or dmd folders. Yep, it's installed system-wide on Linux. Downloaded from zlib.net, and the sample works now. Thanks! There is something wrong with either dmd or rdmd though.. If I compile rdmd (with my patch, haven't tried the original) without -g, it crashes when trying to compile anything...
Re: gtkD doesn't compile on windows
There is something wrong with either dmd or rdmd though.. If I compile rdmd (with my patch, haven't tried the original) without -g, it crashes when trying to compile anything... Does this also happen if you compile it with -g and then run cv2pdb on it?
Re: gtkD doesn't compile on windows
On 19.07.2011 17:53, Trass3r wrote: There is something wrong with either dmd or rdmd though.. If I compile rdmd (with my patch, haven't tried the original) without -g, it crashes when trying to compile anything... Does this also happen if you compile it with -g and then run cv2pdb on it? I cannot compile anything without first compiling rdmd with -g. Compiling rdmd with -g and running cv2pdb on it works.
Re: gtkD doesn't compile on windows
On 07/19/2011 03:21 PM, simendsjo wrote: On 19.07.2011 15:12, Trass3r wrote: atk = DD-atk DD-atk_static.rf: No such file or directory dsss should generate this file. Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool? No verbose flag. What other build tool? dsss uses -v for verbose output. rdmd still doesn't understand subfolders on windows, and it doesn't give good error messages: c:\d\ext\gtkd\demos\gtkrdmd -v HelloWorld.d Failed: dmd -v -v -o- HelloWorld.d -I. HelloWorld.d.deps The dmd command works, so it's rdmd that fails. -- Mike Wey
D and MySQL
I do quite a bit of work with MySQL. I can't seem to find any information on how to use D with MySQL. Is there a tutorial or example around that someone can point me to?
Re: std.concurrency.spawn does not accept delegates
On 2011-07-19 05:40, Steven Schveighoffer wrote: On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On 2011-07-18 15:15, teo wrote: On Mon, 18 Jul 2011 18:14:45 +, Jonathan M Davis wrote: On 2011-07-18 10:54, Simen Kjaeraas wrote: On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: On Monday 18 July 2011 15:55:52 teo wrote: On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote: On Sun, 17 Jul 2011 15:29:02 -0400, teo teo.ubu...@yahoo.com wrote: It looks like std.concurrency.spawn does not accept delegates. Is there any reason for that? There is no type attached to the hidden 'this' pointer. So spawn cannot guarantee it doesn't point to unshared data. -Steve Bad. I tried to pass as an argument a pointer to an instance of a class - a this pointer. That didn't work. Only stuff that's immutable or implicitly convertible immutable can be passed across threads using spawn and send. Otherwise, there's a risk of it ending up getting altered by both threads (or altered by one when the other one is using at it). Sometimes, that can be a bit restrictive (particularly when you _know_ that something isn't going to be altered by the thread sending it after its sent but the compiler doesn't), but it avoids all kinds of problems. If you want to send a class object across, then it needs to be immutable (which tends to be a bit of a pain to do for classes, since they need to have an immutable constructor, which is often a pain to do). It could be that assumeUnique should handle this, by transforming the delegate into something spawn() and friends could handle. Might be worth an enhancement request. There have been discussions about how to do it in the past. Whether assumeUnique will work depends on whether casting to immutable(C) will work (where C is the class' type), and I don't know whether that cast will work or not. If it does, then assumeUnique will do it, since all it does is cast to immutable, but it's the sort of thing that requires language support. There _might_ be a way to solve the problem with some sort of Unique template that spawn and send knew about, but nothing of the sort has been done yet. But until a number of the issues with const and immutable in the compiler have been sorted out, that sort of thing would probably be problematic anyway. - Jonathan M Davis This is a bit too restrictive in my opinion. Only the shared data between two threads should be immutable. But the threads can access all sorts of mutable data as well. And in this case we are actually talking about the control function (or start routine) of a thread. As long as it's address is fixed within the memory of a process its usage for that purpose should be fine. Nobody is going to pass that address around. Am I missing anything here? When passing data between threads, it must be immutable. I have to jump in and correct you, nobody else has. You can also pass data marked as shared. A solution could be to cast the class as shared, pass it, then cast it back to unshared (ensuring you don't access the class from the originator anymore). This is not a compiler-enforced solution, but it gets the job done. But there is risk of concurrency errors if you don't do it right. My recommendation is to isolate the parts that create and pass the shared data. I thought that spawn and send disallowed shared and that you had to deal with shared separately, but if that's not the case, then that's not the case. Regardless, you can't just pass anything with spawn or send (as the OP seems to be trying to do). They have restrictions to avoid concurrency bugs. - Jonathan M Davis
Re: D and MySQL
http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings There is some information, but it's probably outdated. Please update that wiki once you know more :) Apart from that I only know of this binding: http://dsource.org/projects/ddbi
Re: D and MySQL
I wrapped the libmysql C library in D and use it in a lot
of my apps.
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
Grab database.d and mysql.d from there.
To use it:
===
import arsd.mysql;
void main() {
auto mysql = new MySql(localhost, username, password, database name);
// ? based placeholders do conversion and escaping for you
foreach(line; mysql.query(select id, name from users where id ?, 5)) {
// access to columns by name
writefln(%s: %s, line[id], line[name]);
// alternatively, you can write:
writefln(%s: %s, line[0], line[1]);
}
}
===
There's a lot of other stuff in there too, which I'll
write up in the next week or so... but this is the basics of it.
Re: gtkD doesn't compile on windows
I cannot compile anything without first compiling rdmd with -g. Compiling rdmd with -g and running cv2pdb on it works. Really strange. If we just had a stack trace.
Re: D and MySQL
Am 19.07.2011, 20:49 Uhr, schrieb Adam Ruppe destructiona...@gmail.com:
foreach(line; mysql.query(select id, name from users where id ?,
5)) {
// access to columns by name
writefln(%s: %s, line[id], line[name]);
// alternatively, you can write:
writefln(%s: %s, line[0], line[1]);
}
I guess access via opDispatch would also be nice to have?!
Re: D and MySQL
Trass3r wrote:
I guess access via opDispatch would also be nice to have?!
Use mysql.queryDataObject() for that.
foreach(line; mysql.queryDataObject(...rest is the same...) {
writeln(line.id, line.name);
//line[id]
//line[name]
}
all work. But with the DataObject, you don't have integer indexes.
You can also foreach(name, value; line) to go over the returned fields, just
like
with an associative array.
What you gain though is write support:
line.name = something else;
line.commitChanges(); // does an update
You can also create new DataObjects:
auto obj = new DataObject(mysql, users);
obj.id = 10;
obj.name = My Name;
obj.commitChanges(); // does a select. if empty, inserts. if not, updates.
The DataObject is found in database.d - it is meant to work generically with any
database backend.
Re: gtkD doesn't compile on windows
On 19.07.2011 20:01, Mike Wey wrote: On 07/19/2011 03:21 PM, simendsjo wrote: On 19.07.2011 15:12, Trass3r wrote: atk = DD-atk DD-atk_static.rf: No such file or directory dsss should generate this file. But it doesn't. Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool? No verbose flag. What other build tool? dsss uses -v for verbose output. Unrecognized argument: -v rdmd still doesn't understand subfolders on windows, and it doesn't give good error messages: c:\d\ext\gtkd\demos\gtkrdmd -v HelloWorld.d Failed: dmd -v -v -o- HelloWorld.d -I. HelloWorld.d.deps The dmd command works, so it's rdmd that fails.
