gmane.comp.lang.d.learn

Re: Multi-library project path issue

#coder — 2012-05-26T02:43:04

Thanks for the quick and helpful reply. I will give it a shot.



On Friday, 25 May 2012 at 06:36:07 UTC, Jacob Carlborg wrote:

Re: druntime investigation troubles

Sean Kelly — 2012-05-26T02:27:27


Not really. I wanted initialization to be the same either way, but unittests seem optional.

Re: druntime investigation troubles

Sean Kelly — 2012-05-26T02:26:21


None that I can think of. I bet it's just really old code.

Re: Translating C const

Jonathan M Davis — 2012-05-25T23:17:19

Well, the reason that it's not an issue at all with function parameters where 
it's the pointer which is const is that the const portion is being copied. 
With a struct being passed to a function as an argument, anything which is 
directly const in the struct doesn't have to stay const when passed (it's just 
the indirect stuff which would be - pointers and references - though having a 
reference as a member variable is a bit evil). However, if that same struct 
can be passed around via a pointer, then those member variables would have to 
be const.

I'm not sure that it's possible to generically constify C structs for D 
correctly. If you just use D's const on const member variables, then you won't 
be able to mutate what's pointed to by pointers which were const but pointed 
to mutable data in the C definition. In many cases, that wouldn't be an issue 
at all, but depending on what you needed to do in D, it would be. On the other 
hand, if you just didn't use const at all, then you _could_ mutate what nee

Re: Simplified socket creation and handling

Donald Duvall — 2012-05-25T20:55:11

Sorry for the typo: I do NOT understand it completely.

Re: Simplified socket creation and handling

Donald Duvall — 2012-05-25T20:50:25

Would it be possible for someone to write some documentation on 
this socket server and make it windows compatible?

I am just learning D and coming from C# sockets this is much 
different and I understand it completely. I would much appreciate 
any help with understanding sockets in D and any pointers in the 
right direction.

Re: Why doesn't this throw?

Steven Schveighoffer — 2012-05-25T14:53:15

On Fri, 25 May 2012 08:59:47 -0400, Andrej Mitrovic  
<andrej.mitrovich< at >gmail.com> wrote:


Because remove has a bug.

-Steve

Re: druntime investigation troubles

Steven Schveighoffer — 2012-05-25T14:31:52

On Thu, 24 May 2012 16:40:46 -0400, Sean Kelly <sean< at >invisibleduck.org>  
wrote:


oh.  That's.... horrible.

Yeah, we should eliminate this ASAP.  Is there any reason it has to be  
done before C's main?

-Steve

Why doesn't this throw?

Andrej Mitrovic — 2012-05-25T12:59:47

import std.algorithm;
import std.stdio;

void main()
{
    int[] a = [1, 2, 3];
    a = a.remove(3);
    writeln(a);
}

writes [1, 2]

If I'd called a.remove with index 2 I would get the above result, but
index 3 is clearly out of bounds, so why'd it remove the last element
instead of throwing?

Re: state of web programming

Dejan Lekic — 2012-05-25T11:06:28

web-stuff

http://vibed.org

Re: Reading ASCII file with some codes above 127 (exten ascii)

Regan Heath — 2012-05-25T09:05:29

The only thing which would worry me about this code is the cast(char[]) in  
the final writeln.. I know some parts of phobos verify the char data is  
correct UTF-8 and this line casts latin-1 to char[] which can potentially  
create invalid UTF-8 data.  That said, I had a really quick look at the  
phobos code for File.writeln and I'm not sure whether this function does  
any UTF-8 validation.  I would be happier if the latin-1 was written as a  
stream of bytes with no assumed interpretation, IMO.

R

Re: Multi-library project path issue

Jacob Carlborg — 2012-05-25T06:36:06

It depends on what naming scheme you want to have on your modules. I 
think you should go with "Lib1.TestFile1". Actually I would go with 
lower case package names, i.e. "lib1.TestFile1". In that case you need 
to add a flag to DMD to indicate the import search path. This search 
path should point to the parent folder of the root package(s), in this 
case the parent folder of "Lib1", i.e. AppFolder.

