On Thursday, 22 June 2017 at 05:57:59 UTC, bauss wrote:
On Wednesday, 21 June 2017 at 15:55:27 UTC, David Nadlinger
wrote:
On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer
wrote:
Fresh install of GDC. (tried with 32x ad 32_64x)
Where did you get the GDC executable from? The GDC proje
On Wednesday, 21 June 2017 at 15:55:27 UTC, David Nadlinger wrote:
On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote:
Fresh install of GDC. (tried with 32x ad 32_64x)
Where did you get the GDC executable from? The GDC project
doesn't currently offer any official builds that targ
On 06/21/2017 09:39 PM, timvol wrote:
size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 1 )
{
return 10; // More complex calculated value
}
size_t calcLength(ubyte ubFuncCode)() if ( ubFuncCode == 2 )
{
return 20; // More complex calculated value
On Wednesday, 21 June 2017 at 19:39:14 UTC, timvol wrote:
Hi! I've a simple array of bytes I received using sockets. What
I want to do is to calculate the target length of the message.
So, I defined a calcLength() function for each function code
(it's the first byte in my array). My problem is
On 06/21/2017 12:20 PM, uncorroded wrote:
> So @trusted is me guaranteeing to the compiler that this
> function is safe?
Yes and you shouldn't lie. :)
> Is there any way of auditing this code through
> valgrind, etc.
That's a good idea, which you can do yourself but I don't think you can
be s
On Wednesday, 21 June 2017 at 17:11:41 UTC, TheGag96 wrote:
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it
sees something that *might* be a pointer, it assumes it *is* a
pointer and thus had better not get freed.
S
Hi! I've a simple array of bytes I received using sockets. What I
want to do is to calculate the target length of the message. So,
I defined a calcLength() function for each function code (it's
the first byte in my array). My problem is that I defined the
calcLength() function using conditions
On 06/21/2017 07:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:
Being a systems programming language means you should be able to do
things outside the type system (in @system code, of course, not in @safe
code), including storing pointers as int values. Any C code that your D
program interoper
On Wednesday, 21 June 2017 at 19:11:44 UTC, Ali Çehreli wrote:
On 06/21/2017 12:06 PM, uncorroded wrote:
> Is
> there any way of making the function with @safe as well? I
get the
> errors "cannot call @system function
'core.stdc.stdio.fread,fopen,fclose'.
@trusted is exactly for that. It can be
On 06/21/2017 12:06 PM, uncorroded wrote:
> Is
> there any way of making the function with @safe as well? I get the
> errors "cannot call @system function
'core.stdc.stdio.fread,fopen,fclose'.
@trusted is exactly for that. It can be called from @safe code:
@trusted @nogc ubyte[n] rand_bytes(u
On Wednesday, 21 June 2017 at 18:58:58 UTC, tetyys wrote:
On Wednesday, 21 June 2017 at 18:49:01 UTC, uncorroded wrote:
Is there a way of making this work with D slices? Can they be
used as C-style pointers?
What about this:
@nogc ubyte[n] rand_bytes(uint n)() {
import core.stdc.stdio;
On Wednesday, 21 June 2017 at 18:58:58 UTC, tetyys wrote:
On Wednesday, 21 June 2017 at 18:49:01 UTC, uncorroded wrote:
Is there a way of making this work with D slices? Can they be
used as C-style pointers?
What about this
Or simpler,
while (left)
left -= fread(buf[n-left .. $].ptr, u
- Fixed-length arrays are value types. You may not want to return them
if n is very large.
- Every array has the .ptr property that gives the pointer to the first
element.
- What can be helpful to you here is the fact that you can treat any
memory as a slice:
import core.stdc.stdlib;
stru
On Wednesday, 21 June 2017 at 18:49:01 UTC, uncorroded wrote:
Is there a way of making this work with D slices? Can they be
used as C-style pointers?
What about this:
@nogc ubyte[n] rand_bytes(uint n)() {
import core.stdc.stdio;
FILE *fp;
fp = fopen("/dev/urandom", "r");
ubyte[
Hi all,
I am writing a program to read device /dev/urandom file to get
some random bytes. I am trying to bypass D's GC as I know the
length of the buffer needed. I tried using std.stdio.File and
rawRead but File cannot be used with @nogc. So I used
core.stdc.stdio and used traditional C style
On Wed, Jun 21, 2017 at 05:11:41PM +, TheGag96 via Digitalmars-d-learn
wrote:
> On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
> > This comes from the fact that D's GC is conservative - if it sees
> > something that *might* be a pointer, it assumes it *is* a pointer
> > and t
On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
This comes from the fact that D's GC is conservative - if it
sees something that *might* be a pointer, it assumes it *is* a
pointer and thus had better not get freed.
So is the GC then simply made to be "better-safe-than-sorry" o
On 2017-06-21 17:51, David Nadlinger wrote:
This is not relevant for cross-compilation, as long as you have the
libraries available. You can actually link a D Windows x64/MSVCRT
executable from Linux today if you copy over the necessary libraries.
The question is just how we can make this as eas
On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote:
Fresh install of GDC. (tried with 32x ad 32_64x)
Where did you get the GDC executable from? The GDC project
doesn't currently offer any official builds that target Windows;
the 6.3.0 builds from https://gdcproject.org/downloads
On Wednesday, 21 June 2017 at 06:58:43 UTC, Jacob Carlborg wrote:
Musl (or similar) should be available as an alternative. That
will make it easier to cross-compile as well.
This is not relevant for cross-compilation, as long as you have
the libraries available. You can actually link a D Windo
On Wednesday, 21 June 2017 at 15:34:15 UTC, TheGag96 wrote:
Could it ever be fixed?
Easiest: stick `-m64` in your build. While it is somewhat common
in 32 bit, it is very rare in 64 bit.
This comes from the fact that D's GC is conservative - if it sees
something that *might* be a pointer, i
I saw this Tip of the Week a while ago
(http://arsdnet.net/this-week-in-d/2017-mar-12.html) and was kind
of perplexed at it. It seems like a crazy potential bug... How
exactly is the GC implemented that causes this problem to crop
up? Does the GC just blindly scan memory until it finds pointers
On Saturday, 17 June 2017 at 00:37:18 UTC, Jolly James wrote:
Unfortunately, the public DUB package requires to be linked
with the libs from pkgBASE/lib. What do I have to add to
pkgBASE's dub.json?
Side-note: the lib/ should not be moved for portability
reasons if this is possible
My ba
On Wednesday, 21 June 2017 at 13:07:31 UTC, Jolly James wrote:
*push*
Have you asked on the Dub forum?
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
*push*
On Monday, 19 June 2017 at 23:11:29 UTC, Joel wrote:
On Sunday, 18 June 2017 at 09:48:31 UTC, Ivan Kazmenko wrote:
On Sunday, 18 June 2017 at 07:41:27 UTC, Joel wrote:
I got the file here: http://ftp.digitalmars.com/bup.zip
It works on other computers.
I was trying to update to the latest DAl
On 2017-06-20 21:59, David Nadlinger wrote:
For Windows, we use the MS C runtime, though, and the legal situation
around redistribution seems a bit unclear.
Musl (or similar) should be available as an alternative. That will make
it easier to cross-compile as well. But I guess MS C runtime is
On 2017-06-20 14:10, Steven Schveighoffer wrote:
I remember they specifically did not want to depend on anything in the C
library.
I can only tell you what I read from the source code :) . I didn't know
enough about these things back in the D1 and Tango days.
--
/Jacob Carlborg
28 matches
Mail list logo
