Re: libc dependency

2017-06-21 Thread Jacob Carlborg via Digitalmars-d-learn
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

Re: implib.exe no output files

2017-06-21 Thread Ivan Kazmenko via Digitalmars-d-learn
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

Re: Linking external *.lib files

2017-06-21 Thread bachmeier via Digitalmars-d-learn
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/

Re: Linking external *.lib files

2017-06-21 Thread Jolly James via Digitalmars-d-learn
*push*

Re: Using array slices with C-style fread() from file

2017-06-21 Thread tetyys via Digitalmars-d-learn
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,

Re: Using array slices with C-style fread() from file

2017-06-21 Thread Ali Çehreli via Digitalmars-d-learn
- 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;

Re: Using array slices with C-style fread() from file

2017-06-21 Thread uncorroded via Digitalmars-d-learn
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

Re: Dealing with the interior pointers bug

2017-06-21 Thread ag0aep6g via Digitalmars-d-learn
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

Re: Using array slices with C-style fread() from file

2017-06-21 Thread tetyys via Digitalmars-d-learn
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");

Re: Using array slices with C-style fread() from file

2017-06-21 Thread uncorroded via Digitalmars-d-learn
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;

Read conditional function parameters during compile time using __traits

2017-06-21 Thread timvol via Digitalmars-d-learn
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

Re: Dealing with the interior pointers bug

2017-06-21 Thread Cym13 via Digitalmars-d-learn
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.

Re: Dealing with the interior pointers bug

2017-06-21 Thread H. S. Teoh via Digitalmars-d-learn
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

Using array slices with C-style fread() from file

2017-06-21 Thread uncorroded via Digitalmars-d-learn
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

Re: Using array slices with C-style fread() from file

2017-06-21 Thread Ali Çehreli via Digitalmars-d-learn
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]

Re: Read conditional function parameters during compile time using __traits

2017-06-21 Thread Eugene Wissner via Digitalmars-d-learn
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

Re: Using array slices with C-style fread() from file

2017-06-21 Thread Ali Çehreli via Digitalmars-d-learn
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

Re: GDC generate wrong .exe ("not a valid win32 application")

2017-06-21 Thread David Nadlinger via Digitalmars-d-learn
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

Dealing with the interior pointers bug

2017-06-21 Thread TheGag96 via Digitalmars-d-learn
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

Re: libc dependency

2017-06-21 Thread David Nadlinger via Digitalmars-d-learn
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

Re: Linking external *.lib files

2017-06-21 Thread Mike Parker via Digitalmars-d-learn
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

Re: Dealing with the interior pointers bug

2017-06-21 Thread TheGag96 via Digitalmars-d-learn
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"

Re: libc dependency

2017-06-21 Thread Jacob Carlborg via Digitalmars-d-learn
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