Re: Darwin 32 release broken (in uni.d)
On 2013-08-12 15:57, monarch_dodra wrote: It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead? It should be reverted now. I change the compiler from GCC to Clang, apparently that didn't work out. Walter did fix a bunch of warnings tough :) -- /Jacob Carlborg
Re: Darwin 32 release broken (in uni.d)
On Tuesday, 13 August 2013 at 04:39:11 UTC, Dmitry Olshansky wrote: 12-Aug-2013 17:57, monarch_dodra пишет: It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead? That's right but ... In the phobos mailing list next time :) Right... I'll do that next time. On Tuesday, 13 August 2013 at 06:37:28 UTC, Jacob Carlborg wrote: On 2013-08-12 15:57, monarch_dodra wrote: It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead? It should be reverted now. I change the compiler from GCC to Clang, apparently that didn't work out. Walter did fix a bunch of warnings tough :) Cool. Thanks for the feedback. I closed the ticket then.
Re: glad OpenGL loader generator
Am 13.08.2013 05:51, schrieb evilrat: On Monday, 12 August 2013 at 13:45:46 UTC, David wrote: Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX. no no, i don't want use other opengl bindings right now, derelict just fine, but i need some good(public available) math lib to put in my examples, and the problem is that gl3n compiles as 32 bit(-m32) on OS X(i use it because i don't have PC and i don't know when i would have it) by default and there seems no way to remove this misbehavior :( This shouldn't happen and doesn't happen for me. Easiest way to use gl3n (and also what I recommend) is to use it as git submodule or simply copy the sources into your project and integrate it into your buildsystem.
Re: stop to maitain rpm
On Monday, 12 August 2013 at 13:46:52 UTC, David wrote: I don't know how it is for other distros, but the newest dmd and ldc version are available in the Archlinux's [community] repository while gdc and dub are available in the AUR, meaning you get a fully working D environment on Archlinux by doing LDC is in [community] already Um, that is what I wrote, isn't it? , and iirc Dicebot is working on getting GDC into [community], too Yes, I currently maintain the gdc-git package in AUR and he contacted me about getting it into [community]. But since gdc-git is a development package based on gcc 4.9 instead of gcc 4.8 (like current Arch [core] gcc), I made a seperate package gdc (also available in the AUR atm) for that purpose. I believe that when he's done with the PGP key issue and has looked the PGKBUILD for the gdc package over he'll adopt the gdc package into [community], at which point it'll be removed from the AUR.
Re: glad OpenGL loader generator
On Tuesday, 13 August 2013 at 10:41:49 UTC, David wrote: This shouldn't happen and doesn't happen for me. Easiest way to use gl3n (and also what I recommend) is to use it as git submodule or simply copy the sources into your project and integrate it into your buildsystem. ok thanks, i'll try later.
Re: glad OpenGL loader generator
glad now supports also EGL, GLX and WGL
Re: Parameter-less templates?
2013/8/13 monarch_dodra monarchdo...@gmail.com
Related: I have encountered this problem, and I can't seem to work around
it; *other* than non-parameterized templates. Basically, I have this pred
function, we'll call it foo. This pred function can itself be
parameterized to take its own (optional) pred. This basically allows:
foo(a, b)
or
foo!pred(a, b)
This is traditionally solved by doing:
void foo(A, B)(A a, B b);
void foo(alias pred, A, B)(A a, B b);
Here is the kicker though: foo is itself a pred. This means that I
*need* to be able to pass foo!pred as a predicate. This does not work, as
foo!pred is nothing: The compiler doesn't know what you are talking
about, as the parameters A and B are missing. This is usually solved by a
template:
template foo(alias pred)
{
void foo(A, B)(A a, B b);
}
This works *however* the presence of the void foo(A, B)(A a, B b);
confuses the crap out of the compiler:
foo(a, b); //OK
alias PRED = foo!hello;
PRED(a, b); //OK
BUT:
foo!hello(a, b); //Error:
Error: template hello.foo does not match any function template
declaration. Candidates are:
hello.foo(R1, R2)(R1 r1, R2 r2)
hello.foo(alias pred)
Error: template hello.foo(R1, R2)(R1 r1, R2 r2) cannot deduce template
function from argument types !(hello)(int, int)
Error: template instance foo!hello errors instantiating template
So... how to make this work? AFAIK, non-parameterized templates should
solve it. Or is it just a compiler issue?
FYI: This is a problem present in Phobos. You can use:
equal!equal(RoR1, RoR2)
To compare two ranges of ranges. equal!equal gets instanciated, because
the args are present to finish the missing R1/R2 args after pred.
However, this neat trick stop there:
equal!(equal!equal)(RoRoR1, RoRoR2)
This time, this does not work, as the compiler can't resolve the predicate.
I'd like to solve this. IMO equal!equal is one of the neatest 1-word
in D, and I want to make sure it works as one would expect it to.
So: Any workaround recommendations? Alternatives? Thoughts on
parameter-less templates (regardless of my issue)?
Maybe: http://d.puremagic.com/issues/show_bug.cgi?id=10811
Kenji Hara
Re: deimos libx11 license
On 8/12/2013 10:41 PM, luminousone wrote: The original license of Xlib I am pretty sure is the x11 license, any idea who the maintainer of the libx11 deimos project is, The contributors to each commit are listed on github - you should be able to contact them. The Deimos project files should be nothing more than the declarations necessary to connect D code to the library. I think it's been settled that a list of declarations is not copyrightable, as I recall Linux settled that. Where you start getting into trouble is if you copy the comments and creative elements.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 2013-08-13 02:42, Andrei Alexandrescu wrote: Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin? I don't see why we couldn't do that. It's a completely separate tool and shouldn't infect anything else. We might need to accompany it with a license file and a link to the source code to be on the safe side. -- /Jacob Carlborg
Re: Request for editor scripting help
On Friday, 9 August 2013 at 06:41:10 UTC, Brian Schott wrote: I've been making some progress on a project called DCD[1], which is D's answer to Go's Gocode[2]. It's a command-line client/server autocompletion program for D built off the same lexer/parser/ast code that powers DScanner. I'd like to get some help writing integration scripts for the editors that I don't use such as Vim, Emacs, Sublime, and of course your favorite that I left off the list. If you have experience scripting your text editor of choice and some spare time to play with new and unstable software, please consider creating a pull request. [1] https://github.com/Hackerpilot/DCD [2] https://github.com/nsf/gocode How hard would it be for dcd to offer completion based on line and column numbers instead of byte offsets?
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 2013-08-11 23:35, Anon wrote: Does pragma(lib, curl) not work on Windows/DMD? I know it does in Linux (used in DMD and LDC, ignored under GDC), and was under the impression that that was the portable way to use pragma(lib). No, it's not portable. Example, libraries on Posix are usually named libfoo.a, on Windows they're named foo.lib. As far as I know that is not handled by pragma(lib). -- /Jacob Carlborg
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 2013-08-10 20:35, Nick Sabalausky wrote: Although it took longer than I expected to get around to it, I'm working on a release-generator tool for DMD. I'm finding that a very significant amount of the effort involved (much more than I expected) is discovering and dealing with all the fun little differences between the posix and win32 makefiles (and now we have some win64 makefiles as well). Efforts can be made to decrease these differences, but simply having them separate makefiles in the first place (let alone using completely different makes: GNU make vs DM make) is a natural invitation for divergence. No disrespect intended to Digital Mars Make, but since GNU make appears to be more feature-rich, have wider overall adoption, and is freely available on Windows as a pre-built binary http://gnuwin32.sourceforge.net/packages/make.htm: Would it be acceptable to use gmake as *the* make for DMD? Ie, either convert the windows makefiles to gmake, or expand the posix makefiles to support windows? I'd be willing to give it a shot myself, and I could trivially write a small batch utility to download Win gmake and put it on the current PATH, so that nobody has to go downloading/installing it manually. I would do this *after* finishing the release-generator tool, but afterwords it would allow the tool's implantation to be greatly simplified. Is this something that would be acceptable, or does building DMD for Windows need to stay as DM make? This might not be entirely related to the DMD makefiles but with the druntime and Phobos makefiles I really hate that if I need to add a new module I need to repeat the name several times. So whatever happens to the makefiles, I would prefer that the files that should be compiled shouldn't have to be mentioned at all (or at most once). I just compile everything in a directory with the correct extensions. -- /Jacob Carlborg
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 2013-08-12 00:38, H. S. Teoh wrote: Maybe my previous post didn't get the idea across clearly, so let me try again. My underlying thrust was: instead of maintaining 3 different makefiles (or more) by hand, have a single source for all of them, and write a small D program to generate posix.mak, win32.mak, win64.mak, whatever, from that source. If it's written in D it will have the same bootstrap problem. But perhaps that's ok since we're moving DMD to D anyway. -- /Jacob Carlborg
Re: Request for editor scripting help
On Tuesday, 13 August 2013 at 06:58:23 UTC, Tobias Pankrath wrote: How hard would it be for dcd to offer completion based on line and column numbers instead of byte offsets? It's more code to maintain, but it's possible. The token structure stores its line and column. https://github.com/Hackerpilot/Dscanner/blob/master/stdx/d/lexer.d#L129
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 2013-08-12 20:06, Russel Winder wrote: This is where Waf has a benefit. SCons can put the build system with the project leaving only a Python dependency, but Waf is built for this mode of working. Why don't they embed Python inside SCons, at least as an option. -- /Jacob Carlborg
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Sunday, August 11, 2013 13:36:54 Walter Bright wrote: On the subject of friction, I believe we make a mistake by making a dependency on libcurl, a library over which we don't have control. Some issues: http://d.puremagic.com/issues/show_bug.cgi?id=10710 http://d.puremagic.com/issues/show_bug.cgi?id=8756 Of course, if having libcurl in Phobos is causing enough problems, that raises the question as to whether we should reverse our decision to include it in Phobos. That would of course create it's own set of problems, because it would break existing code, but it would be trivial enough to change such code to import a separate library rather than std.net.curl if we decided that including it in Phobos was causing enough problems that it wasn't worth it and moved std.net.curl to somewhere else outside of Phobos. - Jonathan M Davis
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 2013-08-12 21:03, Sean Kelly wrote: I suppose std.zip is in the same boat. Not entirely, since we include the source code for libz. -- /Jacob Carlborg
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Monday, 12 August 2013 at 16:29:36 UTC, H. S. Teoh wrote: On Mon, Aug 12, 2013 at 11:16:19AM +0100, Russel Winder wrote: On Sun, 2013-08-11 at 15:41 -0700, H. S. Teoh wrote: On Sun, Aug 11, 2013 at 09:26:11AM +0100, Russel Winder wrote: On Sat, 2013-08-10 at 14:27 -0400, Nick Sabalausky wrote: […] is discovering and dealing with all the fun little differences between the posix and win32 makefiles (and now we have some win64 makefiles as well). […] Isn't this sort of problem solved by using SCons, Waf or (if you really have to) CMake? [...] +1. But people around here seems to have a beef against anything that isn't make. *shrug* Make was a revolution and a revelation in 1977, it changed my life. However, it is sad to see projects such as Rust, Julia and D clinging to a 35 year old build concept when it has been proved time and time again that external DSL frameworks for build do not work for cross-platform working. Only internal DSL build frameworks have succeeded in that arena, cf. Gradle, SBT, SCons, Waf,… +1. If I were the one making the decisions, I'd go for SCons. Or tup (http://gittup.org/tup/), but tup seems to be currently posix-specific, so SCons still wins if you want cross-platform building. The only part of this thread that has any up side at all is to ditch all build frameworks and write the build in D over the bootstrap D that will be essential for the D build since D is written in D. It's a pity Rust hasn't twigged to this. I think the D build tool should extend / be built on top of rdmd to be able to handle non-D sources. Once we have that, we basically already have a working build system. I note that the Go tooling is written is C and Go, they ditched make when they realized their vision for packaging – which works very well indeed, particularly pulling in source packages from GitHub, BitBucket and Launchpad, compiling and installing the compiled package into the appropriate place for use. I ditched make about a decade ago, and I would never go back if I had the choice. Sadly, most of the rest of the world still seems stuck in that quagmirem, unable to move on. On the other hand, I bet a cross-platform SCons build of D could be in place and production within days as opposed to the substitute-your-favourite-long-time that a D rewrite in D will take. It doesn't matter than the SCons build may be thrown away down the line, it solves a problem now for not that much effort. What do you say? Let's throw together an SConstruct for DMD, druntime, and phobos, and submit a pull for it? The only downside is that I can predict people will start complaining about the Python dependency. (Which is why I proposed writing a build system in D -- it will be superior to make (anything would be!), and people will have no excuse about what language it's written in.) Still if the core D community are clinging to build == make, then they will have to suffer the irritant of having to have a separate build system for each and every platform. That's they way Make is. [...] I used to evangelize SCons to everybody I meet... but after people adamantly refused to abandon their precious outdated crappy makefiles, I gave up. If they wish to continue suffering, it's not really my business to stop them. T Thanks for the link! I found this excellent paper there: http://gittup.org/tup/build_system_rules_and_algorithms.pdf . :)
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Monday, 12 August 2013 at 16:29:36 UTC, H. S. Teoh wrote: On Mon, Aug 12, 2013 at 11:16:19AM +0100, Russel Winder wrote: On Sun, 2013-08-11 at 15:41 -0700, H. S. Teoh wrote: On Sun, Aug 11, 2013 at 09:26:11AM +0100, Russel Winder wrote: On Sat, 2013-08-10 at 14:27 -0400, Nick Sabalausky wrote: […] is discovering and dealing with all the fun little differences between the posix and win32 makefiles (and now we have some win64 makefiles as well). […] Isn't this sort of problem solved by using SCons, Waf or (if you really have to) CMake? [...] +1. But people around here seems to have a beef against anything that isn't make. *shrug* Make was a revolution and a revelation in 1977, it changed my life. However, it is sad to see projects such as Rust, Julia and D clinging to a 35 year old build concept when it has been proved time and time again that external DSL frameworks for build do not work for cross-platform working. Only internal DSL build frameworks have succeeded in that arena, cf. Gradle, SBT, SCons, Waf,… +1. If I were the one making the decisions, I'd go for SCons. Or tup (http://gittup.org/tup/), but tup seems to be currently posix-specific, so SCons still wins if you want cross-platform building. The only part of this thread that has any up side at all is to ditch all build frameworks and write the build in D over the bootstrap D that will be essential for the D build since D is written in D. It's a pity Rust hasn't twigged to this. I think the D build tool should extend / be built on top of rdmd to be able to handle non-D sources. Once we have that, we basically already have a working build system. I note that the Go tooling is written is C and Go, they ditched make when they realized their vision for packaging – which works very well indeed, particularly pulling in source packages from GitHub, BitBucket and Launchpad, compiling and installing the compiled package into the appropriate place for use. I ditched make about a decade ago, and I would never go back if I had the choice. Sadly, most of the rest of the world still seems stuck in that quagmirem, unable to move on. On the other hand, I bet a cross-platform SCons build of D could be in place and production within days as opposed to the substitute-your-favourite-long-time that a D rewrite in D will take. It doesn't matter than the SCons build may be thrown away down the line, it solves a problem now for not that much effort. What do you say? Let's throw together an SConstruct for DMD, druntime, and phobos, and submit a pull for it? The only downside is that I can predict people will start complaining about the Python dependency. (Which is why I proposed writing a build system in D -- it will be superior to make (anything would be!), and people will have no excuse about what language it's written in.) Still if the core D community are clinging to build == make, then they will have to suffer the irritant of having to have a separate build system for each and every platform. That's they way Make is. [...] I used to evangelize SCons to everybody I meet... but after people adamantly refused to abandon their precious outdated crappy makefiles, I gave up. If they wish to continue suffering, it's not really my business to stop them. I am one of them. In my real life I use Maven most of the time, but for absolutely everything else, including (small/toy) Java projects, I use GNU Make. I know it is does not really matter to many people, but honestly, Make exists on EVERY platform I have ever tried. We have OpenVMS servers here for an example. Guess what, make works like a charm there, and everybody knows (more/less) how to use it. :)
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 8/12/2013 11:48 PM, Jacob Carlborg wrote: On 2013-08-13 02:42, Andrei Alexandrescu wrote: Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin? I don't see why we couldn't do that. It's a completely separate tool and shouldn't infect anything else. We might need to accompany it with a license file and a link to the source code to be on the safe side. Again, read my reply to Brad in this thread.
Re: Parameter-less templates?
On Tuesday, 13 August 2013 at 01:08:01 UTC, deadalnix wrote:
On Monday, 12 August 2013 at 19:03:41 UTC, monarch_dodra wrote:
D has introduced a pretty cool tool: templates. These are
basically namespaces that can be instantiated by a type/alias.
Mixing with them the notion of eponymous allows to do some
seriously cool things with them.
One of the things I find strange though is that they *must* be
parameterized.
Yes and no.
void foo()() {} is a parameter-less template.
As the construct already exists at semantic level, I guess
making it available everywhere is the way to go.
I think strictly speaking, that is a parameterless parameterized
function, as opposed to a non parameterized function.
In regards to template (I mean the actual template), I guess I
wish we could either:
1. Allow non-parameterized templates (eg template foo {...})
2. Allow invoking a template without parameters (provided the
template has 0 parameters, or default parameters), without doing
!()
But yeah, I think I agree with you, that it should be made
available everywhere.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote: On Monday, 12 August 2013 at 18:57:12 UTC, Chris wrote: On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: unless it's a very specific thing like web development where PHP etc are handier. D rox for webdev too :) Only downside is it isn't pre-installed like php tends to be, but it still rox. Hehe, sometimes I have the feeling that PHP is only language that does _not_ rock for webdev :) Well, probably with the exception of Brainfuck. No sure about latter though. PHP is terrible. The fact that you have to mark variables with $ is simply ridiculous. PHP is not very exciting. But it does the job. Alas, why do the mediocre solutions always find acceptance? Rewind history back to early 2000 and you'll understand. At the time, PHP was the best solution (which says more about how bad the situation was than how great PHP was :D). True, true. There weren't many options back in the day. But that's no excuse for bad or absurd language design. $asolutely $no $need $to $have $a $syntax $like $this = At least it does its job ok.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote: On 8/12/2013 11:48 PM, Jacob Carlborg wrote: On 2013-08-13 02:42, Andrei Alexandrescu wrote: Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin? I don't see why we couldn't do that. It's a completely separate tool and shouldn't infect anything else. We might need to accompany it with a license file and a link to the source code to be on the safe side. Again, read my reply to Brad in this thread. Presumably you are referring to this quote, which does not show up as a reply? Oh, I forgot to mention, licensing. We want Phobos to be free of any restrictive licensing. GPL is restrictive, and so is LGPL. We very deliberately picked Boost. Having Phobos be a mix of GPL and Boost would utterly defeat picking Boost. If you're only talking about distributing a GPL-licensed gmake binary with dmd/phobos, I don't think it has any impact on Phobos licensing, ie the GPL would only apply to the gmake binary. The GPL is a very badly written license, but I think it has been generally established that you can distribute tools like gmake or g++ with your own code and that doesn't make your own code have to be GPL, as long as gmake/g++ are only used to process/compile your code and your own code doesn't integrate the source for gmake/g++, ie gdc, which is almost never the case. Personally, I like the D-based build system idea. Distribute dmd/phobos with a D-based build tool like dub, which has been compiled ahead of time for each supported platform and will compile D for you, if you want. Of course, this means that you'll still need to maintain makefiles on the D build machines that will build dub for the D maintainers to distribute, but it isolates all the complexity of makefiles from end users, so they don't have to touch any of that stuff. Whether that ease of use is worth the extra effort, I don't know.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 13 August 2013 10:55, Joakim joa...@airpost.net wrote: On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote: On 8/12/2013 11:48 PM, Jacob Carlborg wrote: On 2013-08-13 02:42, Andrei Alexandrescu wrote: Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin? I don't see why we couldn't do that. It's a completely separate tool and shouldn't infect anything else. We might need to accompany it with a license file and a link to the source code to be on the safe side. Again, read my reply to Brad in this thread. Presumably you are referring to this quote, which does not show up as a reply? Oh, I forgot to mention, licensing. We want Phobos to be free of any restrictive licensing. GPL is restrictive, and so is LGPL. We very deliberately picked Boost. Having Phobos be a mix of GPL and Boost would utterly defeat picking Boost. If you're only talking about distributing a GPL-licensed gmake binary with dmd/phobos, I don't think it has any impact on Phobos licensing, ie the GPL would only apply to the gmake binary. The GPL is a very badly written license, but I think it has been generally established that you can distribute tools like gmake or g++ with your own code and that doesn't make your own code have to be GPL, as long as gmake/g++ are only used to process/compile your code and your own code doesn't integrate the source for gmake/g++, ie gdc, which is almost never the case. Pardon? (I don't understand what point you are trying to put across about gdc, so I think it might be wrong ;-) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, 2013-08-13 at 09:09 +0200, Jacob Carlborg wrote: On 2013-08-12 20:06, Russel Winder wrote: This is where Waf has a benefit. SCons can put the build system with the project leaving only a Python dependency, but Waf is built for this mode of working. Why don't they embed Python inside SCons, at least as an option. SCons is a Python application and so is normally installed in the Python installation. I am sure there could be a Windows installer created, but I guess most Windows people use Visual Studio (*). No package-based system really needs Python shipped with SCons as it is so trivial to install Python and then SCons. OS X comes with Python pre-installed, though it is an old version (**). The reality here is that most major Fortran, C and C++ places are either politically opposed to Python, or are already using it. The former are incapable of using SCons and the latter would get annoyed by another Python installation when they already have one. Most HPC places are using SciPy, most banks now use Python, most engineering places are using Python. (*) SCons can create Visual Studio projects. (**) Anyone using Python earlier than 2.7 is either contractually obliged or nuts. Most sensible folk are already using Python 3.3 or rapidly moving towards it. SCons sadly is not Python 3 compatible. At least not yet, but there are plans. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.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: qtD
On Tue, 2013-08-13 at 05:11 +0200, michaelc37 wrote: […] patched the make file for ldc2, but ran into a problem during compile with Atomic.d. Your changes are better than mine so I ditched mine. I think the llvm_memory_barrier function no longer exists. I found and tried to apply fixes from a patch made to tango's Atomic.d http://www.dsource.org/projects/tango/attachment/ticket/2101/llvm3.atomic.patch), ended up with a compile error that made no sense to me Error: Integer constant expression expected instead of ordering AtomicOrdering ordering = getOrdering(ms == msync.rel ? msync.seq : ms); ... ... llvm_atomic_store!(T)(cast(T)newval, cast(shared T*)val, ordering); I don't think I got that far as I got a Can't find the D compiler problem. It seems the build rebuilds the build in some way but fails. :-(( Classes in typesystem: 538 Generated: - d.: 529 (529) - cpp-impl..: 506 (506) - cpp-h.: 399 (399) - meta-info.: 28 (28) - pri...: 7 (7) Done, 344 warnings (577 known issues) [100%] Built target dgen Scanning dependencies of target main -- The CXX compiler identification is GNU 4.8.1 -- The C compiler identification is GNU 4.8.1 -- Check for working CXX compiler: /home/users/russel/bin.Linux.x86_64/c++ -- Check for working CXX compiler: /home/users/russel/bin.Linux.x86_64/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working C compiler: /home/users/russel/bin.Linux.x86_64/gcc -- Check for working C compiler: /home/users/russel/bin.Linux.x86_64/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done CMake Error at cmake/FindD.cmake:41 (message): D compiler is not found Call Stack (most recent call first): CMakeLists.txt:180 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! make[2]: *** [main] Error 1 make[1]: *** [CMakeFiles/main.dir/all] Error 2 make: *** [all] Error 2 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.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: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tuesday, 13 August 2013 at 06:56:11 UTC, Jacob Carlborg wrote: No, it's not portable. Example, libraries on Posix are usually named libfoo.a, on Windows they're named foo.lib. As far as I know that is not handled by pragma(lib). Yes, it is. pragma(lib, foo) works on both systems. It passes the name foo to the linker, which knows about the cross platform differences. I use it all the time on Windows and Linux without any problems. The problem people have with pragma(lib) is that gdc's architecture doesn't allow it; the front end in gcc can't pass an argument to the linker, and also that separate compilation with any compiler doesn't pass the pragma (its instruction is only in the .d file, not the .o). I don't see this as a problem with the feature - it doesn't have to work in every case to be very useful. worst case, if it doesn't work, you're just doing it the way you would anyway. Even so, however, pragma(lib) can still serve to document the fact that the library is required. In summary, pragma(lib) is great and you can have it when you pry it from my cold, dead hands.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tuesday, 13 August 2013 at 05:05:35 UTC, Jonathan M Davis wrote: (though it loses its history if you change to a different tty) Yeah, though there's an easy solution here too: gnu screen! Though shift+pageup doesn't quite work even there, if you change ttys it does clear that buffer, but screen's own scrollback is still there, hit C-a [ to go into copy mode and you can scroll around it). There are some minor bugs with screen and gpm (the text mode mouse driver), but overall it works well. Of course, screen works just as well on putty, xterm, and just about anything else. On my laptop's putty shortcut, I have it automatically run screen for me, so it resumes my session and offers the nice C-a a feature all the time (though on the laptop I rebound that to C-s due to the shape fo the keyboard, and to make nesting screens easier). I love it.
Re: std.serialization: pre-voting review / discussion
On Monday, 12 August 2013 at 19:55:01 UTC, Jacob Carlborg wrote: I don't think a pull request should be made before a module has gone through the review queue and is approved. With Github it's easy to diff between a fork and upstream: https://github.com/jacob-carlborg/phobos/compare/serialization Agreed. * I forgot to add that the unit tests are, a bit controversial, located in std.serialization.tests That is something that requires the input from Phobos devs.
Re: Parameter-less templates?
On Tuesday, 13 August 2013 at 09:41:45 UTC, monarch_dodra wrote:
I think strictly speaking, that is a parameterless
parameterized function, as opposed to a non parameterized
function.
No, this is simply syntax sugar on top of eponymous template
declaration.
In regards to template (I mean the actual template), I guess
I wish we could either:
1. Allow non-parameterized templates (eg template foo {...})
2. Allow invoking a template without parameters (provided the
template has 0 parameters, or default parameters), without
doing !()
Amen !
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Saturday, 10 August 2013 at 18:35:10 UTC, Nick Sabalausky wrote: Would it be acceptable to use gmake as *the* make for DMD? Ie, either convert the windows makefiles to gmake, or expand the posix makefiles to support windows? 1. expand posix makefiles to support windows 2. leave dm makefile for those who doesn't have gmake 3. use unified posix/windows makefile 4. everyone is happy
Re: std.serialization: pre-voting review / discussion
2 everyone: should I interpret lack of activity as lack of interest in getting this into Phobos or lack of issues to comment on? ;)
Ideas for a brand new widget toolkit
Hello everyone, These days I've been searching for a cross-platform IDE for D and I found out that there aren't any viable standalone options. After a few clicks, I've ran over this topic: http://forum.dlang.org/thread/astrlgbptrlvcdicq...@forum.dlang.org and it wasn't a surprise to see there are other people searching for the very same thing.One of the reasons for the absence of such IDEs is that there are no widget toolkits written in D except DWT, but some people are complaining about DWT for being a clone of SWT and that clients will want DWT to be in sync with SWT since SWT is a marketing paradigm. As such, I want to embark on a long journey of writing a new widget toolkit from scratch. Here are the ideas that people came up with so far(sorry if I omitted something): evilrat: * we need a truly D UI(not wrapper) first * there are almost no declarative cross platform(i mean major OS) toolkit for writing simple yet highly customizable UI's, with HTML markup-like, customizable UI's without messing with imperative(C/C++/D/whatever) code eles: * a D-ported version of a rather anonymous toolkit won't be shaded by the original * evolution is slower, so not a fast-moving target * the team behind that toolkit will be more than glad to help, as their toolkit will gain in popularity, and could even be converted to D-development (instead of C or C++ or whatever) * re-write FOX tk in D, not to bind to it * drivers as the lower bound in my original post. The rest should be drawn... Trvhgoy: * define the layout with a markup language like XAML or XUL for example and the styling with a CSS-like definition. Mike Parker: * Harmonia might be a good place to start: http://harmonia.terrainformatica.com/doku.php Chris: * a UI tool like Glade or Interface Builder is indispensible Jacob Carlborg: * You would still need to some graphics primitives. Do you want to implement them yourself as well? I mean, you have to draw the line somewhere. There's always a layer beneath you that you rely on, if you're not doing embedded or similar. * you want a non-native toolkit. * primitives would be implemented on top of OpenGL or DirectX. OpenGL is implemented in the graphics drivers, don't know how it works with DirectX. Now let me complete these notes: * I think that porting an anonymous toolkit to D will do more harm than good because if the original project was lacking some features then clients will think that the ported version lacks them as well. If we want to take this route then, besides Harmonia and FOX tk, we might borrow things from FLTK(Fast Light Toolkit) * If the projects starts from zero, with its own design and is shiny new then people will be more attracted. * Even if we don't port a toolkit we can still get inspired to see how they interact with the underlying system. For example, we can take a look over the SDL way of handling input. * for drawing primitives we can use Cairo(curently used by GTK) or libX11 on linux and Directx on windows.Bindings for cairo and libX11 are provided by Deimos. I'm not sure if we can use OpenGL because it requires a rendering window or it renders in fullscreen mode.That rendering window can be provided by other toolkits but I don't think we want to depend on them. The OS window manager(xorg on linux) needs to keep track of the things it draws on its root window or surface and must be aware what to clean-up after you close your program. So the layer beneath this widget toolkit on Linux would be X(libX11). * XAML is being developed by Microsoft and XUL by Mozzilla. I think XUL is a better choice for a markup language and more friendlier with an open source toolkit. It would be pretty nice if we can make the GuiParser and abstract class and provide an implementation for XUL because that will allow us to write an implementation for the QML(Qt) aswell or other flavors of layout and style files. * If we want the project to scale up nicely then we should do things by the book. That is doing some research to see what technologies are involved, what the client programmers want(this thread) and then write some specs. * After we have the specs then we can start designing the toolkit using UML diagrams such that we will end up with a clean API and avoid future re-factoring. For UML designs, I recommend this web app https://www.draw.io/ which saves its files in XML format and we can store them in the git repository. * Only after we have a good design we will begin the actual coding. * there is this 3D modelling tool called Blender which has a modern-looking UI. People have been wondering if that GUI can be used as a library and the answer is no because the gui is harcoded into Blender. If our default ui look resembles that one(not necessarily identical) then we will gain more clients.Maybe we can even get support from its huge community of artists. Take a look: http://www.blender.org/features-gallery/features/ * this
Re: std.serialization: pre-voting review / discussion
On 08/12/2013 03:27 PM, Dicebot wrote: Stepping up to act as a Review Manager for Jacob Carlborg std.serialization Input Code: https://github.com/jacob-carlborg/phobos/tree/serialization Documentation: https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/index.html I had no look at the code, but just opened the documentation, asking the question: What do I need to do to serialize this graph data structure, I have here?. The documentation does not seem to give a straight answer. Now, that's an issue I have with almost all phobos modules, for example with std.container, but I'll raise this point here: Our documentational standards are not good enough, because all we ever have is some API documentation ala this is module X, it contains the symbols A, B, C, which have a short description respectively. However a good documentation (look at docs.python.org for example) needs to do more. The module has a purpose, because it should help me to accomplish a task. The documentation must say (preferably in a single location) what this task is and how this module/library may help me in accomplishing it's task. An outline of the basic design decisions (for example where does std.container mention it's structures have reference semantics?) are often invaluable in unterstanding api/ more detailed documentation. I know how much work such documentation is and I surely wouldn't vote against std.serialization just because of this. But it's one of the two biggest hindrances if you want to get started / productive with D. (IMHO)
Re: Ideas for a brand new widget toolkit
On 08/13/2013 03:23 PM, Paul Z. Barsan wrote: Think of this topic as writing letters to Santa, so: what say you ? I'd bet on QtD.
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote: I haven't hosted the project yet because I'm undecided what hosting service should I use. AFAIK, sourceforge is for projects and it gives you the option of hosting a website, using other bugtrackers such as Trac and github is focused more on the code. So where do you think a project of this magnitude should be hosted ? http://pages.github.com/ perhaps?
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 13:32:04 UTC, Tobias Pankrath wrote: I'd bet on QtD. QtD provides language bindings just like GtkD or wxD. Qt as a framework is a mammoth. It provides support for networking, threads and even has wrappers for basic types such as QString. Phobos already provides support for this sort of things. Besides that, there are widget toolkits written in all major programming languages: GTK+ in C, Qt in C++, Swing in Java and so on. Another gui toolkit will bring more users to D itself. On Tuesday, 13 August 2013 at 13:51:40 UTC, John Colvin wrote: http://pages.github.com/ perhaps? I didn't know of this github feature. I only used sourceforge and bitbucket before. Another option was dsource but it seems to me like a sinking boat and its user are moving their projects to github. Thanks for the tip !
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 14:22:09 UTC, Tobias Pankrath wrote: So additionally to a GUI Toolkit we get a framework full of useful things Useful for C++. Sometimes. Actually, that was a reason to prefer GTK over Qt for me even in C++ times. No way I'll ever use this monster in D.
Re: Ideas for a brand new widget toolkit
Coincidentally, I started slapping one together over the weekend. As you can see, it is hideous: http://arsdnet.net/gui.png And if I saw someone else coding a gui the way I am, I'd call them silly for rejecting all things that are good and decent. So, what am I doing and why am I doing it that way? Let's start with the why: Qt and GTK are just too big, and other lightweight wrappers still tend to have runtime requirements that i hate. I want to be able to distribute a stand-alone exe that people can use that is 1 MB, so there's a reasonable download time from my slow computer. The qtd and gtkd wrappers make them even bigger and more fragile. The D forms library is ok, still a bit big and buggy when I tried, but the real blocker there is zero linux support. So I'm doing just win32 and xlib, built on my simpledisplay.d that already provides basics. Since xlib doesn't provide any widgets, I'm diying there. (But might change my mind later and dynamically link gtk, idk, the linux version will probably only be used by myself so it isn't that important.) My goal: provide very basic, but useful, capabilities in one D module. What exactly am I doing? Just drawing rectangles and reading events (simpledisplay.d supports these, and I'm improving it as needed for this) and calling it a gui! I don't my approach of from scratch, custom widgets is a good idea in most cases.
Re: Ideas for a brand new widget toolkit
On 08/13/2013 04:10 PM, Paul Z. Barsan wrote: QtD provides language bindings just like GtkD or wxD. Qt as a framework is a mammoth. It provides support for networking, threads and even has wrappers for basic types such as QString. Phobos already provides support for this sort of things. So additionally to a GUI Toolkit we get a framework full of useful things, that many C++ programmer already know. I'll take that as an argument pro QtD. Besides that, there are widget toolkits written in all major programming languages: GTK+ in C, Qt in C++, Swing in Java and so on. Nope. GTK+, Qt and Swing all have a over hundred man years advantage over yet-another-gui-toolkit. Programmer who want to build a non trivially gui, will just take a language that has a comparable solution to these three. That will not be D. Another gui toolkit will bring more users to D itself. Good bindings to an existant GUI toolkit will bring users to D. No one really cares, which language it's originally written in. See Python/Ruby.
Re: std.serialization: pre-voting review / discussion
13-Aug-2013 17:15, Dicebot пишет: 2 everyone: should I interpret lack of activity as lack of interest in getting this into Phobos or lack of issues to comment on? ;) Give us some time darn it ;) -- Dmitry Olshansky
Re: std.serialization: pre-voting review / discussion
13-Aug-2013 16:48, Dicebot пишет: On Monday, 12 August 2013 at 19:55:01 UTC, Jacob Carlborg wrote: I don't think a pull request should be made before a module has gone through the review queue and is approved. With Github it's easy to diff between a fork and upstream: https://github.com/jacob-carlborg/phobos/compare/serialization Agreed. * I forgot to add that the unit tests are, a bit controversial, located in std.serialization.tests That is something that requires the input from Phobos devs. IMHO a good idea to have a non-trivial test suite to be separate so that it doesn't not clutter other module(s). That said isolated tests for individual pieces and internal stuff are better kept together with the code they test. -- Dmitry Olshansky
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Tuesday, 13 August 2013 at 09:52:25 UTC, Chris wrote: On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote: On Monday, 12 August 2013 at 18:57:12 UTC, Chris wrote: On Monday, 12 August 2013 at 17:23:39 UTC, Dicebot wrote: On Monday, 12 August 2013 at 16:58:22 UTC, Adam D. Ruppe wrote: On Monday, 12 August 2013 at 16:45:52 UTC, Chris wrote: True, true. There weren't many options back in the day. But that's no excuse for bad or absurd language design. $asolutely $no $need $to $have $a $syntax $like $this = And I recall that PHP was meaning something like Personally, I Hate Perl :)
Unconditional loop exists
Are situations like this, that are potential signs of
bugs/mistakes, worth reporting with warnings?
int foo() {
// Unconditional 'break' within a loop:
foreach (immutable _; 0 .. 10) {
//...
break;
}
// Unconditional 'return' within a loop:
foreach (immutable _; 0 .. 10) {
//...
return 0;
}
assert(0);
}
Bye,
bearophile
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 14:10:24 UTC, Paul Z. Barsan wrote: On Tuesday, 13 August 2013 at 13:32:04 UTC, Tobias Pankrath wrote: I'd bet on QtD. QtD provides language bindings just like GtkD or wxD. Qt as a framework is a mammoth. It provides support for networking, threads and even has wrappers for basic types such as QString. Phobos already provides support for this sort of things. clip Qt is modular. I would assume a qtD would only need to support QtCore and QtGui (those are pretty big though), but you still shouldn't need to support all of the Qt Framework (XML, Networking, QtConcurrent, etc.). Craig
Re: std.serialization: pre-voting review / discussion
On 2013-08-13 15:33, Tobias Pankrath wrote: I had no look at the code, but just opened the documentation, asking the question: What do I need to do to serialize this graph data structure, I have here?. The documentation does not seem to give a straight answer. There's a fully working example here: https://dl.dropboxusercontent.com/u/18386187/docs/std.serialization/std_serialization_serializer.html I worked quite hard with the documentation. There are code examples here as well, I just don't know where to put them in Phobos: https://github.com/jacob-carlborg/orange/wiki/_pages -- /Jacob Carlborg
Re: std.serialization: pre-voting review / discussion
On 2013-08-13 16:34, Dmitry Olshansky wrote: IMHO a good idea to have a non-trivial test suite to be separate so that it doesn't not clutter other module(s). That said isolated tests for individual pieces and internal stuff are better kept together with the code they test. They are of a high level nature and not for the internal stuff. -- /Jacob Carlborg
Re: std.serialization: pre-voting review / discussion
On Tuesday, 13 August 2013 at 14:35:06 UTC, Dmitry Olshansky wrote: IMHO a good idea to have a non-trivial test suite to be separate so that it doesn't not clutter other module(s). That said isolated tests for individual pieces and internal stuff are better kept together with the code they test. What do you think about having top-level folder with functional tests for a more complex packages?
Re: Unconditional loop exists
On Tuesday, 13 August 2013 at 14:56:32 UTC, bearophile wrote:
Are situations like this, that are potential signs of
bugs/mistakes, worth reporting with warnings?
int foo() {
// Unconditional 'break' within a loop:
foreach (immutable _; 0 .. 10) {
//...
break;
}
// Unconditional 'return' within a loop:
foreach (immutable _; 0 .. 10) {
//...
return 0;
}
assert(0);
}
Bye,
bearophile
Arguably, D has the unreachable code warning, so an
unconditional break would short circuit the incrementation code.
So I think there is no need for a new warning for this, but to
make it detect that a certain amount of code is not reachable.
Re: std.serialization: pre-voting review / discussion
On Tuesday, 13 August 2013 at 15:04:38 UTC, Jacob Carlborg wrote: I worked quite hard with the documentation. There are code examples here as well, I just don't know where to put them in Phobos: https://github.com/jacob-carlborg/orange/wiki/_pages Two random proposals for discussion: 1) Chosing one or two examples that cover most typical use cases and put them into `serializer` module header. 2) Create a devoted `examples` module which is not imported in `package.d` but is available in documentation.
Re: Ideas for a brand new widget toolkit
Am 13.08.2013 15:23, schrieb Paul Z. Barsan: Think of this topic as writing letters to Santa, so: what say you sorry your list is much to big - feels like the next Doom 5 128 Bit with hypergigagraphics... your talking about serveral years of development - and yes - there are many developers that want a new great gui blabla thing - but don't want to invest time to produce it - want != personal invest just look at the design and code of Qt and you will see that is much much more needed then just nice ideas (and even if D will help to keep out strange looking codestuff, macros etc - you will still neede much of the surounding code btw: you should not start to design a new gui system without deep knowledge of the currently used ones (like GtK, Qt, ... XUL, XAML,...)
Re: Unconditional loop exists
On 08/13/2013 04:56 PM, bearophile wrote:
Are situations like this, that are potential signs of bugs/mistakes,
worth reporting with warnings?
int foo() {
// Unconditional 'break' within a loop:
foreach (immutable _; 0 .. 10) {
//...
break;
}
// Unconditional 'return' within a loop:
foreach (immutable _; 0 .. 10) {
//...
return 0;
}
assert(0);
}
Bye,
bearophile
Well, the following is the most generic way to get the first element of
some iterable:
foreach(x;s) return x;
Re: Unconditional loop exists
monarch_dodra: Arguably, D has the unreachable code warning, so an unconditional break would short circuit the incrementation code. So I think there is no need for a new warning for this, but to make it detect that a certain amount of code is not reachable. The D compiler gives a warning if you add code after those return and break. So the missing warning is useful when those return and break are at the end of the loop body. That assert(0) is needed because D doesn't deduce that return is always executed. Bye, bearophile
Re: Ideas for a brand new widget toolkit
Start else another GUI toolkit it's bad idea, we already have about 5-6 GUI toolkit's that's done only on half. Much better to take any of existent, for example http://code.google.com/p/dgui/ and continue of it's developing
Re: Unconditional loop exists
Timon Gehr: Well, the following is the most generic way to get the first element of some iterable: foreach(x;s) return x; I think I have not used that idiom even with opApply, but it's acceptable code. And perhaps someone will find a use case even for the unconditional loop break. So I think this little idea-proposal is already closed :-) Bye, bearophile
Re: std.serialization: pre-voting review / discussion
On 2013-08-13 17:09, Dicebot wrote: What do you think about having top-level folder with functional tests for a more complex packages? I think that's a good idea. -- /Jacob Carlborg
Re: std.serialization: pre-voting review / discussion
On 2013-08-13 17:12, Dicebot wrote: 2) Create a devoted `examples` module which is not imported in `package.d` but is available in documentation. I'm wondering if the package.d module could be used for this, somehow. -- /Jacob Carlborg
Re: Ideas for a brand new widget toolkit
On 2013-08-13 15:23, Paul Z. Barsan wrote: Hello everyone, Oh, another one of these threads... These days I've been searching for a cross-platform IDE for D and I found out that there aren't any viable standalone options. After a few clicks, I've ran over this topic: http://forum.dlang.org/thread/astrlgbptrlvcdicq...@forum.dlang.org and it wasn't a surprise to see there are other people searching for the very same thing.One of the reasons for the absence of such IDEs is that there are no widget toolkits written in D except DWT, but some people are complaining about DWT for being a clone of SWT and that clients will want DWT to be in sync with SWT since SWT is a marketing paradigm. As such, I want to embark on a long journey of writing a new widget toolkit from scratch. Jacob Carlborg: * You would still need to some graphics primitives. Do you want to implement them yourself as well? I mean, you have to draw the line somewhere. There's always a layer beneath you that you rely on, if you're not doing embedded or similar. * you want a non-native toolkit. * primitives would be implemented on top of OpenGL or DirectX. OpenGL is implemented in the graphics drivers, don't know how it works with DirectX. This is very out of context and not what I think, I just responded to a post. Think of this topic as writing letters to Santa, so: what say you ? All I can say that creating a new toolkit from scratch is a huge amount of work. -- /Jacob Carlborg
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 13:23:07 UTC, Paul Z. Barsan wrote: Think of this topic as writing letters to Santa, so: what say you ? Aww, you've gone and reminded me of Hybrid [1] again. D1/Tango IIRC, but I think it had good potential. No lazy updates, though, so probably not as useful for ordinary desktop applications. ...I wonder if Tomasz will ever come back? -Wyatt [1] http://h3.gd/code/hybrid/wiki/
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, Aug 13, 2013 at 11:55:12AM +0200, Joakim wrote: [...] Personally, I like the D-based build system idea. Distribute dmd/phobos with a D-based build tool like dub, which has been compiled ahead of time for each supported platform and will compile D for you, if you want. Of course, this means that you'll still need to maintain makefiles on the D build machines that will build dub for the D maintainers to distribute, but it isolates all the complexity of makefiles from end users, so they don't have to touch any of that stuff. Whether that ease of use is worth the extra effort, I don't know. There's no need to maintain any makefiles once the D build tool is usable. As long as you have a working binary of dmd that can compile the tool, that's good enough. T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, Aug 13, 2013 at 09:03:12AM +0200, Jacob Carlborg wrote: On 2013-08-12 00:38, H. S. Teoh wrote: Maybe my previous post didn't get the idea across clearly, so let me try again. My underlying thrust was: instead of maintaining 3 different makefiles (or more) by hand, have a single source for all of them, and write a small D program to generate posix.mak, win32.mak, win64.mak, whatever, from that source. If it's written in D it will have the same bootstrap problem. But perhaps that's ok since we're moving DMD to D anyway. [...] Well, yes, we're moving DMD to D anyway, so we're going to face the bootstrap problem regardless. But that's not really what I'm getting at. My whole point was to have a single source of truth for how to build what needs to be built, instead of scattering it across 3+ makefiles that need to be maintained separately. T -- Never wrestle a pig. You both get covered in mud, and the pig likes it.
Re: Is D the Answer to the One vs. Two Language High ,Performance Computing Dilemma?
On Tue, Aug 13, 2013 at 11:52:23AM +0200, Chris wrote: On Tuesday, 13 August 2013 at 01:00:12 UTC, deadalnix wrote: [...] Rewind history back to early 2000 and you'll understand. At the time, PHP was the best solution (which says more about how bad the situation was than how great PHP was :D). True, true. There weren't many options back in the day. But that's no excuse for bad or absurd language design. $asolutely $no $need $to $have $a $syntax $like $this = At least it does its job ok. I honestly don't understand what's so bad about using $ for variables. That has nothing to do with PHP's *real* design flaws, which are many and varied. To fixate on $ only hides the real problems, described here: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ Note that using $ for variables isn't listed there. T -- I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. -- swr
GPGPUs
The era of GPGPUs for Bitcoin mining are now over, they moved to ASICs. The new market for GPGPUs is likely the banks, and other Big Data folk. True many of the banks are already doing some GPGPU usage, but it is not big as yet. But it is coming. Most of the banks are either reinforcing their JVM commitment, via Scala, or are re-architecting to C++ and Python. True there is some C#/F# but it is all for terminals not for strategic computing, and it is diminishing (despite what you might hear from .NET oriented training companies). Currently GPGPU tooling means C. OpenCL and CUDA (if you have to) are C API for C coding. There are some C++ bindings. There are interesting moves afoot with the JVM to enable access to GPGPU from Java, Scala, Groovy, etc. but this is years away, which is a longer timescale than the opportunity. Python's offerings, PyOpenCL and PyCUDA are basically ways of managing C coded kernels which rather misses the point. I may get involved in trying to write an expression language in Python to go with PyOpenCL so that kernels can be written in Python – a more ambitious version aimed at Groovy is also mooted. However, D has the opportunity of gaining a bridgehead if a combination of D, PyD, QtD and C++ gets to be seen as a viable solid platform for development. The analogue here is the way Java is giving way to Scala and Groovy, but in an evolutionary way as things all interwork. The opportunity is for D to be seen as the analogue of Scala on the JVM for the native code world: a language that interworks well with all the other players on the platform but provides more. The entry point would be if D had a way of creating GPGPU kernels that is better than the current C/C++ + tooling. This email is not a direct proposal to do work, just really an enquiry to see if there is any interest in this area. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.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: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tuesday, 13 August 2013 at 16:11:44 UTC, H. S. Teoh wrote: There's no need to maintain any makefiles once the D build tool is usable. On this note, I've often wondered why D compilers (or dmd, at least) don't just try to infer the necessary files to compile/link for a project based on the modules it imports. Obviously this breaks down once you need to express linkage with external libraries; but figuring out as much as possible automatically would be neat. e.g. Say the top of smallProj.d has: import common.func; import common.data; ...and you have a common/ directory with func.d and data.d, it seems the compiler could accept: dmd smallProj.d ...as a shorthand for: dmd common/func.d common/data.d smallProj.d Given that it doesn't work this way, I'm guessing there's some aspect I've missed that throws it into the same sort of hellscape of agony as every other build system in the world, but I can't figure out what it might be... -Wyatt
Re: GPGPUs
On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder wrote: The era of GPGPUs for Bitcoin mining are now over, they moved to ASICs. The new market for GPGPUs is likely the banks, and other Big Data folk. True many of the banks are already doing some GPGPU usage, but it is not big as yet. But it is coming. Most of the banks are either reinforcing their JVM commitment, via Scala, or are re-architecting to C++ and Python. True there is some C#/F# but it is all for terminals not for strategic computing, and it is diminishing (despite what you might hear from .NET oriented training companies). Currently GPGPU tooling means C. OpenCL and CUDA (if you have to) are C API for C coding. There are some C++ bindings. There are interesting moves afoot with the JVM to enable access to GPGPU from Java, Scala, Groovy, etc. but this is years away, which is a longer timescale than the opportunity. Python's offerings, PyOpenCL and PyCUDA are basically ways of managing C coded kernels which rather misses the point. I may get involved in trying to write an expression language in Python to go with PyOpenCL so that kernels can be written in Python – a more ambitious version aimed at Groovy is also mooted. However, D has the opportunity of gaining a bridgehead if a combination of D, PyD, QtD and C++ gets to be seen as a viable solid platform for development. The analogue here is the way Java is giving way to Scala and Groovy, but in an evolutionary way as things all interwork. The opportunity is for D to be seen as the analogue of Scala on the JVM for the native code world: a language that interworks well with all the other players on the platform but provides more. The entry point would be if D had a way of creating GPGPU kernels that is better than the current C/C++ + tooling. This email is not a direct proposal to do work, just really an enquiry to see if there is any interest in this area. I'm interested. There may be a significant need for gpu work for my PhD, seeing as the amount of data needing to be crunched is a bit daunting (dozens of sensors with MHz sampling, with very intensive image analysis / computer vision work). I could farm the whole thing out to cpu nodes, but using the gpu nodes would be more fun. However, I'm insanely busy atm and have next to no experience with gpu programming, so I'm probably not gonna be that useful for a while!
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tuesday, 13 August 2013 at 16:39:06 UTC, Wyatt wrote: Given that it doesn't work this way, I'm guessing there's some aspect I've missed that throws it into the same sort of hellscape of agony as every other build system in the world, but I can't figure out what it might be... It exactly what rdmd does. Merging this functionality into dmd itself was discussed but not done.
Re: std.serialization: pre-voting review / discussion
On 2013-08-12 15:27, Dicebot wrote: Jacob, it is probably worth creating a pull request with latest rebased version of your proposal to simplify getting a quick overview of changes. Also please tell if there is anything you want/need to implement before merging. I have rebased now. -- /Jacob Carlborg
Re: Ideas for a brand new widget toolkit
On 2013-08-13 08:23, Paul Z. Barsan wrote: Now let me complete these notes: * I think that porting an anonymous toolkit to D will do more harm than good because if the original project was lacking some features then clients will think that the ported version lacks them as well. If we want to take this route then, besides Harmonia and FOX tk, we might borrow things from FLTK(Fast Light Toolkit) * If the projects starts from zero, with its own design and is shiny new then people will be more attracted. * Even if we don't port a toolkit we can still get inspired to see how they interact with the underlying system. For example, we can take a look over the SDL way of handling input. * for drawing primitives we can use Cairo(curently used by GTK) or libX11 on linux and Directx on windows.Bindings for cairo and libX11 are provided by Deimos. I'm not sure if we can use OpenGL because it requires a rendering window or it renders in fullscreen mode.That rendering window can be provided by other toolkits but I don't think we want to depend on them. The OS window manager(xorg on linux) needs to keep track of the things it draws on its root window or surface and must be aware what to clean-up after you close your program. So the layer beneath this widget toolkit on Linux would be X(libX11). * XAML is being developed by Microsoft and XUL by Mozzilla. I think XUL is a better choice for a markup language and more friendlier with an open source toolkit. It would be pretty nice if we can make the GuiParser and abstract class and provide an implementation for XUL because that will allow us to write an implementation for the QML(Qt) aswell or other flavors of layout and style files. * If we want the project to scale up nicely then we should do things by the book. That is doing some research to see what technologies are involved, what the client programmers want(this thread) and then write some specs. * After we have the specs then we can start designing the toolkit using UML diagrams such that we will end up with a clean API and avoid future re-factoring. For UML designs, I recommend this web app https://www.draw.io/ which saves its files in XML format and we can store them in the git repository. * Only after we have a good design we will begin the actual coding. * there is this 3D modelling tool called Blender which has a modern-looking UI. People have been wondering if that GUI can be used as a library and the answer is no because the gui is harcoded into Blender. If our default ui look resembles that one(not necessarily identical) then we will gain more clients.Maybe we can even get support from its huge community of artists. Take a look: http://www.blender.org/features-gallery/features/ * this toolkit can complement DWT because DWT will provide native look and this one will provide the same look on all platforms. i like your ideas, especially the the clear top-down strategy. if the vision, i.e. design/API and roadmap is clear, and the documentation is good from the very beginning (something i want to stress particularly), then it could develop some dynamic. to ppl shrugging it off with the arguments that it is too much work or has been tried before: well, these arguments cancel each other out. previous projects have been very promising and accomplished a lot, enough for a kickstart. in theory - as it did not happen. and why? i think their biggest problem was that they were basically one man projects, not community projects. they did not outline design goals, open issues, roadmaps, - heck they did not even provide a sufficient documentation for using them. so they more or less died once the original maintainer lost interest. i often think what nice a D GUI package we would have by now if those 3 or 4 ppl running the previous attempts would have worked together. i played a bit with DFL some years ago and was quite impressed (it even had a GUI designer!) - but only to a certain point. i wanted multi platform and being only the occasional programmer, i need a good, detailed documentation. so back than i decided to not use D altogether as a GUI was a must for my application. (the core procedures being in C i still hope to move it to D at one point though) having a D-simple and D-safe pure D GUI is worth a try and would boost D's popularity. if it takes 2 years before it is usable, so what. it would not slow down improving D in other aspects as i think a GUI development would motivate a different set of ppl to contribute, i.e. would not withdraw current phobos and compiler devs. just my 2c, det
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, 13 Aug 2013 11:55:12 +0200 Joakim joa...@airpost.net wrote: On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote: On 8/12/2013 11:48 PM, Jacob Carlborg wrote: On 2013-08-13 02:42, Andrei Alexandrescu wrote: Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin? I don't see why we couldn't do that. It's a completely separate tool and shouldn't infect anything else. We might need to accompany it with a license file and a link to the source code to be on the safe side. Again, read my reply to Brad in this thread. Presumably you are referring to this quote, which does not show up as a reply? I think he's referring to technical issues with gmake apparently not always playing nice on windows.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, 13 Aug 2013 09:03:12 +0200 Jacob Carlborg d...@me.com wrote: On 2013-08-12 00:38, H. S. Teoh wrote: Maybe my previous post didn't get the idea across clearly, so let me try again. My underlying thrust was: instead of maintaining 3 different makefiles (or more) by hand, have a single source for all of them, and write a small D program to generate posix.mak, win32.mak, win64.mak, whatever, from that source. If it's written in D it will have the same bootstrap problem. Sort of, but...no, not really. Since this tool would be cable of generating any platform-specific makefile or script or whatever, and there's no reason to restrict it to *only* generate a makefile/script for the current platform, that means it can function much like a cross-compiler: Suppose there's some computer DMD isn't installed on. Maybe it's even a new platform that DMD hasn't been ported to. H.S. Teoh's tool could be run on *any existing* D-capable system to generate the makefile/script for the intended target computer. Maybe that might even require adding a new shell/makefile output to the tool, but it would *not* require running H.S. Teoh's tool (or anything else) on the actual intended target platform. Then, that makefile/script which was generated on...windows or whatever...is then transferred (email, ftp, floppy, whatever) to the new system and DONE - a working buildscript, ready to attempt compiling DMD, without *anything* having been run yet. But perhaps that's ok since we're moving DMD to D anyway.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 2013-08-13 19:37, Nick Sabalausky wrote: Sort of, but...no, not really. Since this tool would be cable of generating any platform-specific makefile or script or whatever, and there's no reason to restrict it to *only* generate a makefile/script for the current platform, that means it can function much like a cross-compiler: Well if you output a build file for a different tool that's completely different. -- /Jacob Carlborg
Alternative to Github downloads
Is there anyone that have a good alternative to Github downloads? -- /Jacob Carlborg
Typeinfo inconsistencies
So, I got some free time today and decided to look into issue 6210, and found out that the problem was caused by this: char[]a = h.dup; const(char)[] b = h; stringc = h; writeln(typeid(a).getHash(a)); // prints 104 writeln(typeid(b).getHash(b)); // prints 703014434222502 writeln(typeid(c).getHash(c)); // prints 104 This is completely b0rken, because it causes the following code to fail: int[char[]] aa; aa[h] = 1; assert(aa.dup == aa); // fails The reason for this inconsistency is that char[] and immutable(char)[] (aka string) have their getHash functions overridden in druntime's src/rt/typeinfo/ti_Ag.d, but there is no such override for const(char)[]. I tried adding another subclass for const(char)[]'s typeid that inherits the correct version of getHash, but it didn't work because presumably this stuff is hardcoded into the compiler somewhere. So my question is, where in the compiler decides to use the specific typeinfos for char[] and immutable(char)[], but not const(char)[]? T -- That's not a bug; that's a feature!
Re: Ideas for a brand new widget toolkit
The problem is that the scale of a project like this literally stops people from starting. Couple this with the fact that a non existent project doesn't attract any developers and you've got negative feelings from the start. I wouldn't worry about that though! I think the benefits of a project like this far outweigh any initial worries about scale. Personally, i would love for there to be a D GUI toolkit that is available for all D supported platforms. It would be awesome being able to create D GUI applications in a straight forward way and something which i truly think would attract many more developers to D. IMHO It's one of the two big attractors* to using any language, i.e. an easy to use GUI toolkit. I honestly think that's why C# and Python caught on as quickly as they did. If work is started on a project like this and shows promise, i wouldn't be adverse to contributing. Keep this quote in mind: Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say hey, that almost works for me, and they'll get involved in the project. Linus Torvalds - Linux Times (2004-10-25) http://web.archive.org/web/20050404020308/http://www.linuxtimes.net/modules.php?name=Newsfile=articlesid=145 SO who will be the first to start? ;) * The other is games programming capability but we'll leave discussing building a full opengl games programming framework for another thread. ;)
D-thrift package detects regressions since 2.061, where is the regression suite located?
Grrr... Apparently nobody has been testing the D - Apache Thrift bindings since 2.061, and dmd has since accumulated multiple regressions that affect the correctness of the Thrift implementation. I emailed with David N. and he said that this was quite common for each release of dmd, and that while he used to religously evaluate each new dmd release on the Thrift bindings, he had simply not had the time for more recent recents to test each thoroughly. Serialization: this is fundamental. This really isn't the kind of thing that should ever be allowed to break. Hence it really isn't something that should be tested manually. It should be an automatic part of the automatic regression detection test suite. Where is the regression suite for D located, and how can I add to it? There used to be github issue tracking, but I don't see it any more... is it hiding under their new interface perhaps...? Thanks. - glycerine
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, 13 Aug 2013 15:13:38 +0200 Kagamin s...@here.lot wrote: On Saturday, 10 August 2013 at 18:35:10 UTC, Nick Sabalausky wrote: Would it be acceptable to use gmake as *the* make for DMD? Ie, either convert the windows makefiles to gmake, or expand the posix makefiles to support windows? 1. expand posix makefiles to support windows 2. leave dm makefile for those who doesn't have gmake 3. use unified posix/windows makefile 4. everyone is happy That still involves the overhead of maintaining duplicate makefiles and a tendency for gradual divergence.
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 17:40:05 UTC, Gary Willoughby wrote: clip I think the benefits of a project like this far outweigh any initial worries about scale. Personally, i would love for there to be a D GUI toolkit that is available for all D supported platforms. It would be awesome being able to create D GUI applications in a straight forward way and something which i truly think would attract many more developers to D. IMHO It's one of the two big attractors* to using any language, i.e. an easy to use GUI toolkit. I honestly think that's why C# and Python caught on as quickly as they did. clip What is the Python GUI toolkit you speak of?
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, Aug 13, 2013 at 01:45:41PM -0400, Nick Sabalausky wrote: On Tue, 13 Aug 2013 15:13:38 +0200 Kagamin s...@here.lot wrote: On Saturday, 10 August 2013 at 18:35:10 UTC, Nick Sabalausky wrote: Would it be acceptable to use gmake as *the* make for DMD? Ie, either convert the windows makefiles to gmake, or expand the posix makefiles to support windows? 1. expand posix makefiles to support windows 2. leave dm makefile for those who doesn't have gmake 3. use unified posix/windows makefile 4. everyone is happy That still involves the overhead of maintaining duplicate makefiles and a tendency for gradual divergence. It violates DRY, and thus inherits all of the associated problems. T -- The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.
Re: UFCS for templates
On Thursday, 8 August 2013 at 17:35:02 UTC, JS wrote:
Can we have UFCS for templates?
e.g.,
T New(T, A...)(A args) { }
T t = T.New(args);
Note, in this case, the type parameter is substituted.
A while back I made this enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=8381
It might be similar to what you're proposing (although it's not
clear what it is that you're proposing).
I'd be interested in hearing some actual use cases for this
feature though (I can't think of any even though I made that
feature request).
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 8/13/13 10:39 AM, Jacob Carlborg wrote: On 2013-08-13 19:37, Nick Sabalausky wrote: Sort of, but...no, not really. Since this tool would be cable of generating any platform-specific makefile or script or whatever, and there's no reason to restrict it to *only* generate a makefile/script for the current platform, that means it can function much like a cross-compiler: Well if you output a build file for a different tool that's completely different. And more complicated. To quote myself (and fix a typo): The margins involved are small enough to make it difficult for the solution to not become worse than the problem. The sheer fact that this thread has been going on for so long without a slam-dunk solution emerging is quite telling. Andrei
Re: Ideas for a brand new widget toolkit
On Tue, 2013-08-13 at 19:40 +0200, Gary Willoughby wrote: […] truly think would attract many more developers to D. IMHO It's one of the two big attractors* to using any language, i.e. an easy to use GUI toolkit. I honestly think that's why C# and Python caught on as quickly as they did. Python has no widget set. It wraps and ships tk by default. There are wrappers for Qt, wxWidgets, GTK, and others. So the Python message is use other people's widget sets. Easy graphics, both UI and data visualization, is a huge attractor. cf. SciPy (Matplotlib), PyGame, etc. […] Keep this quote in mind: Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say hey, that almost works for me, and they'll get involved in the project. Linus Torvalds - Linux Times (2004-10-25) http://web.archive.org/web/20050404020308/http://www.linuxtimes.net/modules.php?name=Newsfile=articlesid=145 This is basically a reaffirmation of John Gall's observation from 1975 General systemantics, an essay on how systems work, and especially how they fail...: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.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: Unconditional loop exists
If you get bored: 1. Run dscanner --ast on some source code 2. Create an XPath expression to find the code you don't like 3. Create a tool that checks the expression against the AST 4. Enjoy your low-budget static code analysis tool. (This idea shamelessly stolen from PMD) https://github.com/Hackerpilot/Dscanner/ http://pmd.sourceforge.net/pmd-5.0.5/xpathruletutorial.html
Re: D-thrift package detects regressions since 2.061, where is the regression suite located?
On Tuesday, August 13, 2013 19:49:51 glycerine wrote: Grrr... Apparently nobody has been testing the D - Apache Thrift bindings since 2.061, and dmd has since accumulated multiple regressions that affect the correctness of the Thrift implementation. I emailed with David N. and he said that this was quite common for each release of dmd, and that while he used to religously evaluate each new dmd release on the Thrift bindings, he had simply not had the time for more recent recents to test each thoroughly. Serialization: this is fundamental. This really isn't the kind of thing that should ever be allowed to break. Hence it really isn't something that should be tested manually. It should be an automatic part of the automatic regression detection test suite. Where is the regression suite for D located, and how can I add to it? We do not include 3rd party libraries or projects in any kind of regression suite, so if that's what you're looking for, you're out of luck. David or someone else working on the Thrift stuff would have had to set something up for the D Thrift stuff specifically. We do have an autotester which tests that the current compiler and standard library implementation pass their tests, as well as a tester which tests that pull requests pass the tests as well, and that can be found here: http://d.puremagic.com/test-results/ If you report bugs in bugzilla, then when they are fixed, unit tests for those bugs will be added for them so that they won't fail again. Our bugzilla can be found here: http://d.puremagic.com/issues. There used to be github issue tracking, but I don't see it any more... is it hiding under their new interface perhaps...? We've never used github issue tracking for either the compiler or D's standard libraries. Maybe they were enabled before, but if so, they were ignored. I don't know what the D Thrift stuff does though. - Jonathan M Davis
Re: Request for editor scripting help
On Tuesday, 13 August 2013 at 01:34:37 UTC, Brian Schott wrote: On Monday, 12 August 2013 at 19:34:53 UTC, Brian Schott wrote: You're correct. I forgot to do a push last night. Unfortunately I won't be able to get this fixed for another 5 hours or so. It's checked in now. OK, I got it to work. I'm gonna copy and modify the Dscanner plugin to use DCD instead so you can have something to bundle with your repo, but in the long run, I think it's better to have a combined plugin - one that first tries DCD, and if it can't connect to the server uses Dscanner as backup. That's the way the Clojure plugins work(though to be fair - they have to. Clojure takes ages to load, so you either use a live REPL server or smash your computer with a sledgehammer) Such combined plugin shouldn't be in part of one tool's repository - since it depends on both - so when I finally get down to write one I'll put it in a separate repository. Also, I would probably make it a plugin for a build system(probably dub), so I could take import paths from there.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 8/13/2013 2:55 AM, Joakim wrote: On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote: On 8/12/2013 11:48 PM, Jacob Carlborg wrote: On 2013-08-13 02:42, Andrei Alexandrescu wrote: Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin? I don't see why we couldn't do that. It's a completely separate tool and shouldn't infect anything else. We might need to accompany it with a license file and a link to the source code to be on the safe side. Again, read my reply to Brad in this thread. Presumably you are referring to this quote, which does not show up as a reply? Nobody seems to have read it or be able to find it, it has no replies, so I quote it here: n 8/11/2013 11:49 AM, Brad Roberts wrote: Gross over generalization when talking about _one_ app in _one_ scenario. It happens over and over to me. Most 'ports' to Windows seem to be: 1. get it to compile 2. ship it! You're deflecting rather than being willing to discuss a topic that comes up regularly. I'm posting in this thread because I'm willing to discuss it. I've added much more detail in this post. You are also well aware of just how often having multiple make files has cause pain by them not being updated in sync. Yes, and I am usually the one who gets to resync them - and I think it's worth it. Does gmake have _any_ of those problems? The last time I tried it, it bombed because the makefiles had CRLF's. Not an auspicious start. This has probably been fixed, but I haven't cared to try again. But ok, it's been a while, let's take a look: Consider: http://gnuwin32.sourceforge.net/install.html In the first paragraph, it says the user must have msvcrt.dll, which doesn't come with it and the user must go find it if he doesn't have it. Then some packages require msvcp60.dll, which the user must also go find elsewhere. Then, it must be installed. It even is complicated enough to motivate someone to write a download and maintenance utility. Some packages must be installed in their default directories (usually c:\progra~1\packagename), or you have to set corresponding environment variables or set options at the command line; see the documentation of the package, or, when available, the installation instructions on the package page. Oh joy. I downloaded the zip file, unzipped it, and ran make.exe. I was rewarded with a dialog box: The program can't start because libintl3.dll is missing from your computer. Try reinstalling the program to fix this problem. This dll isn't included with the zip file, and the install instructions don't mention it, let alone where I can get it. The length of the command-line is limited; see MSDN. DM make solves that problem. The MS-Windows command interpreters, command.com and cmd.exe, understand both the backward slash '\' (which is the default) and the forward slash '/' (such as on Unix) in filenames. In general, it is best to use forward slashes, since some programs internally use the filename, e.g. to derive a directory name, and in doing this rely on the forward slash as path separator. Actually, Windows utilities (even ones provided by Microsoft) sometimes fail to recognize / as a separator. I've not found any consistent rule about this, other than it's going to suck sooner or later if you try using / instead of \. I didn't get further, because I don't have libintl3.dll. -- Contrast that with DM make: 1. There is no install and no setup. It's just make.exe. Run it, it works. No friction. 2. Don't need no dlls one must search the internet for, and also no worries about dll hell from getting the wrong one. DM make runs on a vanilla install of Windows. 3. It's designed from the ground up to work with Windows. For example, it recognizes del as a builtin Windows command, not a program, and handles it directly. It does things in the Windows way. 4. It handles arbitrarily long command lines. 5. No worries with people having a different make.exe than the one the makefiles were built for, as make.exe is distributed with dmd. 6. It's a small program, 50K, meaning it fits in a corner and is a trivial part of the dmd package. -- If for no other reason, I oppose using gnu make for dmd on Windows because it significantly raises the barrier of entry for anyone who wants to just recompile Phobos. Gratuitously adding friction for users is not what we need - note the regular posts we get from newbies and the existing friction they encounter.
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 17:49:21 UTC, Craig Dillabaugh wrote: What is the Python GUI toolkit you speak of? As Russel alluded to it was Tkinter i was referring to. It has been bundled with Python for years (since the beginning?) and it's one of the first GUI toolkits i used years ago. It's very very basic but it's ideal for fast prototypes and just for putting something on a window. I have seen people use it for simple editors to scientific work for plotting data, etc. It's not how awesome it was but how easy it was to use and get results. http://wiki.python.org/moin/TkInter
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 8/13/2013 10:14 AM, Nick Sabalausky wrote: I think he's referring to technical issues with gmake apparently not always playing nice on windows. There's only one post by Brad in this thread and one reply! What's the mystery?
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, 13 Aug 2013 10:50:28 -0700 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 8/13/13 10:39 AM, Jacob Carlborg wrote: Well if you output a build file for a different tool that's completely different. And more complicated. To quote myself (and fix a typo): The margins involved are small enough to make it difficult for the solution to not become worse than the problem. The sheer fact that this thread has been going on for so long without a slam-dunk solution emerging is quite telling. I think it's more telling of the fact that programmers tend not to agree on things ;) (...Not entirely joking, either.)
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On 8/13/2013 3:54 AM, Russel Winder wrote: (**) Anyone using Python earlier than 2.7 is either contractually obliged or nuts. Most sensible folk are already using Python 3.3 or rapidly moving towards it. SCons sadly is not Python 3 compatible. At least not yet, but there are plans. So SCons is developed by people who are nuts? :-)
Re: GPGPUs
On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder wrote: The entry point would be if D had a way of creating GPGPU kernels that is better than the current C/C++ + tooling. You mean an alternative to OpenCL language? Because, I imagine, a library (libopencl) would be easy enough to write/bind. Who'll gonna standardize this language?
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tue, 13 Aug 2013 14:17:55 -0400 Nick Sabalausky seewebsitetocontac...@semitwist.com wrote: On Tue, 13 Aug 2013 10:50:28 -0700 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 8/13/13 10:39 AM, Jacob Carlborg wrote: Well if you output a build file for a different tool that's completely different. And more complicated. To quote myself (and fix a typo): The margins involved are small enough to make it difficult for the solution to not become worse than the problem. The sheer fact that this thread has been going on for so long without a slam-dunk solution emerging is quite telling. I think it's more telling of the fact that programmers tend not to agree on things ;) (...Not entirely joking, either.) But more seriously though, I think a fairly clear solution *has* emerged: A D-based tool. Everything else, including maintaining the status quo, has pretty much been ruled out by the majority for one reason or another - or at the very least have all has serious objections raised. But there haven't been any serious objections to the idea of a D-based tool - just some productive discussion of what form it should take. Besides, a solution doesn't need to be a slam-dunk to be worthwhile.
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 18:11:11 UTC, Gary Willoughby wrote: I have seen people use it for simple editors to scientific work for plotting data, etc. It's not how awesome it was but how easy it was to use and get results. e.g. Here's a small open source project i created 12+ years ago to provide a UI for another small project all using Tkinter: http://nathrach.republicofnewhome.org/mappergui.html It was ridiculously easy to use and if it hadn't been so i probably wouldn't of even tried Python. I was into my RPG games and wanted maps! :) (btw the code is horrible so don't bother looking. he he..)
Re: GPGPUs
On Tuesday, 13 August 2013 at 16:27:46 UTC, Russel Winder wrote: The era of GPGPUs for Bitcoin mining are now over, they moved to ASICs. The new market for GPGPUs is likely the banks, and other Big Data folk. True many of the banks are already doing some GPGPU usage, but it is not big as yet. But it is coming. Most of the banks are either reinforcing their JVM commitment, via Scala, or are re-architecting to C++ and Python. True there is some C#/F# but it is all for terminals not for strategic computing, and it is diminishing (despite what you might hear from .NET oriented training companies). Currently GPGPU tooling means C. OpenCL and CUDA (if you have to) are C API for C coding. There are some C++ bindings. There are interesting moves afoot with the JVM to enable access to GPGPU from Java, Scala, Groovy, etc. but this is years away, which is a longer timescale than the opportunity. Python's offerings, PyOpenCL and PyCUDA are basically ways of managing C coded kernels which rather misses the point. I may get involved in trying to write an expression language in Python to go with PyOpenCL so that kernels can be written in Python – a more ambitious version aimed at Groovy is also mooted. However, D has the opportunity of gaining a bridgehead if a combination of D, PyD, QtD and C++ gets to be seen as a viable solid platform for development. The analogue here is the way Java is giving way to Scala and Groovy, but in an evolutionary way as things all interwork. The opportunity is for D to be seen as the analogue of Scala on the JVM for the native code world: a language that interworks well with all the other players on the platform but provides more. The entry point would be if D had a way of creating GPGPU kernels that is better than the current C/C++ + tooling. This email is not a direct proposal to do work, just really an enquiry to see if there is any interest in this area. I suggest looking into HSA. http://developer.amd.com/wordpress/media/2012/10/hsa10.pdf This will be available on AMD APUs in December, and will trickle out to arm and other platforms over time.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
Well, there has been announcement of D-based build system (bub) recently, maybe it can be used for some dogfooding? :)
Re: Ideas for a brand new widget toolkit
On 8/13/13, Gary Willoughby d...@nomad.so wrote: e.g. Here's a small open source project i created 12+ years ago to provide a UI for another small project all using Tkinter: http://nathrach.republicofnewhome.org/mappergui.html Small note: I'm working on an updated D wrapper around Tk v8.6. There was a project like this called Dkinter, but it got abandoned 5 years ago (and was largely incomplete), so I've started my own wrappping effort. I think an alpha version should be ready in ~10 weeks, maybe more (I hate to guess time schedules like this, and I'm rather busy these days, but the progress is steady).
Re: Alternative to Github downloads
On Tuesday, 13 August 2013 at 17:38:15 UTC, Jacob Carlborg wrote: Is there anyone that have a good alternative to Github downloads? BitBucket, CodePlex, SourceForge SkyDrive, DropBox WindowsAzure, Amazon AWS
Re: Typeinfo inconsistencies
On Tuesday, 13 August 2013 at 17:42:31 UTC, H. S. Teoh wrote: So, I got some free time today and decided to look into issue 6210, and found out that the problem was caused by this: char[]a = h.dup; const(char)[] b = h; stringc = h; writeln(typeid(a).getHash(a)); // prints 104 writeln(typeid(b).getHash(b)); // prints 703014434222502 writeln(typeid(c).getHash(c)); // prints 104 This is completely b0rken, because it causes the following code to fail: int[char[]] aa; aa[h] = 1; assert(aa.dup == aa); // fails The reason for this inconsistency is that char[] and immutable(char)[] (aka string) have their getHash functions overridden in druntime's src/rt/typeinfo/ti_Ag.d, but there is no such override for const(char)[]. I tried adding another subclass for const(char)[]'s typeid that inherits the correct version of getHash, but it didn't work because presumably this stuff is hardcoded into the compiler somewhere. So my question is, where in the compiler decides to use the specific typeinfos for char[] and immutable(char)[], but not const(char)[]? T It seems that important path is taken here: https://github.com/D-Programming-Language/dmd/blob/master/src/typinf.c#L138 And root of the issue maybe here: https://github.com/D-Programming-Language/dmd/blob/master/src/typinf.c#L793 (essentially if(char immutable)) Based on ad-hoc dmd debug: If type is AssociativeArray!(const(char)[], int) Type::builtinTypeInfo returns 0. If type is char[] !t-vtinfo is false, so entire branch is skipped. If type is const(char)[] then !t-builtinTypeInfo() is true and dmd executes COMDAT generation branch. If type is const(char) then !t-builtinTypeInfo() is true and dmd executes COMDAT generation branch (also if (t-isConst()) is also true). If type is char then !t-builtinTypeInfo() is false. It seems that it is consistent with your observations.
Re: Ideas for a brand new widget toolkit
Maybe a port of Fltk library? Small and good enough.
Re: Have Win DMD use gmake instead of a separate DMMake makefile?
On Tuesday, 13 August 2013 at 10:09:11 UTC, Iain Buclaw wrote: On 13 August 2013 10:55, Joakim joa...@airpost.net wrote: would only apply to the gmake binary. The GPL is a very badly written license, but I think it has been generally established that you can distribute tools like gmake or g++ with your own code and that doesn't make your own code have to be GPL, as long as gmake/g++ are only used to process/compile your code and your own code doesn't integrate the source for gmake/g++, ie gdc, which is almost never the case. Pardon? (I don't understand what point you are trying to put across about gdc, so I think it might be wrong ;-) You seem to have a lot of problems reading what's written. ;) The point was that if you are distributing dmd and phobos source with GPL binary tools like gmake or g++, which are then only compiled by those binaries, there is no problem with the GPL. You only need to provide the source for gmake and g++. If you were distributing gdc, which actually integrates with the same compiler backend source as g++, then you have to include the source for the gdc frontend and whatever other glue files it uses. Since most source code doesn't integrate with the gcc compiler backend, the GPL licensing of gmake/g++ is not a problem for most projects, including dmd. On Tuesday, 13 August 2013 at 16:11:44 UTC, H. S. Teoh wrote: On Tue, Aug 13, 2013 at 11:55:12AM +0200, Joakim wrote: [...] Personally, I like the D-based build system idea. Distribute dmd/phobos with a D-based build tool like dub, which has been compiled ahead of time for each supported platform and will compile D for you, if you want. Of course, this means that you'll still need to maintain makefiles on the D build machines that will build dub for the D maintainers to distribute, but it isolates all the complexity of makefiles from end users, so they don't have to touch any of that stuff. Whether that ease of use is worth the extra effort, I don't know. There's no need to maintain any makefiles once the D build tool is usable. As long as you have a working binary of dmd that can compile the tool, that's good enough. I thought you'd still need the makefiles around for the rare occasion when you bootstrap to a new platform, as the D-based build tool won't compile there initially. Perhaps I'm wrong, I don't know much about all the vagaries involved with bootstrapping. On Tuesday, 13 August 2013 at 18:10:06 UTC, Walter Bright wrote: On 8/13/2013 2:55 AM, Joakim wrote: On Tuesday, 13 August 2013 at 08:30:26 UTC, Walter Bright wrote: On 8/12/2013 11:48 PM, Jacob Carlborg wrote: On 2013-08-13 02:42, Andrei Alexandrescu wrote: Is is possible from a licensing standpoint to just distribute a copy of gmake built by gnuwin? I don't see why we couldn't do that. It's a completely separate tool and shouldn't infect anything else. We might need to accompany it with a license file and a link to the source code to be on the safe side. Again, read my reply to Brad in this thread. Presumably you are referring to this quote, which does not show up as a reply? Nobody seems to have read it or be able to find it, it has no replies, so I quote it here: I think we've all seen that post. The problem is that Andrei, and Jacob later, were only asking about licensing issues with gmake, but your pasted response to Brad didn't mention licensing. You're probably right that distributing gmake is problematic on technical and ease of use grounds. I was just making a narrow point that the GPL likely isn't an issue, which is what Andrei and Jacob asked about.
Re: Ideas for a brand new widget toolkit
On Tuesday, 13 August 2013 at 19:21:31 UTC, Michael wrote: Maybe a port of Fltk library? Small and good enough. There is a C++ GUI framework (BSD license) with good design and native controls http://vcf-online.org/. Is it good enough for making a partial port?
