On Wednesday, 1 August 2012 at 03:24:43 UTC, Chris Cain wrote:
Even now there are people trying to extend olive branches to
you even though you continue to be insulting.
Insulting only the people who have insulted me.
You seem to be wound tight and there's no sense in taking your
On Tuesday, 31 July 2012 at 04:15:40 UTC, Bernard Helyer wrote:
If they won't learn the compilation model, they won't be good
programmers.
I'm not saying that good messages are a bad thing, but if they
don't
understand the basic concept of source - object file - linker
- exe or dll,
then they
On Tuesday, 31 July 2012 at 09:26:42 UTC, Jakob Ovrum wrote:
You're expecting the same diversity and quality of the
toolchain of a small, relatively new (D2 is from 2007)
programming language as you do from giants like C++ and .NET
languages. This is unreasonable.
You have a point, and I
On Tuesday, 31 July 2012 at 09:33:57 UTC, David wrote:
It's not D itself I have a problem with. It's the complete
lack of reliable tools for it. No IDE. No GUI designer. No
nothing. Coding a real application in D is like using Cobra,
or Nemerle - in short, frustrating and slow.
Mh, if this
On Tuesday, 31 July 2012 at 10:59:49 UTC, Don Clugston wrote:
Yeah, we still have *miles* to go on the toolchain. As a
community we've been putting most of our effort into getting
the compiler stable, and to a lesser extent working on the the
standard library. Most of the other things are
On Tuesday, 31 July 2012 at 11:20:53 UTC, bearophile wrote:
Mh, if this is *your* opinion, why are you using D then?
Because its community is helpful and friendly :-)
lol ;)
On Tuesday, 31 July 2012 at 00:30:50 UTC, Bernard Helyer wrote:
Oh, and if there are complaints of LoadLibraryA or whatever not
being nothrow, remove any trace of nothrow from those modules.
Yeah, that didn't work.
bash.exe-3.1$ dmd -lib -ofdfl *.d internal/*.d -I..
DFL: dfl.com is
On Tuesday, 31 July 2012 at 19:07:52 UTC, q66 wrote:
On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:
Oh, now, that's going too far. Do you think I'm some kind of
programming newbie? A college student, perhaps? I have a BSc
in Software Engineering, and I've been coding for 16 years. So
On Tuesday, 31 July 2012 at 18:53:43 UTC, Bernard Helyer wrote:
On Tuesday, 31 July 2012 at 17:16:56 UTC, Stuart wrote:
Er, no. Before I used .NET, I used C++ almost exclusively for
a number of years. I'm a little out of practice, but I
understand the general principles involved.
No you
On Tuesday, 31 July 2012 at 19:05:07 UTC, Andrej Mitrovic wrote:
I've had some success with using DGui, which seems to be
loosely based
on DFL. http://code.google.com/p/dgui/
I can't find any trace of documentation on that site.
On Wednesday, 1 August 2012 at 01:10:30 UTC, Andrei Alexandrescu
wrote:
I've also been surprised by Bernard's exaggerated reaction.
Your vent was not the most unreasonable out there.
Mm. I just got really frustrated at not being able to use this
interesting new language.
(Which,
On Wednesday, 1 August 2012 at 01:12:37 UTC, Timon Gehr wrote:
On 08/01/2012 02:44 AM, Stuart wrote:
If I don't point out that I know something, I'm ignorant.
And when I do, I'm a showoff. I can't win.
- Why would it be interesting to talk about whether someone
'knows something
On Wednesday, 1 August 2012 at 02:35:13 UTC, Bernard Helyer wrote:
Now Stuart, I'll apologise if I have caused offense, and offer
a question -- where are you getting your DFL sources from?
You'll apologise if telling me to fuck off and stop wasting
everyone's time caused offence? Oooh, I
What. The. Fuck?
I'm trying to write an actual program in D, but no matter what I
do I get stupid errors that mean nothing to me. (Reminds me of
C++)
Error 42: Symbol Undefined
_D8infinity8standard7runtime4IApp4IApp11__InterfaceZ
Huh? This usually happens if I omit the module statement at the
top of
I notice nobody so far seems to have any idea why I'm getting
these errors.
On Monday, 30 July 2012 at 19:03:13 UTC, Dmitry Olshansky wrote:
Why would you use internal module of library is beyond me
Perhaps because nobody saw fit to define IsWindow() in module
core.sys.windows.windows?
dmd your_module.d dfl.lib
No, that doesn't help. Because I'm getting this
On Monday, 30 July 2012 at 20:04:25 UTC, Dmitry Olshansky wrote:
On 30-Jul-12 23:45, Stuart wrote:
No, that doesn't help. Because I'm getting this same shit when
I import
my OWN .d files:
It doesn't matter whose these file are. You need all of them
passed to compiler (then it will link them
On Monday, 30 July 2012 at 20:08:34 UTC, Stuart wrote:
Well I'm using VisualD, and have both projects in my solution.
Is there some option I ought to be setting? I can't go running
arbitrary commandlines all over the shop.
Nvm, I got it. Project Dependencies dialog.
On Monday, 30 July 2012 at 21:40:35 UTC, Walter Bright wrote:
A ModuleInfo is generated for each compiled module and inserted
into its corresponding .obj file. If the linker cannot find it,
then it is likely that you need to specify that .obj on the
link command.
Ah, it would seem that my
On Monday, 30 July 2012 at 23:07:35 UTC, bearophile wrote:
Stuart:
I'm about ready to give up here. I like the idea of D, but
it's like using fucking Linux:
I understand. The troubles you find are present in widely used
languages. D is a young language and it's not widespread, so
you
On Monday, 30 July 2012 at 23:31:14 UTC, Andrei Alexandrescu
wrote:
I empathize. The one thing that may be different is that the
forums at forum.dlang.org tend to be a bit more responsive and
to the point.
Well, perhaps someone can explain why I can't compile DFL?
I'm getting the same
Let me be clear: I have no problem with the language of D. It
looks quite decent. It's just not feasible to actually write a
PROGRAM in it. Sure, if I want a quick-and-dirty commandline tool
or something, no problem; but a Windows application? Without an
IDE or GUI designer? No way. Even MFC
On Tuesday, 31 July 2012 at 00:06:43 UTC, cal wrote:
On Monday, 30 July 2012 at 23:40:02 UTC, Stuart wrote:
I have no problem with DMD. DMD is a perfectly reasonable
Windows executable. I am objecting to the frustrating way DFL
is compile-it-yourself and doesn't work; and also the
frustrating
On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
Recursion isn't just a security risk - it's a performance
hit
On Friday, 27 July 2012 at 22:34:13 UTC, Dmitry Olshansky wrote:
On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
I would like to point out here that the example VB.NET code I
just
gave for lazy-populating a list of all files on a drive uses
NO
recursion whatsoever.
It sure thing
On Friday, 27 July 2012 at 22:38:46 UTC, Dmitry Olshansky wrote:
On 27-Jul-12 22:58, Stuart wrote:
Well, off the top of my head, you could use something like:
Public Iterator Function AllFiles(RootDirectory As String)
As
IEnumerable(Of String)
Dim Roots As New Queue(Of String) From
On Saturday, 28 July 2012 at 02:31:42 UTC, Alex Rønne Petersen
wrote:
In all fairness, I think C still has its place. The advantage
of writing software in C is that when you want to port it to a
new platform/architecture, there will almost always be a C
compiler available. This isn't the
On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen wrote:
But note, even then, that D only targets 32-bit architectures
and up, while C can handle 16-bit architectures.
True, but I'm kind of shocked that anything 16-bit
On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne Petersen
wrote:
On 28-07-2012 09:36, Stuart wrote:
On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
- Scheme
- Haskell
- OCaml
- F#
- Erlang
- Clojure
- Some C and C++ compilers (gcc, Intel, MSVC in release mode)
- Most
On Saturday, 28 July 2012 at 07:58:23 UTC, Rainer Schuetze wrote:
On 27.07.2012 15:20, Stuart wrote:
Yes, removing the .suo file fixed the problem. I don't know
why. I will create a ticket. Would submitting my .suo file
help?
Yes, please do. Even though it is system specific, maybe I can
On Saturday, 28 July 2012 at 08:05:09 UTC, Daniel Murphy wrote:
Stuart stu...@gmx.com wrote in message
Embedded systems mostly use Java now in any case, as I
understand
it.
Your understanding is obviously quite limited.
Quite possibly. I'm not an expert on embedded systems.
On Saturday, 28 July 2012 at 08:53:43 UTC, Dmitry Olshansky wrote:
On 28-Jul-12 11:49, Stuart wrote:
But as I understand it, for ranges I'd need to write a whole
new class.
struct. Yeah, you need it.
Here, I'm writing a SINGLE FUNCTION in standard imperative
style.
That implicitly
On Saturday, 28 July 2012 at 11:43:14 UTC, Jacob Carlborg wrote:
On 2012-07-28 09:52, Stuart wrote:
Ah. So, in essence, C has a purpose because [a] it supports
incredibly
obsolete hardware that nobody in their right mind would be
using; and
[b] nobody's ported D to MacOS (or whatever) yet
On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:
I tend to favour F# instead of OCaml due to three things
I've never really seen the point of F#. Aside from maths, what is
F# good for that a standard imperative language is not?
Especially when you consider that all flavours of
On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
On Fri, 27 Jul 2012 04:09:36 +0200
Stuart stu...@gmx.com wrote:
I can't think of ANY situation where goto would be the only
viable option.
Duff's device.
According to Wikipedia, Duff's device (about which, until just
now, I
On Friday, 27 July 2012 at 02:48:36 UTC, Jonathan M Davis wrote:
I'm having difficulty thinking in terms of D. It looks like
C++,
it compiles to native code (unlike .NET), therefore I need to
manage memory myself... ;)
I'll get the hang of it eventually.
In general, you should just let the
On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
D equivalent: iota(0, int.max, 2).map!(a = /* do something
with even numbers */)();
I think you're missing the point. The purpose isn't to generate a
sequence of numbers, but to illustrate how the Yield keyword is
used in
On Friday, 27 July 2012 at 06:36:17 UTC, Jacob Carlborg wrote:
On 2012-07-27 02:25, Jonathan M Davis wrote:
scope on local variables is going to be deprecated, because
it's unsafe. scope on function parameters and scope statements
are here to stay.
scope on class declarations as well.
Huh?
On Friday, 27 July 2012 at 07:41:50 UTC, Simen Kjaeraas wrote:
On Fri, 27 Jul 2012 06:36:57 +0200, Alex Rønne Petersen
a...@lycus.org wrote:
Jumping over initialization isn't as problematic in D because
variables are guaranteed to have a default initialization
value (if not initialized to
On Friday, 27 July 2012 at 07:42:51 UTC, Nick Sabalausky wrote:
On Fri, 27 Jul 2012 08:31:36 +0200
Jacob Carlborg d...@me.com wrote:
Note that iterators in .NET and C++ are a bit different. .NET
has language support with the yield keyword.
I wonder how that works under the hood.
It's
On Friday, 27 July 2012 at 12:56:12 UTC, Rainer Schuetze wrote:
Incidentally, none of that answered my original question,
which is why does VisualD crash?
I tried to reproduce it, but for my solutions it works. I
suspect it might have to do with your window layout. You might
try to remove
On Friday, 27 July 2012 at 15:09:38 UTC, Graham Fawcett wrote:
On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
D equivalent: iota(0, int.max, 2).map!(a = /* do something
with even numbers */)();
I think you're missing
On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen
wrote:
On 27-07-2012 14:56, Stuart wrote:
In any case, isn't it the job of the compiler to unroll loops?
Why
should the coder have to do this himself? Unless of course
he's using a
thin shitty wrapper over assembly language
On Friday, 27 July 2012 at 15:42:27 UTC, Sean Kelly wrote:
On Jul 27, 2012, at 8:05 AM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
core.thread.Fiber has yield and has been used as the basis for
this style of iterator. See Mikola Lysenko's talk from the D
conference a few years
On Friday, 27 July 2012 at 16:15:46 UTC, Jesse Phillips wrote:
Taking a look at DirIteratorImpl[1] in std.file suggest there
is a lot of setup to navigate the filesystem on Windows. How
does Yield help with that logic?
Well, off the top of my head, you could use something like:
Public
On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
But this advantage is unimportant since arbitrary deep
recursion is a security risk (especially for servers that
typically use threads with tiny stacks).
I would like to point out here that the example VB.NET code I
just gave
On Friday, 27 July 2012 at 19:03:34 UTC, Jonathan M Davis wrote:
Regardless, with where D is right now, there's no way that such
a feature would be added the language itself any time soon.
What do you mean? Where *is* D at right now? Has development
stopped? Is there a massive feature
On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
Recursion isn't just a security risk - it's a performance hit
as well.
Only in languages without tail call optimizations.
Which is pretty much all of them.
Scheme does
On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
I'm pretty sure Yield has a performance hit as well, 'cos it
amounts to an implicit context-switch between two fibers.
Unless I'm sorely mistaken, Yield has bugger-all to do with
fibers. I say again: I'm not talking about threading.
On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
Nevertheless, D has gotten to the point where it's powerful
enough that most feature requests can be implemented in a
library rather than as a language extension.
How could Yield be implemented as a library feature? Something
like:
On Friday, 27 July 2012 at 19:18:11 UTC, Artur Skawina wrote:
A more or less direct translation of your original example
would be:
[...interesting code elided...]
Hmm. I think I need to learn more about ranges. They look quite
powerful. It could, as you suggest, be nothing more than [a] a
On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
an implicit context-switch between two fibers
I've just looked up fiber and coroutine. Sounds like a very
useful concept. As previously stated, VB.NET iterators implement
coroutines WITHOUT fibers; but I can see where fibers would
On Friday, 27 July 2012 at 20:42:40 UTC, Nick Sabalausky wrote:
On Fri, 27 Jul 2012 17:52:27 +0200
Jesse Phillips jessekphillip...@gmail.com wrote:
so I guess you can take my opinion of GUI designers with an
atom of salt.
annoyingly pedanticIt would have to be a molecule. Try to
take an
I'm quite new to D, and I've just been reading the guides. I just
wanted to say I'm very impressed with some of the features I'm
reading about. Slices, closures, the scope keyword(!!!), class
variable initialisers, anonymous array literals, array
concatenation, synchronisation... even decent
On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:
Welcome! :)
GOTO is evil; 'goto' is not! ;) goto makes switch-case
statements safer in D:
Well, kinda. Goto case and such are one thing, but allowing the
arbitrary use of goto for jumping around from label to label
I just
On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
D uses ranges instead of iterators. You can read more about
them here: http://ddili.org/ders/d.en/ranges.html
I find ranges to be a vast improvement over iterators
personally (I use iterators extensively in C++ for my job and
On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
scope on local variables is going to be deprecated, because
it's unsafe.
Um...could you explain why? I thought scope on locals was a
really nice feature. I was looking forward to making use of it
for deterministic resource
On Friday, 27 July 2012 at 01:25:45 UTC, F i L wrote:
I know many are attached at the hip to Visual Studios, but I
recommend MonoDevelop + Mono-D plugin for D programming. It's
very nice, with the exception of a few bug, it offers is
*similar* experience to Visual Studios C#/VB. Plus it's
On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
Now, we have way more safe constructs for moving around in code
then was the case when goto was originally vilified,
and everyone is using those constructs rather than goto.
But the stigma remains and everyone is used to thinking
On Friday, 27 July 2012 at 01:54:16 UTC, Chad J wrote:
Stuart other readers:
I just asked about this in the other thread, and Jonathan
mentioned that std.typecons.scoped can be used to accomplish
the same thing. So the functionality isn't being removed; it's
just being moved from
On Friday, 27 July 2012 at 02:17:22 UTC, Jonathan M Davis wrote:
We have library documentation on dlang.org:
http://dlang.org/phobos/std_typecons.html#scoped
Wow! That's a lot of information.
Better get reading it, then.
Thanks.
On Friday, 27 July 2012 at 02:13:19 UTC, Jonathan M Davis wrote:
It's inherently unsafe. What happens if you returned a
reference to foo from someFunc?
Good answer. I didn't think of that.
scope on local variables is going away for pretty much the same
reason that delete is.
Delete is
On Monday, 23 July 2012 at 21:14:31 UTC, Simen Kjaeraas wrote:
On Mon, 23 Jul 2012 22:51:19 +0200, Stuart stu...@gmx.com
wrote:
Saves us having to create a struct for every goddamn little
function; or using tuples directly, which means we have to
refer to variables like .value1 and .value2
On Tuesday, 24 July 2012 at 14:50:02 UTC, Regan Heath wrote:
On Tue, 24 Jul 2012 15:42:19 +0100, Stuart stu...@gmx.com
wrote:
You mean it's already supported? Nice! Although, It'd still be
awesome to be able to do things like:
auto a,b = bar();
auto c,_ = bar();
Sadly the comma
I've only recently discovered D, and I already think it's great.
I mean, where else am I going to find a language that [a]
compiles to native code, [b] has classes, [c] has no stupid
flat-file #include system, and [d] has a GC? Honestly, I can't
think of any others!
I really don't understand
On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky wrote:
C++ is living in the 70's.
Precisely what I have been thinking. It's a loose wrapper around
assembly, nothing more. Certainly not the high-level language
it's touted as.
On Monday, 23 July 2012 at 06:28:56 UTC, Jacob Carlborg wrote:
On 2012-07-22 15:12, Stuart wrote:
I don't know why implib is ignoring the /s switch, but it is.
I used it a couple of weeks ago and it worked.
Oh, well, I guess that makes it alright, huh? I guess I must just
be an idiot
On Monday, 23 July 2012 at 06:44:22 UTC, Walter Bright wrote:
On 7/22/2012 6:12 AM, Stuart wrote:
Okay, but if you had a keyword - say, extern(rawC) - that
did no mangling
whatsoever, then I could run implib without manually editing
every single damn
line in every Microsoft .def file by hand
On Monday, 23 July 2012 at 14:08:39 UTC, Daniel Murphy wrote:
Stuart stu...@gmx.com wrote in message
news:hcrszoaeyauztrlpi...@forum.dlang.org...
Correct me if I'm wrong, but isn't it only C++ that does
mangling?
You're wrong.
Fair enough. But there are still times when we need a version
On Monday, 23 July 2012 at 15:56:37 UTC, Paulo Pinto wrote:
Am 23.07.2012 14:49, schrieb Stuart:
On Saturday, 21 July 2012 at 22:16:52 UTC, Nick Sabalausky
wrote:
C++ is living in the 70's.
Precisely what I have been thinking. It's a loose wrapper
around
assembly, nothing more. Certainly
On Monday, 23 July 2012 at 17:28:38 UTC, David Nadlinger wrote:
On Monday, 23 July 2012 at 17:25:43 UTC, Stuart wrote:
Fair enough. But there are still times when we need a version
of export that doesn't mangle.
No. This is even impossible to do with some compiler backends.
For example, LLVM
On Monday, 23 July 2012 at 20:51:19 UTC, Stuart wrote:
Incidentally, it'd be really handy to have anonymous tuples in
D.
Or perhaps I should've said named tuples. I dunno what the
correct term might be. All I know is, I've only seen it in one or
two obscure languages, and I've always wished
On Monday, 23 July 2012 at 22:53:52 UTC, dnewbie wrote:
If you have the Windows SDK you can run
coffimplib C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Lib\shlwapi.lib
C:\D\dmd2\windows\lib\shlwapi.lib
Finally! Something that works!
Thank you. I had tried implib and other coff
On Sunday, 22 July 2012 at 02:06:37 UTC, JImmy Cao wrote:
Use either /s or /system
Yes, but - at least with the version of implib I'm using - it has
no effect.
On Sunday, 22 July 2012 at 07:01:50 UTC, Walter Bright wrote:
This is a very old issue. To be compatible with the output of
the Microsoft C compiler, the Windows calling convention is:
_name@nn
but somehow Microsoft left off the _ and @nn in the DLLs.
Hence, part of the whole reason for
Hi. Is there any way to instruct the D compiler not to use name
mangling when referencing an external C++ function?
For example:
extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR
pszExt);
In this particular case, the exported function being referenced
is not called
Let me just add, I really *like* the terse syntax of D. Lambdas,
uniform function call syntax, and so on.
Although the most important difference between C++ and D, in my
opinion, is the absence of the damn #include statement!! That
archaic assembly-language-inspired way of cramming billions
On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen
wrote:
Shouldn't you be using extern (Windows) ?
Yeah. I changed it to (System) in the hope it'd try *not*
mangling the name; and didn't bother changing it back when I
discovered it didn't help.
The language (which, let me say,
On Saturday, 21 July 2012 at 20:07:00 UTC, Jonathan M Davis wrote:
Of course, since PathRenameExtensions does what
std.path.setExtension does, it
would probably be better to just use that, but the OP's
question _does_ apply
to other functions which may not have D replacements, so the
question
On Saturday, 21 July 2012 at 21:25:29 UTC, JImmy Cao wrote:
On Saturday, 21 July 2012 at 21:17:17 UTC, Stuart wrote:
On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne
Petersen wrote:
Shouldn't you be using extern (Windows) ?
Yeah. I changed it to (System) in the hope it'd try
On Saturday, 21 July 2012 at 21:21:41 UTC, David Nadlinger wrote:
extern(C) exists … and we couldn't even have made it to
yesterday without it.
Yes, but it prepends _ to the function name.
The following code -
void STOP() { asm { int 3; }; }
- generates the warning:
Incorrect warning: use '{ }' for an empty statement, not a ';'
That's wrong, yeah?
On Saturday, 21 July 2012 at 22:53:25 UTC, Alex Rønne Petersen
wrote:
On 22-07-2012 00:52, Stuart wrote:
The following code -
void STOP() { asm { int 3; }; }
- generates the warning:
Incorrect warning: use '{ }' for an empty statement, not a
';'
That's wrong, yeah?
No. Drop
On Saturday, 21 July 2012 at 22:51:14 UTC, Adam D. Ruppe wrote:
On Saturday, 21 July 2012 at 22:38:32 UTC, Stuart wrote:
Attempts to bind to a function called _PathRenameExtension.
Which is, naturally, of no use whatsoever.
That is the norm on Windows though:
Granted. But not everyone's
85 matches
Mail list logo
