On Thu, Jan 14, 2021 at 12:36:12PM +, claptrap via Digitalmars-d-learn
wrote:
[...]
> I think you also have to consider that the GC you get with D is not
> state of the art, and if the opinions expressed on the newsgroup are
> accurate, it's not likely to get any better. So while you can find
On Friday, 15 January 2021 at 07:16:21 UTC, Daniel Kozak wrote:
On Fri, Jan 15, 2021 at 8:00 AM dog2002 via Digitalmars-d-learn
< digitalmars-d-learn@puremagic.com> wrote:
On Friday, 15 January 2021 at 06:33:55 UTC, Paul Backus wrote:
> On Friday, 15 January 2021 at 06:31:18 UTC, Paul Backus
On Fri, Jan 15, 2021 at 8:20 AM dog2002 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Friday, 15 January 2021 at 06:56:36 UTC, dog2002 wrote:
> > On Friday, 15 January 2021 at 06:33:55 UTC, Paul Backus wrote:
> >> On Friday, 15 January 2021 at 06:31:18 UTC, Paul Backus
On Friday, 15 January 2021 at 06:56:36 UTC, dog2002 wrote:
On Friday, 15 January 2021 at 06:33:55 UTC, Paul Backus wrote:
On Friday, 15 January 2021 at 06:31:18 UTC, Paul Backus wrote:
You can save a little bit of memory here by allocating
tempBuffer on the stack:
ubyte[512]
On Fri, Jan 15, 2021 at 8:00 AM dog2002 via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Friday, 15 January 2021 at 06:33:55 UTC, Paul Backus wrote:
> > On Friday, 15 January 2021 at 06:31:18 UTC, Paul Backus wrote:
> >>
> >> You can save a little bit of memory here by
On Friday, 15 January 2021 at 06:33:55 UTC, Paul Backus wrote:
On Friday, 15 January 2021 at 06:31:18 UTC, Paul Backus wrote:
You can save a little bit of memory here by allocating
tempBuffer on the stack:
ubyte[512] tempBuffer;
_inputFile.rawRead(tempBuffer[]); // note the explicit
On Friday, 15 January 2021 at 06:31:18 UTC, Paul Backus wrote:
You can save a little bit of memory here by allocating
tempBuffer on the stack:
ubyte[512] tempBuffer;
_inputFile.rawRead(tempBuffer[]); // note the explicit []
I made a mistake; this should be:
ubyte[512]
On Friday, 15 January 2021 at 06:15:06 UTC, dog2002 wrote:
void func(string inputFile, string outFile, uint chunk_size) {
try {
File _inputFile = File(inputFile, "r");
File _outputFile = File(outFile, "w");
ubyte[]
On Thursday, 14 January 2021 at 22:28:19 UTC, Paul Backus wrote:
On Thursday, 14 January 2021 at 20:23:37 UTC, dog2002 wrote:
About 1000 large files.
I want to replace several first bytes in all the files, so I
just copy the remaining bytes into a new file. Might this be
the reason for high
On Thursday, 14 January 2021 at 20:35:49 UTC, Dennis wrote:
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
If it's not a bother, I'd like to know how you usually
approach it
Usually I don't deal with null because my functions get
primitive types, slices, or structs. `ref`
On Thursday, 14 January 2021 at 20:23:08 UTC, Steven
Schveighoffer wrote:
You could kinda automate it like:
struct NullCheck(T)
{
private T* _val;
auto opDispatch(string mem)() if (__traits(hasMember, T,
mem)) {
alias Ret = typeof(() { return __traits(getMember,
*_val, mem);
On Thursday, 14 January 2021 at 20:23:37 UTC, dog2002 wrote:
About 1000 large files.
I want to replace several first bytes in all the files, so I
just copy the remaining bytes into a new file. Might this be
the reason for high memory consumption? If so, is there a way
not to copy the entire
On Thursday, 14 January 2021 at 21:49:41 UTC, Christian Köstlin
wrote:
...
Did you have a look at https://code.dlang.org/packages/optional?
Especially
https://aliak00.github.io/optional/optional/oc/oc.html might go
in the right direction.
Kind regards,
Christian
Thats nice!!!
I was
On Thursday, 14 January 2021 at 19:24:54 UTC, Adam D. Ruppe wrote:
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
This is only an open question to know what code patterns you
usually use to solve this situation in D:
I'm almost never in this situation except for reading things
On 12.01.21 22:37, Jack wrote:
I was looking for a way to avoid null checks everywhere. I was checking
the Null object pattern, or use something like enforce pattern, or even
if I could make a new operator and implement something like C#'s .?
operator, that Java was going to have one but they
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
If it's not a bother, I'd like to know how you usually approach
it
Usually I don't deal with null because my functions get primitive
types, slices, or structs. `ref` parameters can be used to
replace pointers that may not be null.
On Thursday, 14 January 2021 at 15:18:28 UTC, ddcovery wrote:
I understand perfectly the D community people that needs to
work without GC: **it is not snobbish**: it is a real need.
But not only a "need"... sometimes it is basically the way a
team wants to work: explicit memory
On Thursday, 14 January 2021 at 16:47:45 UTC, drug wrote:
On 1/14/21 7:06 PM, dog2002 wrote:
On Thursday, 14 January 2021 at 16:01:43 UTC, drug wrote:
On 1/14/21 6:55 PM, drug wrote:
But this method consumes a huge amount of memory (up to
4 GB and more). Is there a more appropriate way to
On 1/14/21 1:24 PM, ddcovery wrote:
I know there is other threads about null safety and the "possible" ways
to support this in D and so on.
This is only an open question to know what code patterns you usually use
to solve this situation in D:
if(person.father.father.name == "Peter")
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
I know there is other threads about null safety and the
"possible" ways to support this in D and so on.
This is only an open question to know what code patterns you
usually use to solve this situation in D:
On Thursday, 14 January 2021 at 18:24:44 UTC, ddcovery wrote:
This is only an open question to know what code patterns you
usually use to solve this situation in D:
I'm almost never in this situation except for reading things like
xml or json data that may be missing.
So I just special
On Thursday, 14 January 2021 at 18:10:43 UTC, mw wrote:
Python's `del` isn't guaranteed to free the memory, that's what
Fair point, but I was thinking of the C interop interface. You
can create your own wrapper (e.g. numpy) and do manual memory
management, but it isn't something people want
On Tuesday, 12 January 2021 at 11:28:12 UTC, ludo wrote:
Ok, I agree that ends up being a kind of strange singleton. But
yes it was D v1 code. Do we agree that the following
multi-threaded singleton pattern is the proper way as of today.
It looks fine to me. The D wiki has the following
I know there is other threads about null safety and the
"possible" ways to support this in D and so on.
This is only an open question to know what code patterns you
usually use to solve this situation in D:
if(person.father.father.name == "Peter") doSomething();
if(person.father.age > 80
On Thursday, 14 January 2021 at 09:26:06 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 14 January 2021 at 00:37:29 UTC, mw wrote:
ok, what I really mean is:
... in other "(more popular) languages (than D, and directly
supported by the language & std library only)" ...
Well, even Python
On 1/14/21 7:06 PM, dog2002 wrote:
On Thursday, 14 January 2021 at 16:01:43 UTC, drug wrote:
On 1/14/21 6:55 PM, drug wrote:
But this method consumes a huge amount of memory (up to 4 GB and
more). Is there a more appropriate way to walk directories
recursively that does not consume a lot of
On 1/14/21 7:30 PM, dog2002 wrote:
On Thursday, 14 January 2021 at 16:18:28 UTC, drug wrote:
On 1/14/21 7:06 PM, dog2002 wrote:
On Thursday, 14 January 2021 at 16:01:43 UTC, drug wrote:
[...]
Yes. I forgot to add it in the original post.
Does using `ref` changed anything?
Try following:
On Thursday, 14 January 2021 at 16:18:28 UTC, drug wrote:
On 1/14/21 7:06 PM, dog2002 wrote:
On Thursday, 14 January 2021 at 16:01:43 UTC, drug wrote:
[...]
Yes. I forgot to add it in the original post.
Does using `ref` changed anything?
Try following:
```
import std;
void
On 1/14/21 7:06 PM, dog2002 wrote:
On Thursday, 14 January 2021 at 16:01:43 UTC, drug wrote:
On 1/14/21 6:55 PM, drug wrote:
But this method consumes a huge amount of memory (up to 4 GB and
more). Is there a more appropriate way to walk directories
recursively that does not consume a lot of
On Thursday, 14 January 2021 at 16:01:43 UTC, drug wrote:
On 1/14/21 6:55 PM, drug wrote:
But this method consumes a huge amount of memory (up to 4 GB
and more). Is there a more appropriate way to walk
directories recursively that does not consume a lot of memory?
DirEntry is a struct.
On 1/14/21 6:55 PM, drug wrote:
But this method consumes a huge amount of memory (up to 4 GB and
more). Is there a more appropriate way to walk directories recursively
that does not consume a lot of memory?
DirEntry is a struct. First of all I would try this:
```D
foreach(ref entry;
On 1/14/21 6:46 PM, dog2002 wrote:
I need to make some operations with all the files in a directory and
subdirectories. Currently, I do it like this:
import std;
void DirIteration(string path) {
try {
foreach(entry; dirEntries(path, SpanMode.shallow, false)) {
I need to make some operations with all the files in a directory
and subdirectories. Currently, I do it like this:
import std;
void DirIteration(string path) {
try {
foreach(entry; dirEntries(path, SpanMode.shallow, false))
{ //SpanMode.shallow allows skip directories if any error
On Thursday, 14 January 2021 at 15:20:54 UTC, Jack wrote:
On Thursday, 14 January 2021 at 09:13:27 UTC, evilrat wrote:
On Thursday, 14 January 2021 at 05:44:43 UTC, Jack wrote:
On Wednesday, 13 January 2021 at 17:21:23 UTC, Paul Backus
wrote:
Member functions (including static ones) can't be
On Thursday, 14 January 2021 at 09:13:27 UTC, evilrat wrote:
On Thursday, 14 January 2021 at 05:44:43 UTC, Jack wrote:
On Wednesday, 13 January 2021 at 17:21:23 UTC, Paul Backus
wrote:
Member functions (including static ones) can't be called with
UFCS.
is this documented somewhere? Is
On Thursday, 14 January 2021 at 10:28:13 UTC, Basile B. wrote:
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
Semi serious answer:
In the domain
On Thursday, 14 January 2021 at 14:28:43 UTC, Виталий Фадеев
wrote:
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
How write quickly without GC ?
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
I like GC.
How write quickly without GC ?
On Thursday, 14 January 2021 at 13:05:31 UTC, sighoya wrote:
But this is already the case for C++ and Rust. Remembering the
days back developing in C++ there were a huge amount of memory
deallocation side effects because opencv's memory management
differs from qt's memory management.
The
On Thursday, 14 January 2021 at 13:16:16 UTC, Ola Fosheim Grøstad
wrote:
1. Use "shared" to prevent GC allocated memory from entering
other threads and switch to thread local GC. Then use ARC for
shared.
2. Redefine language semantics/type system for a different GC
model. This will break
On Thursday, 14 January 2021 at 13:10:14 UTC, sighoya wrote:
On Thursday, 14 January 2021 at 13:08:06 UTC, Ola Fosheim
Grøstad wrote:
Because Java has a well defined virtual machine with lots of
restrictions.
So you're insisting this isn't possible in D?
It isn't possible in a meaningful
On Thursday, 14 January 2021 at 13:08:06 UTC, Ola Fosheim Grøstad
wrote:
Because Java has a well defined virtual machine with lots of
restrictions.
So you're insisting this isn't possible in D?
On Thursday, 14 January 2021 at 11:11:58 UTC, Ola Fosheim Grøstad
wrote:
I know your response is *tongue in cheek*, but I actually find
it easier to use c++11 style memory management across the board
than mixing two models.
But this is already the case for C++ and Rust. Remembering the
On Thursday, 14 January 2021 at 13:01:04 UTC, sighoya wrote:
Why not offering more than one just as it is the case in Java?
The advantage hereby is to adapt the GC algorithm after the
program was compiled, so you can reuse the same program with
different GC algorithms.
Because Java has a
As other people already mentioned, garbage collection incurs some
amount of non-determinism and people working in low level areas
prefer to handle things deterministically because they think
non-deterministic handling of memory makes your code slow.
For example rendering in gaming gets paused
On Wednesday, 13 January 2021 at 20:06:51 UTC, H. S. Teoh wrote:
On Wed, Jan 13, 2021 at 06:58:56PM +, Marcone via
Digitalmars-d-learn wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
It's not merely
On Thursday, 14 January 2021 at 10:28:13 UTC, Basile B. wrote:
Semi serious answer:
In the domain of hoby-ism and small companies programmers that
work with statically typed languages all believe that they are
super hero in the domain of memory managment. When they see
"GC" they think that
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
Semi serious answer:
In the domain of hoby-ism and small companies programmers that
work with
On Thursday, 14 January 2021 at 10:05:51 UTC, Guillaume Piolat
wrote:
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
Languages where the GC usage
On Wednesday, 13 January 2021 at 18:58:56 UTC, Marcone wrote:
I've always heard programmers complain about Garbage Collector
GC. But I never understood why they complain. What's bad about
GC?
Languages where the GC usage is unavoidable (Javascript and Java)
have created a lot of situations
On Thursday, 14 January 2021 at 00:37:29 UTC, mw wrote:
ok, what I really mean is:
... in other "(more popular) languages (than D, and directly
supported by the language & std library only)" ...
Well, even Python supports both, if you want to, so... I suppose
you mean system level
On Thursday, 14 January 2021 at 05:44:43 UTC, Jack wrote:
On Wednesday, 13 January 2021 at 17:21:23 UTC, Paul Backus
wrote:
Member functions (including static ones) can't be called with
UFCS.
is this documented somewhere? Is this going to change?
It will stay as is.
It is somewhat
52 matches
Mail list logo
