On Thursday, 1 September 2016 at 11:11:15 UTC, Cauterite wrote:
How does one test whether a symbol is deprecated? I would have
expected something like: __traits(isDeprecated, foo).
Such a trait makes it possible to write code that will break,
just because something has been marked as deprecate
Hi, I'm having some trouble getting an xml file using
std.net.curl. I'm using get() to receive device info from a roku
television using this code:
char[] inputQuery(string input) {
string url = ip ~ "query/" ~ input;
auto client = HTTP();
auto content = get(url,client);
retu
On Tuesday, 29 August 2017 at 00:52:11 UTC, Cecil Ward wrote:
I am vacillating - considering breaking a lifetime's C habits
and letting the D garbage collector make life wonderful by just
cleaning up after me and ruining my future C disciple by not
deleting stuff myself.
The tsv command line
On Tuesday, 29 August 2017 at 03:16:13 UTC, Johnson Jones wrote:
T[] arr
and is a linear sequential memory array of T's with an unbound
length and is effectively the same as T*(although D treats them
differently?)?
It is a T* AND a size variable bundled together.
We can fix the length by
On Tuesday, August 29, 2017 03:16:13 Johnson Jones via Digitalmars-d-learn
wrote:
> I need to get this straight:
>
> A normal single dimensional array in D is defined as
>
> T[] arr
>
> and is a linear sequential memory array of T's with an unbound
> length and is effectively the same as T*(althou
I need to get this straight:
A normal single dimensional array in D is defined as
T[] arr
and is a linear sequential memory array of T's with an unbound
length and is effectively the same as T*(although D treats them
differently?)?
We can fix the length by adding a upper bound:
T[N] arr;
On Tuesday, 29 August 2017 at 00:52:11 UTC, Cecil Ward wrote:
I don't know when the GC actually gets a chance to run.
Another alternative that I *think* (maybe someone who knows a bit
more about the gc can chime in?) would work is if you manually
stopped the gc then ran collections when profi
On Tuesday, 29 August 2017 at 02:47:34 UTC, Johnson Jones wrote:
[...]
Seems only long and ulong are issues.
With respect to the currently major platforms you can reasonable
expect software to run on, yes.
Just don't try to use D on something with e.g. 32 bit C shorts
unless you bind to it v
On Tuesday, 29 August 2017 at 01:56:43 UTC, Moritz Maxeiner wrote:
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
[...]
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
There are different 64bit data models [1] and it seems your
platform uses LLP64,
On 29/08/2017 2:49 AM, Cecil Ward wrote:
I have written a few zero-overhead (fully inlining) D wrappers around
certain new x64 instructions as an exercise to help me learn D and get
used to GDC asm. I've also written D replacements for older processors.
They are templated functions with customi
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
import core.stdc.config;
pragma(msg, c_long.sizeof);
prints 4UL
both on x64 and x86
and and C:
void foo()
{
int dummy;
switch (dummy) {
case sizeof(long) :
case sizeof(long) :
bre
On Tuesday, 29 August 2017 at 01:34:40 UTC, Johnson Jones wrote:
[...]
produces 4 on both x86 and x64. So, I'm not sure how you are
getting 8.
There are different 64bit data models [1] and it seems your
platform uses LLP64, which uses 32bit longs. Am I correct in
assuming you're on Windows
I have written a few zero-overhead (fully inlining) D wrappers
around certain new x64 instructions as an exercise to help me
learn D and get used to GDC asm. I've also written D replacements
for older processors. They are templated functions with
customised variants supporting a variety of diff
On Tuesday, 29 August 2017 at 00:52:11 UTC, Cecil Ward wrote:
I am vacillating - considering breaking a lifetime's C habits
and letting the D garbage collector make life wonderful by just
cleaning up after me and ruining my future C disciple by not
deleting stuff myself.
It's not a panacea, b
On Tuesday, 29 August 2017 at 00:42:45 UTC, Steven Schveighoffer
wrote:
On 8/28/17 7:47 PM, Johnson Jones wrote:
[...]
Then I think possibly the port audio bindings are not correct.
It's also possible that long is not 64-bit even on the platform
you are using. Finally, it's also possible tha
On 08/28/2017 06:25 PM, Ali Çehreli wrote:
I don't like the current format of the page
Apparently, I was looking for this one:
https://dlang.org/blog/the-gc-series/
Ali
I don't like the current format of the page (all articles are expanded
as opposed to being an index page) but there are currently four D blog
articles on GC and memory management:
https://dlang.org/blog/category/gc/
Ali
On Tuesday, August 29, 2017 00:52:11 Cecil Ward via Digitalmars-d-learn
wrote:
> I am vacillating - considering breaking a lifetime's C habits and
> letting the D garbage collector make life wonderful by just
> cleaning up after me and ruining my future C disciple by not
> deleting stuff myself.
>
D's GC is stop the world (aka all threads) and does not run on its own
(requires being asked to collect).
It is only given the opportunity to collect when you allocate (new/more)
memory. It can decide not to, or to do so at any point making it very
unpredictable.
This is why we keep saying t
I am vacillating - considering breaking a lifetime's C habits and
letting the D garbage collector make life wonderful by just
cleaning up after me and ruining my future C disciple by not
deleting stuff myself.
I don't know when the GC actually gets a chance to run.
I am wondering if deleting
On 8/28/17 7:47 PM, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041e
On Monday, 28 August 2017 at 14:27:19 UTC, Jacob Carlborg wrote:
I'm working on some code that sanitizes and converts values of
different types to strings. I thought it would be a good idea
to wrap the sanitized string in a struct to have some type
safety. Ideally it should not be possible to c
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx, [typeid(PaStreamParameters)+
On Monday, 28 August 2017 at 22:47:12 UTC, Andre Pany wrote:
On Monday, 28 August 2017 at 22:28:18 UTC, Moritz Maxeiner
wrote:
On Monday, 28 August 2017 at 21:52:58 UTC, Andre Pany wrote:
[...]
To make my question short:) If ColumnsArray is a class I can
access the attribute "reference" but n
On Monday, 28 August 2017 at 21:29:31 UTC, Jonathan M Davis wrote:
I think that it's pretty clear that a new traits for __traits
would be required. Per the documentation, getFunctionAttributes
does not include anything about deprecation, and even if it
did, it wouldn't be sufficient anyway, b
On Monday, 28 August 2017 at 22:41:56 UTC, Moritz Maxeiner wrote:
On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven
Schveighoffer wrote:
[...]
and where are these c_ types defined? The reason I replaced
them was precisely becaus
On Monday, 28 August 2017 at 22:28:18 UTC, Moritz Maxeiner wrote:
On Monday, 28 August 2017 at 21:52:58 UTC, Andre Pany wrote:
[...]
To make my question short:) If ColumnsArray is a class I can
access the attribute "reference" but not if it is a struct. I
would rather prefer a struct, but wit
On Monday, 28 August 2017 at 22:21:18 UTC, Johnson Jones wrote:
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
[...]
For C/C++ interaction, always use c_... types if they are
available. The idea is both that they will be corre
On Monday, 28 August 2017 at 21:52:58 UTC, Andre Pany wrote:
[...]
To make my question short:) If ColumnsArray is a class I can
access the attribute "reference" but not if it is a struct. I
would rather prefer a struct, but with a struct
it seems I cannot access "reference".
How can I access
On Monday, 28 August 2017 at 21:35:27 UTC, Steven Schveighoffer
wrote:
On 8/27/17 10:17 PM, Johnson Jones wrote:
[...]
For C/C++ interaction, always use c_... types if they are
available. The idea is both that they will be correctly defined
for the width, and also it will mangle correctly fo
Hi,
I build some framework to access Delphi components from D.
Delphi supports property array access "StringGrid1.Columns[2]"
which is translated in Delphi to a private method call
"GetColumn(2)".
I need to imitate this behavior in my D code.
Therefore my TCustomGrid class has a inner struct
On Monday, 28 August 2017 at 14:27:19 UTC, Jacob Carlborg wrote:
I'm working on some code that sanitizes and converts values of
different types to strings. I thought it would be a good idea
to wrap the sanitized string in a struct to have some type
safety. Ideally it should not be possible to c
On 8/27/17 10:17 PM, Johnson Jones wrote:
Looking at the assembly shows something like this:
0041ea98 push 0x0
0041ea9a push 0x0
0041ea9c push 0x0
0041ea9e push dword 0x100
0041eaa3 mov ecx, [typeid(PaStreamParameters)+0xe36fc (0x80d4cc)]
0041eaa9 mov eax, [fs:0x2c]
0041eaaf mov edx, [eax
On Monday, August 28, 2017 13:08:04 jmh530 via Digitalmars-d-learn wrote:
> On Saturday, 26 August 2017 at 07:17:49 UTC, user1234 wrote:
> > getAttributes is made for UDAs only.
>
> Okay, well if you change it to
>
> deprecated {
> void foo();
> }
>
> void main() {
> pragma(msg, __traits(
How do I get the protection status of function in another module?
Basically I have some code that loops through all the members of
another module and I want to be able to skip the ones that are
private.
The code below prints public for foo.
module A;
private void foo();
---
On Monday, 28 August 2017 at 06:27:20 UTC, Jacob Carlborg wrote:
On 2017-08-25 23:25, Enjoys Math wrote:
Something like this:
module file_watcher;
import std.concurrency;
import std.file;
import std.signals;
import std.datetime;
void fileWatcher(Tid tid, string filename, int loopSleep) {
I'm working on some code that sanitizes and converts values of different
types to strings. I thought it would be a good idea to wrap the
sanitized string in a struct to have some type safety. Ideally it should
not be possible to create this type without going through the sanitizing
functions.
On Wednesday, 23 August 2017 at 13:06:36 UTC, Steven
Schveighoffer wrote:
On 8/23/17 5:53 AM, biocyberman wrote:
[...]
I'll respond to all your questions with what I would do,
instead of answering each one.
I would suggest an approach similar to how I approached parsing
JSON data. In your
On Saturday, 26 August 2017 at 16:52:36 UTC, Cecil Ward wrote:
I have a pure function that has constant inputs, known at
compile-time, contains no funny stuff internally - looked at
the generated code, and no RTL calls at all. But in a test call
with constant literal values (arrays initialised
On Monday, 28 August 2017 at 03:16:24 UTC, Mike Parker wrote:
On Sunday, 27 August 2017 at 17:47:54 UTC, Cecil Ward wrote:
[...]
The rules for CTFE are outlined in the docs [1]. What is
described there is all there is to it. If those criteria are
not met, the function cannot be executed at c
On Sunday, 27 August 2017 at 00:08:45 UTC, Jonathan M Davis wrote:
[...]
Indeed. I used the term CTFE too loosely.
On Saturday, 26 August 2017 at 07:17:49 UTC, user1234 wrote:
getAttributes is made for UDAs only.
Okay, well if you change it to
deprecated {
void foo();
}
void main() {
pragma(msg, __traits(getFunctionAttributes, foo));
}
then you just get
tuple(@system)
so the issue still stands
On 2017-08-28 08:31, Nemanja Boric wrote:
On Monday, 28 August 2017 at 06:27:20 UTC, Jacob Carlborg wrote:
http://code.dlang.org/packages/vibe-core
http://code.dlang.org/packages/libasync
In addition, to avoid polling, it's possible to register yourself to the
operating system so it will tell
43 matches
Mail list logo
