Re: Byte Order Swapping Function

[Jonathan M Davis]

On Wednesday 13 July 2011 23:37:02 Andrew Wiley wrote:
> Hey, does anyone else thing a function like this belongs in Phobos, and if
> so, where do you think it should go?
> 
> T ntoh(T)(T val) if (__traits(isArithmetic, T)) {
> version(BigEndian) {
>  return val;
> }
> else version (LittleEndian) {
>  ubyte[] arr = (cast(ubyte*)&val)[0 .. T.sizeof];
> ubyte temp;
> for(int i = 0; i < T.sizeof/2; i++) {
>  temp = arr[i];
> arr[i] = arr[T.sizeof - i - 1];
> arr[T.sizeof - i - 1] = temp;
>  }
> return val;
> }
>  else static assert(0, "Are you sure you're using a computer?");
>  }
> 
> I was looking for something along these lines in the docs today and couldn't
> find it. It looks like there's a stream in std.stream to do this, but,
> well, I think we've all been pretending std.stream doesn't exist for a
> while now.

core.sys.posix.arpa.inet.d
std.c.windows.winsock.d

- Jonathan M Davis

Re: Prototype buildsystem "Drake"

[Russel Winder]

Nick,

On Wed, 2011-07-13 at 17:41 -0400, Nick Sabalausky wrote:
[ . . . ]
> Yea, D is likely to be a little more verbose than what could be done in Ruby 
> (or Python). Personally, I think that's well worth it, though. I don't know 
> how many others would agree or not.
[ . . . ]

You might want to take a quick look at SBT -- the standard Scala build
framework.  It's advocates started it because Ant and Maven are XML hell
and are generally problematic, and Gradle is build on Java and Groovy,
and (as you might expect) Scala folk abhor all things dynamic (i.e.
Groovy) and insist on static type checking.  I have some doubts about
the huge downloads they dump into each project hierarchy, but there is
no doubt that they have made excellent use of a statically type language
to create a DSL for building Scala things.

If D can be used to go down this sort of road, and if it can support the
build and install facilities of SCons and Waf, then it could be a
winner. 

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


signature.asc
Description: This is a digitally signed message part

Re: Re Build system requirements [ was Re: Prototype buildsystem "Drake" ]

[Russel Winder]

On Wed, 2011-07-13 at 20:32 +0200, Jacob Carlborg wrote:
[ . . . ]
> I think that one of the problem with these language independent build 
> tools is that they don't make it as easy as it could, because they 
> usually don't know enough about a given language.

This is generally due to incomplete support in the tools, this is not a
problem with general build frameworks per se.  In systems such as Waf
and SCons, the framework provides facilities for creating tools and for
those tools to build DAGs that then get "resolved" in the second phase
of activity.  The language specific tool does things as a first phase of
activity -- i.e. building the DAG.  The tools should realize all the
language specific things that that languages users needs and/or the
language expects.  Anything that is not handled is a problem that should
be fixed by the tool maintainer.

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


signature.asc
Description: This is a digitally signed message part

Byte Order Swapping Function

[Andrew Wiley]

Hey, does anyone else thing a function like this belongs in Phobos, and if
so, where do you think it should go?

T ntoh(T)(T val) if (__traits(isArithmetic, T)) {
version(BigEndian) {
 return val;
}
else version (LittleEndian) {
 ubyte[] arr = (cast(ubyte*)&val)[0 .. T.sizeof];
ubyte temp;
for(int i = 0; i < T.sizeof/2; i++) {
 temp = arr[i];
arr[i] = arr[T.sizeof - i - 1];
arr[T.sizeof - i - 1] = temp;
 }
return val;
}
 else static assert(0, "Are you sure you're using a computer?");
 }

I was looking for something along these lines in the docs today and couldn't
find it. It looks like there's a stream in std.stream to do this, but, well,
I think we've all been pretending std.stream doesn't exist for a while now.

Re: Strange gtkd behaviour

[maarten van damme]

when I leave destroy out the inputbox always stays visible even after I've
pressed ok.
here are the other files
http://dl.dropbox.com/u/15024434/Main.d
http://dl.dropbox.com/u/15024434/InputBox.d
http://dl.dropbox.com/u/15024434/MessageBox.d

> On 07/13/2011 11:00 PM, maarten van damme wrote:
>
>> Hello everyone,
>> I wrote two classes that inherit from the Mainwindow class, one is a
>> dialog that asks for your input and one is a plain old messagebox.
>> you can check out the input class here, I think thats the one with the
>> problem: 
>> http://dl.dropbox.com/u/**15024434/InputBox.d
>> or read the method most likely containing the error:
>> void onclicked(Button button){
>> *answer=input.getText();
>> destroy();
>> Main.quit();
>> }
>>
>> Then I have a main class where I create an inputbox and do Main.run(),
>> then when the user closes the window or presses ok everything after the
>> first main.run gets runned and that displays a messagebox that depends
>> on what the user entered followed by another Main.run();
>>
>> The problem is that when you press ok to close the first input window
>> and then close the next messagebox the program keeps running in memory.
>> Everything after the second Main.run never gets executed. When you
>> however close the first window using the close button and then close the
>> next messagebox the program terminates correctly.
>> I'm assuming I don't completely destroy the inputbox in the onclicked
>> method?
>>
>> If what I gave you is not enough I can give you the links to all the
>> files. Note that these classes are simply me learning gtkd and the d
>> language in general. If you see me doing something "dirty" or bad please
>> tell me so I learn a bit from my mistakes :)
>>
>> Maarten
>>
>
> I'm not sure if the Main.Quit gets executed after you've destroyed the
> InputBox, does it work correctly without the call to destroy?
>
> If not links to the other files would be helpfull.
>
> --
> Mike Wey
>

Re: Google +1 button for dpl.org?

[Nick Sabalausky]

"Jerry Quinn"  wrote in message 
news:ivlpao$1td9$1...@digitalmars.com...
> Hi folks,
>
> This seemed like the right place to toss this out...
>
> What do folks think of adding a google +1 button to 
> d-programming-language.org?  I just created a google+ account and 
> discovered it.
>

I strongly believe that Dig/Twitface/etc buttons DO NOT belong on misc pages 
across the web. If someone wants to go "marking" (or whatever the term is) 
different sites or pages with those services, then that belongs in something 
that's orthogonal to the pages themselves, such as a browser feature or 
plugin. The current trend of embedding it in each page on the web just drags 
us all back to the dark ages when every application came with it's own set 
of drivers or {insert your own example of absurd non-orthogonality}. It 
makes absolutely no sense.

Plus, I don't want to see us jump on the bandwagon of being yet another 
uppity trend-whorish site trying to cram those moronic "services" down 
everyone's throats.

*Cough* Umm, eerrmm...I mean..."I'm not sure if it's really something we 
should do." ;)

---
Not sent from an iPhone.

Google +1 button for dpl.org?

[Jerry Quinn]

Hi folks,

This seemed like the right place to toss this out...

What do folks think of adding a google +1 button to d-programming-language.org? 
 I just created a google+ account and discovered it.

Jerry

Re: Prototype buildsystem "Drake"

[Andrej Mitrovic]

Why build a tool anyway? Why not make a build library that we can use
in our build scripts?

Then we just import the library in our `build.d` script, write the
build script with the help of those library functions, and let the
user run `rdmd build.d`. No need to install any tools, just run rdmd.

I'm already using this approach for DWinProj., the only issue is that
the build script is a little large (~300 lines), but a lot of its code
could be put into a library (e.g. it has file traversing, parallel
builds, checking if all tools are present, checking if all libraries
are present, converting header files, etc..).

This would reduce the script to a few dozen lines. And that's probably
what I'll do to make my other projects easier to build.

Re: Prototype buildsystem "Drake"

[Andrei Alexandrescu]

On 7/13/11 5:32 PM, Ulrik Mikaelsson wrote:

Not trying to be argumentative, but what exactly do you see as the
gains in having a D-buildtool built in D (or D-specific build-tool in
any language, for that matter)?


I think it's a matter of positioning D and eating one's dogfood. If D is 
inconceivable for the kind of tasks that Python or Ruby are adept at, 
then sure, we could and should use either. On the other hand, if we 
advocate D as a good tool for short scripts, using the competition would 
hurt its brand.


Personally I believe D is plenty adequate for short scripts, of which 
I've written a ton of. So the path of least resistance for a package 
manager or for a build tool is D, not any other language. I'd question 
much harder the decision of using another language (D is, however, not a 
competitor for the likes of bash or make).



Seriously, I'm really asking, since
I'm having a hard time seeing it? Personally, I can only see the
drawbacks;

  * Building druntime and phobos might be difficult with a d-based buildtool


Druntime and phobos are distributed, and only built by a small number of 
users. We should not worry about building them. Also, a tool based on 
other language would require that language's environment to be already 
available.



  * The build-tool itself will need bootstrapping. A user that wants to
test some D-project, will first have to aquire (build) and install
some D-compiler with custom tools. Then install druntime with another
custom build-system. Then Phobos. Then drake. And THEN, the
application/library he/she was interested in. Shortening this path is
IMHO REALLY important to see more D adoption. From my personal
experience, convincing developers and testers to fight through this
path is HARD.


The installation provides the adequate tools. Installing and building 
from scratch is unnecessary. A user wanting to test some project needs 
to (a) install dmd using OS-specific installation tools (which we 
already have) and (b) use the provided tools to build whatever project.



  * Cross-language builds (project with bindings), and builds with
external targets might be more difficult than need be, if the "2nd"
language is not supported by drake.


This is a good advantage of generic build tools.


  * Verbose build-script is IMHO a _really_ undesireable trait.


I don't understand this.


  * How soon will I as a developer be able to "just build" a D-binding
to a C++-app (with needed C-glue-code) in Drake? Will a user of, say
Gentoo, be able to count on this working in his/her envrironment too?


This pretty much depends on the capabilities of the tool, which would 
have to be fairly D-specific.



  * Non-compilation actions will have to be reimplemented; document
generation, test execution, install-tasks following OS-specific
install procedures (XDG-guidelines etc.), ...


Here you're conflating the capabilities of the tool with the 
capabilities of the _langauge_ used to implement the tool.



IMHO, it sounds like a case of the NIH-syndrome, but I might be
missing something obvious?


I see no NIH here. D is an ample language scaling up to large programs 
and down to scripts. If the question is to build a tool from scratch, D 
is the obvious choice and any other choice is just odd. It's like some 
tools I've seen (none successful) that required the competition's 
product to be installed in order to work.



Andrei

Re: D users on Google+

[Mike Parker]

On 7/14/2011 9:10 AM, Tyro[a.c.edwards] wrote:

On 7/13/2011 5:52 PM, simendsjo wrote:

Are there any D users on Google+ I can stalk?
The only one I found was Andrei Alexandrescu, but as he works at
Facebook, I doubt he'll be posting much.



An invite would be appreciated... edwards [dot] ac [at] gmail [dot] com



Done.

Re: D users on Google+

[Mike Parker]

On 7/14/2011 3:59 AM, simendsjo wrote:

On 13.07.2011 19:22, Graham Fawcett wrote:

If invites are in good supply, I would appreciate one too.:)


Done. I have no idea what the limit is, but I have obviously not hit it
yet...


They seem to be unlimited, but they do get turned off every now and 
again for a day or two at a time.

Re: d-p-l.org statement.html

[Jonathan M Davis]

On Wednesday 13 July 2011 21:49:00  wrote:
> http://www.d-programming-language.org/statement.html
> 
> Scroll down to the bottom. Looks like someone committed a file that had
> merge markup in it. I'm not even sure how git would let you do this.

Easily. When it gives you a merge conflict, you just commit the file generated 
from the merge without dealing with the conflicts - or you do try and deal with 
the conflicts but you miss one. That sort of thing is caught very easily with 
code, because it's not going to compile with all of those >> and 
<<< in the file. ddoc, on the other hand, can legally contain >>> and 
<<<, so the documentation compiled just fine. No one caught it, and it 
ended up in the master repository.

-  Jonathan M Davis

d-p-l.org statement.html

[Johann MacDonagh]

http://www.d-programming-language.org/statement.html

Scroll down to the bottom. Looks like someone committed a file that had 
merge markup in it. I'm not even sure how git would let you do this.

popcnt

[Todd VanderVeen]

I see some recent additions were made to the inline assembler. Are there any
near term plans to support popcnt?

Re: D users on Google+

[Tyro[a.c.edwards]]

On 7/13/2011 5:52 PM, simendsjo wrote:

Are there any D users on Google+ I can stalk?
The only one I found was Andrei Alexandrescu, but as he works at
Facebook, I doubt he'll be posting much.



An invite would be appreciated... edwards [dot] ac [at] gmail [dot] com

Re: Prototype buildsystem "Drake"

[David Nadlinger]

On 7/13/11 11:41 PM, Nick Sabalausky wrote:

"getDCompiler" seems unnecessary, both ldc and gdc have a dmd compatible
wrapper, ldmd and gdmd. These wrappers takes the same flags as dmd and
translate them to the correct "native" flags.



That's great, I didn't know that. […]


Be aware though that neither of them supports the -lib switch. By the 
way, does anyone have a wrapper emulating it for LDC lying around? That 
way, the Phobos build system wouldn't have to be duplicated for it, and 
e.g. the test suite could be built easily.


David

Re: Prototype buildsystem "Drake"

[Chris Molozian]

