On Thursday, 8 May 2014 at 04:46:48 UTC, John wrote:
How is the performance when compared to other GUIs like Qt or
Gtk? For example, in one application, I need to dynamically
create several hundred of controls at runtime.
BTW, what's your use case? Nested tabbed dialog? After creation
it
On Sunday, 4 May 2014 at 16:18:53 UTC, Gary Willoughby wrote:
https://github.com/nomad-software/tkd
https://github.com/nomad-software/tkd/blob/master/source/tkd/element/element.d
Since you allocate CommandArgs in C heap, its content is
invisible to GC and will be freed - uniqueData and
On Sunday, 11 May 2014 at 10:16:35 UTC, Kagamin wrote:
https://github.com/nomad-software/tkd/blob/master/source/tkd/element/element.d
Since you allocate CommandArgs in C heap, its content is
invisible to GC and will be freed - uniqueData and callback.
Can you clarify what you mean here? Are
GC cleans up for you. Usually this won't happen because
uniqueData is likely to be in data section and callback is likely
to be a member of a widget used elsewhere. But if they aren't, GC
will free them and you end up with dangling pointers in
CommandArgs.
On Sunday, 11 May 2014 at 14:04:44 UTC, Kagamin wrote:
GC cleans up for you. Usually this won't happen because
uniqueData is likely to be in data section and callback is
likely to be a member of a widget used elsewhere. But if they
aren't, GC will free them and you end up with dangling
The timezones being so different, I'm not sure livestreaming will help
me... But I do plan to watch any videos of it as soon as they are up.
On Sun, May 11, 2014 at 5:06 AM, Joakim via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On Friday, 9 May 2014 at 19:48:20 UTC,
On 11 May 2014 14:57, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/10/2014 8:58 PM, Manu via Digitalmars-d wrote:
This is truly a niche usage case though,
Come on! Like about 80% of the programs on any linux box? Like the OCR
program I run? A payroll processing
On 5/10/14, 11:27 PM, Manu via Digitalmars-d wrote:
On 11 May 2014 14:57, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/10/2014 8:58 PM, Manu via Digitalmars-d wrote:
This is truly a niche usage case though,
Come on! Like about 80% of the programs on any linux
Am 06.05.2014 05:40, schrieb Manu via Digitalmars-d:
Does ~this() actually work, or just usually work?
Do you call your destructors manually like C#?
Back when I actually used D's GC, it did usually work. There were a few
workarounds because destructors would be called in the wrong thread,
Am 10.05.2014 19:54, schrieb Andrei Alexandrescu:
The next sentence goes on to list the advantages of RC (issues we have
wrestled with, like destructors), and then goes on to say the recent
awesome RC is within 10% of the fastest tracing collectors.
Are you suggesting that D's GC is among 'the
On 5/10/2014 11:27 PM, Manu via Digitalmars-d wrote:
Because if this was an easy problem, it would have been solved. In
particular, if the ARC overhead was easily removed by simple compiler
enhancements, why hasn't ARC taken the world by storm? It's not like ARC was
invented yesterday.
And as
On 5/11/2014 1:22 AM, Benjamin Thaut wrote:
Honenstly, D doesn't currently have any GC support at all. The only GC support
we have is that the GC knows all threads and can halt them. And D knows which
function to call, to destroy class objects. So basically we have the same level
of GC support
On 5/11/2014 1:22 AM, Benjamin Thaut wrote:
2) Most modern GC algorithms require write-barriers for pointers which are on
the heap. This is a major problem for D, because structs can be both on the
stack and on the heap. So if you call a method of a struct, the compiler can not
know if the write
On Saturday, 10 May 2014 at 19:41:15 UTC, H. S. Teoh wrote:
On Sat, May 10, 2014 at 09:16:54PM +0200, Xavier Bigand wrote:
Why theses questions :
- Memory management seems to be one of last (or the last)
critical
point for a vastly adoption in production.
[...]
Nah, it's just the thing
Am 11.05.2014 10:53, schrieb Walter Bright:
On 5/11/2014 1:22 AM, Benjamin Thaut wrote:
This is not quite correct. The Boehm GC knows nothing about the
interiors of structs.
The D one does (or at least has the capability of doing so using
RTinfo). This means that the D collector can be
On 11 May 2014 17:52, Benjamin Thaut via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am 06.05.2014 05:40, schrieb Manu via Digitalmars-d:
I support the notion that if the GC isn't removed as a foundational
feature of D, then destructors should probably be removed from D.
That said, I
The vast majority of software, at least as far as I can see, use
web services. That makes up the vast majority of software on my
Android phone. Garbage collection is definitely applicable for
web servers, so there is a huge area where D and a garbage
collector can apply nicely. I think the
Am 11.05.2014 12:57, schrieb w0rp:
The vast majority of software, at least as far as I can see, use web
services. That makes up the vast majority of software on my Android
phone. Garbage collection is definitely applicable for web servers, so
there is a huge area where D and a garbage collector
On Tuesday, 6 May 2014 at 03:40:47 UTC, Manu via Digitalmars-d
wrote:
On 3 May 2014 18:49, Benjamin Thaut via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am 30.04.2014 22:21, schrieb Andrei Alexandrescu:
Walter and I have had a long chat in which we figured our
current
offering of
On Sunday, 11 May 2014 at 08:59:42 UTC, Walter Bright wrote:
D also cannot be performance competitive with C++ if pervasive
ARC is used and memory safety is retained. Rust is attempting
to solve this problem by using 'borrowed' pointers, but this is
unproven technology, see my reply to Manu
On 11/05/14 05:58, Nick Sabalausky via Digitalmars-d wrote:
The seed doesn't need to be compromised for synchronized RNGs to fubar security.
Before we go onto the detail of discussion, thanks very much for the extensive
explanation. I was slightly worried that my previous email might have
On 2014-05-11 08:29:13 +, Walter Bright newshou...@digitalmars.com said:
Again, O-C and C++/CX ARC are not memory safe because in order to make
it perform they provide unsafe escapes from it.
But D could provide memory-safe escapes. If we keep the current GC to
collect cycles, we could
On Sunday, 11 May 2014 at 12:52:29 UTC, Michel Fortin wrote:
On 2014-05-11 08:29:13 +, Walter Bright
newshou...@digitalmars.com said:
Again, O-C and C++/CX ARC are not memory safe because in order
to make it perform they provide unsafe escapes from it.
But D could provide memory-safe
On 05/11/2014 10:29 AM, Walter Bright wrote:
...
- A Comment on Rust --
This is based on my very incomplete knowledge of Rust, i.e. just reading
a few online documents on it. If I'm wrong, please correct me.
...
Well, region-based memory management is not new, and
Am Sun, 11 May 2014 14:52:50 +1000
schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com:
On 11 May 2014 05:39, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, May 10, 2014 at 09:16:54PM +0200, Xavier Bigand via Digitalmars-d
wrote:
- Same question if D
On 12 May 2014 02:38, Marco Leise via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Sun, 11 May 2014 14:52:50 +1000
schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com:
On 11 May 2014 05:39, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, May 10, 2014 at
Am Wed, 07 May 2014 06:50:33 +
schrieb Paulo Pinto pj...@progtools.org:
A *nix package manager is brain dead idea for software
development as it ties the language libraries to the specific OS
one is using.
What do you have in mind here? I don't quite get the picture.
Are you opposed to a
On 11.05.2014 10:22, Benjamin Thaut wrote:
Am 10.05.2014 19:54, schrieb Andrei Alexandrescu:
The next sentence goes on to list the advantages of RC (issues we have
wrestled with, like destructors), and then goes on to say the recent
awesome RC is within 10% of the fastest tracing
On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
On 11.05.2014 10:22, Benjamin Thaut wrote:
Am 10.05.2014 19:54, schrieb Andrei Alexandrescu:
The next sentence goes on to list the advantages of RC
(issues we have
wrestled with, like destructors), and then goes on to say
the
On 5/11/2014 5:52 AM, Michel Fortin wrote:
On 2014-05-11 08:29:13 +, Walter Bright newshou...@digitalmars.com said:
Again, O-C and C++/CX ARC are not memory safe because in order to make it
perform they provide unsafe escapes from it.
But D could provide memory-safe escapes. If we keep
On 5/11/2014 7:55 AM, w0rp wrote:
Python people don't tend to talk about speed that much.
:-)
On 5/11/2014 8:54 AM, Timon Gehr wrote:
It is not an escape from ARC per se. It is a way to write type safe code which
is not dependent on the allocation strategy of the processed data. (One can e.g.
safely borrow mutable data as immutable and the type system ensures that during
the time of the
On Sunday, 11 May 2014 at 17:36:44 UTC, Manu via Digitalmars-d
wrote:
On 12 May 2014 02:38, Marco Leise via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Sun, 11 May 2014 14:52:50 +1000
schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com:
On 11 May 2014 05:39, H. S. Teoh via
On 5/11/2014 2:48 AM, Benjamin Thaut wrote:
Mostly percise doesn't help. Its either fully percise or beeing stuck with a
impercise mark sweep.
This is not correct. It helps because most of the false pointers will be in the
heap, and the heap will be accurately scanned, nearly eliminating
On 11.05.2014 21:16, John Colvin wrote:
On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
For a reasonable GC I currently see 2 possible directions:
Coventry
1. Use a scheme that takes a snapshot of the heap, stack and registers
at the moment of collection and do the actual
On 5/11/2014 11:18 AM, Rainer Schuetze wrote:
1. Use a scheme that takes a snapshot of the heap, stack and registers at the
moment of collection and do the actual collection in another thread/process
while the application can continue to run. This is the way Leandro Lucarellas
concurrent GC
On 2014-05-11 19:37:30 +, Walter Bright newshou...@digitalmars.com said:
On 5/11/2014 5:52 AM, Michel Fortin wrote:
On 2014-05-11 08:29:13 +, Walter Bright newshou...@digitalmars.com said:
Again, O-C and C++/CX ARC are not memory safe because in order to make it
perform they provide
On 11.05.2014 22:33, Walter Bright wrote:
The Boehm collector cannot move objects around, the D one can.
Oh it can? Really?
Yes. D, for example, requires that objects not be self-referential for
this reason.
I don't think the GC would have problems with fixing up internal
pointers to
On 05/11/2014 10:05 PM, Walter Bright wrote:
On 5/11/2014 8:54 AM, Timon Gehr wrote:
It is not an escape from ARC per se. It is a way to write type safe
code which
is not dependent on the allocation strategy of the processed data.
(One can e.g.
safely borrow mutable data as immutable and the
On 5/11/2014 1:45 PM, Rainer Schuetze wrote:
On 11.05.2014 22:33, Walter Bright wrote:
The Boehm collector cannot move objects around, the D one can.
Oh it can? Really?
Yes. D, for example, requires that objects not be self-referential for
this reason.
I don't think the GC would have
On Sunday, 11 May 2014 at 11:42:37 UTC, ponce wrote:
On Sunday, 11 May 2014 at 08:59:42 UTC, Walter Bright wrote:
D also cannot be performance competitive with C++ if pervasive
ARC is used and memory safety is retained. Rust is attempting
to solve this problem by using 'borrowed' pointers,
On 5/11/2014 1:43 PM, Michel Fortin wrote:
It is a variation on that scheme, but with one significant difference: those two
pointer types can mix and there's no restriction on assignments from one type to
the other. There's therefore no transitive effect and no complicated ownership
rule to
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~. Heck
I didn't find any @ while casually browsing the code. It's like
they are not using it at all.
Similarly in current C++ std::shared_ptr is barely there while
std::unique_ptr is
Am 11.05.2014 23:43, schrieb sclytrack:
On Sunday, 11 May 2014 at 11:42:37 UTC, ponce wrote:
On Sunday, 11 May 2014 at 08:59:42 UTC, Walter Bright wrote:
D also cannot be performance competitive with C++ if pervasive ARC is
used and memory safety is retained. Rust is attempting to solve this
On Sunday, 11 May 2014 at 22:06:55 UTC, Francesco Cattoglio wrote:
On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~.
Heck I didn't find any @ while casually browsing the code.
On Sunday, 11 May 2014 at 21:49:06 UTC, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~.
Heck I didn't find any @ while casually browsing the code.
It's like they are not using it at all.
Similarly in current C++
11-May-2014 23:16, John Colvin пишет:
On Sunday, 11 May 2014 at 18:18:41 UTC, Rainer Schuetze wrote:
On 11.05.2014 10:22, Benjamin Thaut wrote:
Am 10.05.2014 19:54, schrieb Andrei Alexandrescu:
The next sentence goes on to list the advantages of RC (issues we have
wrestled with, like
On 5/11/2014 3:42 PM, Dmitry Olshansky wrote:
Provided heap was allocated as one big mmap-ed region (or File mapping in Win32)
it should be straightforward to remap it as Copy-on-Write. This would though
reduce virtual memory available in half (if not more provided we'd want to leave
some space
On 5/11/14, 2:49 PM, ponce wrote:
On Sunday, 11 May 2014 at 21:43:06 UTC, sclytrack wrote:
There is very little use of @, it's mostly and ~. Heck I
didn't find any @ while casually browsing the code. It's like they are
not using it at all.
Similarly in current C++ std::shared_ptr is
On 5/11/2014 1:59 PM, Timon Gehr wrote:
On 05/11/2014 10:05 PM, Walter Bright wrote:
That's clearly an additional benefit of the borrowed pointer notion. But
have you examined generated Rust code for the cost of inc/dec? I
haven't, but I don't see any way they could avoid this (very expensive)
I just want to write a web client app on D for medical
institutions. It must be a complicated interface. What tools
(GUI) should I use for quick programming?
Can I somehow abstract from web programming?
Thanks in advance.
Regards, Sergey
On 2014-05-11 21:41:10 +, Walter Bright newshou...@digitalmars.com said:
Your proposal still relies on a GC to provide the memory safety, and
has no inherent protection against GC pauses. Your idea has a lot of
merit, but it is a hybrid ARC/GC system.
If you thread carefully you can
On Saturday, 10 May 2014 at 09:32:30 UTC, Jacob Carlborg wrote:
Cross-posting to get noticed:
http://forum.dlang.org/thread/lkkrij$1r3j$1...@digitalmars.com#post-lkkrij:241r3j:241:40digitalmars.com
Good things.
Am Mon, 12 May 2014 03:36:34 +1000
schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com:
On 12 May 2014 02:38, Marco Leise via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Am Sun, 11 May 2014 14:52:50 +1000
schrieb Manu via Digitalmars-d digitalmars-d@puremagic.com:
On 11 May
Am Sun, 11 May 2014 14:41:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
Your proposal still relies on a GC to provide the memory safety,
[…] it is a hybrid ARC/GC system.
But I thought ARC cannot be designed without GC to resolve
cycles. Or is your comment pure rethoric?
--
On Sunday, 11 May 2014 at 20:45:08 UTC, Rainer Schuetze wrote:
On 11.05.2014 22:33, Walter Bright wrote:
The Boehm collector cannot move objects around, the D one
can.
Oh it can? Really?
Yes. D, for example, requires that objects not be
self-referential for
this reason.
I don't think
On 5/11/2014 9:47 PM, Marco Leise wrote:
Am Sun, 11 May 2014 14:41:10 -0700
schrieb Walter Bright newshou...@digitalmars.com:
Your proposal still relies on a GC to provide the memory safety,
[…] it is a hybrid ARC/GC system.
But I thought ARC cannot be designed without GC to resolve
cycles.
On Sunday, 11 May 2014 at 20:18:23 UTC, luminousone wrote:
I thought x86_64 pointers are sign extended? or does that just
apply to real memory pointers and not virtual memory pointers?
With typed slices you can use one 64 bit base pointer and two 32
bit indexes instead of two pointers.
On 5/11/2014 8:44 PM, Michel Fortin wrote:
As long as C++/CX and O-C are brought out here as proven, successful examples
for D to emulate here, and there is no acknowledgement that they are not
remotely memory safe, I need to continue to point this out.
You should not say that ARC is not safe
Am Sun, 11 May 2014 17:50:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
As long as those pointers don't escape. Am I right in that one cannot store a
borrowed pointer into a global data structure?
Right, and that's the point and entirely positive-to-do™.
Your general purpose
Thank you for your help. But if I change the default console encoding,will it
affect other programs,making other console program show messy code?
On 2014年5月11日 格林尼治标准时间+0800下午1时18分42秒, FrankLike via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Sunday, 11 May 2014 at 02:38:44
Thank you for your help. But if I change the default setting,will it affect
other programs,making other console program show messy code?
On 2014年5月11日 格林尼治标准时间+0800下午12时30分40秒, Ali Çehreli via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On 05/10/2014 07:19 PM, IceNature via
On Sunday, 11 May 2014 at 05:34:38 UTC, Moses wrote:
Thanks, I also found that I need to include the flag
-I/usr/include/dmd/phobos to get it to compile. I tried doing:
export PATH=$PATH:/usr/include/dmd/phobos
but apparently I still need the -I flag. Is there another way
to get around
On Sunday, 11 May 2014 at 07:31:10 UTC, FreeSlave wrote:
On Friday, 9 May 2014 at 21:42:14 UTC, Vlad Levenfeld wrote:
Is this still the case if the method is const or pure?
Const methods still require synchronization, because other
threads may change some data, needed by const method while
On Friday, 9 May 2014 at 21:42:14 UTC, Vlad Levenfeld wrote:
Is this still the case if the method is const or pure?
Const methods still require synchronization, because other
threads may change some data, needed by const method while method
is executed, and then you may get wrong results.
On Sunday, 11 May 2014 at 05:34:38 UTC, Moses wrote:
On Sunday, 11 May 2014 at 04:33:24 UTC, Ali Çehreli wrote:
On 05/10/2014 07:12 PM, Moses wrote:
After using the 1-click Ubuntu installer, I'm having trouble
figuring
out how to import standard library functions for Phobos. I
get the
Known bug https://issues.dlang.org/show_bug.cgi?id=2742
On Sunday, 11 May 2014 at 06:35:26 UTC, IceNature via
Digitalmars-d-learn wrote:
Thank you for your help. But if I change the default console
encoding,will it affect other programs,making other console
program show messy code?
Don't affect,and you must set the font to a unicode font ,such
On Saturday, 10 May 2014 at 20:24:50 UTC, MarisaLovesUsAll wrote:
Hi!
I sometimes got a useless messages in stdout from SDL_Image
library, and I want to temporary silence it. How do I do?
You can temporary redirect output to file. Example (on C):
#include stdio.h
#include unistd.h
#include
The problem has been solved with your help. Thank you very much.
On 2014年5月11日 格林尼治标准时间+0800下午3时43分41秒, FrankLike via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Sunday, 11 May 2014 at 06:35:26 UTC, IceNature via
Digitalmars-d-learn wrote:
Thank you for your help. But if I
On Sunday, 11 May 2014 at 07:43:07 UTC, Kagamin wrote:
Known bug https://issues.dlang.org/show_bug.cgi?id=2742
It's not bug. Write-functions are designed to output text to
stdout, and it's issue of programmer to make sure that expected
acceptor can interpret them properly. Note that stdout
On Saturday, 10 May 2014 at 20:24:50 UTC, MarisaLovesUsAll wrote:
Hi!
I sometimes got a useless messages in stdout from SDL_Image
library, and I want to temporary silence it. How do I do?
Are you sure it's stdout, not stderr? For the latter, you would
need to redirect FD 2, not FD 1:
On Sunday, 11 May 2014 at 08:48:43 UTC, FreeSlave wrote:
On Sunday, 11 May 2014 at 07:43:07 UTC, Kagamin wrote:
Known bug https://issues.dlang.org/show_bug.cgi?id=2742
It's not bug. Write-functions are designed to output text to
stdout, and it's issue of programmer to make sure that expected
On Friday, 9 May 2014 at 21:37:37 UTC, Vlad Levenfeld wrote:
Error: non-shared const method is not callable using a shared
mutable object
Why not? If the method is const, it can't modify the object
anyway.
Because thread-safety isn't only a problem when writing to
memory, reads must also
On Friday, 9 May 2014 at 21:58:41 UTC, Steven Schveighoffer wrote:
On Fri, 09 May 2014 17:45:37 -0400, Vlad Levenfeld
vlevenf...@gmail.com wrote:
Is there any way to declare a method as safe regardless of
shared/mutability/etc (or some other way to avoid
cast(Type)object.property every time
I have searched and can not understand something about passing
AAs to a function.
I have reduced the gist of the question to a tiny program below.
If I put ref in the function stmt it works, i.e.:
ref int[int] aa
My confusion is that AAs are supposed to be passed as refs
anyway, so I
On Sunday, 11 May 2014 at 14:46:35 UTC, rbutler wrote:
I have searched and can not understand something about passing
AAs to a function.
I have reduced the gist of the question to a tiny program below.
If I put ref in the function stmt it works, i.e.:
ref int[int] aa
My confusion is
On Sunday, 11 May 2014 at 15:22:29 UTC, John Colvin wrote:
On Sunday, 11 May 2014 at 14:46:35 UTC, rbutler wrote:
I have searched and can not understand something about passing
AAs to a function.
I have reduced the gist of the question to a tiny program
below.
If I put ref in the function
On 5/10/2014 9:02 AM, Jack wrote:
First off a rant:
I use the Code::Blocks IDE and at times it has been proven to a
double-edged source because of various issueslike this one:
http://forum.dlang.org/thread/ndeyzrifseipuebvy...@forum.dlang.org)
and am now itching to search for other IDEs to
On 05/11/2014 07:46 AM, rbutler wrote:
I have searched and can not understand something about passing AAs to a
function.
I have reduced the gist of the question to a tiny program below.
If I put ref in the function stmt it works, i.e.:
ref int[int] aa
My confusion is that AAs are
On Sunday, 11 May 2014 at 16:54:18 UTC, Ali Çehreli wrote:
On 05/11/2014 07:46 AM, rbutler wrote:
I have searched and can not understand something about
passing AAs to a
function.
I have reduced the gist of the question to a tiny program
below.
If I put ref in the function stmt it works,
On 05/11/2014 10:00 AM, John Colvin wrote:
On Sunday, 11 May 2014 at 16:54:18 UTC, Ali Çehreli wrote:
On 05/11/2014 07:46 AM, rbutler wrote:
I have searched and can not understand something about
passing AAs to a
function.
I have reduced the gist of the question to a tiny program
Thanks, I also found that I need to include the flag
-I/usr/include/dmd/phobos to get it to compile. I tried doing:
export PATH=$PATH:/usr/include/dmd/phobos
but apparently I still need the -I flag. Is there another way
to get around this?
Does your /etc directory contain dmd.conf file?
On 10.05.2014 10:42, FrankLike wrote:
I've been using VisualD for a long time without problems. If it makes
you nervous, you can get the source from Github and compile it yourself.
Hello,Meta
When I compile the Visual D projects:
at first,I compile the 'build' project,then get some
El 11/05/14 07:34, Moses via Digitalmars-d-learn ha escrit:
On Sunday, 11 May 2014 at 04:33:24 UTC, Ali Çehreli wrote:
On 05/10/2014 07:12 PM, Moses wrote:
After using the 1-click Ubuntu installer, I'm having trouble figuring
out how to import standard library functions for Phobos. I get the
On Sun, 11 May 2014 17:00:13 +
Remind me again why we can't just change this to a sensible
initial state? Or at least add a .initialize()?
All reference types have a null init value. Arrays and classes have the exact
same issue as AAs. Anything else would require not only allocating memory
On Sunday, 11 May 2014 at 14:46:35 UTC, rbutler wrote:
I have searched and can not understand something about passing
AAs to a function.
I have reduced the gist of the question to a tiny program below.
If I put ref in the function stmt it works, i.e.:
ref int[int] aa
My confusion is
On Sunday, 11 May 2014 at 16:17:20 UTC, Nick Sabalausky wrote:
Sorry, I haven't really used the curl stuff yet, so I can't be
a bigger help, but a couple notes below:
It's alright. I'm actually up for any information right now.
Access Violation, despite its wording, isn't usually about
There are some quotes missing when building the Debug
configuration. I have committed a fix and also added the
missing file reported in your other message (IIRC it is not
needed by every VS SDK).
Thank you,I'll try it.
Frank
https://issues.dlang.org/show_bug.cgi?id=12731
Issue ID: 12731
Summary: Infinite range slices are not themselves sliceable
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
https://issues.dlang.org/show_bug.cgi?id=12731
--- Comment #1 from monarchdo...@gmail.com ---
https://github.com/D-Programming-Language/phobos/pull/2158
--
https://issues.dlang.org/show_bug.cgi?id=12732
Issue ID: 12732
Summary: Add an Appender-like template that recursively builds
a structure of Appender fields
Product: D
Version: D2
Hardware: All
OS: All
https://issues.dlang.org/show_bug.cgi?id=12732
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
Oops, I failed to properly test that implementation. Lemme fix that up real
soon.
--
https://issues.dlang.org/show_bug.cgi?id=12732
--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
And because of string mixins the mixin() won't work if the type is from another
module which isn't imported. Well maybe we can implement this without string
mixins somehow.
--
https://issues.dlang.org/show_bug.cgi?id=12732
--- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
There we go:
-
import std.array;
import std.string;
import std.typetuple;
alias ApplyAppender(T : E[], E) = Appender!T;
alias ApplyAppender(T) = T;
enum Identifier(alias S) =
https://issues.dlang.org/show_bug.cgi?id=9641
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #1 from
https://issues.dlang.org/show_bug.cgi?id=12733
Issue ID: 12733
Summary: parallelism.amap incorrect assignment without
initialization
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=12724
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment
https://issues.dlang.org/show_bug.cgi?id=12724
--- Comment #5 from bearophile_h...@eml.cc ---
(In reply to Andrej Mitrovic from comment #3)
Yeah it seems like an arbitrary limitation since invariants allow return
statements.
That limitation is very far from being arbitrary.
--
https://issues.dlang.org/show_bug.cgi?id=8758
bearophile_h...@eml.cc changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 110 matches
Mail list logo