AppFolder
   |- main.d
   |- Lib1
      |- TestFile1.d
      |- TestFile2.d
   |- Lib2
      |- TestFile3.d
         |- Lib3
            |- TestFile4.d

$ dmd AppFolder/main.d -I./AppFolder

The module and import declarations of the TestFiles should look like this:

module Lib1.TestFile1;

import Lib1.TestFile2;
import Lib2.TestFile3;
import Lib2.Lib3.TestFile4;

For Mono-D you need to be able to specify the same search path. I have 
no idea how to do that in Mono-D.

Re: druntime investigation troubles

Jacob Carlborg — 2012-05-25T06:25:15


Yeah, I've noticed that. Does the unit test really need to run when you 
call rt_init from C?

Multi-library project path issue

#coder — 2012-05-25T06:15:30

Hi,

I am using the Mono-D for building a project with 3-4 library 
projects and one console project. Although I am using the Mono-D 
but I think this issue is not unique to Mono-D. Please advise me 
with a solution, if I am missing something obvious here.

Issue;

I have two "library" project with something similar to following:

AppFolder  (AppFolder contains the below two folders for 
individual project)

Lib1
  |
  ------ TestFile1.d
  |
  ------ TestFile2.d (import TestFile1;) // TestFile2 is importing 
TestFile1 in same library project.


Lib2  (Lib2 has linker path to "lib1.a" and include path to 
"AppFolder")
|
------ TestFile3.d (import Lib1.TestFile2).


If I compile the Lib1 folder alone then it will work fine but now 
if I compile the Lib2 folder then the error will be in 
"TestFile2.d" of Lib1 project that "TestFile1" is not found. If I 
change the "Import" in TestFile2 to

import Lib1.TestFile1;

Then the compilation of Lib2 starts to work. Now, if I try to 
compile the Lib1 project alone in Mo

Re: null matches typed pointers before void pointers

bearophile — 2012-05-24T22:01:31

http://d.puremagic.com/issues/show_bug.cgi?id=8146

Re: druntime investigation troubles

Sean Kelly — 2012-05-24T20:40:46


It's not STI_monitor specifically. STI_anything is a module ctor and STD_anything is a module dtor. Or at least that's my recollection. There are a few places in the DMC runtime that have initializers like this. I think one is somewhere in the floating-point support code.

Re: druntime investigation troubles

Steven Schveighoffer — 2012-05-24T20:27:40

On Thu, 24 May 2012 15:44:28 -0400, Sean Kelly <sean< at >invisibleduck.org>  
wrote:


Yeah, I do too.  I did a full text search for STI_monitor and found  
nothing.

That's why I'm confused...

-Steve

Re: druntime investigation troubles

Sean Kelly — 2012-05-24T19:49:37


There's a difference in how unittest execution is handled.  This could probably be sorted out though.

Re: std.concurrency.send

Sean Kelly — 2012-05-24T19:38:10


Maybe use register().



I'll admit that send() has only spotty support for shared.  This should be fixed.

Re: druntime investigation troubles

Sean Kelly — 2012-05-24T19:44:28


This code is before my time, but I believe that DMC implicitly treats STI functions as module ctors, and DMD inherits this behavior because it shares a C runtime with DMC.  It's been a while since I've looked at all of this, but the full C runtime source is shipped with DMC--I have a copy.

Re: Reading ASCII file with some codes above 127 (exten ascii)

era scarecrow — 2012-05-24T19:47:05

  My solution may have a flaw in it's lookup table; namely if I 
got one of the codes wrong. I used regex and a site to reference 
them all so I Hope it's right. I can't remember but I think it 
was from http://www.alanwood.net/demos/ansi.html

  The main reason I wrote it was there was no good explanations in 
the documentation of anywhere of how to use std.encoding and 
transcode. This meant I was stuck and needed some simple 
solution. I'm not sure if my solution is going to be faster, but 
it does do minimal object allocation/resizing/abstraction, and 
tries not to make a new string if it doesn't have to.

  Who knows? Perhaps it will be added to phobos once the table is 
verified.