On 19/05/14 08:29, Jacob Carlborg wrote:
DWT is still around. Although, I don't have any memory of seeing the
monitor being used.
The "synchronized" statement is used in DWT.
--
/Jacob Carlborg
On Mon, 19 May 2014 06:05:26 +
via Digitalmars-d wrote:
> On Monday, 19 May 2014 at 05:39:49 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > 1. it makes it easier to reason about code, because it
> > guarantees that the
> > function didn't access any global or static variables.
>
> It ca
On 18/05/14 07:01, Walter Bright wrote:
While I agree with Andrei's agreements (!), the rationale for the
current approach is to make it relatively straightforward to translate
existing Java code into D. There was a fair amount of this in the early
days of D, I'm not sure how much of that lately
On Monday, 19 May 2014 at 05:39:49 UTC, Jonathan M Davis via
Digitalmars-d wrote:
1. it makes it easier to reason about code, because it
guarantees that the
function didn't access any global or static variables.
It can, through the parameters, like an array of pointers. And
avoiding IO is not
On Mon, 19 May 2014 05:16:13 +
via Digitalmars-d wrote:
> On Monday, 19 May 2014 at 01:19:29 UTC, Jonathan M Davis via
> Digitalmars-d wrote:
> > It's already so rare that memoization of a function call can
> > occur, that I'm
> > pretty much convinced that memoization is useless as an
> > op
On Monday, 19 May 2014 at 01:19:29 UTC, Jonathan M Davis via
Digitalmars-d wrote:
It's already so rare that memoization of a function call can
occur, that I'm
pretty much convinced that memoization is useless as an
optimization - at
least as long as the compiler is doing it. After all, how often
On Sunday, 18 May 2014 at 08:02:59 UTC, bearophile wrote:
deadalnix:
If the machine code is the same, the function can be merged by
the optimizer.
But in general isn't it more efficient to not generate bloat
instead of generating it, detecting it, and removing it?
Bye,
bearophile
Yes, th
Ed, the "humanistic" programmer. It fits.
Email me. Would like to communicate.
Jim Fox (RPI Physics grad and roommate; now full bore
software/database programmer/administrator LOL)
On Sunday, 6 April 2008 at 01:47:20 UTC, Edward Diener wrote:
Bill Baxter wrote:
Has anyone heard of this?:
On Sun, 18 May 2014 17:48:45 -0700, Adam Wilson wrote:
Addendum:
In the module Structs and Interfaces are wrapped with static if blocks
in the following manner:
static if(DX110)
{
//Enumerations
}
static if(DX111) { //...}
static if(DX112) { //...}
static if(DX110)
{
//Str
On Sun, 18 May 2014 06:58:25 -0700
"H. S. Teoh via Digitalmars-d" wrote:
> On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via
> Digitalmars-d wrote:
> > On Thu, 15 May 2014 08:43:11 -0700
> > Andrei Alexandrescu via Digitalmars-d
> > wrote:
> >
> > > On 5/15/14, 6:28 AM, Dicebot wrot
On Sun, 18 May 2014 17:48:45 -0700, Adam Wilson wrote:
Addendum:
In the module Structs and Interfaces are wrapped with static if blocks
in the following manner:
static if(DX110)
{
//Enumerations
}
static if(DX111) { //...}
static if(DX112) { //...}
static if(DX110)
{
//Str
Addendum:
In the module Structs and Interfaces are wrapped with static if blocks in
the following manner:
static if(DX110)
{
//Enumerations
}
static if(DX111) { //...}
static if(DX112) { //...}
static if(DX110)
{
//Structs
}
static if(DX111) { //...}
static if(DX112) { //...}
Hi guys,
I have been beating my head against this wall for a few days and I am
having difficult understanding what's going on here. I am building the
DirectX COM bindings for Aurora and DMD is popping out an "Undefined
Identifier" error when I use an interface as a member of a struct.
Con
"Undefined Behavior in C++; what is it, and why should I care":
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/Undefined-Behavior.pdf?raw=true
This reminds us to remove as much undefined behavior as
possible from D.
Fixing some of those problems will break some D code.
On Mon, 05 May 2014 19:20:45 -0700, Lionello Lunesu
wrote:
Hi all,
After last year's incident with my tires getting slashed, I'm really
hoping I can do without a car during this year's DConf. How feasible is
this?
I'll be staying at Aloft. Would be great if there's someone I can share
Nordlöw:
This may be a good start:
https://github.com/nordlow/justd/blob/master/bound.d
I presume some ways to improve it are to add to core.bitop some D
standard intrinsics to detect overflows and carry, to increase
run-time performance to sufficient levels. If they are not fast,
people w
Here are the slides of a nice talk, "Removing undefined
behavior from integer operations: the bounded::integer library":
This may be a good start:
https://github.com/nordlow/justd/blob/master/bound.d
On Sunday, 18 May 2014 at 17:58:04 UTC, jack death wrote:
this sucks. it would be nice to get a gui lib that works with
32 and 64 bit. create a nice language and don't the tools/libs
to use it.
with your attitude you will not have a chance to became main
stream.
D bindings exist for an - admi
On 5/13/2014 8:46 AM, Yuriy wrote:
Your feedback is very appreciated. Thanx.
The "_monitor" slot is also used for std.signals. It's been set up in druntime
to support more than just being a monitor.
We've also considered it for a hook for a reference count (though that design
had other prob
On 05/18/2014 11:03 AM, bearophile wrote:
Some more slides pack from "C++ Now 2014":
For those of us who are in the Bay Area, we will have a trip report:
http://www.meetup.com/SFBay-Association-of-C-C-Users/events/179180452/
Ali
Some more slides pack from "C++ Now 2014":
"Undefined Behavior in C++; what is it, and why should I care":
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/Undefined-Behavior.pdf?raw=true
This reminds us to remove as much undefined behavior as possible
from D.
"Mach7: Th
this sucks. it would be nice to get a gui lib that works with 32
and 64 bit. create a nice language and don't the tools/libs to
use it.
with your attitude you will not have a chance to became main
stream.
On Sunday, 18 May 2014 at 17:50:47 UTC, Gary Willoughby wrote:
On Thursday, 15 May 2014
On Thursday, 15 May 2014 at 03:58:15 UTC, FrankLike wrote:
1.DFL's Memory Usage is the least than other. winsamp.exe is
2.1M,DFL's example's exe is 2.7M.
2.The size of DFL's example's exe files is the least than other,
and only a single file.
3.DFL's source code is the most easy to understand.
D
On 18 May 2014 14:46, Dragos Carp via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:
>
>> Hi all,
>>
>> After last year's incident with my tires getting slashed, I'm really
>> hoping I can do without a car during this year's DCo
Also see https://github.com/rejectedsoftware/ddox for DDOC
compatible documentation generator that uses the JSON output.
However, due to various shortcomings, of which not all are easy
to resolve, I'm planning to instead directly use a D parser at
some point.
Yes, this seems like a good too
On Sunday, 18 May 2014 at 14:54:44 UTC, FrankLike wrote:
1.DFL's Memory Usage is the least than other. winsamp.exe is
2.1M,DFL's example's exe is 2.7M.
DGui's Memory Usage is 3.2M.
[1] https://bitbucket.org/dgui/dgui
[2] https://bitbucket.org/dgui/dgui/downloads
You will put it in code.dl
1.DFL's Memory Usage is the least than other. winsamp.exe is
2.1M,DFL's example's exe is 2.7M.
DGui's Memory Usage is 3.2M.
[1] https://bitbucket.org/dgui/dgui
[2] https://bitbucket.org/dgui/dgui/downloads
You will put it in code.dlang.org and github.com?
DGui is very cool,the exe's size
*http://denis-sh.bitbucket.org/
Where is the DGui?
This dgui is very cool.
On Sunday, 18 May 2014 at 10:33:53 UTC, Andrei Alexandrescu wrote:
Maybe I misunderstood - I thought the change preserves
semantics. -- Andrei
There are two layers to the changes discussed in this thread. The
first is to remove __monitor from Object. This is something I
think we all agree on.
Andrei Alexandrescu:
Maybe I misunderstood - I thought the change preserves
semantics. -- Andrei
Perhaps it's Walter that has misunderstood.
Bye,
bearophile
On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Thu, 15 May 2014 08:43:11 -0700
> Andrei Alexandrescu via Digitalmars-d
> wrote:
>
> > On 5/15/14, 6:28 AM, Dicebot wrote:
> > > This is not true. Because of such code you can't ever
> > > automatically memo
On Sunday, 18 May 2014 at 13:44:14 UTC, FrankLike wrote:
I'd suggest to put the effort in DGui [1] instead because its
author, Antonio Davide Trogu, kindly changed the license to
Boost as he want the library to be used.
By the way, see DGui examples at Downloads page [2], they are
smaller,
On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:
Hi all,
After last year's incident with my tires getting slashed, I'm
really hoping I can do without a car during this year's DConf.
How feasible is this?
I'll be staying at Aloft. Would be great if there's someone I
can share a
I'd suggest to put the effort in DGui [1] instead because its
author, Antonio Davide Trogu, kindly changed the license to
Boost as he want the library to be used.
By the way, see DGui examples at Downloads page [2], they are
smaller, than DFL ones. Also one of DGui goals was a source
code s
On Sunday, 18 May 2014 at 09:22:53 UTC, FrankLike wrote:
DFL isn't boost licensed, that's the problem for me. And
Christopher didn't answered anything on my proposal to change
the license.
I'd suggest to put the effort in DGui [1] instead because its
author, Antonio Davide Trogu, kindly cha
On 5/17/14, 10:01 PM, Walter Bright wrote:
On 5/14/2014 2:17 PM, Andrei Alexandrescu wrote:
On 5/14/14, 6:33 AM, Yuriy wrote:
4. I consider D a killemall language, that may be potentially used on
tiny AVRs and PICs, where polymorphism might be welcome, but an extra
pointer for each class instan
Am 17.05.2014 20:28, schrieb Mason McGill:
On Saturday, 17 May 2014 at 18:03:53 UTC, Tolga Cakiroglu wrote:
After having some experience with documentation generation from
dmd command like, and seeing outputs, I wasn't satisfied with it.
Other alternatives as Doxygen is available, though it pars
DFL isn't boost licensed, that's the problem for me. And
Christopher didn't answered anything on my proposal to change
the license.
I'd suggest to put the effort in DGui [1] instead because its
author, Antonio Davide Trogu, kindly changed the license to
Boost as he want the library to be us
Am 18.05.2014 10:18, schrieb bearophile:
Paulo Pinto:
Am 18.05.2014 10:02, schrieb bearophile:
But in general isn't it more efficient to not generate bloat instead of
generating it, detecting it, and removing it?
Bye,
bearophile
Which you can only do if the compiler can see the whole code.
Andrei Alexandrescu:
https://github.com/andralex/phobos/blob/allocator/std/allocator.d
Destruction is as always welcome. I plan to get into tracing
tomorrow morning.
If you have a system with more cores/CPUs, and each core owns
part of the memory (a core can access the memory of another cor
On 5/7/2014 12:03 PM, Maxime Chevalier-Boisvert wrote:
auto ptr = cast(wchar*)alloca(wchar.sizeof * len);
if (ptr == null) throw new Error("...");
auto mySlice = ptr[0 .. len];
Is the slice going to be allocated on the stack? (I imagine the answer is yes)
Yes (slices do not copy).
On 5/7/2014 11:26 AM, Maxime Chevalier-Boisvert wrote:
I have a very specific use case (JIT compiler) in which I have a pre-allocated
array of wchar string data stored somewhere in memory. I'd like to be able to
create a temporary D wstring object to pass this as a "regular" string to other
funct
Paulo Pinto:
Am 18.05.2014 10:02, schrieb bearophile:
But in general isn't it more efficient to not generate bloat
instead of
generating it, detecting it, and removing it?
Bye,
bearophile
Which you can only do if the compiler can see the whole code.
It doesn't work in binary libraries.
I
monarch_dodra:
It's not used in phobos (as far as I know of anyways). It
*could* be implemented in SortedRange's BinaryFind though.
Recently SortedRanges were changed, now they don't need to be
random access ranges, so this is possible and I think it's good:
https://issues.dlang.org/show_bu
Am 18.05.2014 10:02, schrieb bearophile:
deadalnix:
If the machine code is the same, the function can be merged by the
optimizer.
But in general isn't it more efficient to not generate bloat instead of
generating it, detecting it, and removing it?
Bye,
bearophile
Which you can only do if t
deadalnix:
If the machine code is the same, the function can be merged by
the optimizer.
But in general isn't it more efficient to not generate bloat
instead of generating it, detecting it, and removing it?
Bye,
bearophile
On Friday, 16 May 2014 at 06:46:08 UTC, Jacob Carlborg wrote:
On 16/05/14 00:16, Etienne wrote:
Templates are compile-time, a D compiler always takes care of
all its
compile-time duties =)
Unfortunately it does not. It causes unnecessary bloat. Take
this for example:
void foo (T) (T t);
07.05.2014 22:26, Maxime Chevalier-Boisvert пишет:
I have a very specific use case (JIT compiler) in which I have a
pre-allocated array of wchar string data stored somewhere in memory. I'd
like to be able to create a temporary D wstring object to pass this as a
"regular" string to other functions
15.05.2014 7:58, FrankLike пишет:
1.DFL's Memory Usage is the least than other. winsamp.exe is
2.1M,DFL's example's exe is 2.7M.
2.The size of DFL's example's exe files is the least than other,
and only a single file.
3.DFL's source code is the most easy to understand.
D need Christopher E. Mill
On Saturday, 17 May 2014 at 22:05:03 UTC, bearophile wrote:
monarch_dodra:
for a sorted linked list (or forward iterators in general),
you can find the result with O(N) *walk* iterations, but still
only O(log(N)) *comparison* iterations.
I think I have never implement such algorithm, but you
50 matches
Mail list logo