I completely agree. I definitely believe that work on a new build tool 
is worthwhile especially if it has built in support for D. It's a shame 
that so many build tools at the moment are being developed using 
interpreted languages, it's obviously for the benefits of creating DSLs 
that extend the base language itself. They tend to suffer from slowness 
though (my subjective opinion ;-) ).


I don't think building the tool in D is a good idea either for reasons 
mentioned by Ulrik. It's worth considering using Lua 
 or Io  for the build 
description language but writing the tool in C (or other).


Cheers,

Chris


On 07/13/11 23:32, Ulrik Mikaelsson wrote:

2011/7/13 Nick Sabalausky:

"Jacob Carlborg"  wrote in message
news:ivke5k$2m78$1...@digitalmars.com...

First I have to say that I know you are doing this because you want to use
D as the language for the build scripts. The reason I did choose Ruby
because I think D will be too verbose and when I'm looking at drakefile.d
I do think it's too verbose.

Yea, D is likely to be a little more verbose than what could be done in Ruby
(or Python). Personally, I think that's well worth it, though. I don't know
how many others would agree or not.


Not trying to be argumentative, but what exactly do you see as the
gains in having a D-buildtool built in D (or D-specific build-tool in
any language, for that matter)? Seriously, I'm really asking, since
I'm having a hard time seeing it? Personally, I can only see the
drawbacks;

  * Building druntime and phobos might be difficult with a d-based buildtool
  * The build-tool itself will need bootstrapping. A user that wants to
test some D-project, will first have to aquire (build) and install
some D-compiler with custom tools. Then install druntime with another
custom build-system. Then Phobos. Then drake. And THEN, the
application/library he/she was interested in. Shortening this path is
IMHO REALLY important to see more D adoption. From my personal
experience, convincing developers and testers to fight through this
path is HARD.
  * Cross-language builds (project with bindings), and builds with
external targets might be more difficult than need be, if the "2nd"
language is not supported by drake.
  * Verbose build-script is IMHO a _really_ undesireable trait.
  * How soon will I as a developer be able to "just build" a D-binding
to a C++-app (with needed C-glue-code) in Drake? Will a user of, say
Gentoo, be able to count on this working in his/her envrironment too?
  * Non-compilation actions will have to be reimplemented; document
generation, test execution, install-tasks following OS-specific
install procedures (XDG-guidelines etc.), ...

IMHO, it sounds like a case of the NIH-syndrome, but I might be
missing something obvious?

Re: Prototype buildsystem "Drake"

[Nick Sabalausky]

"Jacob Carlborg"  wrote in message 
news:ivkpdp$8dj$1...@digitalmars.com...
>>
>> FWIW, my Drake system takes that as a high priority, too. For example, if
>> you have project "foo", then you can get the cross-platform binary 
>> filename,
>> object filename, shared lib filename, static lib filename, etc like this:
>>
>> "foo".exe  // "foo.exe" or "foo"
>> "foo".obj  // "foo.obj" or "foo.o"
>> "foo".lib  // "foo.lib" or "foo.a"
>> "foo".slib  // "foo.dll" or "foo.so"
>> "foo".bat  // "foo.bat" or "foo"
>> "foo".sh   // "foo.bat" or "foo.sh"
>
> Don't forget "foo.dylib" on Mac OS X.
>

Thanks, I didn't know about that. Does OSX use .dylib instead of .so, or is 
it another thing that it has in addition to .so?

Are there any other OSX-specific (or BSD-specific, for that matter) 
extensions to be aware of? Until now, I thought it just used all the same 
extensions as Linux.

Oh also, to Posix-people: Could "slib" be easily confused as being to "lib" 
what "sbin" is to "bin"?

Re: Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

2011/7/13 Nick Sabalausky :
> "Jacob Carlborg"  wrote in message
> news:ivke5k$2m78$1...@digitalmars.com...
>>
>> First I have to say that I know you are doing this because you want to use
>> D as the language for the build scripts. The reason I did choose Ruby
>> because I think D will be too verbose and when I'm looking at drakefile.d
>> I do think it's too verbose.
>
> Yea, D is likely to be a little more verbose than what could be done in Ruby
> (or Python). Personally, I think that's well worth it, though. I don't know
> how many others would agree or not.
>

Not trying to be argumentative, but what exactly do you see as the
gains in having a D-buildtool built in D (or D-specific build-tool in
any language, for that matter)? Seriously, I'm really asking, since
I'm having a hard time seeing it? Personally, I can only see the
drawbacks;

 * Building druntime and phobos might be difficult with a d-based buildtool
 * The build-tool itself will need bootstrapping. A user that wants to
test some D-project, will first have to aquire (build) and install
some D-compiler with custom tools. Then install druntime with another
custom build-system. Then Phobos. Then drake. And THEN, the
application/library he/she was interested in. Shortening this path is
IMHO REALLY important to see more D adoption. From my personal
experience, convincing developers and testers to fight through this
path is HARD.
 * Cross-language builds (project with bindings), and builds with
external targets might be more difficult than need be, if the "2nd"
language is not supported by drake.
 * Verbose build-script is IMHO a _really_ undesireable trait.
 * How soon will I as a developer be able to "just build" a D-binding
to a C++-app (with needed C-glue-code) in Drake? Will a user of, say
Gentoo, be able to count on this working in his/her envrironment too?
 * Non-compilation actions will have to be reimplemented; document
generation, test execution, install-tasks following OS-specific
install procedures (XDG-guidelines etc.), ...

IMHO, it sounds like a case of the NIH-syndrome, but I might be
missing something obvious?

Re: Prototype buildsystem "Drake"

[Chris Molozian]

I'm glad the feedback helped, this may be of use to help in abstracting 
away platform specific configuration: 
http://public.perforce.com/public/jam/src/Jambase


Cheers,

Chris


On 07/13/11 19:31, Nick Sabalausky wrote:

"Chris Molozian"  wrote in message
news:mailman.1595.1310554903.14074.digitalmar...@puremagic.com...

I asked about build tools for D on the mailing list a while ago. I
needed a solution that allowed me to mix C++ and D builds in a
cross-platform way with minimum fuss. You can find the discussion about
it here

(you were also a part of it IIRC). My biggest requirement at the time was:

  * Keeping platform checks e.g. IF (MAC) {} ELSE IF(LINUX) {} ... etc.
to an absolute minimum. What's the point in a cross-platform
language if when you build projects in it you need to write a short
essay for the build system...

FWIW, my Drake system takes that as a high priority, too. For example, if
you have project "foo", then you can get the cross-platform binary filename,
object filename, shared lib filename, static lib filename, etc like this:

"foo".exe  // "foo.exe" or "foo"
"foo".obj  // "foo.obj" or "foo.o"
"foo".lib  // "foo.lib" or "foo.a"
"foo".slib  // "foo.dll" or "foo.so"
"foo".bat  // "foo.bat" or "foo"
"foo".sh   // "foo.bat" or "foo.sh"

And new ones are easy to define:



I also intend to make sure that invoking "./blah" works on Windows.


  * Pre-built binaries available to all platforms (or as many as possible).


With Drake, the only pre-built binaries that are needed are DMD. The drake
command itself is a trivial one-line shell/batch script that invokes RDMD to
build+run the drakefile (which imports the rest of drake).

Of course, something still needs to be done to set up the DRAKE env var to
point to the Drake directory (or at least do something to get the path to
Drake into the -I arg sent to RDMD...) Not entirely sure how I want to do
that, although I think I have one idea.


In the end I settled for Jam (ftjam)
, it works tremendously well.
It's easy to get binaries for almost any operating system (especially
with projects like homebrew  for Mac).
I have very few gripes with it:

  * The build description language is very simple (once you fully grok
it), but could have done with a lot more example-based documentation.
  * It's missing a few features like recursive-directory scanning (for
source files), and the ability to pipe the output from a program
into a variable in the build script (e.g. C++FLAGS = `llvm-config
--cxxflags`).
  * A convenient way to force all generated object and library files
into a dedicated build folder. It's possible but not very easy to do.
  * I'm a big fan of convention over configuration, I know it's a very
subjective topic but I like the way Maven3 and Gradle assume a
project structure (that you can deviate from if you need to). This
usually requires very good supporting documentation.

The build script I put together for my project looked like this,
http://mysticpaste.com/private/TCcTE6KGxn .


Interesting points to keep in mind, thanks. After recently looking at Waf, I
do agree with you that it'd be nice to, as you say, "assume a project
structure (that you can deviate from if you need to)". Definitely some
benefits to be gained from that.

Re: Time for Phobos CTFE-ability unittests...right? RIGHT?

[Jonathan M Davis]

On 2011-07-13 13:58, filgood wrote:
> Jonathan,
> 
> Given that D2 is now the main version, would it not be possible - maybe
> in the future - if big changes like the CTFE work by Don are planned to
> bring to do this in a 2.1 release of D (and once stable bump to a 2.2
> release or so)... While the big changes happen in 2.1, the 2 releases
> would only hold bug fixes?

D versioning doesn't work that way. Currently, we have 1.069 for D1 and 2.054 
for D2. The next version of D2 will be 2.055. I don't know exactly what 
Walter's plans are, but it looks to me like the idea is that 2.100 will follow 
2.099. But regardless, D is still in development, and CTFE happens to be one 
one of its less stable elements. A lot of work is being done on it, and it 
will probably stabilize relatively soon, but until it does, I don't expect 
that we'll be making any guarantees about what will or won't be CTFEable. 
Certainly, Don has been opposed to such suggestions thus far. I hope that once 
it's more stable, we'll be able to have unit tests in Phobos to guarantee that 
at least some set of functions stay CTFEable if they're already CTFEable, but 
we're just not going to make any such guarantees before CTFE is more stable.

Not to mention, while most stuff in D is relatively stable, and the language 
spec really shouldn't be changing much - if at all - at this point, both the 
compiler and libraries are still under heavy development. Breaking changes 
should be rare, but they do happen. And newer and/or fancier features are the 
ones which are most likely to break. CTFE happens to be one of them. There are 
a couple of others (alias this and inout) which aren't even completely 
implemented yet. So, it's questionable if talking about D2 as if it were 
stable is a good idea. It's getting close. IIRC, in a recent discussion on it, 
Don thought that it would reach that point before the end of the year, but 
some features just aren't yet stable enough to be guaranteed to continue to 
work exactly as they do now. Fortunately, that list should be rather short. 
But CTFE is on it.

So, we're not going to fork D2 at this point and have a 2.0 which only has bug 
fixes and 2.1 which has new features. We're fast approaching the point where 
what we have will be stable and there shouldn't be any big breaking changes 
(big breaking changes are actually pretty rare as it is at this point), but 
we're not going to effectively fork development to provide a more stable 
branch for a feature for which we're not yet giving guarantees about its 
stability.

I _do_ think that having unit tests in Phobos for CTFEability is a good idea, 
but until Don says that CTFE is stable enough for that, we're not going to do 
it. I believe that he's on vacation at the moment (which is presumably why he 
hasn't said anything on this thread), and maybe he can be persuaded once he's 
back, but the last time that he had anything to say about it, he was against 
the idea.

- Jonathan M Davis

Re: Prototype buildsystem "Drake"

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:ivl4f8$t29$1...@digitalmars.com...
> "jdrewsen"  wrote in message 
> news:ivl1gp$o1v$1...@digitalmars.com...
>>
>> A good start I think. The first thing that I think should be fixed is the 
>> naming.
>>
>> Drake should be called dbuild
>> Orb should be called dpack
>>
>> You read the name and you have an idea of what it does - nothing fancy.
>>
>
> I think that's an excellent point. Only thing: Is "dbuild" already taken? 
> Also I'd hate to claim that name if nobody ended up liking it ;)
>

I mean, if nobody ended up liking the tool. A tool with an official-sounding 
name like "dbuild" should be something with a strong following. 

Re: Prototype buildsystem "Drake"

[Nick Sabalausky]

"jdrewsen"  wrote in message 
news:ivl1gp$o1v$1...@digitalmars.com...
>
> A good start I think. The first thing that I think should be fixed is the 
> naming.
>
> Drake should be called dbuild
> Orb should be called dpack
>
> You read the name and you have an idea of what it does - nothing fancy.
>

I think that's an excellent point. Only thing: Is "dbuild" already taken? 
Also I'd hate to claim that name if nobody ended up liking it ;)


> People coming from ruby may recognize the drake name, but I guess many c++ 
> peoply have no idea.
> Orb is not derived from anything I guess.
>
> Regarding drake itself:
>
> I really like how general it is but at the same time miss some simplicity. 
> "Make the common task easy and the uncommon possible"
>

Yea, that's a fair point. But I figure I should start with general and then 
build the simple/structured on top of that, rather than trying to go the 
other way around.


> Some steps that you could take in that direction is to predefine commonly 
> used modes like "build", "clean" etc. And the define buildMode(), 
> cleanMode() as builtins. That would get rid of the "immutable modes = ..." 
> lines in simple projects.
>
> Maybe let the wrapper that loads the drakefile insert the "import 
> drake.all" and also wrap the "void drakefile() { ... }" around the file. 
> Maybe that is what your have already listed on the todo?
>
> As suggested elsewhere you could get rid of target!Task or target!File and 
> just defined the target() and file() functions.
>
> Also a convenience could be to just include all .d files found for an exe 
> target if no .d files are explicitly listed.
>
> I guess this would make it possible to have a drakefile as simple as:
>
> task("appA".exe);
>

Thanks, definitely things to think about.

