I am using ranges (wrapped in InputRangeObject for use in
interfaces) of shared objects, with new beta some cases are
broken:
```
import std.range;
class A {}
InputRange!(shared A) foo()
{
return [new A].inputRangeObject;
}
void bar()
{
auto res = foo.array;
}
void main() {}
See if stdio allows you to specify delete sharing when opening
the file.
On windows files are traditionally opened without delete sharing,
such files can't be deleted until closed, because all sharing
options are always honored.
On Sunday, 6 July 2014 at 19:27:38 UTC, Rainer Schuetze wrote:
Ok, that allows separate compilation of the class, but
templates are still compiled with the rest of the program. I
thought the templates were the part that cause the slow
compilation.
I had no chance to profile till now, but I
On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote:
See if stdio allows you to specify delete sharing when opening
the file.
I don't know what delete sharing is exactly, but the File
constructor simply calls fopen and I don't see any option for the
Windows fopen that seems to do it:
On Mon, 07 Jul 2014 12:17:34 +0100, Joakim dl...@joakim.airpost.net
wrote:
On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote:
See if stdio allows you to specify delete sharing when opening the file.
I don't know what delete sharing is exactly, but the File constructor
simply calls
Hi all,
I'm discovering the D language that seems very nice in many
aspects, but I'm quite confused by the container and range APIs
while trying to design a very simple interface-oriented API.
Especially I can't figure out how std.containers can connect
properly with std.ranges :
I'm trying to
On Monday, 7 July 2014 at 11:17:35 UTC, Joakim wrote:
On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote:
See if stdio allows you to specify delete sharing when opening
the file.
In std.stdio, File(name, mode) is forwarded to _wfopen on Windows
and to fopen on posix.
On Windows there
On Monday, 7 July 2014 at 12:06:21 UTC, Frédérik wrote:
Hi all,
I'm discovering the D language that seems very nice in many
aspects, but I'm quite confused by the container and range APIs
while trying to design a very simple interface-oriented API.
Especially I can't figure out how
Frédérik:
Especially I can't figure out how std.containers can connect
properly with std.ranges :
std.containers is still primitive, it needs to be improved and
fleshed out, after Andrei's memory allocators.
I would need to get the range that comes from the red black tree
(as returned by
On Monday, 7 July 2014 at 12:06:21 UTC, Frédérik wrote:
I'm trying to achieve something like that (approximate D code):
interface MyObjectSet
{
void add(MyObject o);
void SortedRange!MyObject opSlice();
}
class SomeRedBlackBasedImplementation
{
private RedBlackTree!MyObject
Meta:
(a SortedRange needs a range with random access,
I think SortedRange was recently improved, and now accepts more
than just random access ranges.
Bye,
bearophile
Thank you very much to all of you for these very quick and
precise answers !! As well as for tour recommendations about D's
idiomatisms, it seems very important to me since there are so
many available paradigms in D.
I'll try these solutions and I'll be able to go ahead with my
first D
On Monday, 7 July 2014 at 12:00:48 UTC, Regan Heath wrote:
But! I agree with Adam, leave it as a thin wrapper. Being a
windows programmer by trade I would expect the remove to fail,
I would not expect all my files to be opened with delete
sharing enabled by default.
R
And I believe
It can be also a bad user experience, when delete succeeds only
pertially and doesn't free the disk space. Delete-on-close flag
should be better in this regard.
On Mon, 07 Jul 2014 15:18:51 +0100, Jesse Phillips
jesse.k.phillip...@gmail.com wrote:
On Monday, 7 July 2014 at 12:00:48 UTC, Regan Heath wrote:
But! I agree with Adam, leave it as a thin wrapper. Being a windows
programmer by trade I would expect the remove to fail, I would not
expect
Hi again,
The solution of making an array from the range works, but I'm
concerned about the cost of instantiating a (potentially very
large) array each time I need to walk across the set. Unless
doing that is costless in D for any reason, it does not seem
practical in my case.
And when
On Monday, 7 July 2014 at 09:53:22 UTC, NCrashed wrote:
I am using ranges (wrapped in InputRangeObject for use in
interfaces) of shared objects, with new beta some cases are
broken:
```
import std.range;
class A {}
InputRange!(shared A) foo()
{
return [new A].inputRangeObject;
}
On Monday, 7 July 2014 at 14:25:54 UTC, Regan Heath wrote:
If I had to guess, I would say it would still be possible to
access the file.
It's documented so. I guess, linux implements file deletion with
delete-on-close feature too, if it exists, a separate deletion
operation is not needed.
Thanks! Between the -deps flag and duml I think this is exactly
what I need.
On Monday, 7 July 2014 at 09:56:17 UTC, Marc Schütz wrote:
On Monday, 7 July 2014 at 02:57:09 UTC, Frustrated wrote:
So, I took all the code surrounding the error message(which
was a lot of code) and stuck it into one .d file.
No errors! Works as expected.
So, WTF?!?!
I guess now I have to
On Monday, 7 July 2014 at 14:51:37 UTC, Fr wrote:
The solution of making an array from the range works, but I'm
concerned about the cost of instantiating a (potentially very
large) array each time I need to walk across the set. Unless
doing that is costless in D for any reason, it does not
On Sunday, 6 July 2014 at 11:25:04 UTC, w0rp wrote:
I hit this myself also. I was trying to use the master branch
DMD, druntime, and phobos with a recent vibe.d for building the
documentation with ddox, and I ran into the reliance on
std.metastrings.
I got things to work after some cleanups
On Monday, 7 July 2014 at 12:00:48 UTC, Regan Heath wrote:
On Mon, 07 Jul 2014 12:17:34 +0100, Joakim
dl...@joakim.airpost.net wrote:
On Monday, 7 July 2014 at 10:19:01 UTC, Kagamin wrote:
See if stdio allows you to specify delete sharing when
opening the file.
I don't know what delete
when I build dustmite using dmd or gdc with no options or -O3, it
is 18M but in the dmd directory, dustmite is only 650k. I assume
I'm statically linking the whole library while in the small one
is using some dynamic link library? Or is all that debug
information or what?
On Monday, 7 July 2014 at 17:50:35 UTC, Frustrated wrote:
when I build dustmite using dmd or gdc with no options or -O3,
it is 18M but in the dmd directory, dustmite is only 650k. I
assume I'm statically linking the whole library while in the
small one is using some dynamic link library? Or is
On Monday, 7 July 2014 at 16:58:51 UTC, anonymous wrote:
No array is created in the example. Where do you think an array
is created?
It's in the example above :
SortedRange!(MyObject[]) opSlice() {
sequence[].array.assumeSorted; }
I thought that that using .array would lead to
On Monday, 7 July 2014 at 19:20:24 UTC, Fr wrote:
It's in the example above :
SortedRange!(MyObject[]) opSlice() {
sequence[].array.assumeSorted; }
I thought that that using .array would lead to instantiating
something.
Yes, this *will* instantiate an array and copy all of the items
from
Using std.algorithm.sort(a,b,c,d,e) I get the error message :
core.exception.AssertError@C:\dmd\windows\bin\..\..\src\phobos\std\algorithm.d(1
0350): Predicate for isSorted is not antisymmetric. Both pred(a,
b) and pred(b,
a) are true for a=Tuple!(float, int, uint[], int,
uint[])(-7.56963e-05,
Archibald:
Using std.algorithm.sort(a,b,c,d,e)
But isn't std.algorithm.sort accepting only one argument?
Bye,
bearophile
On Monday, 7 July 2014 at 19:20:24 UTC, Fr wrote:
On Monday, 7 July 2014 at 16:58:51 UTC, anonymous wrote:
No array is created in the example. Where do you think an array
is created?
It's in the example above :
SortedRange!(MyObject[]) opSlice() {
sequence[].array.assumeSorted; }
I
On Monday, 7 July 2014 at 20:10:10 UTC, Archibald wrote:
Using std.algorithm.sort(a,b,c,d,e) I get the error message :
core.exception.AssertError@C:\dmd\windows\bin\..\..\src\phobos\std\algorithm.d(1
0350): Predicate for isSorted is not antisymmetric. Both
pred(a, b) and pred(b,
a) are true
On Monday, 7 July 2014 at 20:17:16 UTC, bearophile wrote:
Archibald:
Using std.algorithm.sort(a,b,c,d,e)
But isn't std.algorithm.sort accepting only one argument?
Bye,
bearophile
Sorry, it's sort(zip(a,b,c,d,e))
Is it chain you are after to concatenate the objects and sort
them together?
http://dlang.org/phobos/std_range.html#.chain
You'd need to cast them all to the same type.
On Monday, 7 July 2014 at 20:50:06 UTC, Archibald wrote:
On Monday, 7 July 2014 at 20:17:16 UTC, bearophile wrote:
On Mon, Jul 07, 2014 at 08:35:53PM +, anonymous via Digitalmars-d-learn
wrote:
[...]
Looks like a bad bug:
void main()
{
uint[] a = [0x22_DF_FF_FF];
uint[] b = [0xA2_DF_FF_FF];
assert(!(a b b a)); /* fails */
}
This looks pretty serious. Please file a bug:
I'm using a compile time regex to find some tags in an input
string. Is it possible to capture the offset of the matches in
some way? Otherwise I have to calculate the offsets myself by
iterating over the results of matchAll.
Thanks,
Jeroen
---
Example code:
import std.stdio;
import
Because D currently doesn't support RAII using named parameters
like in Python I tried the following.
Say I have an aggregate
class C { int x,y,z,w; }
or similarly
struct C { int x,y,z,w; }
I know define a generic _free_ function
ref T set(string member, T, U)(ref T a, in U value) if
On Mon, 07 Jul 2014 21:34:05 +, Nordlöw wrote:
However using this function through UFCS
auto cx = new C().set!x(11);
fails as
algorithm_ex.d(1257,17): Error: template algorithm_ex.set cannot deduce
function from argument types !(x)(C, int), candidates are:
On Mon, 07 Jul 2014 21:49:22 +, Justin Whear wrote:
On Mon, 07 Jul 2014 21:34:05 +, Nordlöw wrote:
However using this function through UFCS
auto cx = new C().set!x(11);
fails as
algorithm_ex.d(1257,17): Error: template algorithm_ex.set cannot deduce
function from
On 07.07.2014 12:46, ParticlePeter wrote:
On Sunday, 6 July 2014 at 19:27:38 UTC, Rainer Schuetze wrote:
These object files are in the library ;-) That means manual selection,
though, as incremental builds to multiple object files don't work with
dmd, and single file compilation is painfully
Hey all,
I've not posted here in a while, but I've been keeping up to
speed with D's progress over the last couple of years and remain
consistently impressed with the language.
I'm part of a new computing society in the University of
Newcastle, Australia, and am essentially known throughout
On Monday, 7 July 2014 at 21:50:22 UTC, Justin Whear wrote:
Copy and paste gone astray; should be this link:
http://dpaste.dzfl.pl/3c33ad70040f
Thx!
In C my favorite way of achieving encapsulation is to use
incomplete types. The module header contains the definition of an
incomplete type and the prototypes for the public functions which
operate on it. I have read D has incomplete types too however D
does not have headers and as a C guy I
You may want to spearhead the effort to get Win32 support of
MSVC into D, if you care enough about it. Rainer has done most
of the work, you'd just have to turn his patches into pull
requests, shepherd them through the review process, and maybe
add some polish:
Let me see what I can do for time. There's the above, it's
also possible to link mixed coff and omf with jwlink
(http://www.japheth.de/JWlink/JWlink.htm).
There's a couple of paths and while win32 isn't leading edge, I
think enhancing it is a worthwhile project for lesser lights
like
On Mon, Jul 07, 2014 at 11:47:25PM +, Aerolite via Digitalmars-d-learn
wrote:
[...]
So, if you would be so kind, give me a bullet list of the aspects of D
you believe to be good, awesome, bad, and/or ugly. If you have the
time, some code examples wouldn't go amiss either! Try not to go
46 matches
Mail list logo
