Not active?
http://forum.dlang.org/post/hnqtpurwklqrpobno...@forum.dlang.org
On Thursday, 19 December 2013 at 08:38:15 UTC, Jeremy DeHaan
wrote:
Let me ask this instead. Under what circumstances would a File
want to allocate?
In the case of a simple string it won't allocate, it's only for
formatting. I could only find alloca, so it's probably fixed.
On Thursday, 19
I was not able to play with a mouse.
Connecting to the same device a touchscreen - all right, mouse -
like nothing.
Isn't mailman the said nntp gateway?
On 23 December 2013 07:46, Russel Winder rus...@winder.org.uk wrote:
I am guessing I will need to raise issues in the various issue trackers
but:
I am finding that GtkD highlights some issues for GDC and LDC2. One of
the moment relates to gtk.Builder.connectSignals. My code compiles and
runs
On Mon, 2013-12-23 at 08:15 +, Iain Buclaw wrote:
[…]
Thanks for the heads up. I expect full bug report and a reduced by
dustmite reproducible test case. ;-)
It might not be that small given that you have to have a Glade file and
a main, but I will ty.
Which issue tracker to submit to?
--
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
This is follow-up of several hot discussion threads that have
happened several months ago. It has become pretty clear that
there is no good way out of existing situation and least bad
needs to be picked
On 2013-12-22 22:30, Iain Buclaw wrote:
While useful the ability to write inline assembler functions, DMD
can't inline these around the place. So you get all the benefits of
being able to shortcut the fastest route to do X, but with the
slowdown of 25% because there's a big elephant in the
On 12/22/2013 11:46 PM, Russel Winder wrote:
Also interesting to note that -o- appears to do bizarre things with both
DMD and LDC2 (not an issue for GDC of course).
What are you expecting -o- to do? It is documented to suppress generation of .o
files.
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
This is follow-up of several hot discussion threads that have
happened several months ago. It has become pretty clear that
there is no good way out of existing situation and least bad
needs to be picked
On Monday, 23 December 2013 at 09:14:46 UTC, John Colvin wrote:
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
This is follow-up of several hot discussion threads that have
happened several months ago. It has become pretty clear that
there is no good
On 23 December 2013 08:34, Russel Winder rus...@winder.org.uk wrote:
On Mon, 2013-12-23 at 08:15 +, Iain Buclaw wrote:
[…]
Thanks for the heads up. I expect full bug report and a reduced by
dustmite reproducible test case. ;-)
It might not be that small given that you have to have a
On 23 December 2013 10:03, Walter Bright newshou...@digitalmars.com wrote:
On 12/22/2013 11:46 PM, Russel Winder wrote:
Also interesting to note that -o- appears to do bizarre things with both
DMD and LDC2 (not an issue for GDC of course).
What are you expecting -o- to do?
A better
On 23 December 2013 10:51, Iain Buclaw ibuc...@gdcproject.org wrote:
On 23 December 2013 10:03, Walter Bright newshou...@digitalmars.com wrote:
On 12/22/2013 11:46 PM, Russel Winder wrote:
Also interesting to note that -o- appears to do bizarre things with both
DMD and LDC2 (not an issue for
On 12/23/13, Dicebot pub...@dicebot.lv wrote:
http://wiki.dlang.org/DIP54
Quoting:
There is also a private `std.typetuple.Pack` which is similar to
current `std.typetuple.Tuple` but does not auto-expand. It is a tool
absolutely necessary for more complex algorithms used in
metaprogramming
Iain Buclaw:
For inline assembly, making dmd work better how?
I meant making dmd better in general. Faster floating point, more
optimization tricks, etc.
Not possible without some sort of translation map, which would
be target
specific, so not suitable for GDC, and language specific so not
On Monday, 23 December 2013 at 11:08:26 UTC, Andrej Mitrovic
wrote:
If you simply remove the auto-expanding TypeTuple you will force
coders to reinvent it. This may not seem like a big deal since
you can
simply do alias List(T..) = T;, but it's a convenience
template that
should stay in
On Monday, 23 December 2013 at 11:08:26 UTC, Andrej Mitrovic
wrote:
We always seem to forget that all newbies will eventually become
experienced current users. Current (experienced) users need a
little
respect as well, not everything has to be tailored to the next
batch
of newbies by breaking
On Monday, 23 December 2013 at 10:15:19 UTC, ilya-stromberg wrote:
About `auto-expansion` problem: please add documentation that
describes difference between `auto-expansion TypeTuple` and
`TemplateArgumentList without auto-expansion`. I personally
don't
know any difference, probably because I
On 12/23/2013 04:02 AM, Dicebot wrote:
On Monday, 23 December 2013 at 03:00:11 UTC, Jakob Ovrum wrote:
On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
People who want auto-expanding template argument lists can still do
this:
It's not perfectly clear, but it looks to me that
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct
is misleading.
Can explain this a bit? What makes one miss distinction between
language term and library type? (Hint: latter is denoted by
CamelCase ;))
On Monday, 23 December 2013 at 03:45:07 UTC, Jakob Ovrum wrote:
We can't afford to add even more tuple types in library.
One tuple and two compile-time lists - where the auto-expanding
one covers the vast majority of use cases - doesn't sound at
all bad.
I think this is the root cause of
On Sunday, 22 December 2013 at 19:49:21 UTC, Joseph Rushton
Wakeling wrote:
On 20/12/13 02:40, Francesco Cattoglio wrote:
I don't know, I feel like I would be more useful if I only
sticked with working
on the standard library when needed and writing software that
others might find
interesting
On 23 December 2013 11:05, bearophile bearophileh...@lycos.com wrote:
Iain Buclaw:
For inline assembly, making dmd work better how?
I meant making dmd better in general. Faster floating point, more
optimization tricks, etc.
Not possible without some sort of translation map, which would
On Monday, 23 December 2013 at 11:44:01 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 10:15:19 UTC, ilya-stromberg
wrote:
About `auto-expansion` problem: please add documentation that
describes difference between `auto-expansion TypeTuple` and
`TemplateArgumentList without auto-expansion`.
Iain Buclaw:
Did you really think that __simd went through a design phase? :-)
I understand. So there is still a problem bigger than __simd.
Bye,
bearophile
Jakob Ovrum:
One tuple and two compile-time lists - where the auto-expanding
one covers the vast majority of use cases - doesn't sound at
all bad.
Plus built-in syntax to unpack tuples in various situations.
Bye,
bearophile
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
Can we add alias for `auto-expansion TypeTuple` and add link to
the previous documentation like this:
alias ExpandedTemplateArgumentList(T) =
TemplateArgumentList!(T).expand;
It looks like it can fix all objections here.
On Monday, 23 December 2013 at 10:47:11 UTC, Iain Buclaw wrote:
For GDC, goto bugzilla.gdcproject.org;
And for LDC, it's https://github.com/ldc-developers/ldc/issues,
but I tink you know that URL already.
David
On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg
wrote:
Can we add alias for `auto-expansion TypeTuple` and add link
to the previous documentation like this:
alias ExpandedTemplateArgumentList(T) =
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
Full support. Never used tuple or TypeTuple since I don't
understand what they are for, and their precise relationship to
templated argument lists. Better names will help.
A code breakage with a
On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg
wrote:
Can we add alias for `auto-expansion TypeTuple` and add link
to the previous documentation like this:
alias ExpandedTemplateArgumentList(T) =
On Monday, 23 December 2013 at 13:13:13 UTC, monarch_dodra wrote:
On Monday, 23 December 2013 at 12:25:55 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg
wrote:
Can we add alias for `auto-expansion TypeTuple` and add link
to the previous documentation like this:
5 Algorithms from `std.typetuple` are re-written to accept
non-expanding template argument lists and form base for
`std.meta.` package.
Why? This seems to me like it would create duplication for
nothing. These templates would do the expanding themselves?
Unless I'm mistaken, the
On Monday, 23 December 2013 at 13:23:39 UTC, monarch_dodra wrote:
5 Algorithms from `std.typetuple` are re-written to accept
non-expanding template argument lists and form base for
`std.meta.` package.
Why? This seems to me like it would create duplication for
nothing. These templates would
On Monday, 23 December 2013 at 11:58:06 UTC, Dicebot wrote:
Also having both types at the same time will cause difficulties
with template algorithms currently present in std.typetuple -
having some defined in terms of raw argument list and others in
terms of packed TemplateArgumentList is just
On Monday, 23 December 2013 at 11:59:34 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct
is misleading.
Can explain this a bit? What makes one miss distinction between
language term and library
On Monday, 23 December 2013 at 13:41:07 UTC, Maxim Fomin wrote:
On Monday, 23 December 2013 at 11:59:34 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct
is misleading.
Can explain this a bit? What
On 2013-12-23 01:39:24 +, Dicebot pub...@dicebot.lv said:
http://wiki.dlang.org/DIP54
This is follow-up of several hot discussion threads that have happened
several months ago. It has become pretty clear that there is no good
way out of existing situation and least bad needs to be picked
On Monday, 23 December 2013 at 13:31:36 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 13:23:39 UTC, monarch_dodra
eg:
staticIndexOf(int, TemplateArgumentList!(int, double), int);
Produces 1? 2? 3?
I really don't know.
Compile-time error, new `staticIndexOf` will strictly accept 2
Disclaimer: I am a newbie and I have *almost* understood the
difference between built-in tuples, Tuple and TypeTuple. Almost.
I'll have to get back to you on that. I also have some bad
history with auto-expansion from my work with bash scripts, but
that's for me and my therapist.
On Monday,
On Monday, 23 December 2013 at 13:58:13 UTC, JR wrote:
... I have *almost* understood the difference between built-in
tuples, Tuple and TypeTuple.
I had this feeling probably 5 or 6 times in past few years, only
to find some new surprise every time :D Can only hope that
finally got it right
On Monday, 23 December 2013 at 13:50:26 UTC, monarch_dodra wrote:
Ok... Then that'll break existing code that doesn't even *use*
TypeTuple... Seems lose-lose to me :/
Yes, this DIP defines breaking transition that requires user
action at some point. It is expected and approved by Andrei - we
On Monday, 23 December 2013 at 14:00:21 UTC, Dicebot wrote:
On Monday, 23 December 2013 at 13:50:26 UTC, monarch_dodra
wrote:
Ok... Then that'll break existing code that doesn't even *use*
TypeTuple... Seems lose-lose to me :/
Yes, this DIP defines breaking transition that requires user
Francesco Cattoglio:
Do you think this would make sense?
Other things in Phobos work like this. Usually in Phobos Big-O
requirements are more important than keeping the range type
unchanged.
Bye,
bearophile
On Monday, 23 December 2013 at 15:23:45 UTC, bearophile wrote:
If the new iota accepts new types, then no existing code is
using iota for such cases. So you are not breaking code is you
offer a more restricted range for such types, avoiding O(n)
behavior for them.
I do realize this, but I
Francesco Cattoglio:
- iota() currently returns a Random Access range, and I'm sure
nobody would agree to downgrade the result to a ForwardRange or
an InputRange, because that would break an unknown amount of
code.
...
Everything else ends up being the same as before: popBack() can
be
Hmm... I don't expect lots of magic there. It probably uses dlsym
to find handlers, so they should be exported from the executable.
Check if it's the case.
On Monday, 23 December 2013 at 15:34:07 UTC, monarch_dodra wrote:
You proposal
(this is still all about your proposal 5), wants to make
std.typetuple use TAL's in all their implementations.
I mean interface.
On Mon, 2013-12-23 at 02:03 -0800, Walter Bright wrote:
On 12/22/2013 11:46 PM, Russel Winder wrote:
Also interesting to note that -o- appears to do bizarre things with both
DMD and LDC2 (not an issue for GDC of course).
What are you expecting -o- to do? It is documented to suppress
On 12/23/2013 12:59 PM, Dicebot wrote:
On Monday, 23 December 2013 at 11:50:08 UTC, Timon Gehr wrote:
This misunderstanding arose because the name of the construct is
misleading.
Can explain this a bit? What makes one miss distinction between language
term and library type?
(It is not a
On Mon, 2013-12-23 at 10:51 +, Iain Buclaw wrote:
[…]
As for GDC it could one of two things.
1) Write assembly output to stdout
2) Create an executable named -
Are either of those actually useful?
-o- is not something I would ever think of as an option to any GCC-based
compiler, perhaps
Sorry for the amount of text, but I tried to explain everything
in a clear and simple way.
I'm willing to volunteer for adding support for more types in
iota. The relevant discussion is:
https://d.puremagic.com/issues/show_bug.cgi?id=10762
A few preliminary considerations:
- iota() currently
On 12/22/2013 10:43 PM, Brad Anderson wrote:
On Sunday, 22 December 2013 at 21:14:54 UTC, Stephen Jones wrote:
Isn't there a problem using Microsoft's visual studio to link for 64
bit in that visual studio 2013 is free only for enrolled students?
Recent versions of Visual Studio Express
First, let me say thanks for the addition of the popcnt inline
assembler opcode. I had placed a project on hold until it was
available. I look forward to using D again.
I determined this instruction was available after some
experimentation as its not documented on the inline assembler
page.
On Sunday, 22 December 2013 at 21:14:54 UTC, Stephen Jones wrote:
Isn't there a problem using Microsoft's visual studio to link
for 64 bit in that visual studio 2013 is free only for enrolled
students?
Microsoft has several programs like dreamspark (students,
teachers etc) or bizspark (new
On Monday, 23 December 2013 at 15:59:10 UTC, Timon Gehr wrote:
As is the former. :P
http://dlang.org/template.html#TemplateArgumentList
I think using the name TemplateArgumentList for anything other
than a shallow wrapper around a template argument list does not
actually improve the naming
On 12/23/13, Dicebot pub...@dicebot.lv wrote:
http://wiki.dlang.org/DIP54
I'm waiting to see what others who use TypeTuples think of the DIP.
E.g. Philippe Sigaud, David Nadlinger, Hara Kenji, Martin Nowak, Don
Clugston, David Simcha, Steven Schveighoffer, etc. I'm pretty sure
(most) of these
On Mon, Dec 23, 2013 at 02:04:52PM +, Dicebot wrote:
On Monday, 23 December 2013 at 13:58:13 UTC, JR wrote:
... I have *almost* understood the difference between built-in
tuples, Tuple and TypeTuple.
I had this feeling probably 5 or 6 times in past few years, only to
find some new
Actually, I dropped the static if in my example and traded one
problem for another.
As the static variables of core.cpuid are not accessible at
compile time, I would like to emulate the cpu interrogation done
there, but I see that asm statements are disallowed in CTFE. Is
versioning the only
On 23/12/13 12:57, Francesco Cattoglio wrote:
No real battleplan other than turning it into a DUB package, then I guess I will
move from there. But first, I need to analyze and understand the 2 codebases:
the Kyllingstad one and the cristicbz fork. I'd like to understand if there's
any way to
Isn't the point that Microsoft have just illustrated that they
intend tightening their grip over the development tools, in which
case the future viability of D as open source is jeopardized; if
you want to program D you will have to obtain some Microsoft
license to access the linker required
I retract my second concern. I misread a purity error for a CTFE
error. This does work as expected.
import core.cpuid: hasPopcnt;
/// Returns the number of bits which are set.
uint popcnt(ulong bits) nothrow
{
version(X86_64) {
if(hasPopcnt()) {
asm {
On 12/23/2013 12:50 PM, Stephen Jones wrote:
Isn't the point that Microsoft have just illustrated that they intend tightening
their grip over the development tools, in which case the future viability of D
as open source is jeopardized; if you want to program D you will have to obtain
some
On 23 December 2013 22:06, bearophile bearophileh...@lycos.com wrote:
Iain Buclaw:
Did you really think that __simd went through a design phase? :-)
I understand. So there is still a problem bigger than __simd.
To be fair, I don't think this is as significant as it sounds. I agree,
__simd
On 12/23/13 4:25 AM, Dicebot wrote:
On Monday, 23 December 2013 at 12:03:05 UTC, ilya-stromberg wrote:
Can we add alias for `auto-expansion TypeTuple` and add link to the
previous documentation like this:
alias ExpandedTemplateArgumentList(T) = TemplateArgumentList!(T).expand;
It looks like
On 12/23/13 4:07 AM, bearophile wrote:
Jakob Ovrum:
One tuple and two compile-time lists - where the auto-expanding one
covers the vast majority of use cases - doesn't sound at all bad.
Plus built-in syntax to unpack tuples in various situations.
I don't think various situations is a good
On 23 December 2013 16:03, Russel Winder rus...@winder.org.uk wrote:
On Mon, 2013-12-23 at 10:51 +, Iain Buclaw wrote:
[…]
As for GDC it could one of two things.
1) Write assembly output to stdout
2) Create an executable named -
Are either of those actually useful?
-o- is not
Brilliant! I've found myself in need of this exactly, and had
just started on my own - you have saved me a lot of work!
On Sunday, 22 December 2013 at 00:18:51 UTC, Lars T. Kyllingstad
wrote:
I've been working on a D wrapper for the ∅MQ (aka. ZMQ/ZeroMQ)
messaging library, and I think it's
On 23 December 2013 23:02, Manu turkey...@gmail.com wrote:
On 23 December 2013 22:06, bearophile bearophileh...@lycos.com wrote:
Iain Buclaw:
Did you really think that __simd went through a design phase? :-)
I understand. So there is still a problem bigger than __simd.
To be fair, I
On 23 December 2013 16:47, Todd VanderVeen tdvanderv...@gmail.com wrote:
First, let me say thanks for the addition of the popcnt inline assembler
opcode. I had placed a project on hold until it was available. I look
forward to using D again.
I determined this instruction was available after
On 23 December 2013 20:18, Todd VanderVeen tdvanderv...@gmail.com wrote:
Is there any reason that core.cpuid.hasPopcnt() cannot be made pure?
Hopefully, calling it won't change my processor :)
It may have side effects, or no one thought about making it pure.
On 24 December 2013 09:37, Iain Buclaw ibuc...@gdcproject.org wrote:
On 23 December 2013 23:02, Manu turkey...@gmail.com wrote:
On 23 December 2013 22:06, bearophile bearophileh...@lycos.com wrote:
Iain Buclaw:
Did you really think that __simd went through a design phase? :-)
I
On 12/23/13 5:41 AM, Maxim Fomin wrote:
Personally I am upset when I get some weird Phobos structure which
simulates language feature, rathen then having feature in the language
in first place.
It's a fine line to thread. Erring on either side is easy and with bad
consequences.
Andrei
On Mon, Dec 23, 2013 at 04:30:14PM -0800, Andrei Alexandrescu wrote:
On 12/23/13 5:41 AM, Maxim Fomin wrote:
Personally I am upset when I get some weird Phobos structure which
simulates language feature, rathen then having feature in the
language in first place.
It's a fine line to thread.
Andrei Alexandrescu:
I don't think various situations is a good idea. It often
does make code shorter. But it means more rules to be defined,
implemented, and taught.
Here I have written various situations because I have given a
list of those various situations in past posts.
I think the
H. S. Teoh:
Personally, I'm for simplifying the core language and moving
non-essentials out to the standard library
How do you define essential?
- Frequently used;
- The compiler can compile it as efficiently as handwritten code;
- Has a sufficiently clean semantics, that is most times the
On Monday, 23 December 2013 at 21:43:35 UTC, Walter Bright wrote:
On 12/23/2013 12:50 PM, Stephen Jones wrote:
Isn't the point that Microsoft have just illustrated that they
intend tightening
their grip over the development tools, in which case the
future viability of D
as open source is
On Mon, Dec 23, 2013 at 03:00:25PM +, Francesco Cattoglio wrote:
Sorry for the amount of text, but I tried to explain everything in a
clear and simple way.
I'm willing to volunteer for adding support for more types in iota.
The relevant discussion is:
On Mon, Dec 23, 2013 at 03:30:12PM +, Francesco Cattoglio wrote:
On Monday, 23 December 2013 at 15:23:45 UTC, bearophile wrote:
If the new iota accepts new types, then no existing code is using
iota for such cases. So you are not breaking code is you offer a
more restricted range for such
On Tue, Dec 24, 2013 at 01:05:26AM +, bearophile wrote:
H. S. Teoh:
Personally, I'm for simplifying the core language and moving
non-essentials out to the standard library
How do you define essential?
- Frequently used;
I don't think 'frequently used' is sufficient to justify putting
I think this is just getting absurd.
The conflation between the naming issue and auto-expansion is so
bloody dishonest. The DIP looks really good to newbies because it
addresses the former but then they don't really understand the
latter (as some have even said explicitly). Further, if this
On Tue, Dec 24, 2013 at 02:52:18AM +, Jakob Ovrum wrote:
I think this is just getting absurd.
The conflation between the naming issue and auto-expansion is so
bloody dishonest. The DIP looks really good to newbies because it
addresses the former but then they don't really understand the
On Tuesday, 24 December 2013 at 04:08:25 UTC, H. S. Teoh wrote:
So if we only implemented the first part of the DIP, the
renaming of
std.typeconds.TypeTuple - std.meta.list (or whatever, let's
not start
bikeshedding this early), along with the documentation cleanup
which is
long overdue
On Tuesday, 24 December 2013 at 04:48:57 UTC, Jakob Ovrum wrote:
[1] Assuming that the case for non-auto-expanding lists can be
argued sufficiently for inclusion in Phobos, which is yet to be
seen. This DIP doesn't seem to even try.
Clarification: Assuming that the case for non-auto-expanding
On 12/23/13 7:00 AM, Francesco Cattoglio wrote:
A few preliminary considerations:
- iota() currently returns a Random Access range, and I'm sure nobody
would agree to downgrade the result to a ForwardRange or an InputRange,
because that would break an unknown amount of code.
Agreed.
- I
On 12/23/13 7:34 AM, monarch_dodra wrote:
My issue about this is that it will break existing code that doesn't
even use the type TypeTuple. What are the gains of:
anySatisfy!(someTrait, TemplateArgumentList!(int, double));
over
anySatisfy!(someTrait, int, double)
Or
anySatisfy!(someTrait,
On 12/23/13 8:21 AM, monarch_dodra wrote:
On Monday, 23 December 2013 at 15:59:10 UTC, Timon Gehr wrote:
As is the former. :P
http://dlang.org/template.html#TemplateArgumentList
I think using the name TemplateArgumentList for anything other than a
shallow wrapper around a template argument
Am Mon, 23 Dec 2013 23:46:11 +
schrieb Iain Buclaw ibuc...@gdcproject.org:
On 23 December 2013 16:47, Todd VanderVeen tdvanderv...@gmail.com wrote:
First, let me say thanks for the addition of the popcnt inline assembler
opcode. I had placed a project on hold until it was available. I
Am Mon, 23 Dec 2013 23:46:11 +
schrieb Iain Buclaw ibuc...@gdcproject.org:
On 23 December 2013 16:47, Todd VanderVeen tdvanderv...@gmail.com wrote:
First, let me say thanks for the addition of the popcnt inline assembler
opcode. I had placed a project on hold until it was available. I
For my (very) early stage GtkD program, my SCons script (using all
source at once) generates a 6MB executable that works. Dub appears to
think that it is creating a .a archive and create 142MB of it. So how to
create an executable with Dub?
--
Russel.
On Sunday, 22 December 2013 at 21:07:11 UTC, Charles McAnany
wrote:
Friends,
I'm writing a little molecular simulator. Without boring you
with the details, here's the gist of it:
struct Atom{
double x, vx;
double interaction(Atom a2){
return (a2.x-this.x)^^2; //more
On Sunday, 22 December 2013 at 14:52:23 UTC, Russel Winder wrote:
On Sun, 2013-12-22 at 13:29 +, Amateur wrote:
Hello,
I'm beginning with programming on desktop. After choosing which
language is da best for me, I chose D. And now I want to
create
GUI applications, so I tried installing
On 12/22/2013 9:22 PM, David Held wrote:
[...]
D:\workspace\...dmd bug1.d
D:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module
std.c.stdio import 'FHND_WCHAR' not found
D:\D\dmd2\windows\bin\..\..\src\phobos\std\stdio.d(35): Error: module
std.c.stdio import 'FHND_TEXT' not found
On 2013-12-23 09:04, Russel Winder wrote:
For my (very) early stage GtkD program, my SCons script (using all
source at once) generates a 6MB executable that works. Dub appears to
think that it is creating a .a archive and create 142MB of it. So how to
create an executable with Dub?
You need to
On 2013-12-23 10:52, Jacob Carlborg wrote:
You need to add a package.json file to your project.
http://code.dlang.org/package-format
I accidentally sent the above message too soon.
You either need to explicitly set the target type[1] to executable or
make sure your project works with
Show your package.json file and the project structure.
23.12.2013 15:04, Russel Winder пишет:
For my (very) early stage GtkD program, my SCons script (using all
source at once) generates a 6MB executable that works. Dub appears to
think that it is creating a .a archive and create 142MB of it. So how to
create an executable with Dub?
I statically
On Monday, 23 December 2013 at 10:57:09 UTC, Benjamin Thaut wrote:
Doing lots of C interfacing lately I wonder if there is a way
to create a D function with C calling convention but D
mangeling. I need this to place C callbacks onto functions
inside D templates. Putting extern(C) before it
Doing lots of C interfacing lately I wonder if there is a way to create
a D function with C calling convention but D mangeling. I need this to
place C callbacks onto functions inside D templates. Putting extern(C)
before it does not work in this case. As extern(C) will also enforce C
mangling
1 - 100 of 147 matches
Mail list logo