>
> It seems to lack the configure part of the build process e.g. locate the 
> libfoobar.a file for linking or locate a D compiler.
>

Hmm, yea, configure didn't even occur to me. I think it could acually be 
done as just another File target that everything else depends on. Only thing 
is then you'd have to save/load the configuration file manually, so maybe 
there should be some convenience mechnism for that (Maybe utilizing Jacob's 
Orange serialization library once that rewrite is done? Or maybe that would 
be overkill? Is there some INI-file util, or am I just imagining that?)

Re: Strange gtkd behaviour

[Mike Wey]

On 07/13/2011 11:00 PM, maarten van damme wrote:

Hello everyone,
I wrote two classes that inherit from the Mainwindow class, one is a
dialog that asks for your input and one is a plain old messagebox.
you can check out the input class here, I think thats the one with the
problem: http://dl.dropbox.com/u/15024434/InputBox.d
or read the method most likely containing the error:
void onclicked(Button button){
*answer=input.getText();
destroy();
Main.quit();
}

Then I have a main class where I create an inputbox and do Main.run(),
then when the user closes the window or presses ok everything after the
first main.run gets runned and that displays a messagebox that depends
on what the user entered followed by another Main.run();

The problem is that when you press ok to close the first input window
and then close the next messagebox the program keeps running in memory.
Everything after the second Main.run never gets executed. When you
however close the first window using the close button and then close the
next messagebox the program terminates correctly.
I'm assuming I don't completely destroy the inputbox in the onclicked
method?

If what I gave you is not enough I can give you the links to all the
files. Note that these classes are simply me learning gtkd and the d
language in general. If you see me doing something "dirty" or bad please
tell me so I learn a bit from my mistakes :)

Maarten


I'm not sure if the Main.Quit gets executed after you've destroyed the 
InputBox, does it work correctly without the call to destroy?


If not links to the other files would be helpfull.

--
Mike Wey

Re: Prototype buildsystem "Drake"

[Nick Sabalausky]

"Jacob Carlborg"  wrote in message
news:ivke5k$2m78$1...@digitalmars.com...
>
> First I have to say that I know you are doing this because you want to use 
> D as the language for the build scripts. The reason I did choose Ruby 
> because I think D will be too verbose and when I'm looking at drakefile.d 
> I do think it's too verbose.

Yea, D is likely to be a little more verbose than what could be done in Ruby 
(or Python). Personally, I think that's well worth it, though. I don't know 
how many others would agree or not.


> But instead of starting a debate between Ruby and D I'm going to give you 
> a few suggestions and comments instead.
>
> The minimal drakefile doesn't look that minimal.

I think I may be able to make the "immutable modes = [];" optional by 
checking for it with some compile-time reflecion.

The other parts I'll address further below...


> This is the idea I have for a minimal build script file:
>
> target("main.d"); // builds "main.d" as an executable
>
> Or:
>
> target("foobar"); // builds the directory "foobar" as a library
>
> DSSS did this very good.
>

I've never been very comfortable with build systems magically understanding 
and inferring all those details about a language and filetypes. It just 
feels too "magic", it's much more difficult to expand to new 
languages/tools, and every time I use a system like that I feel completely 
lost every time I need to include even just one custom buildstep.

However, Drake's design is expandable. Add-on modules can be created that 
define new target types, so you could do:

module drake_dlang;
class DLang : Target (or File)
{
//...etc
}

target!DLang("main.d");

And that would essentially wrap a File target, adding in any D-specific 
things such as "The target is 'main.exe'". And if you really wanted you 
could take it one more step and do:

void targetD(string source)
{
target!DLang(source);
}

targetD("main.d");


Good add-ons could even be folded into the standard Drake.


> Now looking in the drakefile.d. You have targets and tasks all over the 
> place, almost every target has "Task" as a template parameter. Why is this 
> necessary? Have one function for targets and one for tasks. Example from 
> the drakefile.d:
>
> target!Task("upload", "all",
> (Target t)
> {
> system("ftp ...");
> }
> );
>
> Seems this could look like this:
>
> task("upload", "all", {
> system("ftp...");
> }); // if D just could get a better looking delegate syntax
>

Some Drake terminology first: Every "node" in the dependency tree is a 
"Target". There are three pre-defined types of targets: "Task", "File" and 
"Dir". Other new target types can also be defined. So the template param is 
due to that.

However, I suppose it may be a good idea for every target type to come with 
a matching shortcut:

alias target!Task task;
alias target!File file;
alias target!Dir  dir;

Then your "task("upload", ...);" example should work.

I agree that D's delegate syntax could be better. I think something like 
your example would be possible, but I ran into what seemed like some type 
inference limitations with all the overloading and templates, etc.


> "getDCompiler" seems unnecessary, both ldc and gdc have a dmd compatible 
> wrapper, ldmd and gdmd. These wrappers takes the same flags as dmd and 
> translate them to the correct "native" flags.
>

That's great, I didn't know that. But, you still have to say "ldmd" or 
"gdmd" instead of "dmd". And since the idea of "getDCompiler" is to allow 
the user to select which compiler to use (if the drakefile's author wants to 
support that), something roughly like "getDCompiler" may still be needed, 
albeit in a greatly simplified form.

In any case, it was just an example of using the "modes" feature.


> The "drakfile" function seems unnecessary. I would use a string import (or 
> what it's called), importing the whole build script into a method in a 
> class. All code in the "drakefile" function would instead be at top level.
>

I'm not entirely opposed to that idea, but here are the (perhaps minor?) 
reasons I did it this way:

- Using "import" inside functions is brand-new and likely still buggy. And 
unless I'm mistaken, I think there's other problems that still exist with 
using the same code inside a function as outside (such as some 
order-of-declaration limitations, IIRC). I wanted to get moving on something 
that would work reliably right away without being too sensitive to bleeding 
edge-cases. I figured if all that gets sorted out later on, then maybe a 
Drake v2 could go that route.

- I wasn't sure if a D file that isn't strictly a proper D file would be too 
weird, too confusing, too magical, or would confuse the fuck out of advanced 
IDE's.

If those are really just totally bullshit reasons, then I'm certainly open 
to the idea of doing it as you suggest.


> 

Re: Prototype buildsystem "Drake"

[jdrewsen]

Den 13-07-2011 03:02, Nick Sabalausky skrev:

The recent discussions about package managers and buildsystems has prompted
me to get off my ass (or rather, *on* my ass as per how programming is
usually performed...) and start on the D-based rake-inspired buildtool I've
been meaning to make for awhile now. It's not actually usable yet, but
there's a sample drakefile demonstrating everything, and it does actually
compile and run (but just doesn't build the dependency tree or actually run
any of the build steps). *Should* work on Posix, but I only tested on
Windows, so I may have fucked up the Posix version...

Apologies to Jacob Carlborg for the name being so close to "dake". Didn't
really know what else to call it ("Duck", maybe?) Like dake, it's inspired
by Ruby's Rake. But unlike dake, the buildscript is written in D instead of
Ruby, which was my #1 reason for making a Rake alternative.

Before I go implemeting everything, I'd like to get input on it. Is it
something that could be a major D tool?

Overview of Drake and links to all the code are here:

https://bitbucket.org/Abscissa256/drake/wiki/Home


A good start I think. The first thing that I think should be fixed is 
the naming.


Drake should be called dbuild
Orb should be called dpack

You read the name and you have an idea of what it does - nothing fancy.

People coming from ruby may recognize the drake name, but I guess many 
c++ peoply have no idea.

Orb is not derived from anything I guess.

Regarding drake itself:

I really like how general it is but at the same time miss some 
simplicity. "Make the common task easy and the uncommon possible"


Some steps that you could take in that direction is to predefine 
commonly used modes like "build", "clean" etc. And the define 
buildMode(), cleanMode() as builtins. That would get rid of the 
"immutable modes = ..." lines in simple projects.


Maybe let the wrapper that loads the drakefile insert the "import 
drake.all" and also wrap the "void drakefile() { ... }" around the file. 
Maybe that is what your have already listed on the todo?


As suggested elsewhere you could get rid of target!Task or target!File 
and just defined the target() and file() functions.


Also a convenience could be to just include all .d files found for an 
exe target if no .d files are explicitly listed.


I guess this would make it possible to have a drakefile as simple as:

task("appA".exe);


It seems to lack the configure part of the build process e.g. locate the 
libfoobar.a file for linking or locate a D compiler.


Thanks,
/Jonas

Strange gtkd behaviour

[maarten van damme]

Hello everyone,
I wrote two classes that inherit from the Mainwindow class, one is a dialog
that asks for your input and one is a plain old messagebox.
you can check out the input class here, I think thats the one with the
problem: http://dl.dropbox.com/u/15024434/InputBox.d
or read the method most likely containing the error:
void onclicked(Button button){
*answer=input.getText();
destroy();
Main.quit();
 }

Then I have a main class where I create an inputbox and do Main.run(), then
when the user closes the window or presses ok everything after the first
main.run gets runned and that displays a messagebox that depends on what the
user entered followed by another Main.run();

The problem is that when you press ok to close the first input window and
then close the next messagebox the program keeps running in memory.
Everything after the second Main.run never gets executed. When you however
close the first window using the close button and then close the next
messagebox the program terminates correctly.
I'm assuming I don't completely destroy the inputbox in the onclicked
method?

If what I gave you is not enough I can give you the links to all the files.
Note that these classes are simply me learning gtkd and the d language in
general. If you see me doing something "dirty" or bad please tell me so I
learn a bit from my mistakes :)

Maarten

Re: Time for Phobos CTFE-ability unittests...right? RIGHT?

[filgood]

Jonathan,

Given that D2 is now the main version, would it not be possible - maybe 
in the future - if big changes like the CTFE work by Don are planned to 
bring to do this in a 2.1 release of D (and once stable bump to a 2.2 
release or so)... While the big changes happen in 2.1, the 2 releases 
would only hold bug fixes?


~ filgood


On 13/07/2011 00:29, Jonathan M Davis wrote:

On 2011-07-12 16:17, Andrej Mitrovic wrote:

I don't understand what strip() could be doing to break CTFE anyway?


Don has been making huge changes to CTFE. Stuff that didn't used to compile,
now complie. Stuff which compiled but shouldn't have now doesn't compile.
There's probably stuff which used to compile and should still compile which
doesn't compile now too. But with all of those changes, I'm not sure that it's
at all reasonable to expect CTFE-ability to be stable. It should be heading in
that direction, but I'm not sure how stable Don considers it. Certainly, strip
could be failing for a perfectly legitimate reason, or it could be a bug. I
have no idea. But with all of the changes that have been being made to CTFE,
I'm not at all surprised if stuff has quit working. There's probably more that
works now that didn't before, but with all of the recent changes, breakage
doesn't surprise me one bit.

Having tests in Phobos for CTFE would catch many breakages, but if Don isn't
yet guaranteeing what can and can't be CTFEed by the compiler, then such
breakages could easily be because of fixes which made it so that stuff which
wasn't supposed to compiled but did stopped compiling. So, until Don thinks
that what he's been doing to CTFE is appropriately stable and can make
guarantees about what will and won't be CTFEable as far as language features
go, then Phobos can't make any guarantees about CTFEability.

So, basically, a lot of CTFE changes have been happening, and Don has said
pretty much said that we're not currently making guarantees about what's
CTFEable and what isn't. And until the changes stabilize and Don is willing to
make guarantees, Phobos can't guarantee anything about CTFE.

- Jonathan M Davis

Re: example on DMD 2.0 home page does NOT compile on linux

[Walter Bright]

On 7/13/2011 1:23 PM, mike wrote:

while I'm sure that I can fix is I think it's a little poor that the stock
examples on your website do not compile out of the tin.


Fixed. Thanks for letting us know.

Re: Orbit - Package Manager - Specification/ideas

[jdrewsen]

Den 13-07-2011 21:19, Jacob Carlborg skrev:

I've written a more formal specification of my ideas for a package
manager for D.

https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

Note that I am exploring the possibility of using D as the language for
all the files mentioned in the link above.

The current status is that building packages and installing them works,
but quite limited. No dependency tracking or central repository so far.

Please comment and suggest.


Nice work!

Orb - tool section:

Describe what the "use" command does. I guess it simply adds a required 
orb to the Orbfile in the current directory?


Orbfile section:

The "orb" command that accepts git/hg/svn repositories should also allow 
for a tag/commit parameter I think.


The "orb" commands second parameter could also be a list of serveral 
repositories to try in order for fallback.


I guess a user configuration file in ~/.orb could contain "source" 
commands as well.


Orb package section:

I think the versioning scheme should be set in stone actually. Most 
other packaging systems does that. It makes your life much easier.


Central repository section:

Please let us settle for one format for the metadata.xxx file. My vote 
is for json or yaml. XML is too verbose for my taste. I also think that 
it should be compressed e.g. metadata.json.bzip since it will quickly 
grow quite large and the packaging system has to be fast.


Maybe add the build revision on /orb/-_
since it is quite common reupload the same package version with at 
simple build fix.


Additionally the architecture should be added to the name:
/orb/-_-
Now it is just like how debian files look like :)

Maybe put the file in an arch subdir
/orb//-_

I'm really in favor of doing this in D instead of ruby though.

/Jonas

example on DMD 2.0 home page does NOT compile on linux

[mike]

I have just used the ubuntu package to install DMD64 D Compiler v2.054 on my
mint linux i7 laptop.
when I copy and paste the example from 
http://www.digitalmars.com/d/2.0/index.html
I get ;
mwynn@kraken ~/projects/my_lang/Dsrc $ dmd main.d
main.d(21): Error: constructor main.CmdLin.this (int argc, string argv) is not
callable using argument types (ulong,string)
main.d(21): Error: cannot implicitly convert expression (argc) of type ulong
to int
mwynn@kraken ~/projects/my_lang/Dsrc $ dmd
DMD64 D Compiler v2.054
Copyright (c) 1999-2011 by Digital Mars written by Walter Bright
Documentation: http://www.digitalmars.com/d/2.0/index.html
Usage:

while I'm sure that I can fix is I think it's a little poor that the stock
examples on your website do not compile out of the tin.
I have attached the file I tried to compile just incase my cut'n'paste has 
errors.
begin 644 main.d
M(R$O=7-R+V)I;B]D;60@+7)U;@HO*B!S:"!S='EL92!S8W)I<'0@PH@("`@
M=W)I=&5L;B@B2&5L;&\@5V]R;&0L(%)E;&]A9&5D(BD["@H@("`@+R\@875T
M;R!T>7!E(&EN9F5R96YC92!A;F0@8G5I;'0M:6X@9F]R96%C:`H@("`@9F]R
M96%C:"`H87)G8RP@87)G=CL@87)G7!E
M2!M86YA9V5M96YT"B`@("`@("`@9&5L971E
M(&-L.PH@("`@?0H*("`@("\O($YEF5D"B`@("`@("`@:6YT(&-O=6YT
M+"!A;&QO8V%T960["B`@("!]"@H@("`@+R\@3F5S=&5D(&9U;F-T:6]N2!W:71H("YL96YG=&@*("`@("`@("!S+F%L;&]C871E9"`]('1Y
M<&5O9BAA7!E('!R
M;W!EPH@("`@("`@(')E='5R;B!?87)G8R`K
M(#$["B`@("!]"@H@("`@PH@("`@("`@(')E
M='5R;B!?87)G=CL*("`@('T*"B`@("!S=')I;F<@"`](")N9"(["B`@("`@("`@
M("`@(&)R96%K.PH@("`@("`@("`@8V%S92`R.@H@("`@("`@("`@("!S=69F
M:7@@/2`B

Re: Orbit - Package Manager - Specification/ideas

[Nick Sabalausky]

"Andrej Mitrovic"  wrote in message 
news:mailman.1613.1310586759.14074.digitalmar...@puremagic.com...
> Just curious, why do people prefer using extensionless files? I mean,
> I can easily open them up in an editor, but I can't set up syntax
> highlighting without knowing what type the file is.

Programmer's Notepad 2 lets me map an extention *or* a filename to a syntax 
highlighting profile. But I agree, it's still easier to just use an existing 
extension. I suspect it's partly a just buildsystem tradition, and partly 
because it's not very common to use/need a buildscript with a name other 
than the standard one.

---
Not sent from an iPhone.

Re: Orbit - Package Manager - Specification/ideas

[Andrej Mitrovic]

Just curious, why do people prefer using extensionless files? I mean,
I can easily open them up in an editor, but I can't set up syntax
highlighting without knowing what type the file is.

Re: D users on Google+

[Graham Fawcett]

On Wed, 13 Jul 2011 20:59:49 +0200, simendsjo wrote:

> On 13.07.2011 19:22, Graham Fawcett wrote:
>> If invites are in good supply, I would appreciate one too.:)
> 
> Done. I have no idea what the limit is, but I have obviously not hit it
> yet...

many thanks, Simen, I look forward to giving it a try (and meeting you and the 
other D-listers there).

Regards,
Graham

Orbit - Package Manager - Specification/ideas

[Jacob Carlborg]

I've written a more formal specification of my ideas for a package 
manager for D.


https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D

Note that I am exploring the possibility of using D as the language for 
all the files mentioned in the link above.


The current status is that building packages and installing them works, 
but quite limited. No dependency tracking or central repository so far.


Please comment and suggest.

--
/Jacob Carlborg

Re: C# contracts video

[bearophile]

Robert Clipsham:

> Have C# contracts improved at all since I last used them?

I think they have not improved them a lot, lately.

Bye,
bearophile

Re: D users on Google+

[Robert Clipsham]

On 13/07/2011 19:59, simendsjo wrote:

On 13.07.2011 19:22, Graham Fawcett wrote:

If invites are in good supply, I would appreciate one too.:)


Done. I have no idea what the limit is, but I have obviously not hit it
yet...


Pretty sure it's unlimited, I'm sure there are enough of us to keep 
inviting D folk though ;D


--
Robert
http://octarineparrot.com/

Re: D users on Google+

[Robert Clipsham]

On 13/07/2011 09:52, simendsjo wrote:

Are there any D users on Google+ I can stalk?


I am, not that you'd want to stalk me.


The only one I found was Andrei Alexandrescu, but as he works at
Facebook, I doubt he'll be posting much.


Mark Zuckerberg himself uses Google+ ;p

--
Robert
http://octarineparrot.com/

Re: dmd linux makefile

[Robert Clipsham]

On 13/07/2011 16:14, Trass3r wrote:

Oh and any reason why it only uses -O2 in release mode?


-O2 is standard across most linux distributions. There's some discussion 
here: http://en.gentoo-wiki.com/wiki/CFLAGS#-O2_or_-O3.3F you can find 
more with some googling though.


--
Robert
http://octarineparrot.com/

Re: C# contracts video

[Robert Clipsham]

On 13/07/2011 02:35, bearophile wrote:

A long video presentation of C# contracts, "Compile-time Verification, It's Not Just 
for Type Safety Any More" (Jul 05, 2011), by Greg Young (the speaker is quite 
bombastic):
http://www.infoq.com/presentations/Contracts-Library

The compile-time error shown in the video at about 10 minutes and 40 seconds is 
doable in D with this idea I've shown:
http://d.puremagic.com/issues/show_bug.cgi?id=5906

While the error shown from 11.45 requires something much better, as the 
solver/inferencer used by them.

He says they are slowly adding contracts to all the dotnet framework.

He says (30 minutes 20 seconds) that most unittests become useless. The 
compiler even says some certain unittests can't fail (after statically 
verifying the contracts).

He says that all this stuff is still in its infancy (in dotnet, the Contracts 
library itself, etc).

He says that the dynamic keyword and the contracts, both added to C#4, are 
essentially one against each other.

Around 53.00 he explains the risks of overspecification in Contracts (that 
cause problems similar to writing too many unittests), or adding too much 
specific contracts to an interface, while they are fit for a single 
implementation of it.

Bye,
bearophile


Have C# contracts improved at all since I last used them? Last time I 
went near C# I was incredibly underwhelmed having used D.


--
Robert
http://octarineparrot.com/

Re: D users on Google+

[simendsjo]

On 13.07.2011 19:22, Graham Fawcett wrote:

If invites are in good supply, I would appreciate one too.:)


Done. I have no idea what the limit is, but I have obviously not hit it 
yet...

Re: Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-13 20:31, Nick Sabalausky wrote:

"Chris Molozian"  wrote in message
news:mailman.1595.1310554903.14074.digitalmar...@puremagic.com...

I asked about build tools for D on the mailing list a while ago. I
needed a solution that allowed me to mix C++ and D builds in a
cross-platform way with minimum fuss. You can find the discussion about
it here

(you were also a part of it IIRC). My biggest requirement at the time was:

  * Keeping platform checks e.g. IF (MAC) {} ELSE IF(LINUX) {} ... etc.
to an absolute minimum. What's the point in a cross-platform
language if when you build projects in it you need to write a short
essay for the build system...


FWIW, my Drake system takes that as a high priority, too. For example, if
you have project "foo", then you can get the cross-platform binary filename,
object filename, shared lib filename, static lib filename, etc like this:

"foo".exe  // "foo.exe" or "foo"
"foo".obj  // "foo.obj" or "foo.o"
"foo".lib  // "foo.lib" or "foo.a"
"foo".slib  // "foo.dll" or "foo.so"
"foo".bat  // "foo.bat" or "foo"
"foo".sh   // "foo.bat" or "foo.sh"


Don't forget "foo.dylib" on Mac OS X.

--
/Jacob Carlborg

Re: Prototype buildsystem "Drake"

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:ivkoms$7d9$1...@digitalmars.com...
>
> "foo".exe  // "foo.exe" or "foo"
> "foo".obj  // "foo.obj" or "foo.o"
> "foo".lib  // "foo.lib" or "foo.a"
> "foo".slib  // "foo.dll" or "foo.so"
> "foo".bat  // "foo.bat" or "foo"
> "foo".sh   // "foo.bat" or "foo.sh"
>
> And new ones are easy to define:
>

[Forgot to finish that thought:]

alias crossPlatformSuffix!(".obj", ".o") obj;

Re: Prototype buildsystem "Drake"

[Nick Sabalausky]

"Chris Molozian"  wrote in message 
news:mailman.1595.1310554903.14074.digitalmar...@puremagic.com...
>I asked about build tools for D on the mailing list a while ago. I
> needed a solution that allowed me to mix C++ and D builds in a
> cross-platform way with minimum fuss. You can find the discussion about
> it here
> 
> (you were also a part of it IIRC). My biggest requirement at the time was:
>
>  * Keeping platform checks e.g. IF (MAC) {} ELSE IF(LINUX) {} ... etc.
>to an absolute minimum. What's the point in a cross-platform
>language if when you build projects in it you need to write a short
>essay for the build system...

FWIW, my Drake system takes that as a high priority, too. For example, if 
you have project "foo", then you can get the cross-platform binary filename, 
object filename, shared lib filename, static lib filename, etc like this:

"foo".exe  // "foo.exe" or "foo"
"foo".obj  // "foo.obj" or "foo.o"
"foo".lib  // "foo.lib" or "foo.a"
"foo".slib  // "foo.dll" or "foo.so"
"foo".bat  // "foo.bat" or "foo"
"foo".sh   // "foo.bat" or "foo.sh"

And new ones are easy to define:



I also intend to make sure that invoking "./blah" works on Windows.

>  * Pre-built binaries available to all platforms (or as many as possible).
>

With Drake, the only pre-built binaries that are needed are DMD. The drake 
command itself is a trivial one-line shell/batch script that invokes RDMD to 
build+run the drakefile (which imports the rest of drake).

Of course, something still needs to be done to set up the DRAKE env var to 
point to the Drake directory (or at least do something to get the path to 
Drake into the -I arg sent to RDMD...) Not entirely sure how I want to do 
that, although I think I have one idea.

> In the end I settled for Jam (ftjam)
> , it works tremendously well.
> It's easy to get binaries for almost any operating system (especially
> with projects like homebrew  for Mac).
> I have very few gripes with it:
>
>  * The build description language is very simple (once you fully grok
>it), but could have done with a lot more example-based documentation.
>  * It's missing a few features like recursive-directory scanning (for
>source files), and the ability to pipe the output from a program
>into a variable in the build script (e.g. C++FLAGS = `llvm-config
>--cxxflags`).
>  * A convenient way to force all generated object and library files
>into a dedicated build folder. It's possible but not very easy to do.
>  * I'm a big fan of convention over configuration, I know it's a very
>subjective topic but I like the way Maven3 and Gradle assume a
>project structure (that you can deviate from if you need to). This
>usually requires very good supporting documentation.
>
> The build script I put together for my project looked like this,
> http://mysticpaste.com/private/TCcTE6KGxn .
>

Interesting points to keep in mind, thanks. After recently looking at Waf, I 
do agree with you that it'd be nice to, as you say, "assume a project 
structure (that you can deviate from if you need to)". Definitely some 
benefits to be gained from that.

Re: Re Build system requirements [ was Re: Prototype buildsystem "Drake" ]

[Jacob Carlborg]

On 2011-07-13 19:18, Russel Winder wrote:

On Wed, 2011-07-13 at 17:33 +0200, Jacob Carlborg wrote:


target("main.d"); // builds "main.d" as an executable


The SCons equivalent is:

Program ( 'main.d' )


Or:

target("foobar"); // builds the directory "foobar" as a library


SCons (and I think Waf as well) does not support this idea (at least
currently).  In SCons you have to say:

SharedLibrary ( 'libraryRootName' , Glob ( 'foobar/*.d' ) )
StaticLibrary ( 'libraryRootName' , Glob ( 'foobar/*.d' ) )

D support in Waf is currently far more sophisticated than that of SCons,
but is still based on being a bit more explicit that your proposal
above.


I think that one of the problem with these language independent build 
tools is that they don't make it as easy as it could, because they 
usually don't know enough about a given language.


DSSS works just the same, you specify a D file or a directory and it 
will compile it as an executable or a library. I don't think that a new 
build tool should do any worse than, for example, DSSS.


--
/Jacob Carlborg

Re: toStringz or not toStringz

[Steven Schveighoffer]

On Wed, 13 Jul 2011 13:32:56 -0400, Regan Heath   
wrote:


On Wed, 13 Jul 2011 17:00:39 +0100, Steven Schveighoffer  
 wrote:


How does your proposal know that a char * is part of a heap-allocated  
array?  If you are assuming the only case where char * is passed will  
be arr.ptr, then that doesn't cut it.  What if the compiler doesn't  
know where the char * came from?


See your Q and my A above ("char * foo" example).

The inherent problem of zero-terminated strings is that you don't know  
how long it is until you search for a zero.  If it's not properly  
terminated, then you are screwed.  That problem cannot be "solved",  
even with compiler help -- you can get situations where there is no  
more information other than the pointer.


Really?  But cant we obtain the GC lock and look them up, as mentioned  
above?  And isn't this exactly what toStringz will do when the  
programmer first of all curses because it has crashed, and then adds an  
explicit toStringz call?


Who said the char * points into GC memory?  It could point at stack  
memory, or static data in ROM.


-Steve

Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake"]

[Jacob Carlborg]

On 2011-07-13 19:27, Jonathan M Davis wrote:

On 2011-07-13 08:36, Jacob Carlborg wrote:

On 2011-07-13 07:28, Jonathan M Davis wrote:

On Wednesday 13 July 2011 06:12:58 Russel Winder wrote:

And, of course, I should have mentioned CMake and CMakeD.

The fact that I forgot, shows my prejudice against Makefile-based
systems and for direct DAG-based systems such as Gradle, SCons and Waf.
This though should not stop CMakeD being a part of this debate.

 From previous discussions, it seems that one of the primary reasons for
having


a D build tool in many people's minds is to also handle package
management of D libraries (like Haskell's cabal or rubygems for ruby).
And as great as cmaked, scons, gradle, waf, and other such tools may be,
they don't do that.

- Jonathan M Davis


I don't agree with that. I think a build tool should deal with single
files and building. A package manager should deal with packages (of
files). In Ruby, RubyGems is the package manager and Rake is the build
tool.


Well, I'm not advocating anything in particular. I was just pointing out that
a big part of the discussions on build tools has been package management of
libraries, and any build tool solution which doesn't at least integrate with
some sort of package management solution is likely to not be what at least
some people are looking for.


Ok, I see. I think as well that the build tool and package manager 
should interact with each other. For example, specifying package 
dependencies in the build script. But, I think they need to be separate 
and be usable on their own.



Personally, I don't generally use package management tools for handling
libraries even with languages that have such tools, and I don't generally use
much in the way of build tools either beyond simple scripts (primarily because
I don't generally have projects large enough for it to be an issue). As it
stands, if I were to choose a build tool for a larger project, I'd probably
choose CmakeD, but I'm not super-familiar with all of the tools out there and
haven't generally found much use for them.

I was just trying to point out that a fair bit of the discussion for such
tools in this list has related to package management, and Nick's solution
doesn't address that at all AFAIK.

- Jonathan m Davis


Ok, I see.

--
/Jacob Carlborg

Re: Is private import broken as well?

[Andrej Mitrovic]

See: http://d.puremagic.com/issues/show_bug.cgi?id=6180

Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake"]

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.1611.1310578056.14074.digitalmar...@puremagic.com...
> On 2011-07-13 08:36, Jacob Carlborg wrote:
>>
>> I don't agree with that. I think a build tool should deal with single
>> files and building. A package manager should deal with packages (of
>> files). In Ruby, RubyGems is the package manager and Rake is the build
>> tool.
>
> Well, I'm not advocating anything in particular. I was just pointing out 
> that
> a big part of the discussions on build tools has been package management 
> of
> libraries, and any build tool solution which doesn't at least integrate 
> with
> some sort of package management solution is likely to not be what at least
> some people are looking for.
>
> Personally, I don't generally use package management tools for handling
> libraries even with languages that have such tools, and I don't generally 
> use
> much in the way of build tools either beyond simple scripts (primarily 
> because
> I don't generally have projects large enough for it to be an issue). As it
> stands, if I were to choose a build tool for a larger project, I'd 
> probably
> choose CmakeD, but I'm not super-familiar with all of the tools out there 
> and
> haven't generally found much use for them.
>
> I was just trying to point out that a fair bit of the discussion for such
> tools in this list has related to package management, and Nick's solution
> doesn't address that at all AFAIK.
>

Fair enough. And yea, my solution doesn't even try to address package 
management since it considers that a separate issue. May have been a little 
misleading for me to bring up those discussions in the first place. Really 
what happened was just: For a long time I'd been meaning to make a Rake-like 
tool based on D, Jacob posted his Rake-like tool based on Ruby, and that lit 
a fire under me to finally get started on mine.

Although I have to admit, I've only now started to look at Waf. While I 
definitely still wouldn't want to use it for D projects (for reasons I've 
already mentioned), it does have some interesting design elements that I'm 
going to have to think about.

Is private import broken as well?

[Trass3r]

We all know that public, selective and static imports are broken  
(http://d.puremagic.com/issues/show_bug.cgi?id=314)
Also private imports are broken in some special cases:  
http://d.puremagic.com/issues/show_bug.cgi?id=313 &  
http://d.puremagic.com/issues/show_bug.cgi?id=1161


But apart from that it seemed to work so far.

Yet this works perfectly:

module testb;
Bla foo()
{
return Bla();
}

private struct Bla
{
void arg() {}
}

module test;
import testb;

void main()
{
foo().arg(); // I think this could be allowed
auto b = Bla(); // but this really shouldn't
}

Re: toStringz or not toStringz

[Regan Heath]

On Wed, 13 Jul 2011 17:00:39 +0100, Steven Schveighoffer  
 wrote:
On Wed, 13 Jul 2011 10:59:27 -0400, Regan Heath   
wrote:




I am suggesting the compiler will perform a special operation on all  
char* parameters passed to extern "C" functions.


The operation is a toStringz like operation which is (more or less) as  
follows:


1. If there is a \0 character inside foo[0..$], do nothing.


This is an O(n) operation -- too much overhead.  Especially if you  
already know foo has a 0 in it.  Note that toStringz does not have this  
overhead.


On 2nd thought, this step is unnecessary unless the array length matches  
the memory block length .. it was intended to detect an existing \0 and  
avoid the reallocation.  But, this case is rare so this step could be  
skipped for the general case, or only carried out when the lengths match  
and reallocation is a possibility we want to avoid, or not if the cost is  
too high even for that.


2. If the array allocated memory is > the array length, place a \0 at  
foo[$]


The check to see if the array has allocated length requires a GC lock,  
and O(lgn) search for the block info in the GC.


Not that it doesn't already happen in toStringz, but I just want to  
point out that it's not a small cost.


This is the cost Walter mentioned earlier.  Does this mean that heap  
allocated arrays do not know how much memory they have allocated?  I was  
assuming they held that information, and that a slice to them would also  
know.  How else does an array append operation know whether to  
reallocate?  Does it have to obtain the GC lock and perform an O(lgn)  
search on every append?



3. Reallocate the array memory, updating foo, place a \0 at foo[$]
4. Call the C function passing foo.ptr

So, it will handle all the following cases:

char[] foo;
.. code to populate foo ..

ucase(foo);
ucase(foo.ptr);


I read in your responses below, this is due to you making this  
equivalent to ucase(foo)?  This still has the same problems I listed  
above.


Problems above?  You mean the cost?  Yes, there is a cost to pay, but it's  
a cost which has to be paid (and is already paid by calling toStringz) to  
avoid corrupting memory whether it's done explicitly or implicitly.  And  
the cost is only paid for extern "C" functions with char* parameters.  In  
the rare case where the string already contains \0 and the programmer can  
guarantee that, we can have some way to indicate it, or in some cases  
changing the function parameter to ubyte* or byte* may be the correct  
solution.



What about

char * foo;
.. code to populate foo ..
ucase(foo);

Is there still anything special done by the compiler?


Assuming foo is allocated by the GC toStringz can still find the length of  
the memory block (step #2 above) and reallocate if required, right?  If so  
we can handle this case as well (for no extra cost than incurred by  
toStringz already).



ucase(toStringz(foo));

The problem cases are the buffer cases I mentioned earlier, and they  
wouldn't be a problem if char was initialised to \0 as I first imagined.


The largest problem I've had with all this is there is a necessary  
overhead of conversion.  Not only that, but due to the way reallocation  
works, there may be a move of data.  I think it's better to require  
explicit calls incurring such overhead vs. hiding the overhead calls  
from the developer. Especially if the overhead calls are unnecessary.


But, the overhead is something we already pay calling toStringz  
explicitly, and the reallocation is no different to an append operation.


Generally speaking I would normally agree that it's better to require  
explicit calls incurring overhead etc, but this specific case is something  
new D programmers stumble on all the time, and it makes D look less slick  
than something like C#.  I do realise the target audience is slightly  
different for each, but if we can achieve something similar for no extra  
cost (other than we already pay calling toStringz explicitly), then it's  
well worth considering.


As far as I can see the only problem cases are those where we incur more  
cost than toStringz when it's not required, and those cases seem rare to  
me, and could be handled by an opt-out decoration/keyword or similar.



Other replies inline below..

On Tue, 12 Jul 2011 18:28:56 +0100, Steven Schveighoffer  
 wrote:
On Tue, 12 Jul 2011 13:00:41 -0400, Regan Heath   
wrote:
Replace foo with foo.ptr, it makes no difference to the point I was  
making.


You fix does not help in that case, foo.ptr will be passed as a  
non-null terminated string.


No, see above.


How does your proposal know that a char * is part of a heap-allocated  
array?  If you are assuming the only case where char * is passed will be  
arr.ptr, then that doesn't cut it.  What if the compiler doesn't know  
where the char * came from?


See your Q and my A above ("char * foo" example).

The inherent problem of zero-terminated strings is that you don't kn

Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake"]

[Jonathan M Davis]

On 2011-07-13 08:36, Jacob Carlborg wrote:
> On 2011-07-13 07:28, Jonathan M Davis wrote:
> > On Wednesday 13 July 2011 06:12:58 Russel Winder wrote:
> >> And, of course, I should have mentioned CMake and CMakeD.
> >> 
> >> The fact that I forgot, shows my prejudice against Makefile-based
> >> systems and for direct DAG-based systems such as Gradle, SCons and Waf.
> >> This though should not stop CMakeD being a part of this debate.
> >> 
> >> From previous discussions, it seems that one of the primary reasons for
> >> having
> > 
> > a D build tool in many people's minds is to also handle package
> > management of D libraries (like Haskell's cabal or rubygems for ruby).
> > And as great as cmaked, scons, gradle, waf, and other such tools may be,
> > they don't do that.
> > 
> > - Jonathan M Davis
> 
> I don't agree with that. I think a build tool should deal with single
> files and building. A package manager should deal with packages (of
> files). In Ruby, RubyGems is the package manager and Rake is the build
> tool.

Well, I'm not advocating anything in particular. I was just pointing out that 
a big part of the discussions on build tools has been package management of 
libraries, and any build tool solution which doesn't at least integrate with 
some sort of package management solution is likely to not be what at least 
some people are looking for.

Personally, I don't generally use package management tools for handling 
libraries even with languages that have such tools, and I don't generally use 
much in the way of build tools either beyond simple scripts (primarily because 
I don't generally have projects large enough for it to be an issue). As it 
stands, if I were to choose a build tool for a larger project, I'd probably 
choose CmakeD, but I'm not super-familiar with all of the tools out there and 
haven't generally found much use for them.

I was just trying to point out that a fair bit of the discussion for such 
tools in this list has related to package management, and Nick's solution 
doesn't address that at all AFAIK.

- Jonathan m Davis

Re: D users on Google+

[Graham Fawcett]

On Wed, 13 Jul 2011 17:04:40 +0200, simendsjo wrote:

> On 13.07.2011 17:01, Andrej Mitrovic wrote:
>> I don't have an invite yet, I'll be there when I do. ^^
> Done

If invites are in good supply, I would appreciate one too. :)

cheers,
Graham

Re Build system requirements [ was Re: Prototype buildsystem "Drake" ]

[Russel Winder]

On Wed, 2011-07-13 at 17:33 +0200, Jacob Carlborg wrote:

> target("main.d"); // builds "main.d" as an executable

The SCons equivalent is:

Program ( 'main.d' )

> Or:
> 
> target("foobar"); // builds the directory "foobar" as a library

SCons (and I think Waf as well) does not support this idea (at least
currently).  In SCons you have to say:

SharedLibrary ( 'libraryRootName' , Glob ( 'foobar/*.d' ) )
StaticLibrary ( 'libraryRootName' , Glob ( 'foobar/*.d' ) )

D support in Waf is currently far more sophisticated than that of SCons,
but is still based on being a bit more explicit that your proposal
above.

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


signature.asc
Description: This is a digitally signed message part

Re: toStringz or not toStringz

[Jonathan M Davis]

On 2011-07-13 09:00, Steven Schveighoffer wrote:
> On Wed, 13 Jul 2011 10:59:27 -0400, Regan Heath 
> 
> wrote:
> > I am suggesting the compiler will perform a special operation on all
> > char* parameters passed to extern "C" functions.
> > 
> > The operation is a toStringz like operation which is (more or less) as
> > follows:
> > 
> > 1. If there is a \0 character inside foo[0..$], do nothing.
> 
> This is an O(n) operation -- too much overhead. Especially if you already
> know foo has a 0 in it. Note that toStringz does not have this overhead.
> 
> > 2. If the array allocated memory is > the array length, place a \0 at
> > foo[$]
> 
> The check to see if the array has allocated length requires a GC lock, and
> O(lgn) search for the block info in the GC.
> 
> Not that it doesn't already happen in toStringz, but I just want to point
> out that it's not a small cost.
> 
> > 3. Reallocate the array memory, updating foo, place a \0 at foo[$]
> > 4. Call the C function passing foo.ptr
> > 
> > So, it will handle all the following cases:
> > 
> > char[] foo;
> > .. code to populate foo ..
> > 
> > ucase(foo);
> > ucase(foo.ptr);
> 
> I read in your responses below, this is due to you making this equivalent
> to ucase(foo)? This still has the same problems I listed above.
> 
> What about
> 
> char * foo;
> .. code to populate foo ..
> ucase(foo);
> 
> Is there still anything special done by the compiler?
> 
> > ucase(toStringz(foo));
> > 
> > The problem cases are the buffer cases I mentioned earlier, and they
> > wouldn't be a problem if char was initialised to \0 as I first imagined.
> 
> The largest problem I've had with all this is there is a necessary
> overhead of conversion. Not only that, but due to the way reallocation
> works, there may be a move of data. I think it's better to require
> explicit calls incurring such overhead vs. hiding the overhead calls from
> the developer. Especially if the overhead calls are unnecessary.
> 
> > Other replies inline below..
> > 
> > On Tue, 12 Jul 2011 18:28:56 +0100, Steven Schveighoffer
> > 
> >  wrote:
> >> On Tue, 12 Jul 2011 13:00:41 -0400, Regan Heath 
> >> 
> >> wrote:
> >>> Replace foo with foo.ptr, it makes no difference to the point I was
> >>> making.
> >> 
> >> You fix does not help in that case, foo.ptr will be passed as a
> >> non-null terminated string.
> > 
> > No, see above.
> 
> How does your proposal know that a char * is part of a heap-allocated
> array? If you are assuming the only case where char * is passed will be
> arr.ptr, then that doesn't cut it. What if the compiler doesn't know
> where the char * came from?
> 
> The inherent problem of zero-terminated strings is that you don't know how
> long it is until you search for a zero. If it's not properly terminated,
> then you are screwed. That problem cannot be "solved", even with compiler
> help -- you can get situations where there is no more information other
> than the pointer.
> 
> >> So, your proposal fixes the case:
> >> 
> >> 1. The user tries to pass a string/char[] to a C function. Fails to
> >> compile.
> >> 2. Instead of trying to understand the issue, realizes the .ptr member
> >> is the right type, and switches to that.
> >> 
> >> It does not fix or help with cases where:
> >> * a programmer notices the type of the parameter is char * and uses
> >> 
> >> foo.ptr without trying foo first. (crash)
> >> 
> >> * a programmer calls toStringz without going through the compile/fix
> >> 
> >> cycle above.
> >> 
> >> * a programmer tries to pass string/char[], fails to compile, then
> >> 
> >> looks up how to interface with C and finds toStringz
> >> 
> >> I think this fix really doesn't solve a very common problem.
> > 
> > See above, my intention was to solve all the cases listed here as I
> > suspect the compiler can detect them all, and just 'do the right thing'.
> > 
> > In these cases..
> > 
> > 1. If the programmer writes foo.ptr, the compiler detects that, calls
> > toStringz on 'foo' (not foo.ptr) and updates foo as required (if
> > reallocation occurs).
> 
> What if it's not foo.ptr? What if it's some random char * whose origin
> the compiler isn't aware of?
> 
> > 2. If the programmer calls toStringz, this case is the same as #1 as
> > toStringz returns foo.ptr (I assume).
> 
> Huh? Why should it do anything with toStringz? I'm not getting this one,
> toStringz already has done the work your proposal wants to do.
> 
> >>> This is not a 'new' problem introduced the idea, it's a general
> >>> problem for D/arrays/slices and the same happens with an append,
> >>> right? In which case it's not a reason against the idea.
> >> 
> >> It's new to the features of the C function being called. If you look
> >> up the man page for such a hypothetical function, it might claim that
> >> it alters the data passed in through the argument, but it seems to not
> >> be the case! So there's no way for someone (who arguably is not well
> >> versed in C functions if they didn't know to use toStr

Re: D users on Google+

[Zardoz]

On Wed, 13 Jul 2011 17:39:37 +0200, simendsjo wrote:

> On 13.07.2011 17:35, Jesse Phillips wrote:
>> Google+ isn't really intended for following subjects, though it
>> probably will eventually with public circles or something.
> 
> Have to agree with that. No post tags or public circles makes it quite
> cumbersome to do.

Actually have some things that are similar to twitter. For example you can put 
a + or a @ in a post to 
mention other person.



-- 
Yep, I'm afraid that I have a blog : zardoz.es

Re: toStringz or not toStringz

[Steven Schveighoffer]

On Wed, 13 Jul 2011 10:59:27 -0400, Regan Heath   
wrote:




I am suggesting the compiler will perform a special operation on all  
char* parameters passed to extern "C" functions.


The operation is a toStringz like operation which is (more or less) as  
follows:


1. If there is a \0 character inside foo[0..$], do nothing.


This is an O(n) operation -- too much overhead.  Especially if you already  
know foo has a 0 in it.  Note that toStringz does not have this overhead.


2. If the array allocated memory is > the array length, place a \0 at  
foo[$]


The check to see if the array has allocated length requires a GC lock, and  
O(lgn) search for the block info in the GC.


Not that it doesn't already happen in toStringz, but I just want to point  
out that it's not a small cost.



3. Reallocate the array memory, updating foo, place a \0 at foo[$]
4. Call the C function passing foo.ptr

So, it will handle all the following cases:

char[] foo;
.. code to populate foo ..

ucase(foo);
ucase(foo.ptr);


I read in your responses below, this is due to you making this equivalent  
to ucase(foo)?  This still has the same problems I listed above.


What about

char * foo;
.. code to populate foo ..
ucase(foo);

Is there still anything special done by the compiler?


ucase(toStringz(foo));

The problem cases are the buffer cases I mentioned earlier, and they  
wouldn't be a problem if char was initialised to \0 as I first imagined.


The largest problem I've had with all this is there is a necessary  
overhead of conversion.  Not only that, but due to the way reallocation  
works, there may be a move of data.  I think it's better to require  
explicit calls incurring such overhead vs. hiding the overhead calls from  
the developer.  Especially if the overhead calls are unnecessary.



Other replies inline below..

On Tue, 12 Jul 2011 18:28:56 +0100, Steven Schveighoffer  
 wrote:
On Tue, 12 Jul 2011 13:00:41 -0400, Regan Heath   
wrote:
Replace foo with foo.ptr, it makes no difference to the point I was  
making.


You fix does not help in that case, foo.ptr will be passed as a  
non-null terminated string.


No, see above.


How does your proposal know that a char * is part of a heap-allocated  
array?  If you are assuming the only case where char * is passed will be  
arr.ptr, then that doesn't cut it.  What if the compiler doesn't know  
where the char * came from?


The inherent problem of zero-terminated strings is that you don't know how  
long it is until you search for a zero.  If it's not properly terminated,  
then you are screwed.  That problem cannot be "solved", even with compiler  
help -- you can get situations where there is no more information other  
than the pointer.



So, your proposal fixes the case:

1. The user tries to pass a string/char[] to a C function.  Fails to  
compile.
2. Instead of trying to understand the issue, realizes the .ptr member  
is the right type, and switches to that.


It does not fix or help with cases where:

  * a programmer notices the type of the parameter is char * and uses  
foo.ptr without trying foo first. (crash)
  * a programmer calls toStringz without going through the compile/fix  
cycle above.
  * a programmer tries to pass string/char[], fails to compile, then  
looks up how to interface with C and finds toStringz


I think this fix really doesn't solve a very common problem.


See above, my intention was to solve all the cases listed here as I  
suspect the compiler can detect them all, and just 'do the right thing'.


In these cases..

1. If the programmer writes foo.ptr, the compiler detects that, calls  
toStringz on 'foo' (not foo.ptr) and updates foo as required (if  
reallocation occurs).


What if it's not foo.ptr?  What if it's some random char * whose origin  
the compiler isn't aware of?


2. If the programmer calls toStringz, this case is the same as #1 as  
toStringz returns foo.ptr (I assume).


Huh?  Why should it do anything with toStringz?  I'm not getting this one,  
toStringz already has done the work your proposal wants to do.


This is not a 'new' problem introduced the idea, it's a general  
problem for D/arrays/slices and the same happens with an append,  
right?  In which case it's not a reason against the idea.


It's new to the features of the C function being called.  If you look  
up the man page for such a hypothetical function, it might claim that  
it alters the data passed in through the argument, but it seems to not  
be the case!  So there's no way for someone (who arguably is not well  
versed in C functions if they didn't know to use toStringz) to figure  
out why the code seems not to do what it says it should.  Such a  
programmer may blame either the implementation of the C function, or  
blame the D compiler for not calling the function properly.


None of this is relevant, let me explain..

My idea is for the compiler to detect a char* parameter to an extern "C"  
function and to call toStringz.  When it does 

Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]

[Jacob Carlborg]

On 2011-07-13 07:28, Jonathan M Davis wrote:

On Wednesday 13 July 2011 06:12:58 Russel Winder wrote:

And, of course, I should have mentioned CMake and CMakeD.

The fact that I forgot, shows my prejudice against Makefile-based
systems and for direct DAG-based systems such as Gradle, SCons and Waf.
This though should not stop CMakeD being a part of this debate.



From previous discussions, it seems that one of the primary reasons for having

a D build tool in many people's minds is to also handle package management of
D libraries (like Haskell's cabal or rubygems for ruby). And as great as
cmaked, scons, gradle, waf, and other such tools may be, they don't do that.

- Jonathan M Davis


I don't agree with that. I think a build tool should deal with single 
files and building. A package manager should deal with packages (of 
files). In Ruby, RubyGems is the package manager and Rake is the build tool.


--
/Jacob Carlborg

Re: CTFE: What limitations remain?

[Dmitry Olshansky]

On 13.07.2011 16:43, Steven Schveighoffer wrote:
On Wed, 13 Jul 2011 02:32:41 -0400, Dmitry Olshansky 
 wrote:



On 12.07.2011 18:22, dsimcha wrote:
The documentation for CTFE is outdated and specifies limitations 
that no
longer exist thanks to Don's massive overhaul.  For example, a big 
one is that
pointers now work.  What limitations that could potentially be 
removed still

do exist in CTFE as of 2.054?

Just hited all of the below:
 - try/catch
 - intrinsics (bsr, bsf etc. ) this currently also means no Appender


Don has a patch for appender that allows it to work during CTFE: 
https://github.com/D-Programming-Language/phobos/pull/129


Actually, that was merged, prior to 2.054 release, may want to try 
appender again ;)


And I thought I was on a bleeding edge dmd, apparently I'm too slow to 
pull these in time  :)





 - array.reserve


array.reserve is specific to the GC, and the GC isn't the same during 
compile time.  Asking for this is like asking for GC.malloc.


However, if there ever was a working D compiler written in D, these 
kinds of things could be done no problem.  Reserve does seem like a 
useful thing to allow during CTFE.


Of course, I could change reserve to simply do nothing during ctfe, 
which would make things "work", even though reserving wasn't actually 
happening...


I'd say that would be an adequate workaround.




 - foreach over tupple (aka static foreach)


Ok, so of all above try/catch is the last big thing.

--
Dmitry Olshansky

Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]

[Jacob Carlborg]

On 2011-07-13 09:18, Jonathan M Davis wrote:

On Wednesday 13 July 2011 03:01:04 Nick Sabalausky wrote:

Regarding this topic's frequent ressurection, I see that as a direct result
of it all being *merely* talk, with very little concrete progress. We don't
even *have* a proper package management system (there's DSSS, but it's dead,
bitrotted, and I don't think it handles dependencies or multiple versions
of the same package). So naturally that topic's going to keep coming up
until we have something.


I belive that Jacob Carlborg is working on a solution. So,  there _is_ work
being done on it. By no means does that mean that you shouldn't work on a
solution, but it's not the case that no one has been working on the problem -
though it is true that it's been being brought up for far longer than it's
been being worked on.

- Jonathan M Davis


Yes, I do work on that. And a build tool as well.

--
/Jacob Carlborg

Re: D users on Google+

[simendsjo]

On 13.07.2011 17:35, Jesse Phillips wrote:

Google+ isn't really intended for following subjects, though it probably will 
eventually with public circles or something.


Have to agree with that. No post tags or public circles makes it quite 
cumbersome to do.

Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]

[Jacob Carlborg]

On 2011-07-13 07:10, Russel Winder wrote:

I think that in order to create a momentum, a fundamental choice needs
to be made:

--  Should D have a specialist tool (à la SBT/Scala, Leiningen/Clojure
-- at the risk of massive NIH-ism, just as the Scala and Clojure folk
appear to have) or go with a generalist tool such as Gradle or SCons.


I think that we should go for a D specific build tool.

--
/Jacob Carlborg

Re: Prototype buildsystem "Drake"

[Jacob Carlborg]

On 2011-07-13 03:02, Nick Sabalausky wrote:

The recent discussions about package managers and buildsystems has prompted
me to get off my ass (or rather, *on* my ass as per how programming is
usually performed...) and start on the D-based rake-inspired buildtool I've
been meaning to make for awhile now. It's not actually usable yet, but
there's a sample drakefile demonstrating everything, and it does actually
compile and run (but just doesn't build the dependency tree or actually run
any of the build steps). *Should* work on Posix, but I only tested on
Windows, so I may have fucked up the Posix version...

Apologies to Jacob Carlborg for the name being so close to "dake". Didn't
really know what else to call it ("Duck", maybe?) Like dake, it's inspired
by Ruby's Rake. But unlike dake, the buildscript is written in D instead of
Ruby, which was my #1 reason for making a Rake alternative.

Before I go implemeting everything, I'd like to get input on it. Is it
something that could be a major D tool?

Overview of Drake and links to all the code are here:

https://bitbucket.org/Abscissa256/drake/wiki/Home


First I have to say that I know you are doing this because you want to 
use D as the language for the build scripts. The reason I did choose 
Ruby because I think D will be too verbose and when I'm looking at 
drakefile.d I do think it's too verbose. But instead of starting a 
debate between Ruby and D I'm going to give you a few suggestions and 
comments instead.


The minimal drakefile doesn't look that minimal. This is the idea I have 
for a minimal build script file:


target("main.d"); // builds "main.d" as an executable

Or:

target("foobar"); // builds the directory "foobar" as a library

DSSS did this very good.

Now looking in the drakefile.d. You have targets and tasks all over the 
place, almost every target has "Task" as a template parameter. Why is 
this necessary? Have one function for targets and one for tasks. Example 
from the drakefile.d:


target!Task("upload", "all",
(Target t)
{
system("ftp ...");
}
);

Seems this could look like this:

task("upload", "all", {
system("ftp...");
}); // if D just could get a better looking delegate syntax

"getDCompiler" seems unnecessary, both ldc and gdc have a dmd compatible 
wrapper, ldmd and gdmd. These wrappers takes the same flags as dmd and 
translate them to the correct "native" flags.


The "drakfile" function seems unnecessary. I would use a string import 
(or what it's called), importing the whole build script into a method in 
a class. All code in the "drakefile" function would instead be at top level.


Most of the functions called in the build script should be instance 
methods, this will allow to use threading, possible invoke multiple 
targets/tasks simultaneously and running several build scripts 
simultaneously.


I see installation related code in the build script. I think a package 
manager should be responsible for that. A build tool should deal with 
single files and a package manager should deal with packages (of files).


--
/Jacob Carlborg

Re: dmd linux makefile

[Jonathan M Davis]

On Wednesday 13 July 2011 17:25:45 Trass3r wrote:
> > It's not, use MODEL=32 or MODEL=64 if you want to switch between the
> > compiler being compiled as 32-bit or 64-bit.
> 
> Ah true, always forget that way to set variables.

It's the same convention that druntime and Phobos using for choosing to 
between compiling the 32-bit and 64-bit versions of themselves.

- Jonathan M Davis

Re: D users on Google+

[Jesse Phillips]

Mirko Pilger Wrote:

> > I don't know If now there a method to make proper groups in Google+
> 
> i would guess https://groups.google.com/ will take this place.
> 
> mirko
> 

There have been several groups there, all have died.

Google+ isn't really intended for following subjects, though it probably will 
eventually with public circles or something.

Re: dmd linux makefile

[Trass3r]

It's not, use MODEL=32 or MODEL=64 if you want to switch between the  
compiler being compiled as 32-bit or 64-bit.


Ah true, always forget that way to set variables.

Re: dmd linux makefile

[Jonathan M Davis]

On Wednesday 13 July 2011 17:13:54 Trass3r wrote:
> Why is it still necessary to edit the linux makefile in order to switch
> between release and debug or 32 vs. 64 bit?
> The windows one has had proper targets at least for the former issue for
> ages.

It's not, use MODEL=32 or MODEL=64 if you want to switch between the compiler 
being compiled as 32-bit or 64-bit.

- Jonathan M Davis

dmd linux makefile

[Trass3r]

Why is it still necessary to edit the linux makefile in order to switch  
between release and debug or 32 vs. 64 bit?
The windows one has had proper targets at least for the former issue for  
ages.

Re: dmd linux makefile

[Trass3r]

Oh and any reason why it only uses -O2 in release mode?

Re: Inconsistencies between global imports and function local imports

[Tyro[a.c.edwards]]

On 7/13/2011 12:07 PM, Jonathan M Davis wrote:

On Wednesday 13 July 2011 11:56:10 Tyro[a.c.edwards] wrote:

Methinks function local imports (introduced in 2.054) is a great idea,
however if it is to be allowed, I believe it should provide all the
functionality of global imports: which it currently does not.

import std.stdio;
import std.string;
import std.conv;

// Note: all of these import formats work if imported here but only
// the first work if imported locally to the function.

//import std.utf;
//import std.utf: toUTF16z;
//import std.utf: wcp = toUTF16z;

void main()
{
auto s = "漢字を書くのはどうかな～？";
auto s1 = genText(s);
writeln(to!string(typeid(s1)));
}

auto genText(string t)
{
import std.utf; // This works
//import std.utf: toUTF16z; // This doesn't
//import std.utf: wcp = toUTF16z; // Neither does this

version(Unicode)
{
// Note: Everything here works with global import
// but only the first line works with function local imports

return toUTF16z(t);   // This works
//return t.toUTF16z;  // This doesn't
//return wcp(t);  // Neither does this
//return t.wcp;   // Or this
}
else
{
return t.toStringz;
}
}


import std.utf: toUTF16z;

is broken to begin with:

http://d.puremagic.com/issues/show_bug.cgi?id=314
http://d.puremagic.com/issues/show_bug.cgi?id=5161

Rather than just importing the symbol like it should, a selective import
essentially create a new symbol. So, that's probably why it doesn't work when
importing inside of a function.


IC, thanks for the response/info... Now I know!


[OT - toUTFz]

Wasn't there discussion about adding toUTFz to the std.utf? For some
reason I thought that was forthcoming in 2.054... whatever happened there?


It hasn't been merged in yet. It should be in 2.055.

https://github.com/D-Programming-Language/phobos/pull/123

- Jonathan M Davis


Got it. Thanks again.

Re: Ask for help about Internal error: e2ir.c 5007

[Daniel Murphy]

If you trust me, dropping the dmd.exe I emailed you in place of your 
existing one should give you a line number and file.

"zhang"  wrote in message 
news:mailman.1603.1310568147.14074.digitalmar...@puremagic.com...
> I'm porting the Scintilla (C++) to D. The module of scintilla.Editor is a 
> big one which has over 10,000 lines.
> I have tried my best to get rid of all the warning and error messages 
> emitted by DMD 2.054, except for one:
>
> dmd.exe -version=WindowsXP  -g -debug-IE:\dmd\contrib\import  -c 
> scintilla\Editor.d -ofobj\Debug\scintilla\Editor.obj
> Internal error: e2ir.c 5007
>
> Of course, there are many bugs hidding in the Editor.d. However, I need 
> more hints from the compiler to kill the bugs.
> Thanks for any help.
>
> --
> Zhang 
>
> t 

Re: D users on Google+

[Andrej Mitrovic]

On 7/13/11, simendsjo  wrote:
> On 13.07.2011 17:01, Andrej Mitrovic wrote:
>> I don't have an invite yet, I'll be there when I do. ^^
> Done
>

Sweet!! Many thanks!

Re: Ask for help about Internal error: e2ir.c 5007

[Vladimir Panteleev]

On Wed, 13 Jul 2011 17:42:05 +0300, zhang  wrote:

dmd.exe -version=WindowsXP  -g -debug-IE:\dmd\contrib\import  -c  
scintilla\Editor.d -ofobj\Debug\scintilla\Editor.obj

Internal error: e2ir.c 5007


* SHAMELESS PLUG WARNING *

Until a compiler developer can look at this, you can use DustMite to help  
identify the cause of uninformative compiler error messages:

https://github.com/CyberShadow/DustMite

--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: D users on Google+

[simendsjo]

On 13.07.2011 17:01, Andrej Mitrovic wrote:

I don't have an invite yet, I'll be there when I do. ^^

Done

Re: D users on Google+

[Andrej Mitrovic]

I don't have an invite yet, I'll be there when I do. ^^

Re: toStringz or not toStringz

[Regan Heath]

Ok, it's clear there has been some confusion over what exactly I am  
suggesting.


I am not suggesting the compiler simply insert calls to the existing  
toStringz function as it appears the function does not, or cannot do what  
I am imagining.


I am suggesting the compiler will perform a special operation on all char*  
parameters passed to extern "C" functions.


The operation is a toStringz like operation which is (more or less) as  
follows:


1. If there is a \0 character inside foo[0..$], do nothing.
2. If the array allocated memory is > the array length, place a \0 at  
foo[$]

3. Reallocate the array memory, updating foo, place a \0 at foo[$]
4. Call the C function passing foo.ptr

So, it will handle all the following cases:

char[] foo;
.. code to populate foo ..

ucase(foo);
ucase(foo.ptr);
ucase(toStringz(foo));

The problem cases are the buffer cases I mentioned earlier, and they  
wouldn't be a problem if char was initialised to \0 as I first imagined.


Other replies inline below..

On Tue, 12 Jul 2011 18:28:56 +0100, Steven Schveighoffer  
 wrote:
On Tue, 12 Jul 2011 13:00:41 -0400, Regan Heath   
wrote:


On Tue, 12 Jul 2011 17:09:04 +0100, Steven Schveighoffer  
 wrote:


On Tue, 12 Jul 2011 11:41:56 -0400, Regan Heath   
wrote:


On Tue, 12 Jul 2011 15:59:58 +0100, Steven Schveighoffer  
 wrote:


On Tue, 12 Jul 2011 10:50:07 -0400, Regan Heath  
 wrote:


What if you expect the function is expecting to write to the  
buffer, and the compiler just made a copy of it?  Won't that be  
pretty surprising?


Assuming a C function in this form:

   void write_to_buffer(char *buffer, int length);


No, assuming C function in this form:

void ucase(char* str);

Essentially, a C function which takes a writable  
already-null-terminated string, and writes to it.


Ok, that's an even better example for my case.

It would be used/called like...

   char[] foo;
   .. code which populates foo with something ..
   ucase(foo);

and in D today this would corrupt memory.  Unless the programmer  
remembered to write:


No, it wouldn't compile.  char[] does not cast implicitly to char *.   
(if it does, that needs to change).


Replace foo with foo.ptr, it makes no difference to the point I was  
making.


You fix does not help in that case, foo.ptr will be passed as a non-null  
terminated string.


No, see above.


So, your proposal fixes the case:

1. The user tries to pass a string/char[] to a C function.  Fails to  
compile.
2. Instead of trying to understand the issue, realizes the .ptr member  
is the right type, and switches to that.


It does not fix or help with cases where:

  * a programmer notices the type of the parameter is char * and uses  
foo.ptr without trying foo first. (crash)
  * a programmer calls toStringz without going through the compile/fix  
cycle above.
  * a programmer tries to pass string/char[], fails to compile, then  
looks up how to interface with C and finds toStringz


I think this fix really doesn't solve a very common problem.


See above, my intention was to solve all the cases listed here as I  
suspect the compiler can detect them all, and just 'do the right thing'.


In these cases..

1. If the programmer writes foo.ptr, the compiler detects that, calls  
toStringz on 'foo' (not foo.ptr) and updates foo as required (if  
reallocation occurs).
2. If the programmer calls toStringz, this case is the same as #1 as  
toStringz returns foo.ptr (I assume).

3. If the programmer passes 'foo', the compiler calls toStringz etc.

I am assuming also that if this idea were implemented it would handle  
things intelligently, like for example if when toStringz is called  
the underlying array is out of room and needs to be reallocated, the  
compiler would update the slice/reference 'foo' in the same way as it  
already does for an append which triggers a reallocation.


OK, but what if it's like this:

char[] foo = new char[100];
auto bar = foo;

ucase(foo);

In most cases, bar is also written to, but in some cases only foo is  
written to.


Granted, we're getting further out on the hypothetical limb here :)   
But my point is, making it require explicit calling of toStringz  
instead of implicit makes the code less confusing, because you  
understand "oh, toStringz may reallocate, so I can't expect bar to  
also get updated" vs. simply calling a function with a buffer.


This is not a 'new' problem introduced the idea, it's a general problem  
for D/arrays/slices and the same happens with an append, right?  In  
which case it's not a reason against the idea.


It's new to the features of the C function being called.  If you look up  
the man page for such a hypothetical function, it might claim that it  
alters the data passed in through the argument, but it seems to not be  
the case!  So there's no way for someone (who arguably is not well  
versed in C functions if they didn't know to use toStringz) to figure  
out why the code seems not to do what it says it should.  Suc

Re: D users on Google+

[simendsjo]

On 13.07.2011 16:35, Simen Kjaeraas wrote:

On Wed, 13 Jul 2011 10:52:28 +0200, simendsjo  wrote:


Are there any D users on Google+ I can stalk?
The only one I found was Andrei Alexandrescu, but as he works at
Facebook, I doubt he'll be posting much.


Hey, you found me there, too. Either that, or your similarly-named
clone did.



You were already in my contact list, so I forgot about you.
I also found Gregor Richards (DSSS) actually, but I'm not sure if he's 
still using D.

Ask for help about Internal error: e2ir.c 5007

[zhang]

I'm porting the Scintilla (C++) to D. The module of scintilla.Editor is a big 
one which has over 10,000 lines. 
I have tried my best to get rid of all the warning and error messages emitted 
by DMD 2.054, except for one:

dmd.exe -version=WindowsXP  -g -debug-IE:\dmd\contrib\import  -c 
scintilla\Editor.d -ofobj\Debug\scintilla\Editor.obj
Internal error: e2ir.c 5007

Of course, there are many bugs hidding in the Editor.d. However, I need more 
hints from the compiler to kill the bugs.
Thanks for any help.

--
Zhang 

t

Re: D users on Google+

[simendsjo]

On 13.07.2011 16:29, Jonathan M Davis wrote:

LOL. Because asking people if you can stalk them definitely makes it so that
they want to interact with you...;)


:) Twitter like stalking - I don't ask for address and blood type.

Re: D users on Google+

[Simen Kjaeraas]

On Wed, 13 Jul 2011 10:52:28 +0200, simendsjo  wrote:


Are there any D users on Google+ I can stalk?
The only one I found was Andrei Alexandrescu, but as he works at  
Facebook, I doubt he'll be posting much.


Hey, you found me there, too. Either that, or your similarly-named
clone did.

--
  Simen

Re: D users on Google+

[Jonathan M Davis]

On Wednesday 13 July 2011 10:52:28 simendsjo wrote:
> Are there any D users on Google+ I can stalk?
> The only one I found was Andrei Alexandrescu, but as he works at
> Facebook, I doubt he'll be posting much.

LOL. Because asking people if you can stalk them definitely makes it so that 
they want to interact with you... ;)

- Jonathan M Davis

Re: D users on Google+

[Mirko Pilger]

I don't know If now there a method to make proper groups in Google+


i would guess https://groups.google.com/ will take this place.

mirko

Re: D users on Google+

[Mirko Pilger]

Done


many thanx, added you to my dpl circle.

Re: D users on Google+

[simendsjo]

On 13.07.2011 15:56, Mirko Pilger wrote:

i would join right away if somebody has an invitation left by any chance.

Done

Re: D users on Google+

[Mirko Pilger]

i would join right away if somebody has an invitation left by any chance.

mirko

Re: Any companies using D?

[Thomas Mader]

I think that the hard thing here is to find the balance between too closed
and too open. A static testimonial page is too closed for my opinion.
Nobody will apply to get added to this page and if so it is too much work
for the webpage admin.
A wiki page would be a really good idea. I thought about a wiki like world
map but it's maybe too much effort and not everybody likes to add it's
precise position.
A link to the D wiki should serve well for the start I guess.
Better ideas?

On Wed, Jul 13, 2011 at 2:23 PM, d coder  wrote:

> We are a young startup based in India and we are creating a DSEL for
> Electronic System Level Design and Verification on top of D.
>
> I think it would be useful to have a page on d-p-l.org where we provide a
> list of companies and opensource projects using D. The idea is, not
> everybody using D would be seeing these threads all the time.
>
> Such list exists on Haskell Wiki for haskell application/libraries
> http://www.haskell.org/haskellwiki/Applications_and_libraries and I think
> it is a useful form of propaganda.
>
> Regards
> - Puneet
>

Re: D users on Google+

[Zardoz]

On Wed, 13 Jul 2011 17:06:13 +0530, d coder wrote:

> I am there too. I have not tried g+ much. How about creating a D
> community there?
> I do not know how things work on goolge+ though. I am there too. I have
> not tried g+ much. How about creating a D community there?I do not
> know how things work on goolge+ though.

For the moment, I made a circle and I put inside simendsjo, and Mike. I can't 
find you !
I don't know If now there a method to make proper groups in Google+



-- 
Yep, I'm afraid that I have a blog : zardoz.es

Re: D users on Google+

[Mike Parker]

On 7/13/2011 5:52 PM, simendsjo wrote:

Are there any D users on Google+ I can stalk?
The only one I found was Andrei Alexandrescu, but as he works at
Facebook, I doubt he'll be posting much.


I'm there.

Re: CTFE: What limitations remain?

[Steven Schveighoffer]

On Wed, 13 Jul 2011 02:32:41 -0400, Dmitry Olshansky  
 wrote:



On 12.07.2011 18:22, dsimcha wrote:

The documentation for CTFE is outdated and specifies limitations that no
longer exist thanks to Don's massive overhaul.  For example, a big one  
is that
pointers now work.  What limitations that could potentially be removed  
still

do exist in CTFE as of 2.054?

Just hited all of the below:
 - try/catch
 - intrinsics (bsr, bsf etc. ) this currently also means no Appender


Don has a patch for appender that allows it to work during CTFE:  
https://github.com/D-Programming-Language/phobos/pull/129


Actually, that was merged, prior to 2.054 release, may want to try  
appender again ;)



 - array.reserve


array.reserve is specific to the GC, and the GC isn't the same during  
compile time.  Asking for this is like asking for GC.malloc.


However, if there ever was a working D compiler written in D, these kinds  
of things could be done no problem.  Reserve does seem like a useful thing  
to allow during CTFE.


Of course, I could change reserve to simply do nothing during ctfe, which  
would make things "work", even though reserving wasn't actually  
happening...



 - foreach over tupple (aka static foreach)

Re: Time for Phobos CTFE-ability unittests...right? RIGHT?

[Adam Ruppe]

> https://github.com/D-Programming-Language/phobos/pull/143

Excellent! Thank you.

Re: Any companies using D?

[d coder]

We are a young startup based in India and we are creating a DSEL for
Electronic System Level Design and Verification on top of D.

I think it would be useful to have a page on d-p-l.org where we provide a
list of companies and opensource projects using D. The idea is, not
everybody using D would be seeing these threads all the time.

Such list exists on Haskell Wiki for haskell application/libraries
http://www.haskell.org/haskellwiki/Applications_and_libraries and I think it
is a useful form of propaganda.

Regards
- Puneet

Re: Any companies using D?

[Trass3r]

Am 13.07.2011, 13:55 Uhr, schrieb Thomas Mader :


I think it would be very helpful if there would be a better way to handle
such questions than to post on a forum or newsgroup.
Wouldn't it be nice to have a central point where people can search for
people interested or proficient in D in a given territory or companies  
using D?


We could also have some kind of "testimonials" on the site where users  
(including companies) explain their experiences with D in a short way.

Re: Any companies using D?

[Thomas Mader]

I think it would be very helpful if there would be a better way to handle
such questions than to post on a forum or newsgroup.
Wouldn't it be nice to have a central point where people can search for
people interested or proficient in D in a given territory or companies using
D?
I am not sure on how to handle such things the best way. A social network
can be used which would be too closed for my taste but it can also be build
into the offical D website.
Has somebody experience with this?
I'm sure this would very much improve the speed in which the community is
growing and is even more important in the beginning because it's harder to
find interested parties.

On Tue, Jul 12, 2011 at 10:05 PM, Nemo  wrote:

> ChrisW Wrote:
>
> > Obviously Digital Mars does development in D, but I was wondering if
> > any other companies have yet taken the plunge -- even if just in their
> > R&D department -- to try using D as their development language?
>
> I work for a large American company that writes a lot of software. The
> company does not use D at this point, mostly because of a legacy code base,
> but it is a strong candidate for future work.
>
> For proprietary reasons I can't identify the company nor the plans for use
> of D, but rest assured that D will be used in future here.
>
> Nemo
>

Re: D users on Google+

[d coder]

I am there too. I have not tried g+ much. How about creating a D community
there?
I do not know how things work on goolge+ though.

Re: Prototype buildsystem "Drake"

[Chris Molozian]

I asked about build tools for D on the mailing list a while ago. I 
needed a solution that allowed me to mix C++ and D builds in a 
cross-platform way with minimum fuss. You can find the discussion about 
it here 
 
(you were also a part of it IIRC). My biggest requirement at the time was:


 * Keeping platform checks e.g. IF (MAC) {} ELSE IF(LINUX) {} ... etc.
   to an absolute minimum. What's the point in a cross-platform
   language if when you build projects in it you need to write a short
   essay for the build system...
 * Pre-built binaries available to all platforms (or as many as possible).

In the end I settled for Jam (ftjam) 
, it works tremendously well. 
It's easy to get binaries for almost any operating system (especially 
with projects like homebrew  for Mac). 
I have very few gripes with it:


 * The build description language is very simple (once you fully grok
   it), but could have done with a lot more example-based documentation.
 * It's missing a few features like recursive-directory scanning (for
   source files), and the ability to pipe the output from a program
   into a variable in the build script (e.g. C++FLAGS = `llvm-config
   --cxxflags`).
 * A convenient way to force all generated object and library files
   into a dedicated build folder. It's possible but not very easy to do.
 * I'm a big fan of convention over configuration, I know it's a very
   subjective topic but I like the way Maven3 and Gradle assume a
   project structure (that you can deviate from if you need to). This
   usually requires very good supporting documentation.

The build script I put together for my project looked like this, 
http://mysticpaste.com/private/TCcTE6KGxn .


Hope this helps,

Chris


On 07/13/11 02:02, Nick Sabalausky wrote:

The recent discussions about package managers and buildsystems has prompted
me to get off my ass (or rather, *on* my ass as per how programming is
usually performed...) and start on the D-based rake-inspired buildtool I've
been meaning to make for awhile now. It's not actually usable yet, but
there's a sample drakefile demonstrating everything, and it does actually
compile and run (but just doesn't build the dependency tree or actually run
any of the build steps). *Should* work on Posix, but I only tested on
Windows, so I may have fucked up the Posix version...

Apologies to Jacob Carlborg for the name being so close to "dake". Didn't
really know what else to call it ("Duck", maybe?) Like dake, it's inspired
by Ruby's Rake. But unlike dake, the buildscript is written in D instead of
Ruby, which was my #1 reason for making a Rake alternative.

Before I go implemeting everything, I'd like to get input on it. Is it
something that could be a major D tool?

Overview of Drake and links to all the code are here:

https://bitbucket.org/Abscissa256/drake/wiki/Home

Re: Anyone want to run this through dmc?

[Trass3r]

seems DMC is broke too, but it's debatable if this test case is of
value to DMD.


Yep, is dmc's backend still updated with improvements made in dmd's  
backend?

Re: Tracking down bug: Need a few precompiled 32-bit linux Hello Worlds

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:ivd56d$1s7q$1...@digitalmars.com...
> Twice now (from two totally different projects) I've come across 
> precompiled linux binaries that give me "Illegal Instruction", but they 
> work when I compile them myself. The idea of shared-lib/libc issues has 
> been looked into, but it doesn't seem to be the culprit. Both times, D1 
> and Tango were involved. So I suspect it's something in Tango, but before 
> I take this to the Tango team I'd like to be more sure. For all I know, it 
> could be a D1 thing, or even something backported over from druntime, 
> something else, etc, I don't know.
>
> I don't have a machine with a modern enough CPU that I can reproduce the 
> offending binaries myself, so I'd appreciate if someone could build a few 
> hello worlds for me:
>
> 1. D1/Tango
> 2. D1/Phobos
> 3. D2/Phobos
>
> // d1tango.d
> import tango.io.Stdout;
> void main()
> {
>  Stdout.formatln("Hello");
> }
>
> // d1phobos.d and d2phobos.d
> import std.stdio;
> void main()
> {
>  writefln("Hello");
> }
>
> I'd need them built on a relatively modern CPU, I'd guess that anything 
> that supports 64-bit and/or multi-core will probably do. They need to be 
> 32-bit binaries. And to avoid any shared lib compatibility issues (which 
> seem to be common on linux), they should be built on something like Ubuntu 
> 10.06 (or older) or CentOS 4 (or older), etc (Building in a VM would be 
> fine of course).
>
> I'd appreciate anyone that has the right setup and can spare the bother to 
> help out with this.
>

Nevermind, I was able to borrow someone's laptop and install a VM. If 
anyone's interested, it looks liek it is (somehow) a problem in Tango, and 
the ticket is here: http://www.dsource.org/projects/tango/ticket/2061

Re: D users on Google+

[simendsjo]

On 13.07.2011 12:05, Zardoz wrote:

Any idea of how set a Interest to get only relate stuff about D ?


Not really. I tried "D programming language", but it doesn't work well.

Re: D users on Google+

[Zardoz]

On Wed, 13 Jul 2011 10:52:28 +0200, simendsjo wrote:

> Are there any D users on Google+ I can stalk? The only one I found was
> Andrei Alexandrescu, but as he works at Facebook, I doubt he'll be
> posting much.

Me ? But I'm afraid that I'm only a simple "user" learning D

Any idea of how set a Interest to get only relate stuff about D ? . I try "D 
language" but I get things like 
"Conservative group backtracks on marriage pledge slavery language"



-- 
Yep, I'm afraid that I have a blog : zardoz.es

Re: Re Build tools for D [ was Re: Prototype buildsystem "Drake" ]

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.1593.1310541508.14074.digitalmar...@puremagic.com...
> On Wednesday 13 July 2011 03:01:04 Nick Sabalausky wrote:
>> Regarding this topic's frequent ressurection, I see that as a direct 
>> result
>> of it all being *merely* talk, with very little concrete progress. We 
>> don't
>> even *have* a proper package management system (there's DSSS, but it's 
>> dead,
>> bitrotted, and I don't think it handles dependencies or multiple versions
>> of the same package). So naturally that topic's going to keep coming up
>> until we have something.
>
> I belive that Jacob Carlborg is working on a solution. So,  there _is_ 
> work
> being done on it.

Right. And I'm definitely keeping an eye on Orb. I just meant that the lack 
of a D package manager that's already usable (and still living) is the main 
reason this all keeps getting discussed every so often.

> By no means does that mean that you shouldn't work on a
> solution, but it's not the case that no one has been working on the 
> problem -
> though it is true that it's been being brought up for far longer than it's
> been being worked on.
>

Yea, I didn't mean that nobody's working on it. Just that, for package 
management, there isn't really much usable right now, and for build 
management, there isn't anything that doesn't rely on either makefiles or 
XML or some non-D dynamic langauge/interpreter, etc.